Two builds, one instruction stream: where GCC actually records a non-executable stack

The frame arithmetic is worth doing by hand, because it prices the bug. `handle_client` subtracts 0x160 from rsp, which is 352 bytes ^[10][14]. The 256-byte `request` array is addressed at rbp-0x150 ^[12][2], 336 bytes below the frame pointer, so it ends at rbp-0x51 ^[15]. The socket argument is spilled to rbp-0x154 ^[11]. That leaves one contiguous region big enough for the 64-byte `buffer`: the 80 bytes between rbp-0x50 and rbp. So the destination starts no more than 80 bytes under the saved frame pointer and no more than 88 under the saved return address, meaning 89 written bytes are enough to reach it ^[16]. `recv` is capped at 0xff ^[13], and `strcpy` appends a terminator, so up to 256 bytes can land in those 64: 192 past the end ^[17]. Eighty-nine needed, 256 available.

None of that arithmetic moves when the flag changes. `-z` is a pass-through to the linker ^[5], so there is no codegen difference to find in the first place, and `execstack` works by removing a default the linker would otherwise apply ^[6]. That is why each build step in the script is paired with `readelf -l` rather than a second `objdump` ^[7][22].

It is also worth being clear about what the protected build does not buy. The source itself explains the exploit as overwriting the saved return address to redirect execution ^[24]. Refusing to execute bytes on the stack removes one place to put a payload; it does not stop the write, and the 89-byte reach above is unchanged either way.

The material supplied stops mid-disassembly, at the `call` to `recv@plt` ^[21], so the header dump the whole exercise points at is still owed. Which is fine, because this is the rare mitigation you can verify yourself in two commands: build any object twice, once per `-z` spelling, and compare the program header output. If your toolchain behaves as the author describes, the safe build needs no flag at all ^[6], and the interesting question is which of your makefiles, spec files, or vendored build scripts names the unsafe one.

One more detail from the same file, for anyone tempted to enable the extra test functions: `test2` calls `strcpy(buffer2[0], buffer1)` where `buffer2` is declared `char *buffer2[10]` and never initialised ^[19]. That writes through an uninitialised pointer, a different failure entirely, and `_NOTEST` is what keeps it out of the binary ^[20]. The demo is deliberately vulnerable in exactly one place ^[4]; the guard is load-bearing.