I decided I needed to order my password dictionaries in a manner that would bring the more likely passwords to the beginning, and the least likely passwords to the end. I wasn’t aware of any program that did this, and figured I would write my own.

A few hundred lines of C later and I have a very fast password dictionary ordering program. It is far from perfect, but much better than nothing. It loads the entire dictionary into memory, creates all the information necessary for markov chains, and then uses this information to score each individual password. The passwords are then ordered by their score.

You can find the code in the rainbowsandpwnies googlecode svn repo.

In any case, I thought tonight would be a good chance to share one of those many projects that never see foreign eyes. I thereby present you with my custom spin on what a tech stock tracker should look like. I’m not trading minute to minute, or hour to hour, so I don’t care about real-time stock quotes. What I do care about are new announcements that may tip a stock one way or the other, or stocks that look like they may be headed towards rapid change.

Right now, you’re looking a few hours in python, on a 10 minute cron. It grabs information, parses it, and generates static html. I have plans yet to continue to improve this project. More specifically, I’d like to delve deeper into the news articles, counting keywords that may indicate the direction a stock is about to head. I also planning on grabbing historical stock information and running some regression stats in an attempt to automate finding what stocks are very closely related to one another. If stocks A, B and C are all closely related, and news indicates good things for A and B, good things are most likely in store for C.

Rainbow tables allow us to find plaintexts to cryptographic hash algorithms quickly. They are based off of Hellman Martin’s “A Cryptanalytic Time – Memory Trade-Off“. By including the step in the reduction function, Phillipe Oechslin was able to improve on Hellman Martin’s method, and we came up with Rainbow Tables, the “Faster Cryptanalytic Time – Memory Trade-Off“.

If you are unfamiliar with rainbow tables, it is suggested you become familiar before continuing.

Even rainbow tables are not perfect. They still merge, and merges mean wasted information, wasted space, wasted time. What we really want are perfect rainbow tables. In perfect rainbow tables, each chain has a unique endpoint. We have no merges. They give us nearly the same percentage to find a plaintext as non-perfect rainbow tables, but are much smaller.

Perfect rainbow tables have always taken much longer to create than non-perfect rainbow tables. The two step process to create perfect rainbow tables has been:

1. Create all chains for your rainbow tables
2. Eliminate duplicate chains, until only one instance for each endpoint remains

Each time you eliminate a duplicate chain, all the time spent creating that chain is lost/wasted.

We must also understand that chains can merge at any step. If we have three chains which merge, they may merge like this:

hash(aaaaa) -> 13049 ... reduce(13049, 1) -> bcdef ... hash(bcdef) -> 30459 ... reduce(30459, 2) -> iekdj ... hash(iekdj) -> 69384
hash(bbbbb) -> 93024 ... reduce(93024, 1) -> bcdef ... hash(bcdef) -> 30459 ... reduce(30459, 2) -> iekdj ... hash(iekdj) -> 69384
hash(ccccc) -> 84626 ... reduce(84626, 1) -> dgrhf ... hash(dgrhf) -> 84532 ... reduce(84532, 2) -> iekdj ... hash(iekdj) -> 69384

A Better Method for Creating Perfect Tables

Creating our perfect tables faster is as simple as identifying the merges in our chains before we reach the end of the chain. Instead of creating each chain one at a time, and then checking for merges after-the-fact, we create all of our chains out to a certain “merge step”, eliminate merges, and then continue until the end of the chain. If we repeat this process several times, we can identify progressively more merges before reaching then end of the chain. As we eliminate more merges, the time to get to our next “merge step” is less than the one before it.

Here is an illustration of this process in pseudo-code:

function extend_chains (chains, first_step, last_step)
chains = extend_chains(chains, 0, 99)
throwaway_merges(chains)
chains = extend_chains(chains, 100, 199)
throwaway_merges(chains)
...
chains = extend_chains(chains, 900, 999)
throwaway_merges(chains)

I have implemented my throwaway_merges function in a mergesort (seems fitting) which automatically discards duplicate chains during the sort process.

Performance

The performance of this method depends on the number of merges that will occur in our chains. The more merges, the larger the difference in time between the new method and the old method. As long as the time required to sort the chains and eliminate merges is less than the time gained from eliminating those merges early on, we receive a net gain in speed. Profiling my code, my implementation of throwaway_merges comprises less than 1% of the total computation time.

Just to reiterate, creating merges speeds up this process of creating rainbow tables. Using increasingly longer chains, while still detrimental in the actual cracking process, is no longer as detrimental in the generation of perfect rainbow tables.

I have generated some output from my new method of finding perfect chains compared with an implementation of the original method for finding perfect chains.

All runs were done on a single core of a Q6600 processor in Ubuntu-9.10-amd64 (each process on its own core). Disk write times are not accounted for, but are assumed negligible. The hash function being used is the MD4 implementation available here. I am currently generating MD4 hashes for ease of debugging (I check against md4 hashes generated through python’s hashlib), but these will be NT hashes by release (a simple conversion).

First Run

In the first run, we generate 10,000 chains, each chain with a length of 2048, where hashes reduce to plaintexts a-z 4 characters long. This table will have many merges, and will accent the speed improvement of this new method.

Of the 10000 chains, 405 unique chains remain. That’s only 4.05% of our original chains. My method finished creating its perfect chains in ~1.25 seconds, while the original method finished in ~7.21 seconds. The new method is ~5.8 times as fast.

Second Run

In the second run, we generate 50,000 chains, each chain with a length of 2048, where hashes reduce to plaintexts a-z 5 characters long. This table will have fewer merges, and the improvement will not be as great.

Of the 50000 chains, 9349 unique chains remain. That’s 18.7% of our original chains. My method finished creating its perfect chains in ~15.96 seconds, while the original method finished in ~38.11 seconds. The new method is ~2.4 times as fast.

Third Run

In the third run, we generate 500,000 chains, each chain with a length of 10240, where the hashes reduce to plaintexts of a-z 7 characters long. This table will have fewer merges, and the improvement should be minimal.

Of the 500,000 chains, 313005 unique chains remain. That’s 62.6% of our original chains. My method finished creating its perfect chains in ~1433 seconds, while the original method finished in ~1792 seconds. The new method is ~1.25 times as fast.

Fourth Run

In the third run, we generate 50,000 chains, each chain with a length of 2048, where the hashes reduce to plaintexts of a-z 7 characters long. This table will almost no merges, and there should be no improvement with the new method.

Of the 50,000 chains, 49417 unique chains remain. That’s 98.8% of our original chains. My method finished creating its perfect chains in ~35.99 seconds, while the original method finished in ~36.00 seconds. The new method is ~1.00 times as fast.

Looking Forward

The entirety of this rainbow tables implementation was coded by me in C. The code requires some cleaning up, but once I am done I will be releasing a new, open source (exact license TBD) implementation of rainbow tables in C. The release will include both the original method of generating rainbow tables, and my new method for generating perfect rainbow tables.

Other things I would like to do:

• The chains are currently 20 bytes long. This can be brought down to 12 bytes, this has not been implemented yet.
• I would also like to experiment with a heap sort, where chains are added to the heap as soon as they are generated. The heap will automatically drop duplicate chains. When moving from one “merge step” to another, we just read from one heap and write to another. I am unsure how this will perform compared to my current implementation of merge sort. As the sorting algorithm accounts for only a small amount of time, this is low-priority.
• Assuming this new method will lead to longer chains being generated, implementing “break points” in the chains may be beneficial. Given a chain of length 10,000, we may also store a value which will allow us to pick up our chain at step 5,000. We would call this value a break point. This way, when cracking against the table, and we find a possible collision at, say, position 8,000, we do not have to generate the chain starting from step 0. We can start from step 5,000. This is not my idea, but I do have a link to the original idea. More breakpoints can be added to speed up cracking, at a loss of disk space.

Intel Assembly Comprehensive Cheat Sheet

danukeru from reddit posted a link to this cheat sheet, which lists x86 opcodes, what their abbreviations mean, and their Intel syntax. It is awesome, and I wish I had it earlier.

A little more into lea

This comes from jputnam at reddit as a suggestion.

A quick google search turns up a few articles which are helpful. I especially like this one from the University of Illinois at Urbana-Champaign.

Basically, lea sets a register equal to a value, after computations on that value are completed. Usually, this is an offset from another register. This is different from mov, which is used to set a memory location pointed to by a register equal to a value.

Let’s say we want to set our register ecx equal to ebp+0×12, because that’s where one of our stack variables are, and instead of using [ebp+0x12] everytime we want to refer to that stack variable, we’re going to use ecx (I have no idea why we would ever want to do this, but we’ll pretend). We would use the lea instruction to do this all very neatly in one line.

lea ecx, [ebp+0x12]

If you’re still not entirely cleared up on lea, visit some of the links above. They do an excellent job explaining this instruction.

Explain why eax is set to 0 at the end of main

Another one from jputnam.

It is a common convention to set eax to the return value. Main returns 0. Therefor, we set eax to 0.

If you call a function and want to check its returned value, check eax.

Spend a little more time explaing ebp

This one comes from stevep98 at reddit.

Given this C function:

void function ebp_explanation (int argument)
{
	int i;
}

This is a simplistic example of how this function may look on the stack (ditaa is cool):

Image has been accidentally deleted

0×74 is memory we reserve for int i. Normally, we reserve this space by setting esp somewhere beneath 0×74, so when we push things on to the stack they do not overwrite the memory at 0×74.

We then set ebp somewhere consistent on our stack, and we leave it there. Convention is to set ebp to where it is in the above illustration. From there, when we want to refer to certain pieces of memory (IE stack variables), we refer to them by an offset from ebp. If we want to add 1 to int i, it will look like this:

add DWORD PTR [ebp-0x4], 0x1

Like storing the return value in eax, this is a convention, but not a rule. In fact, when we take our same program from the first tutorial, give gcc the -O3 flag, and look at the disassembled code, we will see gcc decides to refer to int i in regards to esp instead of in regards to ebp.

Stack Alignment

jldugger commented on stack alignment.

If you want some more information stack alignment, which I admittedly didn’t do a terrific job of explaining, a simple google search returns these two pages: ( one | two ). They should help clear things up. I’m going to leave it at that for stack alignment.

What’s to come

I won’t know 100% what will come next until it’s written, but these are the next three topics I would like to hit (remember, I’m learning as I’m writing):

1. Take one.c (the example program from x86 Assembly for C Programmers 1) compiled with -O2 and -O3, and analyze why the compiler does what it does with different levels/kinds of optimization.
2. Begin looking at some more complicated examples, more of the instruction set, and expand our knowledge of the x86 instruction set.
3. We will take a C program, break it down in to assembly, and begin optimizing it in assembly. This will be the first installment of writing/modifying the assembly code.

Beyond that, we’ll find out when we get there.

I’m writing a series of tutorials on x86 assembly for C programmers who are already familiar with many of the basics of programming and computing. The assembly tutorials available online just aren’t doing it for me, and I need something organized the way I think, on the topics I’m interested in, presented in a way which make comprehensive understanding easy. I’ll do the work, go find the answers, and then drop everything here for you to enjoy.

Please note I do not claim to be an expert on the assembly language.

My interest in assembly is for both optimizing C applications, and the purpose of developing exploits for vulnerabilities in common applications, not write applications in assembly from scratch. I’m not interested in, “Good,” examples of assembly, I’m interested in real examples. This will affect the assembly we look at. More specifically, I write the code in C, compile it with gcc, and what comes out is what we’ll be dissecting.

For the purposes of these tutorials, 32-bit x86 assembly. Everything compiled/built/disassembled on the latest stable distro of Ubuntu.

References

The Art of Assembly is an excellent reference, and if you need clarification of any of the topics discussed, I recommend checking it out. Chapter six covers all of the instructions, how they work, and what specifically they do.

Thanks To:

Bushmills from irc.freenode.net##asm for taking the time to explain to a noob why the first 7 lines of assembly were what they were.

The Code

Let’s take a look at a simple C application, and it’s disassembled assembly code.
gcc one.c -o one

#include 

int main (int argc, char * argv [])
{

	int i;

	argc++;

	for (i = 0; i < 10; i++)
		printf("%d\n", i);

	return 0;

}

Disassembled counterpart (for main):
objdump -d one -M intel

080483c4 :
 80483c4:	8d 4c 24 04          	lea    ecx,[esp+0x4]
 80483c8:	83 e4 f0             	and    esp,0xfffffff0
 80483cb:	ff 71 fc             	push   DWORD PTR [ecx-0x4]
 80483ce:	55                   	push   ebp
 80483cf:	89 e5                	mov    ebp,esp
 80483d1:	51                   	push   ecx
 80483d2:	83 ec 24             	sub    esp,0x24
 80483d5:	83 01 01             	add    DWORD PTR [ecx],0x1
 80483d8:	c7 45 f8 00 00 00 00 	mov    DWORD PTR [ebp-0x8],0x0
 80483df:	eb 17                	jmp    80483f8
 80483e1:	8b 45 f8             	mov    eax,DWORD PTR [ebp-0x8]
 80483e4:	89 44 24 04          	mov    DWORD PTR [esp+0x4],eax
 80483e8:	c7 04 24 d0 84 04 08 	mov    DWORD PTR [esp],0x80484d0
 80483ef:	e8 04 ff ff ff       	call   80482f8

 80483f4:	83 45 f8 01          	add    DWORD PTR [ebp-0x8],0x1
 80483f8:	83 7d f8 09          	cmp    DWORD PTR [ebp-0x8],0x9
 80483fc:	7e e3                	jle    80483e1
 80483fe:	b8 00 00 00 00       	mov    eax,0x0
 8048403:	83 c4 24             	add    esp,0x24
 8048406:	59                   	pop    ecx
 8048407:	5d                   	pop    ebp
 8048408:	8d 61 fc             	lea    esp,[ecx-0x4]
 804840b:	c3                   	ret
 804840c:	90                   	nop
 804840d:	90                   	nop
 804840e:	90                   	nop
 804840f:	90                   	nop

This is a list of the instructions that are used above. We'll explain which each of these instructions do as we come across them later:

• lea - Load Effective Address
• and - logical AND
• push - PUSH data on to the stack
• mov - MOVe data from one register to another
• sub - SUBtract
• jmp - JuMP
• call - CALL another subfunction
• add - ADDition
• cmp - CoMPare
• pop - POP data off the stack
• ret - Return control to the parent function

You'll notice we left off jle. jle means jump if less than or equal to, and is a variant of the jmp instruction. You can find all the variations with any assembly reference.

Now let's take a look at the registers used. (ESP/EBP)

• esp - Stack Pointer (for the top of the stack).
• ecx - Counter (used for other purposes described later)
• ebp - Base Pointer
• eax - Accumulator Register (Arithmetic Operations)

If you don't understand exactly what all these registers are, we'll describe them later, and you will see how they are used.

Some Background:

First, some vocabulary:

• Stack: This is, surprise, an implementation of the data structure known as the stack. We use this stack to keep track of information about the program during the course of its running.
• Register: Think of registers as our variables. Think of them as pointers, and we dereference them by putting them in [].
• Instruction: An instruction is an operation we want to run on the processor.
• Operand: Quite simply, an operand is an argument to an instruction.
• Word: Every 4 bytes is considered a word. Wikipedia defines word as the smallest unit of data used by a computer design. We're using a 32 bit operating system, so 32 bit words, 4 byte words...

The x86 Stack and esp

The x86 stack is a LIFO mechanism we use to store information, LIFO being Last In, First Out. push puts data on the stack, pop takes data off the stack. push and pop manipulate data relative to esp, which is the stack pointer.

The stack grows down, meaning we start at higher memory addresses, and as the stack grows, we end up with lower memory addresses. esp is often referred to as pointing to the top of the stack, but in diagrams, the top of the stack is depicted as at the bottom (because we have higher addresses at the top, and lower addresses at the bottom).

esp decrements before adding a value to the stack, not after, so esp will always point to the last element added to the stack.

This may be a bit confusing now, but by the end of the first 7 instructions, you should have a good handle on it.

When we call a function, the stack typically looks like this:

------------------
| argument 1     |
------------------
| argument 0     |
------------------
| return address | <- esp is here
------------------

This is how the function will inherit the stack. In most simplistic tutorials, a few more commands will be executed at the beginning of the function to give us a stack like this:

------------------------
| argument 1           |
------------------------
| argument 0           |
------------------------
| return address       |
------------------------
| original ebp         | <- ebp points here
------------------------
| stack data variables | <- esp is here
------------------------

Aligning the Stack

This stack, as you will see, is nothing more than a bunch of memory in relation to esp, and esp is the only way we can identify where we are in the stack. If we change esp, we change our location in the stack, without using push or pop.

We want the stack to be "aligned", meaning we want our stack variables to start on a word whose address ends in 0, or the memory is evenly divisible by 16, however is easiest for you to think of it. This apparently speeds up the computation of some operations, but more importantly, with the introduction of SSE instructions (which work on 128 bits at once), having your variables aligned improperly can lead to some spectacular failures.

It all has to do with memory segmentation (Edit: Not really. See jldugger's comment. Processor design is important here. Visit the following link to learn more. I'm going to go ahead and mark this under not too terribly important to understand. Keep reading, you'll be fine, I promise.) If you're really interested, do some reading. For now, just know we want our stack to be properly aligned, and that's what gcc is doing in the first seven instructions.

The Assembly

We're going to go instruction by instruction, explaining what's happening, and looking at the stack, along with where our registers are, each step along the way.

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     |
     ------------------
0x78 |   ret addr     | <- esp points here
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |                |
     ------------------
0x68 |                |
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

lea ecx,[esp+0x4]

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here now
     ------------------
0x78 |   ret addr     | <- esp points here
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |                |
     ------------------
0x68 |                |
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

and esp,0xfffffff0

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                | <- esp points here now
     ------------------
0x6c |                |
     ------------------
0x68 |                |
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

push DWORD PTR [ecx-0x4]

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |   ret addr     | <- esp points here now
     ------------------
0x68 |                |
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

push ebp

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |   ret addr     |
     ------------------
0x68 | original ebp   | <- esp points here now
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

mov ebp,esp

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |   ret addr     |
     ------------------
0x68 | original ebp   | <- esp and ebp point here
     ------------------
0x64 |                |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

push ecx

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |   ret addr     |
     ------------------
0x68 | original ebp   | <- ebp points here
     ------------------
0x64 |      0x7c      | <- esp points here now
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                |
     ------------------

sub esp,0x24

     ------------------
0x80 | char * argv[]  |
     ------------------
0x7c |   int argc     | <- ecx points here
     ------------------
0x78 |   ret addr     |
     ------------------
0x74 |                |
     ------------------
0x70 |                |
     ------------------
0x6c |   ret addr     |
     ------------------
0x68 | original ebp   | <- ebp points here
     ------------------
0x64 |      0x7c      |
     ------------------
     ~     ~   ~      ~
     ------------------
0x40 |                | <- esp points here now
     ------------------

The first seven instructions are the most confusing, and things become much simpler from here. Hopefully you have become familiar with the working of the stack. I'm going to omit stack pictures from the remainder of this tutorial.

add DWORD PTR [ecx],0x1

The add instruction works like the sub instruction, except instead of subtraction we are working with addition.

Because of the brackets, we are not adding 1 to ecx, but instead to the memory pointed to by ecx. If you remember from our stack, ecx points to the first argument we passed to main, or int argc. If you remember from our C code, after declaring int i, we incremented argc. Well, here's the assembly instruction for that line of code.

DWORD PTR because integers are 4 bytes (int argc).

mov DWORD PTR [ebp-0x8],0x0

Now we are entering our for loop. The first thing our for loop does is set int i equal to 0. Well, we know int i is a stack variable. We also know the common convention is to refer to stack variables as an offset from ebp. So guess where int i is on the stack? That's right, it's at ebp-0x8. Here we are setting int i equal to 0, the first part of our for loop.

80483df:   eb 17   jmp   80483f8

The jmp instruction is used to "JuMP" from one place in the code to another. I included the two bytes which form this instruction because I wanted to point something out. While we see "jmp 80483f8", which makes this instruction look absolute, it's actually relative. We are jumping 0x17 bytes ahead. 0xdf + 0x02 + 0x17 = 0xf8. Why add the 0x02? Because this jmp instruction is two bytes, and the jump starts after the jmp instruction.

We're going to do some skipping around now. Instead of following the assembly from first instruction to last, I'd instead like to go through the assembly in the order the instructions will be executed.

80483f8:   83 7d f8 09   cmp   DWORD PTR [ebp-0x8],0x9

The CoMPare instruction compares two values, and sets the x86 flags register appropriately. Yes, there's an x86 flags register. No, we aren't that concerned with it right now. Just know that the cmp instruction sets flags which correspond to a comparison between its two operands.

80483fc:   7e e3   jle   80483e1

The Jump if Less than or Equal to instruction will execute a jmp instruction if the x86 flags register has the appropriate flags set, indicating the previous cmp instruction compared one value that was less than or equal to a second value.

We're beginning to see exactly how our for loop executes on the processor. After setting the initial value, we jump immediately down to the comparison, or for our for () statement, "i < 10". The comparison actually comes out to "i <= 9". If this condition holds true, we perform another jump to where the beginning of our for loop code would be.

80483e1:   8b 45 f8   mov   eax,DWORD PTR [ebp-0x8]

eax is one of our general purpose registers we haven't mentioned yet. Here, we are setting it equal to [ebp-0x8], or int i.

80483e4:   89 44 24 04   mov   DWORD PTR [esp+0x4],eax

We are preparing to call the function printf. Printf takes two arguments. Remember, arguments are with the first argument closest to the top of the stack, and the last argument closest to the bottom. We are now positioning arguments on the stack. Int i represents our second argument in our printf() function call, and we are placing it closest to the bottom of the stack here.

80483e8:   c7 04 24 d0 84 04 08   mov   DWORD PTR [esp],0x80484d0

Here we are moving the value 0x80484d0 in to the memory where esp is currently located. We're placing this value into the stack without altering esp. You're probably wondering what is at memory address 0x80484d0. It's these 4 bytes:

0x25 0x64 0x0a 0x00

The C String equivalent would be "%d\n". I hope it looks familiar, because it's the first argument to our printf call.

80483ef:   e8 04 ff ff ff   call   80482f8

And here we go ahead and make the printf call. The call instruction will do a few things. For simplicity's sake, we will say it pushes the address of the next instruction on to the stack (the return address for the next function/procedure), and then begins executing the assembly instruction at the specified location. If you absolutely must know...

We don't really need to worry too much about this now. Just know that 0x80483f4 just got pushed on to the stack, and the next instruction that will be executed is 0x80482f8. When the procedure we call returns, its ret instruction will pop the return address off the stack, meaning the stack should by just as we left it before the call instruction.

80483f4:   83 45 f8 01   add   DWORD PTR [ebp-0x8],0x1

After the printf(), and before we do our next comparison, we need to increment int i. This is where that tiny piece of magic happens.

After this add instruction, we're back to our cmp instruction. We've already covered this, so let's skip ahead to the remaining six instructions, starting at the memory location 0x80483fe.

 80483fe:	b8 00 00 00 00       	mov    eax,0x0
 8048403:	83 c4 24             	add    esp,0x24
 8048406:	59                   	pop    ecx
 8048407:	5d                   	pop    ebp
 8048408:	8d 61 fc             	lea    esp,[ecx-0x4]
 804840b:	c3                   	ret

You should be able to understand what's going on now in these last six lines. If not, here's a quick synopsis to help you on your way:

• 80483fe: Zero out eax... eax := 0
• 8048403: Return esp to its original position, before we made room for stack variables. Need more help? Look at memory location 0x80483d2.
• 8048406: Get ecx back off the stack.
• 8048407: Set ebp to its original value before we entered the procedure. We're returning to our parent function, and it probably wants to know where its stack variables are.
• 8048408: Set esp back to its original value when we entered the main() procedure.
• 804840b: Return, which will pop the return address off the stack, and the next instruction executed will now be at that return address.

Take another look at the assembly instructions. You should now understand all the basics of what is happening at the processor.

In the next tutorial, we'll take a better look at what exactly is happening, with a little less abstraction and a little more detail.