Free version of this article

Before we delve into the nitty-gritty of shellcode injection in scenarios where buffer space is a luxury we don’t have, let me share a bit of a personal backstory.

This exploration into the depths of buffer overflow and shellcode techniques is inspired by a project I tackled during my cybersecurity course at university.

It was one of those challenges that was as thrilling as it was enlightening. The task demanded creativity, a deep understanding of system vulnerabilities, and an almost artistic touch in crafting a solution that worked within the tightest of constraints.

It was not just an academic exercise but a real-world puzzle that tested the limits of what I thought was possible. This article is a reflection of that journey — a testament to the fun and the fight in facing down cyber vulnerabilities head-on.

Now, let’s dive into how we can overcome the challenge of small buffer sizes in shellcode injection, turning constraints into launchpads for sophisticated exploits.

In this case, we face a local shellcode injection since we have access to the binary itself that we exploit on our own machine.

The typical way to exploit a local shellcode is presented as follow:

Local Shellcode: This type is utilized by an attacker who already has limited access to a system. The primary aim here is to spawn a shell with elevated privileges, typically root. For this shellcode to work effectively, the stack needs to be both executable and writable.

The approach involves:

1. Overwriting the saved EIP (Extended Instruction Pointer), allowing the attacker to dictate the next instruction executed.
2. Inserting a new value for the saved EIP that points to a location in the stack where the attacker has placed malicious code.
3. Employing NOPs (no-operation instructions, represented by \x90) to bridge any potential compiler discrepancies, as the exact value of ESP (Stack Pointer) is often uncertain.