Reverse Engineering Process Review

00:01

Okay, So before we start reverse engineering or analyzing malware, it's good to understand what the goal of our analysis might be and how we might define reverse engineering.

00:11

So let's start with that. Let's define reverse engineering. So let me ask you a question. How many of you out there have reverse engineered something before? All right, so I can see that almost everyone's virtual hand is going up, and that's probably true, right? You have reverse engineered something before. That's because the reverse engineering process

00:30

is a way for us to understand

00:32

how things were designed. So any time we look at an object and we ask ourselves, Okay, how is that particular object put together? Can I take it apart? Can I put it back together? We have effectively thought through the reverse engineering process

00:46

with this idea in mind, we can then to find reverse engineering as a way to understand how something was designed, what state it's in when it triggers how it works and what is its purpose. So when we apply the reverse engineering process to malware, we can define it as such. It's the process of which malware

01:04

is deconstructed

01:07

and then we reveal its design, it's code architectures

01:11

and extract knowledge from the malware sample. This could include its purpose modifications to the file system, time stamps and other artifacts, which will cover in more detail a bit later. Now, a few minutes ago, I talked about understanding our analysis schools.

01:25

I described the reverse engineering process as it relates to now where. But I neglected to talk about simply our analysis.

01:32

So the question maybe then, like what's the difference between these two concepts? Right? Well, when we talk about malware analysis, we're talking about the process of determining the functionality or impact of a given Mauer sample like a backdoor worm or virus.

01:47

Now, my experience, the R E and malware analysis processes, they're very similar. However, I've always thought of R E as a sub process of the overall malware analysis procedure,

02:00

meaning that during investigation sometimes I would include versus engineering is a technique and sometimes I wouldn't and honestly, this really all depends on your analysis goals, thes air goals that you should think about ahead of time because it's going to help guide your analysis and reporting.

02:15

For example, if you work in a certain environment. You may Onley be interested in retrieving malicious call outs and using those your rails in a networking blocking scenario.

02:23

And so running malware in a sandbox could be sufficient.

02:28

Or maybe you're involved in an investigation, which requires you to completely detail and encryption algorithm, which the malware uses to Dakota. List of malicious you are else.

02:38

So, depending on your scenario, you may simply choose to include the Ari process. Or you might leave it out

02:45

as it relates to this course. We want to detail the malware analysis process and add reverse engineering elements to it in an effort to prepare you to perform or complex malware investigations.

02:58

Overall, when we talk about reverse engineering or now we're analysis in general, the two processes share commonalities. Usually these are the static analysis and dynamic analysis. Some procedures

03:09

now during static analysis. This is where we analyze an object without executing it. This is where we might view the binary look at the bites of the file and create a strategy which may contain a specific set of tools to guide our analysis process. For example, searching text strings can give us clues about the program where it came from and what it does

03:29

during dynamic analysis. This is where we take our malware and we execute it.

03:34

This typically requires an enclosed environment so that the actions the malware takes doesn't compromise different production systems.

03:40

We usually do this with the aid of virtual machines because they can easily be controlled

03:46

during dynamic analysis. We run tools that monitor in log the environment while the malware is executing.

03:58

Okay, so why are we analyzing malware performing the reverse engineering process at all? Well, as you can see in the chart below, the numbers are pretty staggering. In 2021 it's estimated that the global cost of Mauer will be an estimated $6 trillion.

04:14

We've seen new strains of malware getting more dangerous every day. Right cybercriminals, air motivated tow, launch, more attacks because the large amount of money or information they could receive.

04:25

So to better understand the behaviors of malware and to have a better way to protect systems from the threats,

04:30

it's helpful to know the details of the malware inner workings, for example, with a list of malicious you RL's network administrators air able to impose policies to mitigate such an attack

04:44

or if the Mauer was thio, enter the system because of a user opening in the email attachment that contained a malicious word macro. The Windows administrator could implement the blocking of these macros.

04:55

So by knowing the behaviors of a certain malware through reverse engineering, you can recommend various safeguards to protect your infrastructure and provide your team with valuable threat intelligence.

05:05

Now, before we move on and look at some malware analysis tools, let's take a moment to talk about an important piece of our analysis process. Reporting

05:15

now whether we decide to include reverse engineering while analyzing malware or not, a good practice to become proficient in is reporting. During our analysis, we should document all the information that we collect so that we can create a knowledge base of past investigations, and we can help future analysts or upper management

05:32

review our past findings.

05:34

However, when we're creating a malware analysis report, understand that you need to know your audience,

05:41

understand that a reader may not be as technical issue

05:45

now. Typically, I've seen Mauer reports where the analyst is highly skilled in the analysis is amazing, but it just doesn't fit or meet reporting requirements or the analysis goals,

05:57

so make sure that you keep that in mind.

06:00

Now what elements you finally decide to include in your analysis report may be dictated to you by upper management. But overall, you should attempt to answer the following questions like What does the malware do as a whole? What behaviors are triggered or initiated when the object is executed? What platforms is it intended to work on

06:18

and what code, architecture or constructs were present in the malware?

06:24

Lastly, from my experience, the best reporting I've done is where I tell Good. Now we're story. Keep the technical details simple so that the reader can understand by analysis.