2

I'm working on book "Hacking: the art of exploitation" and I'm trying to go with the writer and get my hands dirty.
I downloaded the source codes, when I compile them I got the same output C executables. But when I the disassemble, using GDB, they have different addresses and different disassembly codes! I do the same commands as in the book!

Btw I've compiled with the command: 

gcc -m32 -g code.c

I'm using 64bit PC and I learn x86 assembly.
So what's wrong? Is it because it's an old source code or what?

Yunnosch
  • 26,130
  • 9
  • 42
  • 54
Nidal Fikri
  • 53
  • 6
  • 7
    Different versions of the compiler produce different results. That book used a much older version of Linux. Unless you use the specific version they are using you'll see different results. – Michael Petch Jun 29 '18 at 06:12
  • I believe in the past one version of the book used Ubuntu Feisty 7.04 – Michael Petch Jun 29 '18 at 06:15
  • http://godbolt.org/ has compilers going back to about gcc4.1, which is a few years old by now. (Use `-xc` to compile in C mode.) That's probably not as old as the book, though. Probably the biggest thing is to [use `gcc -fno-pie -no-pie`](https://stackoverflow.com/q/43367427), if you're on a distro where the default is PIE, because that's a major change in code-gen. – Peter Cordes Jun 29 '18 at 06:15
  • 1
    @PeterCordes Art exploitation goes back to 3.3.6 – Michael Petch Jun 29 '18 at 06:16

1 Answers1

2

TL;DR You cannot match the exact same addresses of a binary compiled on a different machine than the one in the book, in normal circumstances.

Even thought the question is kind of abstract i will try to be as concise as possible. Please keep in mind that the reasons why the addresses between your local debugger and the ones in the book are numerous so the ones I listed bellow are definitely not exhaustive.

  1. ASLR (Address Space Layout Randomization)

ASLR what it does it that pretty much randomizes the higher bytes of the memory addresses (thus, it doesn't randomizes the offset between the functions-variables inside the ELF) as a security mechanism against well known binary exploitation strategies

Let's assume that we have some code compiled e.g. function_A and function_B (assuming we are on Unix-like system, and the flag of the compiler is just the one that you suggested): If you look at the ELF file right before it gets loaded in memory for example in the disassembler of gdb (so you are looking at the byte represendation of the ELF itself) You'll find function_A having an address similar to 0x0000ABCD and function_B an address similar to ```0x0000EF12`. If you set a breakpoint in main ,run the binary and check the addresses again you'll observe that the addresses have now changed to something like 0xUUUUABCD, 0xUUUUEF12, U = Unknown. P.S. GDB by default disables ASLR, so to observe a different address load, you have to close it and repeat the process again, or disable ASLR from inside of gdb.

  1. Compiler changes

The book was published around 2003 for the first time if i can recall correctly. Since then the GCC compiler has changed a lot. Considering the fact that even small changes on the code of the compiler can have a significant difference on the executable that it produces. It is non-trivial to understand why for example the assembly representation of function_A may not even be close to it's representation almost 20 years ago. ( I do know that this is a bit of abstract) but looking more into this would take me a book to explain, but I can suggest you to take a look at Compilers: Principles, Techniques, and Tools aka The Dragon Book.

  1. OS Environment

Since the publish of the book Ubuntu (and in general Linux distros) versions has changed a lot also they evolved, and added features (and removed others) that affect e.g. the loader which responsible for loading the program on RAM. With that being said keep in mind that changing an OS, - especially if you change family of Linux distributions (e.g. going from a Debian-based system to a Fedora-based) - affects the way the binary is loaded in memory , that of course differentiates the addresses in memory.

Shad3
  • 53
  • 8
  • 1
    Other examples of modern compilers not matching old books: [Compiling C to 32-bit assembly with GCC doesn't match a book](https://stackoverflow.com/q/64109864) (my answer discusses some of the same things as yours, about compiler changes and system defaults), and for this book in particular: ["Hacking: The Art of Exploitation" - Assembly Inconsistencies in book examples vs. my system's gcc](https://stackoverflow.com/q/27053865) / [Confused by \[ebp-0xc\] instead of \[ebp-4\] in Art of Exploitation example](https://stackoverflow.com/q/66090921) – Peter Cordes Jun 10 '21 at 16:42
  • 1
    ["Art of Exploitation" disassembly example isn't the same (C code)](https://stackoverflow.com/q/6975617) – Peter Cordes Jun 10 '21 at 16:42