Hacking: the Art of Exploitation

pointer/address to be %p not 0x%08x.

By default, gentoo linux amd64 will set multilib USE flag. You'll have a multilib glibc and gcc. Then to compile and link a program with gcc, just add -m32 parameter to gcc.

gcc -m32 test.c

gcc actually have some functions built into it. It will use its built in version for some functions like printf. Even if you forget include header files, it will be compiled but give out a warning.

~/Work/project/hack ⮀ gcc -g -m32 -o firstprog firstprog.c
firstprog.c: In function ‘main’:
firstprog.c:7:5: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]

To test hacking skills like stack overflow and so on on a modern x86\₆₄ machine. You have to cheat.To disable the stack smashing prevention(SSP) by gcc, you can simply specify a parameter -fno-stack-protector

gcc -fno-stack-protector test.c

To let the stack be executable, you have two choices:

1. add -z execstack parameter to gcc when compiling.
2. Using execstack to set executable stack flag of ELF binaries and shared libraries

Both will work, It depend on you which to choose.

If you check the book carefully later, you'll find some technics to prevent exploitation. One of them is ASLR.

To disable (Address space layout randomization)ASLR globally:

echo 0 > /proc/sys/kernel/randomize_va_space 

Or just run the binary file using setarch.

Please refer to the References and man setarch.

One of my observation is that if you run a 32-bit program on 64-bit system, the address in the memory will differ a lot from just 32-bit system.

According to my experience, the memory address ranges from about 0x804a014 to 0xffffdff8, .data and .bss will locate at around 0x804axxx. But the stack bottom will be at around 0xff7fcxxx. What's important is that environment variables will be at the bottom of memory until 0xffffdff8. 0xffffdff8 will be the filename of the execute file.

There are some other differences from the book. One of these is the length of file change 1, the address of environment variable for shellcode will change 1 byte.

I don't know why things like this, I'll try to find more about it and ask it at StackOverflow. But that's what I get after several tests, your machine may differ.

I find I can't success on the exploitation about dtors. The destruction function address will be in .fini_array section. Note: objdump will show addresses in little endian. So address 0x08048473 will looks like that:

Contents of section .fini_array:
 8049ef8 73840408                             s... 

Furthermore, because of cpu's NX feature, when you try to modify .dtors or fini_array section, you'll just get a segfault.

Last thing I have to mentioned is that libnet-1.0 use too much u_long. u_long will take 8 bytes on a 64-bit machine but 4 bytes on a 32-bit one.

You have to care about that because it will build tcp header with incorrect length of source address and destination address.

I don't know how nemesis(which depends on libnet-1.0) works well on amd64 machines…

To compile and link with libnet-1.0 on gentoo amd64 architecture, try something like this:

gcc `libnet-1.0-config --defines` -o rst_hijack rst_hijack.c -lnet-1.0 -lpcap

When you want to try arp sproofing or arp poisoning, enable the ip forward for the kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward 

bash version 2 will drop previlege when run with setuid. So lots of root shell will falls to normal user without setresuid.

Examine by man before you try the program in this book.

For example, in update_info, add (void *) in to avoid warning. In connectback_shell.s the connect syscall won't save file descriptor in eax. Lots of include was lost in this book…