The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86). This 2007 work by Hovav Shacham appeared in the proceedings of the ACM Conference on Computer and Communications Security. It examines whether an attacker blocked from injecting executable code can instead compute with short instruction sequences already present in an x86 executable. Under the paper’s attacker model, Shacham claimed that a sufficiently large x86 executable body contains enough return-terminated sequences for arbitrary computation. By the end, you should understand the approach, what the shell demonstration established, and why this evaluation does not establish reliability on modern targets.

Start with write-xor-execute. It blocks injected code but does not stop an attacker from reusing executable code already mapped in the process. The building blocks in this work are short sequences of existing instructions that end in return instructions. Rather than invoking whole functions, the attack composes these sequences. The practical distinction is between injecting new instructions and repurposing instructions the process already has.

The technical question is how expressive these small instruction sequences can become when combined. Shacham selected gadgets for loading and storing data, arithmetic, logic, control flow and system calls. He judged that set computationally complete by inspection—that is, by manually checking that its operations were expressive enough to implement arbitrary computation within the model. Computational completeness is a capability result. It does not mean every real target is exploitable, that gadget construction is automatic, or that an exploit will run reliably.

Shacham used Galileo to analyze executable code. On the test machine, Galileo examined more than a million executable bytes in under a couple of seconds and produced a trie representing its results. Shacham then selected gadgets for loading and storing data, doing arithmetic, and applying logic. He also selected gadgets for control flow and system calls. By inspection, he judged the combined set computationally complete. He composed the attack program manually. The evaluation did not include modern mitigations or reliability comparisons.

The chosen gadgets could move and transform data, steer execution and make system calls. By inspection, Shacham judged that set computationally complete. Shacham also built a 12-word return-oriented program that invoked execve on a shell path while write-xor-execute remained active. That concrete execution showed that code reuse could progress from a collection of instruction sequences to a working system-call sequence without injected executable code. It did not demonstrate that every executable contains a suitable set, or that the same construction would be reliable on contemporary systems.

The instruction-byte measurements help explain why the search produced many candidates. Across the covered code, the analysis found a C3 byte used for these return endpoints about once every 178 bytes. Thousands of those instances were intended return instructions. Removing only accidental C3 bytes would therefore leave intentional returns, and Shacham noted that alternative usable sequence terminators could remain as well. The evidence supports the availability of return endpoints in the evaluated library, not a universal density claim for all binaries.

The evidence came from a single older 32-bit x86 Linux/glibc build, and the final program was composed manually. There were no comparisons involving modern mitigations or exploit reliability, so the results do not establish how often the technique transfers to other software or present-day systems. This work also did not originate every form of code reuse: later work acknowledged earlier attacks that reused whole functions or short instruction sequences. It would therefore be inaccurate to attribute every form of code-reuse exploitation to this work alone.

For defenders, write-xor-execute should be assessed as a barrier to injected code, not as proof that attackers cannot compute with existing code. Detection engineers and security architects evaluating that policy should also consider whether attacker-controlled data can arrange reachable, return-terminated sequences into useful operations. Removing accidental C3 bytes alone is not a complete answer because intentional returns and other usable terminators may remain. This is a design caution supported by the evaluated build, not evidence that every contemporary target permits a reliable return-oriented exploit.

Shacham contributed a systematic way to find and combine short x86 instruction sequences, then demonstrated the idea with a manually constructed 12-word program that reached execve while write-xor-execute was active. Teams responsible for memory protection, exploit testing and detection should distinguish blocking code injection from blocking code reuse. They should not infer from this experiment that the classic construction remains broadly reliable today: that question was not tested across modern systems or mitigations.