Wherein We Wade Through A Shellcode Shore: before the dive

 

Open Spotify > Search: 'Call it Fate, Call it Karma', by The Strokes > Play > Thank me later

Are you in the mood for some history and cool computer tales? Just lay back, enjoy the music, and hear me out.

While playing the Narnia game on OverTheWire, I hit a roadblock. I could either hack my way into advancing another level, or I could step back, take a better look at what was being presented, and learn a little bit more in the process. Ask a few questions, you know? Like why is it that...? You catch my drift.

This blogpost marks the beginning of that journey and some of what I learned while studying shellcode, its history, implications, and the tricks of the trade. Since the rabbit hole runs pretty deep, I'll be breaking this post in multiple parts. Don't worry, though—since real friends know C (and then break it) I'll be getting back to the C cracking series in no time. Fret not.

The Narnia game is about code injection and shellcode... But what is that?

It's essentially a small piece of code used as a payload in exploiting vulnerabilities.

It’s a means to an end: allowing attackers to exploit certain bugs, like buffer overflows, and thus alter the normal program logic (e.g., skipping a function altogether and steering the program's flow toward the attacker's purpose).

The name says it all: shellcode—spawning a shell and gaining control of the target machine to run commands at will. This was the original purpose (FYI: more modern shellcode can perform many different actions beyond just spawning a shell).

Shellcode was hugely popular in the late '90s and early 2000s when software was (even more) riddled with vulnerabilities that allowed direct code execution (see: the Morris Worm, 1988).

But shellcode is more than that. Over time, it evolved as hackers got more creative, bypassing security mechanisms, evading antivirus tools, etc. There were even competitions to cram the shortest shellcode possible into tiny bits of data. With the right perspective, anything can be fun.

Shellcode is tipically created in ASM - which allows for compact code (very important in limited memory spaces) and also gives much finer control over CPU instructions and memory manipulation.

Fun fact: Shellcode must be position-independent.

Being position-independent means that it can be executed correctly regardless of where in memory it ends up. This is crucial because we don't know where exactly it will be loaded during execution. Position-independent code (PIC) uses relative addresses, making it adaptable no matter where that code is injected.
Cool, right?

Remember that more modern systems (and even some older ones) use protections like ASLR (Address Space Layout Randomization), which randomizes memory addresses. This often drives assembly students to fits of despair when they realize they can’t follow the same memory positions as they debug code unless they turn those protections off (I’ve heard that self-inflicted hair-pulling isn't uncommon).

You might think that with all these modern protections, shellcode would be mostly irrelevant by now. Not quite.

While many classic exploits have been mitigated by security features like ASLR, DEP/NX, stack canaries, shellcode is still widely used in modern attack vectors like buffer overflow attacks, exploits in poorly configured environments, malware, and Return Oriented Programming (ROP).

A blast from the past

I'm currently reading an oldie but goodie, 'Smashing The Stack For Fun An Profit", and thoroughly enjoying it. It's fun, and if this stuff interests you at all, you should definitely check it out.

No code or exercises on this blogpost—yet. I'm still new to this and want to have something a bit more organized before diving into these waters, but another blopost should follow soon.

If you have any advice on books, courses, or other resources on this subject, please hit me up on LinkedIn, Twitter, Mastodon, or right here. I’m always open to learning more.