WEBVTT 00:00.760 --> 00:06.640 And now that we understand what reverse engineering is and why it's essential, let's shift our focus 00:06.640 --> 00:07.920 to the actual process. 00:08.360 --> 00:13.720 Like any specialized activity, reverse engineering follows a series of structured steps. 00:14.120 --> 00:20.280 These steps help us systematically extract information about software, making our analysis reliable, 00:20.280 --> 00:23.600 reusable, and helpful for developers. 00:25.400 --> 00:32.280 Now let's break this down piece by piece, starting with one of the most overlooked but important parts. 00:34.440 --> 00:39.720 In reverse engineering, we had first the seeking approval phase. 00:41.520 --> 00:47.360 Reverse engineering isn't something you just jump into, especially with proprietary software. 00:47.760 --> 00:56.800 Ethically and often, legally, you need permission from the software's owner before conducting any 00:56.800 --> 00:58.120 form of analysis. 00:58.160 --> 01:01.880 Now, that's not just about, uh, politeness. 01:01.880 --> 01:03.530 It's about legal protection. 01:03.530 --> 01:05.090 If you find a vulnerability. 01:05.250 --> 01:09.450 The best practice is to report it privately to the software vendor. 01:10.210 --> 01:17.010 That's what they say, and that gives them time to fix it before it's disclosed to public. 01:17.210 --> 01:20.410 Now reducing the risk of the flaw being exploited. 01:20.650 --> 01:21.650 And that's it. 01:22.290 --> 01:25.730 There's a very different set of rules when it comes to a malware. 01:26.850 --> 01:32.130 And if you are analyzing a malicious executable you don't need to others permission obviously. 01:32.170 --> 01:40.170 In fact, you are trying to expose that the order and the understand their creation to stop further 01:40.170 --> 01:40.730 harm. 01:40.890 --> 01:48.330 However, if there is ever uncertainty, especially in a corporate environment, consulting legal counsel 01:48.330 --> 01:50.770 is always a wise step. 01:54.450 --> 02:00.650 And then we have the static analysis phase. 02:02.490 --> 02:07.770 Now this is where we begin our analysis without ever running the program. 02:08.090 --> 02:13.170 Now, think of it like dissecting a frog without bringing it to life. 02:13.210 --> 02:18.250 Opening up the binary file, scanning each byte and reading its internals. 02:18.290 --> 02:25.170 Now, from the file structure and the metadata to embedded strings and headers, a lot can be discovered 02:25.170 --> 02:26.250 in this phase here. 02:26.610 --> 02:39.010 Like is it a xa, DLL, dynamic link library or Elf format and so on and so forth. 02:39.290 --> 02:47.650 Or we also can know what architecture is built on like x86 for computers eight. 02:49.850 --> 02:51.930 Or 64 bit. 02:53.890 --> 03:03.250 And our dear readable strings or API calls. 03:05.090 --> 03:12.220 So you are essentially Preparing your mind and toolset for what you might encounter once the programs 03:12.260 --> 03:13.100 runs. 03:15.220 --> 03:19.140 And then we have the dynamic analysis phase. 03:21.820 --> 03:24.860 Now let the software run but carefully. 03:25.300 --> 03:35.820 This is where we place the program inside a virtual cage, typically a virtual machine, and watch what 03:35.820 --> 03:36.420 it does. 03:36.700 --> 03:44.740 Does it create files, change the registry, connect to suspicious domains, install persistence mechanisms. 03:45.060 --> 03:48.380 Now this form of analysis mimics a zoo. 03:48.860 --> 03:56.500 So we want to see the malware's behavior in its natural habitat, but without letting it escape. 03:56.780 --> 04:05.780 So we use logging tools, file monitors, network sniffers, and behavior analysis frameworks to catch 04:05.780 --> 04:09.150 every move the software Makes. 04:10.950 --> 04:14.750 And then we have the low level analysis. 04:16.590 --> 04:21.230 Sometimes a static and dynamic analysis just aren't enough. 04:21.230 --> 04:21.630 Here. 04:22.310 --> 04:30.750 Malware's may use tricks like environment detection, so it can detect that it runs in a virtual machine 04:30.750 --> 04:35.910 and just delete itself, and just doesn't work as intended in its natural habitat. 04:36.550 --> 04:40.230 That's very clever of malware developers. 04:40.990 --> 04:49.390 Uh, now, uh, yeah, they can use tricks like environment detection or time bombs, or only activating 04:49.430 --> 04:50.710 under certain conditions. 04:51.430 --> 04:55.350 There's a more instances about, uh, the last one here. 04:55.790 --> 05:08.350 Now, there's, uh, where low level analysis comes in using a debugger like, uh, x64 dbg or, uh, 05:09.110 --> 05:10.470 g db. 05:10.470 --> 05:19.110 be and win the debug debug we set up. 05:19.390 --> 05:24.430 We step through the program's execution line by line, instruction by instruction. 05:24.670 --> 05:32.430 And this is where you will see exactly what code executes conditionally, what branches the logic follows, 05:32.470 --> 05:41.110 and how values are passed and manipulated in memory, and also how system calls APIs. 05:41.510 --> 05:44.550 Application programming interfaces are chained. 05:45.470 --> 05:54.470 Now this meticulously work, but it is crucial for understanding stealthy and conditional behavior. 05:56.310 --> 06:04.830 And the last one of the last phase is reporting now. 06:04.870 --> 06:05.310 Yeah. 06:05.750 --> 06:08.590 Reporting now. 06:08.590 --> 06:12.030 Sometimes you won't have to report things. 06:12.150 --> 06:18.120 Uh, But this is like official face for reverse engineering. 06:19.360 --> 06:24.480 Now here, by reporting, I mean you are reporting your findings. 06:24.640 --> 06:30.440 Now, documentation is as important as the analysis itself in professional environments. 06:30.440 --> 06:34.880 And a good report doesn't just summarize findings, it tells a story. 06:35.120 --> 06:40.120 Now think of your analysis as a crime scene investigation and your report as a case file. 06:40.720 --> 06:44.080 You may ask the questions what does the software do? 06:44.520 --> 06:46.600 What do specific behaviors trigger? 06:47.000 --> 06:51.240 Why were certain instructions or libraries used? 06:51.960 --> 06:57.040 Where is the software intended to run and how does it interact with its environment? 06:57.080 --> 07:04.640 Now, this report helps future analysts, developers, and security teams learn from previous discoveries. 07:04.680 --> 07:11.560 Now, for example, documenting a buffer overflow found during analysis could lead to future input validation 07:11.560 --> 07:13.920 improvements across multiple applications. 07:13.920 --> 07:14.010 Patience. 07:16.370 --> 07:17.930 And the tools of the trade. 07:18.170 --> 07:25.530 To make all this possible, we use a wide array of specialized tools which you will make detail learned 07:25.530 --> 07:27.650 by detailed in next lectures. 07:27.890 --> 07:33.770 And these tools are have each specific role in the binary analysis tools. 07:33.810 --> 07:39.290 This help us inspect file formats, headers and extract strings. 07:39.610 --> 07:48.970 Example include p a I r detect is easy and bin bulk. 07:50.690 --> 07:53.690 We will use these tools in next lectures. 07:54.650 --> 07:59.490 Now we also use the Disassemblers tools like Ida Pro. 08:01.850 --> 08:11.130 Ghidra, which is free and open source developed by NSA. 08:11.690 --> 08:16.900 Now Ghidra lets us see the raw assembly instructions within an executable. 08:17.740 --> 08:21.140 We will also use the Decompilers. 08:21.620 --> 08:29.660 These provide higher level views of code, translating low level machine instructions into something 08:29.660 --> 08:43.340 resembling the C or Java Ghidra also does that or we also have the jab. 08:43.380 --> 08:46.940 For example g, a, d. 08:49.820 --> 08:51.860 And we will also use the debuggers. 08:52.860 --> 08:56.740 Debuggers allows us to pause and step through execution. 08:56.780 --> 09:02.180 We use them to trace, uh, behavior and identify hidden logic. 09:02.540 --> 09:06.060 Uh, for the debuggers we will mainly use G. 09:11.380 --> 09:19.660 And we will also use monitoring tools uh like procmon Wireshark. 09:21.460 --> 09:25.500 Actually, I have a full ten hour course on Wireshark. 09:25.980 --> 09:31.260 You can check it out and we will also use the Process Explorer monitor system. 09:32.420 --> 09:32.820 So. 09:35.300 --> 09:39.580 We can also monitor the system level activity during execution. 09:40.460 --> 09:43.540 And these tools continue to evolve alongside modern software. 09:43.540 --> 09:46.100 And no single tool here is enough. 09:46.340 --> 09:51.660 It is your judgment, creativity and understanding of the reverse engineering process that ultimately 09:51.780 --> 09:53.980 unlock the software's secrets. 09:54.500 --> 10:01.620 And this layered approach approval, static analysis, dynamic analysis, low level analysis, reporting 10:03.420 --> 10:06.420 forms a core of professional reverse engineering practice. 10:06.620 --> 10:11.780 As we continue this course, we will explore each of these phases with real world samples, tools in 10:11.780 --> 10:16.020 action, and hands on hands workflows to sharpen your skills. 10:16.540 --> 10:17.620 Thank you for watching. 10:17.860 --> 10:20.820 My name is typhoon and I'm waiting you in next lecture.