Basic Static Analysis Part 1
Video Activity
In this module, we'll be discussing basic static analysis and begin with assembly code. You'll learn how to read the raw assembly code from the executable. You'll also be learning about debuggers, compilers, and disassemblers. The key characteristics of static analysis are that it is a slow, very detail-oriented process, requiring huge technical kn...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
or
Already have an account? Sign In »
Time
9 hours 10 minutes
Difficulty
Advanced
CEU/CPE
9
Video Description
In this module, we'll be discussing basic static analysis and begin with assembly code. You'll learn how to read the raw assembly code from the executable. You'll also be learning about debuggers, compilers, and disassemblers. The key characteristics of static analysis are that it is a slow, very detail-oriented process, requiring huge technical know-how. Static analysis is utilised to confirm your findings in dynamic analysis and understand the behaviour of malware. It also helps you to identify additional Indicators of Compromise (IOCs) such as encrypted strings or payloads, domain generation algorithms (DGA's), and network traffic encryption algorithms. Static analysis helps in determining malware defences such as anti-debugging and anti-VM. You'll also learn how to assess malware risks and their impact on a system, malware sophistication, and attributions. Further, you'll learn that assembly code is a human readable code for a particular chip. You'll also learn about various chip architectures like x86, x64. We'll also discuss about the various chip manufacturers such as Intel, AMD, ARM, MIPS and where these are used. Next, we'll understand the x64 and x86 assembly. X86 is the most common architecture and we'll discuss this in some detail as most malware is written in it. X86 is known as a complex syntax instruction set and has many functions. As an aspiring assembly coder or someone trying to read/understand assembly, you'll need programming knowledge like functions, local variables, and application programming interface (API's) and some math know-how like binary, hexadecimal and decimal (and how to convert them). We then move on to demonstrating compilers like GCC C, Cygwin; debuggers like IDA Pro, OllyDbg 2.0, and finally Visual Studio.
Video Transcription
00:04
Hello. Welcome to Cyber on a mission Pearson subject matter Expert for introduction to malware Analysis.
00:09
Today we're gonna be covering the basics of static analysis
00:12
and we're gonna go over part one assembly. So what exactly is stack analysis? Well, we're going to read the raw assembly code
00:21
from an execute a ble,
00:22
and we use tools such a cz deep ogres and disassemble er's.
00:26
Now, when
00:28
I said, you bugger, you probably think, Oh, you're gonna step through each line of the source code
00:34
And that's not quite true. If you have an I. D and integrated development environment, the buggers are useful for finding bugs. You step through each line of the source code, say, Oh, this is the if statement and this is the value I'm comparing this variable against et cetera. Well, we don't
00:52
usually have the source code for malware.
00:55
Fact is exceedingly rare that we do, and
00:58
we step through each instruction,
01:00
each assembly instruction. We're going to see some examples of that in a bit. But several
01:07
dis assemblers do have debunking components in them, so you can run the malware. Aah! And if you ever do run the malware,
01:14
even with a d bugger attached where you think you can control each instruction. Ah, highly suggest you keep it in a virtual machine. Ah, b m like one we built in the earlier videos. So the characteristics of stack analysis is usually that it's so very slow, very detail oriented, and a lot of technical knowledge required.
01:33
I like it. I don't think it's super hard once you get the hang of it. After a few weeks of digging into something,
01:44
you get pretty comfortable with it
01:46
pretty fast, especially if you're executing some code over and over and over again. You can see exactly what the instructions are doing,
01:53
but it does take time to sort through rather large execute bols. So I wouldn't suggest starting with something like visual studio or another large application,
02:06
Um, like photo shopper or something like that,
02:08
because those are huge programs make a bite worth of code is a lot of code.
02:15
So generally, when we're looking at code statically, uh, and we are looking at the individual instructions. We're trying to confirm us dynamic analysis. We saw there create a file in this directory, and it had this weird file name so
02:32
is that name really hard coded into the binary
02:38
like, well, it use that name every single time or to choose that name based on the date or the time, or
02:45
the version of the operating system. So Stack analysis. We can really understand the behavior of the malware, and we can understand what kind of conditional behavior would come about in a different version of the operating system, or whether or not it had access to the Internet or
03:00
different things about
03:02
Ah,
03:04
the family of malware we're looking for, cause that's very hopeful, too. If we look at indicators like Constance that we find our certain strings in the code, you can just Google for and you can see that someone else has already done some analysis, you can find out a lot of information.
03:20
Um,
03:22
some strings in some. Our are meant to be jokes. They know that analysts are gonna look at this later, and they try to make things harder by like encrypting strings. They encrypt payloads like a piece of our drops. Another file, another execute below and then executes that frequently
03:40
just encrypted in the first
03:43
dropping mount where the dropper
03:46
and it be interesting from a stack analysis standpoint to know, you know, when it would drop that. It's like, Okay, I see that it's going toe.
03:55
Look at all the processes that are running, and if there's no process is named,
04:01
you know, whatever d bugger
04:04
or have the d bugger keyword in the process title, then I'll drop this other execute herbal and kick that off. We can also understand
04:14
domain generation algorithms. Some our families out there don't have hard coded domains or I p addresses as commanding control servers
04:24
to report back to. But instead it gets us updates by generating new, malicious
04:30
domains every single day or every single second or every single minute, and will use a time or some other value, like from the Internet.
04:40
Ah,
04:42
the weather or something like that. And we'll use as a seed to generate ah domain name and then check that domain name to see if the Mauer author has put anything there.
04:55
And, of course, the Mount where author usually signs of stuff. So, you know, security researchers can't just take over the botnet by
05:01
planting,
05:04
you know, self destruct configurations on,
05:09
uh,
05:10
fake commanding control servers.
05:12
We can also easily figure out
05:15
well, not so easily, sometimes, but, uh,
05:17
network traffic encryption. Several families of malware will encrypt their network traffic to their command and control server. Sometimes it's really easy to figure out the encryption method they're using. Usually it's like a single bite X or
05:32
operation, which is just one instruction
05:36
that the CPU needs to run in order to get its original traffic.
05:43
And sometimes, if you look at string encryption,
05:47
you'll frequently see that it goes through each bite and just X Or is it against ah value? So we can figure that stuff out statically without running.
05:57
They execute herbal
05:59
and we can determine defense's. So a lot of Mao out there has anti V M or anti debugging defenses like I mentioned earlier.
06:06
And if we dropped inexcusable in R V M and we double clicked it and nothing happened, or we can see in the log that just started and stopped,
06:15
and we don't really know
06:17
why it's doing that
06:18
weaken,
06:20
throw it into a dissembler like Ida pro and just kind of looked through the code, see if anything jumps out at us is being some kind of anti virtual machine technology or anti virtual machine code.
06:33
And it's also important
06:36
when we really dig into a piece of malware what its capabilities are and what code
06:44
wasn't executed during dynamic analysis. And really, what
06:48
is the risk and impact to our organization?
06:53
For example, I was given a piece of malware, and when I ran in a V M,
06:58
all I did was pop up and say, You've been hacked by no uncertain hacker group name here and
07:04
Explorer
07:06
did a quick little refresh.
07:09
And
07:11
within the 1st 30 seconds of stack analysis, you know, I opened up in Ida and I was looking at it. I was just like, Oh, it looks like they just took a bat file
07:19
and they
07:20
ran a tool in a cold bat T x C m in e x e file.
07:26
And so I was able to recover the original bat file, which was just a few lines of code and the 1st 2 lines. Try ran a command to disable the mouse and Iran another command to disable the keyboard, and then it ran a command to take the file key dot bat
07:43
and place it in the startup programs folder, and then it would pop up. You have been hacked
07:48
and then it would kill, Explored at XY,
07:53
and I know it's my mouse and keyboard were still working during this dynamic analysis, and I googled around, and I found out those commands didn't work since Windows 95.
08:03
And furthermore,
08:05
I guess in the older operate older versions the operating system one explorer that X he dies. It doesn't come back, but on all modern operating systems
08:13
they do or explore that XY responds as soon as it's not no longer running.
08:20
So
08:20
it also occurred to me that key dot bat was probably the original file name,
08:26
and it was trying to copy keyed up bat instead of Kita E X E, which is what it's originally named. So
08:33
I was able to determine pretty quickly that this offered very little risk and very low impact. It was very low impact to anyone that was actually infected with it, Uh, and
08:46
with stack analysis,
08:48
after you do it a little while, you can get a feel for how sophisticated the programmer waas. So I was able to look at that piece of malware and determined that
08:58
the actors were not very sophisticated, There was obviously not very much testing. They didn't realize that their persistence mechanism
09:07
failed because they renamed the file. They didn't realize that the keyboard and mouse were still working after they ran these commands and that explored a taxi would just restart after it was killed.
09:22
So
09:24
based on this and other indicators from the region this piece of malware came from, I was able to determine that these Attackers were not very sophisticated. And they were, ah, a lot of hype. They talked a lot, but they didn't actually know a lot. And
09:39
I was able to determine all of this just really quickly within 30 seconds of static analysis and the dynamic analysis in this case do really did not help very much. And,
09:50
well, look at this group that had made another piece of mount where that deleted all the files on the operating system or delete all the files in the computer. Uh,
10:01
I looked at it again on stack analysis and saw it was just a bat t X file running one command, which was delete everything. Recursive Lee under the C drive forcefully,
10:13
and I looked at another piece of power from the same region, and it was also a wiper malware.
10:22
And
10:22
it
10:24
used a driver,
10:26
Ah, benign, well known
10:28
signed driver
10:31
to get direct access to the hard drive and then overwrite the first several chunks of memory
10:37
of the hard drive cold, the NBR or the master boot record. And that
10:43
was, Ah, very faster, and it was a much more sophisticated piece of malware.
10:50
So I was able to attribute
10:52
one group's malware
10:54
and another group's malware to two different actors.
10:58
Earlier I was talking about
11:01
We're going to read the Assembly of Execute a ble. So what exactly is that simple? Answer is it's human readable machine code for a particular chip.
11:11
Each line of assembly usually corresponds to a line of code that the CPU circuitry will execute.
11:20
So Intel invented this 80 86 chip several several years ago, and it was originally eight bit and then 16 bit and then 32 bit.
11:31
And I say 32 bit those air the size of the registers and thusly, how much memory it could address and 32 bits when you address it via word or D word. You could Onley maximally address four gigs or gigabytes off
11:52
memory.
11:52
And so the upper limit for early 32 bit operating systems was four gigs of RAM.
12:00
So we moved on to another architecture. 64 bit architecture, also called Andy 64. Because they're the ones who made the standard on Intel made its own 64 big standard, which was almost completely identical.
12:16
And most all 64 bit ships
12:20
can run X 86 code, like the chips have the circuitry to run both sets of code. And
12:30
if you ever look at X 64
12:33
assembly like we have in the lower left hand corner, it looks pretty similar to the assembly on the right hand side, which is exiting six assembly. We also have arm architectures and MIPS architectures. Air arm is is a lot more common. The MIPs
12:52
arm is usually used in phones and tablets and mrs like in printers and missing some tablets. And this is really just to show you that there's lots of architectures out. There are lots of different ships out there. The most common architecture found in the world is X 86 architecture,
13:11
and
13:13
so we should really get to know X 86
13:16
Assembly because that's what most Mauer's written in malware, like any other piece of software, usually tries to keep with compatibility and wants to infect as many machines as possible.
13:30
So,
13:31
like I was saying, down the left hand side, there's 64 bit code. In the middle is arm assembly, and on the right, it's mitts. And on the far right on up half the page is X 86. And that's what organ, huh? Well, that's what we're going to dig into Maur here. So
13:48
X 86 uses
13:52
a lot of different instructions. I can't remember exactly how many there are, but
13:56
it's not what we call a risk architecture. A risk is reduced. Instruction set, and X 86 is known as a Sisk is a complex instruction set. And that was because Intel wanted just tow, have lots of instructions to do lots of different things
14:16
because,
14:18
like I said, each line each instruction here is physically executed on the circuitry. So if you could combine a whole bunch of operations into one instruction, your code theoretically will be faster. But
14:33
the 14 most common instructions make up 90% of all cud
14:39
out there.
14:39
So
14:41
on the 1st 14 the most common 14 are ones. I've left it here on the right and you're going to see these ah lot, so I would suggest memorizing them.
14:52
And when you're reading assembly, there's two different ways to read. X 86. That's usually with the Intel syntax and the 18 T syntax with the Intel syntax.
15:03
It's generally right toe left, so
15:05
here we see move E X comma five. That means we're moving the value five into the E X Register.
15:13
A register is
15:16
the little bit of memory that's in the CPU.
15:22
There's, ah, a couple of different registers will go over there in a minute. But just know that when I want to manipulate information in the CPU,
15:31
we do it with registers and they are super, super fast.
15:35
It's really,
15:37
really slow to get memory.
15:39
Are there to get something from Ram? It's really, really slow to get something from the hard drive, so if you can do it with registers, you really should.
15:50
And if you're worried about optimizing your code
15:54
compilers do a great job of that. We're going to see some of the different compilers here in a minute,
16:00
and they will produce different
16:03
assembly.
16:04
They will produce different compilers, will produce different assembly. So we can take the same program and use 10 different compilers on it. And it will almost always be different
16:15
between each compiler. And if you do enough stack analysis, you'll get to know the output of certain compilers you could just look at and say, Oh, you know, this was produced by visual studio. Oh, this was produced by Del Fi or Oh, this was produced by, you know, whatever. Visual basic.
16:34
All right, I named languages, but you can usually tell that to.
16:40
So
16:41
you really need to know programming knowledge to get into this, uh, like
16:47
loops and functions and local variables and AP eyes application programming interfaces. You can Google stuff as you go along.
16:56
But if you're looking at the assembly for program and you see
17:02
oh,
17:03
you know there is, you know this jump instruction and then there's an increment instruction. And then there's another jump instruction and it does some stuff. Another trump instruction global.
17:12
If you're
17:14
ah knowledgeable programmer, you be, you could spot that as like Oh, that's a four loop. It's incriminating some counter value
17:22
and then checking constant
17:23
to see if it's over under that,
17:26
um, local variables are useful because we're gonna talk about the stack in the second. Video
17:33
and application programming interfaces are useful because you can usually tell the sophistication of actor. Or you can usually tell the programming
17:41
programming mythology methodology.
17:45
Ah,
17:45
like
17:47
if they like to create their own sockets and read and write and read right information directly from them. That's a different way to transfer information over a network rather than using
18:00
the
18:02
HTML or the wind. I net libraries that Microsoft also provides.
18:07
Also,
18:08
you should know,
18:11
I would also suggest that you would know Ah, bit of math, particularly binary, hexi, decimal and decimal and how to convert between them.
18:21
So we're gonna do a little demonstration. We're gonna take some C code
18:26
and compile it with GCC in Sigmund,
18:30
which is what I prefer and what I suggested in earlier videos. And we're also going to do it and
18:37
the native
18:38
visual studio compiler C L.
18:42
So I'm gonna
18:45
start up a single internal here,
18:48
So the sequin
18:51
fell here,
18:52
do l s. And there's a hello dot C,
18:56
I'm gonna display it on the screen, but saying cat hello, That see? And we can see it is a simple program.
19:03
Simple see program where it just
19:07
includes the library STD
19:08
Iota H, which is standard io.
19:11
And it uses the print a function
19:15
to print hello world to the screen
19:18
So we can say GCC hello dot c
19:22
It will compile it.
19:23
Then we can execute it. The file that output by default is ADA e x e. We can execute it and there's hello world
19:32
with G C. C. You can also specify Dash s function
19:36
and compile it
19:37
and
19:38
we will see that we now have a hello dot s
19:41
So I'm gonna run cat.
19:47
Hello, tha s
19:49
And this is what we call the listing file. This is the Assembly, the X 86 assembly
19:56
that the compiler had to generate
19:57
in order to
20:00
fully compile an e x e file.
20:06
So
20:07
dot file hello dot See, these dots are basically saying that these lines are just
20:15
metadata. They don't have
20:18
any code equivalent.
20:21
That is output.
20:22
That's it.
20:23
They're they're actually sections of the file,
20:26
so we can see that there is indeed some metadata,
20:32
those included. But by this compiler,
20:33
we can see it's using the T and T syntax
20:37
that's doing push. L
20:41
move. L and L sub l
20:44
Cole main
20:48
underscore underscore. Underscore Main.
20:52
So that's pretty interesting. And we can
21:02
Well, you know, there's no clear. And
21:06
just to reset that just
21:08
So now we're going to compile it with
21:11
the visual studio
21:14
compiler
21:15
that Microsoft provides for free, which is very nice of them.
21:18
So under visual studio in Goa
21:21
to the developer Command prompt.
21:23
We're going to browse. We're gonna change directory. Let me increase the thought here.
21:44
Seguin slash homes. LaShawn,
21:52
we see the eight XY the hello dot See the hello. Dot s.
21:56
So
21:59
we're gonna compile with C l. The
22:02
are soft
22:03
supplied C compiler. So we could do hello. Not see
22:10
it created an object file and then created
22:15
Hello? Not yet. See?
22:18
So we're gonna execute hello dot Taxi.
22:21
Hello, world.
22:22
Very simple.
22:23
Now
22:26
Memphis up
22:27
and specify
22:30
the slash f a parameter
22:36
And now
22:38
Microsoft C compartment, Microsoft C compiler will have produced a Hell Oda s m file
22:49
so we can
22:52
look at that
22:52
pad plus plus
22:56
because it's nice and colored.
23:12
Go to Sig one
23:17
home, Sean
23:18
Saluda, Assam
23:22
and we'll also open
23:26
Pelota Es.
23:32
So this is Luda awesome. This compiler produced this assembly file this listing file
23:37
and it was nice enough to go line by line and specify
23:44
the assembly instructions that were produced from that line of code.
23:48
Since we only had two lines of code, it's not that big a deal, but it could be pretty interesting. I highly suggest you experiment with this
23:56
so we can see that this is the Intel syntax.
24:02
Excellent E x e x that zeroes out the ex no matter what value is any axe,
24:07
it is now zero.
24:10
It's just a very quick way of doing it.
24:11
And we can see some push and pop instructions here. And that deals with Stack, which we'll talk about next video.
24:18
We can see that it pushes,
24:21
uh, offset a K, pushes an address
24:25
onto the stack and then calls print up
24:29
and we can see that the address
24:34
has to be somewhere in this file. There it is.
24:38
Hello world. There's a zero a for the backslash end for the new line and then zeroed and marked the end of the string
24:45
and
24:47
color this
24:51
and
24:52
and the listing file produced by GCC. We see that has
24:56
but some fewer instructions that it's in 18 t syntax. I'm sure we could have it come put out
25:04
intel syntax if we wanted to,
25:07
and we can see that it's produced some different assembly.
25:11
So if you're looking at both these files
25:14
in a dissembler
25:15
with enough practice, you can see what was produced by what compiler.
25:21
So here
25:22
we're gonna use a dissembler
25:25
called Ida Pro.
25:26
I don't know the demo for ah, version 6.8. I'm just gonna get hit. Ah, go here
25:34
and I'm gonna pull over my GCC
25:37
execute herbal
25:37
and Ida is going to look at it
25:41
and try to
25:44
load various debugging information.
25:52
And here Oh, give me cava graphical view of the assembly that it's found.
25:57
So this is where
26:00
the main see Artie startup function is and,
26:04
you know, better known as Maine. And then there's also a main function here that will eventually
26:11
pass off control, or b
26:12
the actual main function.
26:15
And this is a good bit of code that the G C C compiler for Sig one has inserted into our execute a ble.
26:26
And if you want to reverse this, um, or you could and easy Way would be to look at the imports and exports. And we can even go to strings because hello, world
26:38
was a string
26:44
Hello world. And we can see where that was access
26:48
by pressing X or just going to this x reference over here.
26:56
And we can see
26:57
our code
27:00
was
27:00
basically And
27:03
until syntax is push
27:06
E v p movie PPS PDS or stack registers, we'll talk about that in the next video. It calls
27:15
the main function here
27:17
and,
27:18
uh,
27:18
moves
27:21
the pointer
27:22
into a certain location
27:25
calls that put s
27:27
which is a better function than
27:33
print F
27:34
for many reasons. Print of his very old.
27:38
But it will make the adjustments.
27:41
You can see up here that
27:44
this blue area this is actually code
27:45
Aah! These areas either couldn't figure out what it was or it's just data so it can press the space bar and actually see
27:55
this code is just a small part of what this pile is that there's lots of other code their library code boilerplate code data. Just blink data.
28:06
Um,
28:07
sometimes it's just,
28:08
uh, references. Sometimes it's just zeros.
28:15
But the point is,
28:17
the compiler took that bit of code
28:18
and created this This execute herbal
28:22
and with the same code
28:25
visual studio
28:26
created a completely different execute a ble. Functionally, they are the same,
28:36
but as we'll see,
28:37
it looks completely different.
28:42
So it's calling thes functions.
28:47
And I didn't know what their names were, so it just gave it a name based on the address that found it in memory.
28:53
We're going to use the same technique to find the actual small bit of code that we wrote.
29:00
I'm gonna go to a few
29:10
strings,
29:12
see, a lot of strings were included.
29:17
I'm gonna find hello world somewhere. Control f Hello.
29:22
Hello, World backslash in.
29:25
We found it here.
29:26
Be impressed, X to see where it's reference and we see
29:32
in this function. So 401260
29:37
that there is a pushy BP move E s p e v p like the other
29:41
ah
29:42
function that we saw in the previous eight XY
29:45
and we can see
29:48
pushed. And then this function is called. If we scroll over this function and then scroll or if we move, hover over this function and scroll with our whole school down.
29:56
It has
29:59
another function, and then that calls to other functions. It looks like
30:02
and provide some arguments, and
30:06
the compiler, like
30:07
visual shell, will do this mainly because of security
30:12
and stability.
30:15
So it will put in certain checks between functions, and it knows we're vulnerable. Print F is vulnerable to a certain type of exploit.
30:25
UH, hold up
30:26
print, string
30:27
our print format string vulnerability. And so it will surround
30:33
the print of function or Microsoft's implementation of the printout function
30:37
with
30:37
more code boilerplate
30:41
boiler plate code. Sometimes what they call it.
30:45
So this shouldn't be alarming. And
30:48
like I said, once you get used to analyzing a few pieces of code programs that you write yourself or publicly available programs, you'll see that
30:56
compilers will insert their own code or add their own stuff like visual studio will add in what they call stack canaries to see if there's a certain type of exploit called a buffer overflow exploit, which we will talk about when we talk about stacks.
31:12
So
31:15
I, uh, is the best dissimilar, but it's not necessarily the best compiler, and
31:21
that's okay.
31:22
But most reverse engineers prefer
31:26
Ah,
31:26
the D bugger cold,
31:30
all ladybug.
31:33
A de bugger that a lot of reverse engineers like to use eyes. Ah, ladybug is currently at 2.1
31:41
version wise, and a lot of people still use 1.1
31:47
because a lot of old plug ins were written for it for a reverse engineering. So we can take our hello Dottie XY
31:52
and we can execute it. And we see that it pops and says, Hello world.
31:57
And if we want to see will step through the program, we can just take it, draw, drop it into a ladybug, and
32:06
we can see that we could step over each instruction.
32:12
Now, if only debug scares you with all this stuff,
32:15
it's okay. Just take it one step at a time. One instruction at a time, if you will
32:20
like the shortcut for this step over construction is F eight. So we can just single step through the program as it's working
32:29
and we can see as the instructions are executed, changes are being made to certain registers
32:35
and we'll get into like
32:37
this push instruction here in a bit,
32:40
Uh, but we can easily step
32:45
in for,
32:46
like, the next call instruction here, or we can step into it and we can actually follow the program flow.
32:54
I'm just gonna step over.
32:59
And
33:00
if we see this, push instruction, execute and push on to the lower right hand pain. There is what we call the stack,
33:09
which we'll talk about in just a minute. You step over and we can see that something was pushed onto the stack.
33:15
We only looks at it and knows it's an argument to the next function, which is a call here,
33:22
which we can step over again.
33:25
And Poppy See X has to do with the stack again,
33:29
which we'll talk about in just a minute. There's a test a l A L. It's testing to see if
33:35
a l zero, we'll talk about a little bit.
33:39
And we can
33:42
keep doing this until we get to the point where it calls the function
33:46
the actually Prince Hello world to the screen.
33:52
You can see it's pushing two parameters. Is calling another function?
33:57
Does it jump? Is pushing to more parameters called another function can see that visual studio has added a lot of code.
34:07
And somewhere here, probably this last function call
34:12
resulted in
34:13
print f being called at some point and hello world being displayed on the screen.
34:17
We can also do a similar sort of thing with visual studio.
34:27
So I'm gonna end all here.
34:37
I'm gonna grab this
34:39
source code
34:42
and copy it.
35:02
Okay, Now, the visuals to you has loaded. I'm gonna start a new project,
35:08
and I'm gonna choose Empty Project. I'm just gonna call this project. Hello?
35:29
I'm gonna add a new file.
35:30
Call it hello dot c
35:37
will create it.
35:38
I will paste in. Ah, hello, World Code and save it.
35:43
Now I'm gonna put a breakpoint
35:45
over here,
35:46
and I'm gonna say debug or local windows debunker,
35:52
that's going to say, Do you want to build this? Yes, of course I do.
35:58
It will build the assembly. It'll compile. It will produce an execute herbal
36:04
and begin to run it just like all he did and stop it at a certain spot.
36:08
Now, here's a really cool thing about visual studio.
36:13
You can right click and say, Go to assembly.
36:16
And over here
36:19
it'll actually show you
36:21
for each line of code that you wrote the assembly that it created.
36:27
And just like the on ladybug
36:29
program,
36:30
we can step over each instruction and then we can see the resulting registers being changed.
36:37
If you want to
36:39
look at all the registers under debug under windows,
36:46
under registers
36:49
throughs.
36:51
So up here
36:52
we can see the X Register with TB Ex register into the P register being changed,
37:00
and we can do the same sort of operation where we step over each instruction and we can see exactly what it does and when it does it,
37:08
Hello World was printed the sign of excuse. This line of code was executed and so highly encourage you to write some source code and see the assembly that it produces because that's really the best way to get to know compilers. It's really the best way to understand what high level source code produced,
37:29
what
37:30
level or what assembly.
37:32
And if you're feeling adventurous, you can always change the architecture
37:39
two from like X 86 toe like X 64
37:45
and do the same sort of thing,
37:52
right Click already can go here seaview disassembly and you can see that they're very similar type of instructions. And so, um,
38:02
you know, instead of
38:04
move
38:07
Ta ex Ah,
38:08
it'll move a different value in the X, or it'll produce ah different function coal, or might do something slightly differently,
38:15
like instead of a push. Instruction it's doing is using an L. E A instruction and doing something called a fast Cole so it doesn't actually push her pop anything out of the stack. It just places something in the register because working with registers are very fast,
38:30
but we'll get into calling conventions later.
Up Next
Intro to Malware Analysis and Reverse Engineering
In this malware analysis course you will learn how to perform dynamic and static analysis on all major files types, how to carve malicious executables from documents and how to recognize common malware tactics and debug and disassemble malicious binaries.
Instructed By
Similar Content
