I am looking at the assembly code of a heap-overflow challenge (heap3 in Protostar) which uses a vulnerability of an old version of dlmalloc to execute the exploit. Below is the assembler dump:

0x08048889 <main+0>:    push   ebp
0x0804888a <main+1>:    mov    ebp,esp
0x0804888c <main+3>:    and    esp,0xfffffff0
0x0804888f <main+6>:    sub    esp,0x20
0x08048892 <main+9>:    mov    DWORD PTR [esp],0x20
0x08048899 <main+16>:   call   0x8048ff2 <malloc>
0x0804889e <main+21>:   mov    DWORD PTR [esp+0x14],eax
0x080488a2 <main+25>:   mov    DWORD PTR [esp],0x20
0x080488a9 <main+32>:   call   0x8048ff2 <malloc>
0x080488ae <main+37>:   mov    DWORD PTR [esp+0x18],eax
0x080488b2 <main+41>:   mov    DWORD PTR [esp],0x20
0x080488b9 <main+48>:   call   0x8048ff2 <malloc>
0x080488be <main+53>:   mov    DWORD PTR [esp+0x1c],eax
0x080488c2 <main+57>:   mov    eax,DWORD PTR [ebp+0xc]
0x080488c5 <main+60>:   add    eax,0x4
0x080488c8 <main+63>:   mov    eax,DWORD PTR [eax]
0x080488ca <main+65>:   mov    DWORD PTR [esp+0x4],eax
0x080488ce <main+69>:   mov    eax,DWORD PTR [esp+0x14]
0x080488d2 <main+73>:   mov    DWORD PTR [esp],eax
0x080488d5 <main+76>:   call   0x8048750 <strcpy@plt>
0x080488da <main+81>:   mov    eax,DWORD PTR [ebp+0xc]
0x080488dd <main+84>:   add    eax,0x8
0x080488e0 <main+87>:   mov    eax,DWORD PTR [eax]
0x080488e2 <main+89>:   mov    DWORD PTR [esp+0x4],eax
0x080488e6 <main+93>:   mov    eax,DWORD PTR [esp+0x18]
0x080488ea <main+97>:   mov    DWORD PTR [esp],eax
0x080488ed <main+100>:  call   0x8048750 <strcpy@plt>
0x080488f2 <main+105>:  mov    eax,DWORD PTR [ebp+0xc]
0x080488f5 <main+108>:  add    eax,0xc
0x080488f8 <main+111>:  mov    eax,DWORD PTR [eax]
0x080488fa <main+113>:  mov    DWORD PTR [esp+0x4],eax
0x080488fe <main+117>:  mov    eax,DWORD PTR [esp+0x1c]
0x08048902 <main+121>:  mov    DWORD PTR [esp],eax
0x08048905 <main+124>:  call   0x8048750 <strcpy@plt>
0x0804890a <main+129>:  mov    eax,DWORD PTR [esp+0x1c]
0x0804890e <main+133>:  mov    DWORD PTR [esp],eax
0x08048911 <main+136>:  call   0x8049824 <free>
0x08048916 <main+141>:  mov    eax,DWORD PTR [esp+0x18]
0x0804891a <main+145>:  mov    DWORD PTR [esp],eax
0x0804891d <main+148>:  call   0x8049824 <free>
0x08048922 <main+153>:  mov    eax,DWORD PTR [esp+0x14]
0x08048926 <main+157>:  mov    DWORD PTR [esp],eax
0x08048929 <main+160>:  call   0x8049824 <free>
0x0804892e <main+165>:  mov    DWORD PTR [esp],0x804ac27
0x08048935 <main+172>:  call   0x8048790 <puts@plt>
0x0804893a <main+177>:  leave
0x0804893b <main+178>:  ret
End of assembler dump.

Now looking at the assembler dump what I can understand is malloc() and free() are linked to the binary statically, while strcpy() and puts() are linked using PLT.

When I try to compile this program using it's source code, I get malloc@plt and free@plt, which when compiled on my local machine uses the wrong version of dlmalloc. The challenge is compiled and placed on a Debian distribution which we have to boot up in order to try this challenge but I would like to try it on my local machine. Can someone explain how I will be able to compile it so that malloc() and free() are statically linked with the binary.

  • Why would you rebuild the binary ? It is enough to copy it to your machine and try it if you want.
    – perror
    Jan 20, 2020 at 14:19
  • Thing is copying from the virtual machine is a big pain for me and I would like to create my own versions of this particular challenge too
    – Rev-time
    Jan 23, 2020 at 6:23

1 Answer 1


You are given only the code of the main() and winner() functions because only these ones are relevant for the exploitation. But, of course, the binary embed also the code of malloc() and free() which are taken from the original Doug Lea's malloc() function. If you want to reproduce the same binary with the code, you may need to add the code of the original Doug Lea's malloc() as well.

You can find the source code here.

  • Thank you for your help. Now this might sound like a stupid question, but could you please explain how I will be able to embed the source code into the binary. I am not quite familiar with using gcc properly
    – Rev-time
    Jan 23, 2020 at 6:25
  • @Rev-time this is probably question for StackOverflow or SuperUser since it does not involve reverse engineering
    – Igor Skochinsky
    Jan 25, 2020 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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