Dynamic Analysis Process Part 3: Advanced Analysis

00:00

Okay. Welcome to dynamic analysis. Part to advance dynamic analysis in this session will learn about D buggers and how they ate our malware analysis.

00:10

Okay, so in this session, we want to look at advanced dynamic analysis, and what we really mean is looking at and malicious program and into bugger. Now, there could be many reasons why we might do this. For instance, we might want to understand how a piece of malware is packed, look at past perimeters of functions, examine a p I function calls

00:28

or maybe examined encryption routines.

00:30

But no matter the reason to perform effective debugging, we need to review a few key concepts. Now, the first is to understand how a particular process is loaded into memory. We looked at that a little bit before, but rather more of the components of the process. In addition, we wanna look at how to debug a process. We want to set break points.

00:48

We want to alter our process execution,

00:51

and we want to look at the call stack. So traditionally, and bugger is a program used to test and debug other programs for our malware analysis purposes. We're going to use a D bugger to run our malware under conditions that are best for us as analysts,

01:04

and this will allow us to track them, always operation and monitor the malware as it changes. Computer resource is

01:11

so to perform these operations, of course, we want to use a do bugger. Now there's different types of debugging tools that we can use, and they're pretty similar nature now. The best known to bugger for Windows is Ali debug. However recently, Ah, ladybugs, cousin x 64 d b. G has taken over as the most used to bugger.

01:32

In addition, you can use the Windows to Bugger, which has been growing in popularity

01:37

as well as my personal favorite, which is the idea to bugger

01:40

as a review. Let's take a few minutes to look at our do bugger. So let's hop over to our lab and as a demonstration here, we've got a simple C program

01:51

that when we run it, the console program asks us for a pass raise.

01:56

When I type Brian, the program tells me that I am not correct and that I should try again

02:02

now to see what this program is doing under the covers. We can use the bugger

02:07

when you open the program. In the bugger, we see the main window or the CPU window. This is where you spend most of your time to bugging, and the CPU window includes assembly code and provides you the option to set break points or modify the programs assembly code as well as look at the program's memory.

02:28

On the top right hand side, you've got the registers window. This allows you the ability to modify registers or look at the values that those registers hold. While your program is being executed

02:38

on the bottom right hand side, you have the stack in the stack view. We can see the stack frame for functions. On the left hand side, you have the memory dump window. You can examine different portions of the memory being used as you move throughout your program.

02:53

Now, as you debug malware or really any other program, there's a few windows that can help you during your analysis. The first is the Execute Herbal Modules window.

03:04

You can access the executed modules window by pressing Ault E or by navigating to the view menu and then clicking on modules.

03:14

Here, you can see all of the loaded P E files in the virtual memory, including the sample you're looking at and all of the libraries and DLL s that are loaded with it. If you're attaching your do bugger to a process, you might also be able to see any injected. DLL, which are in the process, is virtual memory address space.

03:34

The second window that we can use is the memory map window.

03:37

We can access the memory mapped window by pressing Ault M or by navigating to the view menu, then memory map.

03:45

In this window, you can see inside the processes virtual memory.

03:47

In this window, you can see where all of memory is mapped into what address space as well is. It's permissions from this window. You can also dumb portions of this memory to a file. If you want to analyze it outside the do bugger

04:02

during the bugging, you'll have multiple options to run the programs assembly code. For example, Full execution, which will run the program until you hit a break point. The program requires input or the program completes. You can do this by pressing F nine on your keyboard or by navigating to debug and then run.

04:20

Other options for execution include Step through all of the instructions by using step into or step over

04:29

would step into the instructions are executed in a linear fashion

04:32

When executing a function. This will enter the function and execute all the lines in the function

04:39

by using step over. This allows you to execute all of the called functions instructions without stepping through them all to navigate your program. The A single stepping press F seven and two step over Press F eight

04:51

now to dynamically analyze a sample and understands behavior. You'll want to understand and control the program's execution flow. This means that you'll want to stop the execution when a particular condition of the program is met. And while the program is paused, you can examine the program's memory, alter register values and or modify instructions

05:12

to pause execution. You can use break points now. The most common break point you can set is a software break point.

05:17

You could do this by double clicking on the hex representation of the assembly line in the CPU window or by highlighting the text and pressing F two.

05:27

After this, you'll see a red highlight come over the instruction showing that you've set a break point. And as you run the program when the break point is hit, execution of the program will be paused.

05:39

For example, in our program, we might want to understand what phrase our program is actually looking for.

05:44

By looking at the code, we can see that there is a string. Please enter the correct word. And shortly after there is a string comparison,

05:53

this is going to tell us that somewhere in our code there's an if statement that compares the string that's entered with a string in our program

06:00

now because we didn't enter the proper string, it's not gonna print out the right message,

06:03

so to see what string is being compared, we can utilize break points to pause execution and inspect the code.

06:12

When we find the right branch of execution, we may need to modify the program. You might do this when you need to bypass anti debugging tricks, which will take a look at later, test different branches or just alter the flow of execution

06:25

in our program. We can do this using several approaches with, of course, the end goal to see are secret message.

06:30

The first method is to patch the program by changing its assembly instructions.

06:35

For example, in a program, we can see that if the result of our comparison fails, we jump to the address for a one B five

06:44

to make sure this jump isn't taken. We can change the jump to another condition or the opposite condition by pressing the space bar and then typing the new assembly instruction.

06:54

In this instance, we can just change the J any instruction of our comparison to J. E.

07:00

When we continue through the program, the jump isn't taken, and we can see that it will continue the execution flow in print out our secret message.

07:11

The second method is to change the flags of our E or our flags register rather than modifying the code of the conditional jump instruction.

07:20

In this case, we can modify the results of the comparison before the jump is executed. So on the top right hand corner here after the registers, we've got some multiple flags here that we can change here. We can see that if the results of the comparison is not zero, we take the jump.

07:39

So instead of modifying the code. We can simply step to the jump instruction and modify the Z flag register instead. As we continue execution of our program theme messages printed out even though we entered the wrong phrase,

07:55

The third method is to change data values and registers.

07:59

If we restart our program and we run to our comparison, we can see that the Rx Register is filled with EFS. But the test instruction wants to check the value of our X and make sure that it zero

08:16

from our jump instruction. We know the jump will be taken if the result is not equal zero. So in this instance, we can modify the contents of our X by right clicking the register and either changing the value depending on our scenario or in this case will just select zero.

08:37

As you can see, the registers modified. And when we run our program, we get our secret message even though the wrong word was entered.