How Computers Think: A Liars Walk Through x86 Assembly

 

                                                                                    So, yeah. The artist found out about digital art.

 

 

"To teach is to lie."

 

A few days ago I promised to talk a bit about a simple Assembly program.

And talk I shall!

First off, let's just get out of the way what that code is doing:

It takes any number of integer positive values as parameters and adds them.

So, if you run the program with ./<program_name> 40 2 (which we shall in a bit) it will print out the answer:

If this were a Python program, it would be simple as can be. But Python is withholding from you a lot of what is happening behind the scenes. And we want none of that. We want to see stuff as it is happening.

 

First of all, a couple of disclaimers:

- This code isn't as simple as it could be. It's in fact part of a series of lessons I'm going through in order to review and solidify my ASM and debugging knowledge.  They are part of a NASM tutorial (ASMtutor), which I highly advise — it's quite carefully made, without major errors (very common in basic ASM stuff) and which guides you in a smooth manner towards greater knowledge. You can find it here.
- The code I'm using can be found here.

- To create a compiled binary of this code, in particular of the files functions_v1.asm and 13_atoi.asm, you need to download those two files and run: 

nasm -f elf 13_atoi.asm

ld -m elf_i386 13_atoi.o -o atoi

 This will create an executable named atoi, which you can then run as explained before.

- You should know a bit about binary and hexadecimal. Please take a quick gander at this. Knowing how to quickly translate between them will really help to inspect the debugger.
- And speaking of which, I'll be using GDB with GEF and I advise you to do so as well. If you already rock on GDB you probably don't need it. But then again, I highly doubt you'll be reading this if you already have mastered GDB. 

As for GEF, it will make the debugger much more pleasing to the eyes, and your code easier to follow.
- To finally start the debugger (GEF) with our program, we'll run:

- My focus isn't a 'deep dive' into Assembly. I want to give you the very basic and essential tools to be able to go through this code, instruction by instruction and be able to understand how the computer is 'thinking'. In order to do that, I'll give you some basic tools.

- Speaking of which, here is a pdf with the few commands and concepts you'll refer to in order to be able to follow through the code.
- Functions in Assembly are interesting. You can call a function or jump into a function (check the PDF), but also can just enter a function because you're going through the code flow and there is no call, no jump (or there isn't a reason to jump). So, for example, in this case:

You have here a comparison and you are checking if eax is equal to 0, when you do cmp eax, 0. Then you have a jump not zero. If eax is NOT zero, then you jump elsewhere to the function divideLoop. But if eax IS in fact zero, then you just move along that grocery shopping list to the next item on the list. Therefore, you enter the function printLoop and decrease ecx by 1. 

 

On the other hand if printLoop actually had a dot behind it (.printLoop) it would be a function inside of whatever function we are in, and couldn't be called from outside of that function. If in doubt, dig a little deeper into Assembly. 

- You might also need a quick contextual/theoretical rundown, so here it goes:

Assembly is the lowest level code you can have that is still human-readable. Below it is the world of ones and zeroes, and above it the world of different programming languages and their way to read and write programs.

In assembly, we're working in the so-called User Space, but sometimes we need to give control to the Operating System through system calls. To do that, we use interrupts (Here is a link to a nice Linux system call table. If you use Windows we can't be friends, sorry). You won't really need that table in order to follow along and read the code, but it sure helps. We only use two syscalls in this code — one for writing to the terminal, and another to exit cleanly. (look up: do the registers change after the OS is done with them?).

When the syscall happens, the OS takes control of the program, and uses the stack and your registers. After that, you cannot be 100% sure of how all registers will be, so if it matters to you, like what happens in other situations, make sure you save those registers into the stack and get them back after the OS lets go of control and returns it to User space.

 

There are a couple of bitwise operations - basically XOR ('exclusive or'). To learn more about bitwise operators, check this page. And if you like computer games and are even slightly interested in electronics or logic, then take a gander at this game. It's great fun.

But, again, you don't have to jump into bitwise operations to read this code. Just do a mental substitution. Whenever you see, for example xor eax, eax it's basically the same as taking zero and placing it in the register eax or, in other words, doing mov eax, 0. 

Learn boolean logic, bitwise operations, and everything else because you want to and because its fun. :) 

 

What is a register? What is the Stack? You probably heard about those two terms before. Here's a very quick and dirty analogy:

Imagine you're sitting at a desk and I'm telling you to remember things, like a name, then a number, then an address, then another name. Sure, you can do it for a while. Your short term memory will be able to memorize some stuff before it's too much stuff to handle. Those places where you're storing this easy-to-remember, short-term memory stuff are the registers. Registers are temporary containers for fast memory access. Incredibly fast memory access. A bit like short-term variables on steroids.

But what if I start giving you too much stuff to remember? Then you are allowed to write whatever information I tell you on small pieces of paper, as long as you store them properly on a receipt-spike (also known as an order-spike). You've seen them before in restaurants. Something like this:
 

 

                          Analogies R Us: each strip of paper a memory location, an integer, etc

 

This stack, or this order-spike, uses a LIFO system, meaning Last In First Out. Whatever last piece of paper with information you have pushed into that pile, is the last one you can pop out and examine.

Neat, no? So, you can store x amount of things for very quick access inside those registers, and you can push whatever you can't hold in quick access memory into that pile, and then you can take it our and again place it in a register if you so wish (actually, you push copies of those values — the originals remain in registers unless you clear them).

All that I've said so far is to be taken with a pinch of salt. Not only because these last bits are an analogy, but because, like I said in the beginning, to teach is to lie. I have to omit stuff in order to let you do some progress.

Imagine us teaching Math in class and instead of telling kids all over the world that you can't divide by zero, we instead said, there are several instances in mathematics where dividing by zero is perfectly sensible, and then described said instances. Can you imagine the faces of those 7th graders? Nothing would be retained.

By lying to them, they learn a useful rule and important aspect of mathematics, and when they advance in their mathematical careers, they get to learn at least of one way to actually divide by zero.

It's the same here. I'm skimming a lot of fat in order to draw an understandable picture, and to let you (if you so wish) take your first steps in Assembly, which I truly love.

Got any questions? Stuff you don't understand? Stuff you'd like to see? Shoot them in my general direction. Search on Google, use an LLM ("gulp, LLMs?! But aren't they the devil?". Look, I was here when Wikipedia first came up and academia was having a fit over it. I also survived using AltaVista back in the 90s. You'll do fine with LLMs and live to tell the tale).

As I've shown in one of the pictures above, we'll be using our program to add 40 to 2 and to find out the Answer to the Ultimate Question of Life, the Universe, and Everything.

I won't go through the whole code. It would serve little purpose and, besides, you need to walk the walk.

                                                     Ah, Jayne... you look young.
 

 So, back to business!

 

You need to:

- download the two .asm files;

- compile them into a binary file;

- install GEF (GDB probably already installed);

- download the PDF with some information;

- Run GDB and check what happens to the Registers and to the Stack as you step into the program.

 

And that's it! We got a party going.

 

Ok, let's pretend anyone is actually reading this and actually is inspecting the program with the debugger. You run the code in terminal to open the debugger, then when it opens, you write start and press enter.
What might you be seeing at this point in time? Something like this:

                                        Already regretting your very recent life decisions? Don't! This stuff is fascinating.

What a bloody mess! I know. Don't worry. The first time I started looking at this I was pretty confused as well. But let's first try to get some 'unhelpful' information out of the way (ahem, teaching is lying) and focus on the meat of this and at what we'll be focusing on exclusively. So, clean-up time!

 

                                       Some breathing room, at last!
 

Aha, so what do we have here?

We have 3 different screens:

- Registers

- Stack

- Code

 

Lucky us! Because that's exactly what we want to follow as we're moving along our code. Let's start with the registers. If you've looked at your PDF, you'll see the stars of our show there. 

Register Screen:

esp is the stack pointer and it is always pointing to the top of the stack. It's not holding the value at the top of the stack, which is the value 3, but it's holding the value 0xffffd0f0.

Huh.. interesting. If you look at the menu below, you'll see that that's the exact stack address of its topmost value. Memory position 0xffffd0f0 is the topmost piece of paper (like its identifier) and in it we have written the value 3 (more on why 3 later). Everything else we care about is (apparently) 0 for now, so let's move on.

Stack Screen:

Remember that pile of papers stuck at the order-spike? This is it.
 Here's an example of one of these lines:

0xffffd0f8│+0x0008: 0xffffd2e0  →  0x32003034 ("40"?)

Let me explain it to you. 

0xffffd0f8 → memory location in the Stack. This is represented in 4 byte intervals, since we're in a 32 bit program

+0x0008 → Memory offset from the top of the stack. This means that we're in a position 8 bytes above the position of the top of the stack (0xffffd0f0). As we add stuff to the stack the memory values go down. This is an important quirk that you would do good in remembering. Also note that while this has the stack facing upwards, sometimes you'll see it upside down (which makes the memory values 'growing' down appear to be a bit less strange).

0xffffd2e0 → What is stored in that stack position (our piece of paper). In this case it is a pointer to a string. That string is '40'. So, in other words, there is a location in memory that is storing the string '40' and in this stack there is a pointer pointing to the first character of that string, or '4'. Read on, it will be made somewhat clearer. You don't need to know in depth what are pointers, etc to be able to read this program, but knowing these things de-mystifies them plenty and makes your life easier and more enjoyable. 

(bonus cookie points for you if you can explain why, as you go up in the stack you go from  0xffffd2e3 to 0xffffd2e0, a small 3 byte jump, and then follow with a big big jump from 0xffffd2e0 to 0xffffd2a5 a 59 byte-sized jump)

0x32003034 → Well, I see a 40 and the beginning of a 2. :) Let me explain:

As 40 and 2 were used as arguments in our program, they were added to the stack. But they weren't added as integers. In fact, they were added as ASCII characters. 

 We're working with hexadecimal characters and we're looking for the value 40, right?

So, 0x32003034. You'd possibly expect to read from left to right, but we're working in little-endian here, so in fact our number will be presented right to left. And if we look at that table, we would be reading (now reversed) 4, 0, NUL, 2. That NUL is the null byte which marks the end of that string. And I'd bet you my breeches that after that 32 there will be immediately to its left another 00, since these strings are being stored next to each other. If you're paying attention, you'll know I was cheating and you won't want to bet against me as you read the next value in the stack 0x48530032 and see, in black and white that '00 32', which translates to the number 2 (in decimal). You might be tempted to continue translating that line and read 'SH..'. Interesting, no? But I'll leave it to you to find out more.

But you might be asking, why is the Stack in this initial state? And that is a perfectly valid question. As we load up our program and enter its two parameters 40 and 2, we have automatically added 4 things to the stack, in this order (from bottom to top):

- a pointer to the last parameter (our third argument, or argv[2]);

- a pointer to the first parameter (our second argument, or argv[1]);

- a pointer to the program itself, its full path, in fact (our first argument, or argv[0]);

- the number of arguments  (argc).

As you start reading the program and debugging it, you'll see the stack add more items and remove them. 

Code Screen:

This is where you follow your code. the green arrow and green letters shows you where you're at in the code, and the red dot tells you that there's a breakpoint here. If you're into learning more about GDB (please do) then you can try this link as well. This line of code is the next to be executed. And as you press si ('step into') you'll move along the code, Assembly line by Assembly line.

 

So, let's do just that and run si some 4 times, until we get to that compare (cmp). How will that code look like? That Stack, will it change? And the Registers?  Let's see:

 So, what happened? We started by popping the value on the top of the stack and placing it in ecx. So, in that next step you'll see that ecx = 3. Then we do the same and place that value, a pointer to the function name, in edx, removing it from the top of the stack. Finally, we decrease ecx, basically subtracting 1 to the value within and we xor edx, edx which is basically the same as doing mov edx, 0. ecx is holding the number of variables used in our Math and edx is emptied for future use. See how that works? If we push, we take the value in the register and copy it into the stack, and if we pop we remove the value from the stack and place it in the designated variable.

I'm stopping here with the guided code lesson. I'm leaving it up to you. You do have all the tools that you need to do so.

Remember tidbits like: if you call a function, you jump to that function, instead of continuing down the lines of code, but you place the line of code right after the call on top of the stack (the return address is pushed onto the stack). When you hit the instruction ret, on the other hand, you pop whatever value is on top of the stack and go directly to the line that is referenced in that value (a pointer to a memory value). 

GEF will be kind enough to tell you when a jump instruction isn't fulfilled (which means that instead of jumping into a function you continue reading the code below that jump).

Pay also attention to the name of the function and on how far you are away from its start. For example, in this case, I'm inside the inner function .multiplyLoop, inside the function atoi:

 

 

Here's some more stuff you might want to get into:
 

- what is the register eip doing?

-  What's with bl, BYTE PTR [esi+ecx*1]? Can you guess what's happening there?

- Pay attention to where you're going and what's happening when you run a ret instruction.

- Perhaps write down all the commands in a piece of paper and try to 'guess' how the flow should work until the very last operation. Then compare to what you see on GDB. Does it match?

And that's it! You're now ready to start discovering more and more about this wonderful world, or you're thinking that anyone that likes this must be a bit crazy.



Either way, you cannot unsee it now. 
Have fun and hack away!

Wherein We Face A Lindwyrm: don't do LeetCode

 

                    The Lyndwurm. Let's face it sooner. Not later.

Before diving into LeetCode, let me tell you this post was initially going to be about my journey completing a series of 30 Assembly CTFs on pwn.college. It still is, in a way, and I highly recommend that site to anyone interested in hacking and low-level programming (check that site─totally worth it). 

But somewhere along the way, I decided to shift the focus. So, bear with me while we explore LeetCode.

Let’s start with the disclaimers:

• I’m happily employed.
• My knowledge of the hiring process is limited to my own experiences and what I’ve observed.
• Take everything I say here with a grain of salt.

---

What Are LeetCode Problems?

LeetCode-style problems are algorithmic and data structure challenges, often used in technical interviews to (supposedly) assess problem-solving skills, logic, and coding efficiency.

I’ve tried LeetCode. I even did a fair bit of it back in university while studying Python. And I’m here to tell you: it’s not for me. It's probably not for you, either.

Here are 10 reasons why I’ve left LeetCode by the wayside:

---

1. I’m not a programmer, nor do I want to be one.

I work in IT and am aiming to become a Cybersecurity professional, specifically a Reverse Engineer/Malware Analyst. In this realm, LeetCode is of very limited relevance, if any. My focus is on low-level code, systems, and security—not cranking out optimal algorithms for abstract, byte-sized, problems.

---

2. Time is sacred, and LeetCode doesn’t fit my priorities.

Mastering LeetCode takes time—lots of it. As someone who obsesses over how I spend my time, I refuse to pour hours into a skill I find doubtful in utility for my goals. Instead, I could be:

• Diving deeper into malware analysis.
• Learning more about CPU internals.
• Experimenting with Reverse Engineering tools.
• Or even doing other wholesome hobbies like: fishing, watching paint dry, or fine-tuning push-ups.

---

3. It consumes mental bandwidth I’d rather use elsewhere.

Focusing on LeetCode takes up space in my brain that I could dedicate to something more relevant or enjoyable. Cybersecurity is vast, and every moment I spend on coding puzzles is a moment I’m not spending on fun puzzles.

---

4. There are other ways to demonstrate my skills.

I maintain a public GitHub with projects I’ve built. If someone needs proof of my abilities, I can show my work or create something on demand. Writing scripts or automation tools in a real-world context is more relevant to my career than solving arbitrary LeetCode.

---

5. Secure, readable code > Clever one-liners.

LeetCode often rewards speed and brevity, which can lead to unreadable, messy solutions. Writing secure, stable, maintainable code that other humans can understand is far more valuable in real-world applications.

---

6. In cybersecurity, CTFs are the way to go.

Capture The Flag challenges (CTFs) are like games. They’re fun, align with the hacker spirit, and teach you practical skills. I’d rather do CTFs all day than grind through LeetCode puzzles.

---

7. Better ways to assess pressure and skills exist.

In addition to several other assessments, my current company included a 1.5-hour test during the hiring process that challenged me to work under pressure, adapt to new situations, conduct research, and document my process. It was hard, fun, and incredibly insightful. If they had instead asked me to solve 10 LeetCode problems, they wouldn’t have learned anything about my actual skills. No joke—this test was fantastic.

---

8. I’m not here to compete with kids who have all the time in the world.

If I have two free hours, I’ll use them to play in my malware lab—not grind Python or C snippets on Codewars. I have nothing to prove to anyone, and I’m not interested in chasing someone else’s benchmarks.

Years ago, I participated in a BJJ tournament and won (blue belt +40 years category). At the end of the tournament, all the blue belt winners were allowed to face each other in a 'free-for-all styled' match. I said no. I had nothing to prove. I knew the outcome, too─there was no point in fighting guys who had trained as long as I had but were 20 years younger and weighed 20 kilos more. 

Here's what I looked like after winning in my category:

                                                        Cute, huh? Third place didn't even get a medal. He got a broken rib and a trip to the hospital.

---

9. I’m not missing meaningful opportunities.

Sure, some companies prioritize LeetCode skills, but those are likely not the places I want to work at. I’d rather focus on preparing for roles that value my expertise in cybersecurity and low-level systems.

On the flip side, if I do receive a job offer from a company looking to assess my "cyber skills," I’ll be in a much stronger position if I’ve invested my time in honing those skills, rather than spending it on LeetCode.

---

10. Burnout is real.

Burnout is pervasive in IT. I’ve seen people so drained by their work that all they want is to clock out and forget anything technical. They crave time for hobbies, family, and friends, leaving the techie stuff for when it’s absolutely necessary. Not me. I dive into reverse engineering because I genuinely enjoy it, but I make sure to balance it with other hobbies, family time, and necessary downtime. Chasing someone else’s dream isn’t worth sacrificing my mental health.

---

Final Thoughts

For those who insist we must suffer through things we hate to secure a “dream job,” I leave you with this quote from Game of Thrones:

Wherein We Finish The Bandit Game: OTW, part 2

 

Like the title says, I’ve finished that game, and I still maintain that I shouldn't just come here and write my step-by-step flag-finding process. That wouldn't help any reader. Not really.

Besides, in a few seconds, I'm pretty sure you could google several walkthroughs if you wanted to.

What would be the point of that, though? It’s like solving a Rubik's cube not through experimentation and discovery, but by following some ‘recipe’ online.

I'm not going to claim it would be a complete waste of time, but it wouldn't be ideal—for you. Not for me. I'd be fine.

Don’t get me wrong: I have my own write-up of how I found the various OTW flags, in some detail. I might even add it to some half-buried folder in my GitHub account. Why? Because while I was writing, I was trying to find ways to explain my thought process to others—and that’s meaningful—to me. It helped get my thoughts straight.

Instead, I want to offer some ideas, concepts, and approaches to better help you progress and learn from this game.

It is not a hard game. But that’s like saying most mathematics isn't hard. It’s a question of level and having a good grasp of the basics...

Anyway, without further ado, I’ll share a few hints, tips, and ideas to guide you through OTW’s Bandit game. Remember, these are my tips—not some unspoken truth or divine revelation. It’s what I would’ve liked to have hear before starting this trip:

---

1.

This game deals a lot with Linux CLI commands and basics, a few networking fundamentals and protocols (netcat, nmap, SSH, etc.), and finally some version control (Git).

2.

Take your time. Don’t rush to the flag if you can. Ask yourself questions. What do you know? What would you like to know? How could you get that information you're after? Do you understand what the problem is and what's 'holding you back'?

3.

Use the man pages, use sites, and use LLMs. Ask questions as long as you're not just looking for direct answers. It’s fine to ask how to write a specific command or to search for that command and its arguments. But it’s not okay to just paste the challenge and ask ChatGPT or some forum users how to solve it.

4.

Sometimes the end goal is less ‘fun’ than other parts. You’ve been blocked from accessing X? Oh, you found a way around that. Great! Now you have the flag. A question you might ask is: how exactly did the ‘gamemaker’ block me from accessing X? Can I find out how they did it? Can I at least catch a glimpse of that process/command/block/thinggie?

5.

Is there another way to get to the solution? Often there isn’t, but sometimes there is. Have you seen how quickly a program runs when it's feeding useless output to /dev/null versus when it’s sending everything to stdout? You might be surprised.

6.

Ask where you are. What permissions do you have right now? What can you and can’t you do? Where do you want to go? Do you need to ‘talk’ to a service? Does that service need to stay up while you're working? Is it a one-shot thing? How do you ensure that the process or program gets interrupted so that you can inject some code into it? Some challenges require you to make a program run in a (somewhat) unintended way. Try stuff.

7.

At some point you might feel annoyed, frustrated, irritated, or tired. That’s okay. Really, it is. Don’t give up. Are there any hints from the gamemakers? 

'Go check SSH?'

Alright, then go check it. Stop what you're doing (trying to find the flag at all costs) and go read about SSH. I'm not even kidding; it’s really cool to know more about SSH. Check the man page. Think of all the things you could do with its arguments. Is there anything you’d like to try or test? Test it. Try it. Did it work? Why? Why not? Ask an LLM or another person (a forum, etc.) how to use that parameter, and so on. That leads nicely into the next tip.

8.

Step back from a challenge if you're not seeing the answer right now. I’m sure you're not doing this game to get job X. At least not tomorrow. Take your time. Think about other stuff, then come back to the ‘problem’ at hand. In another life, I was a theater director and acting teacher. A student once asked me, "How do I act?" I told her to orbit around her object of desire. I took a lighter and got it so close to my face that I couldn’t see it anymore. I told her that might be too much, but that she could still perhaps learn from it (she could touch it, at least. That's something). 

Stand back from it. Further back until you can't see it anymore. Now you have to imagine the lighter, perhaps think of what you'd like to check the next time you get closer. 

You get my drift. This stuff isn’t rocket science. Don’t just stare at a problem, all sweaty, until your eyes bleed. Take a break. Walk away, look again, look away, look closer, and spin it around.

9.

Remember, this isn’t just for fun. It’s also for learning (but that is fun, right?). Again, take time to learn these tools, and above all, take time to learn how they work—their protocols, how they communicate, what you need to set up for them to work at all, etc.

10.

Remember when I told you to look beyond the problem and try different things? I’m interested in Reverse Engineering. You can bet your breeches I used radare2, created objdumps and other tools to inspect binaries and programs created by the gamemakers. Not necessarily to find the flag, but to understand what makes those programs tick—why they do what they do.

---

Take your time, one moment at a time, and have fun. If it stops being fun, that’s okay too. The internet is filled with games and learning tools.
Go find another one that strikes your fancy.

Often it's not the game, it's your perspective on the game. 

As I explained in part one, I got hacked while navigating my way through lvl.20, and I can tell you that I learned more from that interaction and the hours of study that followed than perhaps in 10 or so levels of Bandit combined.

That's it. I'm going to play Leviathan.

The world’s your oyster—or something.