So You Want to Be a Hacker

every few days someone asks me how to get into hacking. usually over dm, usually some version of "where do i even start." i've answered it enough times now that i figure it's worth writing down properly, once, instead of half-answering it badly forever.

i should say up front: i'm not some elite anything. i've found real bugs, i've been paid for a couple of them, i've spent stupid amounts of time on machines that turned out to have one dumb misconfiguration i should've caught in the first hour. this isn't a résumé post. it's just what i actually did, and what i'd tell a younger version of me to skip.

the first thing nobody tells you is that hacking is mostly reading. not exploit code, not some flashy zero-day. documentation. source. other people's writeups, slowly, more than once, until the thing that felt like magic on the first read starts to feel like plumbing on the third.

i didn't start there, of course. i started where everyone starts, watching a video of someone popping a box in twelve minutes and thinking that's what the job looks like. it isn't. that video is the highlight reel of a hundred hours you didn't see, mostly spent being stuck, mostly spent being wrong.

so the actual starting point, if i'm honest: pick one thing you don't understand and go find out how it works, all the way down, further than feels useful. how does a TCP handshake actually happen. what does a buffer overflow actually overflow into. what is a JWT signature actually checking. you'll want to skip this part because it's slow and it doesn't look like hacking. it is hacking. it's the only part that is.

CTFs are how most people cut their teeth on this, and for a long time i'd have told you unconditionally to go do them. i still would, mostly, but with an asterisk i didn't used to need. a lot of the early-tier challenges are the kind of small, bounded, machine-checkable puzzle that a model can now just solve for you if you point it at the box. that's not a moral judgment, it's just true, and it changes what the exercise is for.

so if you're doing CTFs now, do them the slow way on purpose. don't point an agent at the challenge and take the flag. use it, if you use it at all, the way you'd use a hint system: only after you've actually tried, and only to unstick one specific thing, and then go back and make sure you can explain why the payload worked without looking anything up again. the flag was never the point. the point was always the hour before the flag.

which brings me to the thing i actually want to say about all of this, the reason i felt like writing it now instead of two years ago: the tools changed, and they changed the job in a way that's genuinely good if you use it right and genuinely corrosive if you don't.

an agent can recon a target, map endpoints, read through a huge bundle of source faster than you ever could, and hand you a report with two dozen "findings" in it. some of those findings are real. a lot of them are confident-sounding nonsense, a plausible-looking guess dressed up in the same tone as a verified bug. maybe thirty percent gold, seventy percent noise, and the ratio moves around depending on the day and the target, but it's never zero and it's never a hundred.

your entire job, now, is being able to tell which thirty percent is gold. that's it. that's the actual skill the field is asking for in 2026. not writing the recon script by hand, i don't care if you can, i mean it, i don't. it's reading a claim about a system and knowing, from first principles, whether it survives contact with reality. you can only get that from having done enough of it yourself that you recognize the shape of a real finding versus the shape of a good guess.

so use the tools. i use them constantly, they've made me faster at the parts of the job that were never the interesting parts anyway. but treat every output as a hypothesis, not a result. reproduce it yourself. if you can't explain in your own words why the vulnerability exists and why the fix closes it, you don't have a finding, you have a screenshot, and those are different things even though they look identical from the outside.

on the vibe stuff, briefly, because people ask about this too: the hoodie, the dark terminal, the aesthetic. none of it's required and none of it hurts either. wear what you want. just don't let the aesthetic become the deliverable. i know people with a beautiful ricing setup and a green terminal who've never found a real bug, and i know people running a stock ubuntu install in a well-lit room who've had three CVEs assigned to them this year. the setup is not the skill. it never was.

the other honest thing: it's slow, and it's supposed to be. i spent probably four months before i found anything that mattered, and most of those months were just me being confused in a methodical way. reading the same RFC section four times. setting up a lab wrong and not knowing why for a week. the emotional arc of learning this is mostly just being stuck and then, occasionally, not being stuck anymore, and that second part is worth the whole first part.

imposter syndrome doesn't really go away, for what it's worth, and i've stopped expecting it to. it changes shape. early on it's "i don't know anything." later it's "i know this one corner well and the rest of the field feels like a foreign country." that's not a flaw in you, that's just what the edge of your knowledge always feels like, no matter how far you've pushed it out. the discomfort is the job, not a sign you're doing the job wrong.

write things up. this is the part i'd push hardest on, actually, more than any specific tool or technique. write the boring internal report nobody will read as carefully as you wrote it. write the walkthrough of the CTF box even if fifty people already have. the act of explaining why something worked, in your own words, in full sentences, catches the gaps a screenshot never will. if you can't write the explanation, you don't understand it yet, full stop, and that's useful information about where to go next.

there's no roadmap for this, and i mean that literally, not as a cute closing line. i can tell you what i did and it'll rhyme with what worked for you, but it won't be the same shape. some people come at this through CTFs, some through bug bounty, some through just breaking their own homelab repeatedly until they understand it. the actual throughline isn't a curriculum, it's curiosity that survives being wrong a lot, in public sometimes, without turning into either arrogance or giving up.

so that's the real one. slower than the other post, less funny, and every word of it is true. if you want to get good at this, go get confused about something specific today, and don't let a screenshot convince you that you understand it before you actually do.

— arsh