Here's the output:

enter image description here

pwndbg> p give_shell
$5 = {void ()} 0x8049217 <give_shell>

So if I write this payload python2 -c "print 'A'*104 + '\x1B\x92\x04\x08' + '\x17\x92\x04\x08'" > fatman

and run the program in gdb with this payload. Rather than spawning a shell it gives the following error Idk why.

enter image description here

Why is it happening? and how to spawn a shell? Here's the source code:

#include <stdio.h>

int main() {
    int secret = 0xdeadbeef;
    char name[100] = {0};
    read(0, name, 0x100);
    if (secret == 0x1337) {
        puts("Wow! Here's a secret.");
    } else {
        puts("I guess you're not cool enough to see my secret");

void give_shell() {

I compiled it using gcc -m32 -no-pie -fno-pie -g -fno-stack-protector feed_me_more.c

Here's the checksec:

pegasus@pegasus:~/Documents/ReSINC_CTF$ checksec --file=a.out
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   40 Symbols        No    0               1               a.out
  • @SirMuffington I had added the checksec. It's an AMD machine Commented Jun 25, 2023 at 9:57
  • What is at 0x804921B? I assume you put this in your payload for a reason? The simplest way to determine what is going wrong is to put a breakpoint on (or after) read() and step through. You can then observe the stack being corrupted and which registers are controlled when the main function returns
    – wireghoul
    Commented Jun 27, 2023 at 0:21
  • 0x804921B is just extra 4 bytes to overwrite the and align the stack. What the problem is '\x17\x92\x04\x08' this should be executed. This works when I compile as x64. padding till seg fault + 6 bytes (give_shell) function address. It works as intended. But when I compile as 32. padding till seg fault + (give_shell) function address. (6,4,8) bytes nothing works the last bytes gets corrupted and modified of the payload Commented Jun 27, 2023 at 16:58

1 Answer 1


It looks like your alignment is off...

0x804921B is in ECX and ESP 0x8049217 is in EDI

Perhaps you based this on where you had 0x43434343 positioned. However if you pay attention you can see that again, this is the address of ESP and the reason you crashed is because 0x43434343 is not initialized memory. In order to actually alter the execution of the program you would need to control the EIP register, or use a return oriented programming (ROP) payload.

Perhaps try using a longer string to see if you can overwrite EIP. Per my comment above you can always set a breakpoint inside main() and step through the execution in your debugger to see how you're corrupting the stack and at which point you control which register to determine where you went wrong.

  • Do I have to manually check the payload with longer and shorter string? In x64 it just works fine. I use padding till it gives seg fault. Then I put the 6 byte address where I want the program flow to go. But in x32 The last byte just gets changed for some reason. I had also tried using gdb and breakpoints but couldn't figure it out. As the last byte was getting changed and the library functions are a lot to step into. I had tried ni, si but couldn't fit in my desired payload into EIP Commented Jun 30, 2023 at 14:25
  • In x32 the address (and registers) are 32 bits (4 bytes), opcodes are different, etc. You can't just throw the x64 exploit at it and expect it to work
    – wireghoul
    Commented Jul 3, 2023 at 4:50
  • I am not expecting it to work. Rather I want to learn and know how it will work on x32. Commented Jul 28, 2023 at 21:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .