And now that we understand what reverse engineering is and why it's essential, let's shift our focus
to the actual process.
Like any specialized activity, reverse engineering follows a series of structured steps.
These steps help us systematically extract information about software, making our analysis reliable,
reusable, and helpful for developers.
Now let's break this down piece by piece, starting with one of the most overlooked but important parts.
In reverse engineering, we had first the seeking approval phase.
Reverse engineering isn't something you just jump into, especially with proprietary software.
Ethically and often, legally, you need permission from the software's owner before conducting any
form of analysis.
Now, that's not just about, uh, politeness.
It's about legal protection.
If you find a vulnerability.
The best practice is to report it privately to the software vendor.
That's what they say, and that gives them time to fix it before it's disclosed to public.
Now reducing the risk of the flaw being exploited.
And that's it.
There's a very different set of rules when it comes to a malware.
And if you are analyzing a malicious executable you don't need to others permission obviously.
In fact, you are trying to expose that the order and the understand their creation to stop further
harm.
However, if there is ever uncertainty, especially in a corporate environment, consulting legal counsel
is always a wise step.
And then we have the static analysis phase.
Now this is where we begin our analysis without ever running the program.
Now, think of it like dissecting a frog without bringing it to life.
Opening up the binary file, scanning each byte and reading its internals.
Now, from the file structure and the metadata to embedded strings and headers, a lot can be discovered
in this phase here.
Like is it a xa, DLL, dynamic link library or Elf format and so on and so forth.
Or we also can know what architecture is built on like x86 for computers eight.
Or 64 bit.
And our dear readable strings or API calls.
So you are essentially Preparing your mind and toolset for what you might encounter once the programs
runs.
And then we have the dynamic analysis phase.
Now let the software run but carefully.
This is where we place the program inside a virtual cage, typically a virtual machine, and watch what
it does.
Does it create files, change the registry, connect to suspicious domains, install persistence mechanisms.
Now this form of analysis mimics a zoo.
So we want to see the malware's behavior in its natural habitat, but without letting it escape.
So we use logging tools, file monitors, network sniffers, and behavior analysis frameworks to catch
every move the software Makes.
And then we have the low level analysis.
Sometimes a static and dynamic analysis just aren't enough.
Here.
Malware's may use tricks like environment detection, so it can detect that it runs in a virtual machine
and just delete itself, and just doesn't work as intended in its natural habitat.
That's very clever of malware developers.
Uh, now, uh, yeah, they can use tricks like environment detection or time bombs, or only activating
under certain conditions.
There's a more instances about, uh, the last one here.
Now, there's, uh, where low level analysis comes in using a debugger like, uh, x64 dbg or, uh,
g db.
be and win the debug debug we set up.
We step through the program's execution line by line, instruction by instruction.
And this is where you will see exactly what code executes conditionally, what branches the logic follows,
and how values are passed and manipulated in memory, and also how system calls APIs.
Application programming interfaces are chained.
Now this meticulously work, but it is crucial for understanding stealthy and conditional behavior.
And the last one of the last phase is reporting now.
Yeah.
Reporting now.
Sometimes you won't have to report things.
Uh, But this is like official face for reverse engineering.
Now here, by reporting, I mean you are reporting your findings.
Now, documentation is as important as the analysis itself in professional environments.
And a good report doesn't just summarize findings, it tells a story.
Now think of your analysis as a crime scene investigation and your report as a case file.
You may ask the questions what does the software do?
What do specific behaviors trigger?
Why were certain instructions or libraries used?
Where is the software intended to run and how does it interact with its environment?
Now, this report helps future analysts, developers, and security teams learn from previous discoveries.
Now, for example, documenting a buffer overflow found during analysis could lead to future input validation
improvements across multiple applications.
Patience.
And the tools of the trade.
To make all this possible, we use a wide array of specialized tools which you will make detail learned
by detailed in next lectures.
And these tools are have each specific role in the binary analysis tools.
This help us inspect file formats, headers and extract strings.
Example include p a I r detect is easy and bin bulk.
We will use these tools in next lectures.
Now we also use the Disassemblers tools like Ida Pro.
Ghidra, which is free and open source developed by NSA.
Now Ghidra lets us see the raw assembly instructions within an executable.
We will also use the Decompilers.
These provide higher level views of code, translating low level machine instructions into something
resembling the C or Java Ghidra also does that or we also have the jab.
For example g, a, d.
And we will also use the debuggers.
Debuggers allows us to pause and step through execution.
We use them to trace, uh, behavior and identify hidden logic.
Uh, for the debuggers we will mainly use G.
And we will also use monitoring tools uh like procmon Wireshark.
Actually, I have a full ten hour course on Wireshark.
You can check it out and we will also use the Process Explorer monitor system.
So.
We can also monitor the system level activity during execution.
And these tools continue to evolve alongside modern software.
And no single tool here is enough.
It is your judgment, creativity and understanding of the reverse engineering process that ultimately
unlock the software's secrets.
And this layered approach approval, static analysis, dynamic analysis, low level analysis, reporting
forms a core of professional reverse engineering practice.
As we continue this course, we will explore each of these phases with real world samples, tools in
action, and hands on hands workflows to sharpen your skills.
Thank you for watching.
My name is typhoon and I'm waiting you in next lecture.