Hacking Like Its 2005

Why I Chose to Learn Hacking Like It’s 2005

Forget Kali. Forget convenience. I wanted to understand how computers break — for real.

Most people today install Kali Linux, open up Wireshark, click a few things, and call it hacking.

But that’s not what I wanted.

I didn’t want prebuilt tools or point-and-click exploits.

I wanted to know what was actually happening — when memory overflows, when stacks smash, when a C program gives up its secrets… when you do something you are really not supposed to, just to see if you can.

So I did something weird in 2025:

I built a 32-bit Gentoo box on an old Core 2 Duo…

From source.

By hand.

Over SSH.

On a private VLAN.

With a physical LAN kill switch I wired myself — just in case things get wild.

Why? Because I’m learning from Hacking: The Art of Exploitation, and that book doesn’t care about your GUI. It assumes you know what gdb is. It assumes you’ve written C (although it does give a good introduction). It assumes you want to understand things the hard way.

And I do.

But without any of the hand holding or training wheels that come from using modern systems. Don’t get me wrong, those things are great, but if I want to learn how things actually work, I need to go back to basics.

Also, a lot of those exploits don’t work on modern systems.

Good luck trying to smash a stack with that canary flying around.

Wanna NOP slide to the address?

Yeah, not on a modern system if you don’t know how things work.

Later you can build your own and probably run them on a newer system and destroy it…

But you need to know what you are doing first. And that is why I am setting up this box.

I also get that you could just run an older Ubuntu ISO and make things work on a system that does not remember what you did after you shut it off.

I wanted to build a real system and network I could use to learn how everything fit together. And I had a few old PCs laying around collecting dust, so I figured they would be perfect for a home hacking lab.

The Setup

This isn’t a VM.

This isn’t a Docker container.

This is a physical machine — vulnerable by design — that I can experiment on safely, without risking my main system.

I paired it with a second box (another dusty Dell) to act as my analyst machine.

They live on their own VLAN.

They don’t touch the rest of my network.

I can SSH in, write shellcode, crash things, and watch it all unfold like it’s 1999 with (hopefully) no fallout.

I’ll also do a bare metal backup in stages, so when things go sideways (spoiler: they will) I can just restore from backup without missing a beat.

What I’m Actually Learning

• How memory is laid out at runtime
• What a stack overflow really looks like
• How shellcode is crafted — byte by byte
• What happens when protections like ASLR and DEP are removed
• How to debug with gdb like a surgeon, not a guesser

These aren’t things you learn by running a random tool on a Kali ISO.
They’re things you learn by getting your hands dirty — compiling your own system, writing your own exploits, and breaking things on purpose.

As ytcracker put it:

“Everyone’s a flake these days and i wish it weren’t soooooo

Nobody wanna be a pro

They just want to get a bag (get a bag) full of dough.”

— ytcracker, except crime

That stuck with me.

I don’t want to be the person chasing a quick win — I want to be the one who understands what makes the machine tick. And I want to be the one to break them.

Why This Matters

Because convenience is killing curiosity.

We’re losing the art of understanding how things actually work.
And in security, that’s dangerous.

If you don’t know how a system is built, how can you ever hope to truly secure it?

If you’ve never written a buffer overflow by hand, how can you recognize one in the wild?

I’m not here to gatekeep.

I’m here to say: there’s another way to learn.

A slower, more painful, more powerful way.

If This Resonates With You…

Then stick around.

I’m going to document everything — from compiling Gentoo, to debugging C code, to crafting real-world exploits from scratch.

Not for clout.

Not for SEO.

But because this stuff is worth preserving.

And if even one person reads this and goes, “Hell yeah, I want to build that,” then it was worth it.

Stay tuned for:

• My physical lab setup
• A deep dive into stack smashing
• Real exploit walkthroughs
• And probably some mistakes along the way

This isn’t just hacking. It’s learning how computers work at the atomic level.

BTW I wrote this article while I was waiting for GCC to compile.

So there was no down time.

Got an old box lying around? Boot it up. You might just learn something the cloud can’t teach you.