From Zero to Exploit Dev: What Actually Worked
Table of Contents
TL;DR
Started in 2020 knowing nothing. Spent summers crying on Root-Me. Debugged broken exploits from ExploitDB. Contributed to Metasploit and got my code torn apart until it wasn’t. Published everything. Found CVEs. Built tools. Used AI. Worked alone. Enjoyed the process.
Context
In 2020, I didn’t know how to use a computer properly. No background in IT, no family in tech, no connections. I saw a friend using Kali Linux at boarding school and thought it looked interesting. That was it. That was the start.
In 2023, I did an interview with MyHackerTech where I talked about my perspective at the time. I said things like “be curious”, “be passionate”, “don’t give up”. And I meant it. That was genuinely how I saw things in 2023-2024: just work hard, stay curious, and things fall into place.
Looking back, I still believe that. But I’d add something I didn’t understand back then:
Passion alone doesn’t get you anywhere if nobody sees what you do.
You can be the most skilled person in the room, but if your work isn’t public, it doesn’t exist. The grind matters, but the output matters more.
I’ve had tons of DMs over the years. “How do I start?”, “Give me a roadmap”, “I need a framework to follow.” Here’s the truth:
There is no roadmap. Your roadmap is yours. You don’t plan it, you build it as you go.
Every path is different. This is mine. I’m sharing what I did over the years and how I did it. Take what’s useful, leave the rest.
How It Started
The lockdown in 2020 gave me time. I started on CTF platforms: Root-Me, TryHackMe, HackTheBox. I was bad. Really bad. I spent entire summers on Root-Me challenges I couldn’t solve. It drove me insane. I literally cried out of frustration more than once. But I kept going because I couldn’t stop. Not because I wanted a career, not because I saw money in it. I just couldn’t let a challenge beat me.
TryHackMe was easier at first because walkthroughs existed, so let’s be honest, I had help. But at some point I wanted to do it without. That’s when the real learning started.
HackTheBox I did too, but something about the full pentest methodology annoyed me. The enumeration, the pivoting, the whole process. I didn’t want to do everything. I wanted to specialize in one thing and go deep. That thing turned out to be exploit development.
The real learning started with the old school stuff. VulnHub VMs, Metasploitable, the classic vulnerable boxes that you run on a PC that can barely handle the load. You’d find a CVE related to your target, pull an exploit with searchsploit, and half the time the code was outdated, broken, or just wrong. So you had to:
- Read it
- Understand what it was trying to do
- Fix it
- Adapt it
That’s where I actually learned how exploits work. Not by writing them from scratch, but by reading other people’s broken code and figuring out why it didn’t work.
That habit of reading code, understanding it, fixing it, then eventually writing my own - that’s the entire path. Everything else is just details.
From there I moved to real targets. Bug bounty at first. I tried it, made some money, but honestly it’s not something I fully accept. For me it doesn’t match the OG mindset of this field. That’s a choice. I know it sounds like something from early days, from a generation I never knew. But I’ve always been drawn to that spirit.
But it taught me something important: the difference between a crash and a weaponized exploit. Between a PoC that works in your lab and one that works in production. That distinction matters more than anything.
Honestly, my approach was simple: I didn’t care. I just didn’t want my code to rot. I treated exploit dev like collecting Pokemon:
- Find a vuln
- Write the exploit
- Learn something
- Move on to the next one
No overthinking, no strategy. Just the next challenge. My friends would test my stuff, mod it, break it, give feedback. That loop of build, ship, get feedback, improve - that was the whole process.
But the real fire came later. At first I was just reading other people’s exploits and felt limited. I kept thinking:
I want to be a one man army, just for the fun of it.
Then it became: a new CVE drops, no public exploit exists, maybe just a blog post or an advisory, and I want to be the first to PoC it properly. That drive to go from advisory to working exploit before anyone else, that’s what pushed me to another level.
And yeah, being first is clout too, I won’t pretend otherwise. But it’s clout because you’re bringing value. Anyone can write a PoC a week later when 10 others are already out. Being first means you actually understood the bug fast, you built something reliable fast, and people notice that.
But the real differentiator isn’t being first once. It’s being first consistently. There are plenty of PoCs out there. Constancy is what separates you from the noise.
And reliability. A PoC that works on one version, with the right conditions, maybe, is not the same as a reliable exploit that handles edge cases and actually gives you a shell.
Most public PoCs are partial. Ship something that actually works end to end and you stand out immediately.
What I Actually Did
There’s no shortcut. Here’s what worked, in rough order:
Published everything
Every exploit, every writeup, every tool. Open source, public, documented. Not because I wanted attention, but because I wanted to contribute and because public work is your resume in this field.
Nobody will take your word for it. Show the code.
There’s another reason I publish:
I always figured these exploits were probably being sold on shady markets, Telegram channels, and all that. I wanted to make them public so everyone is on equal footing - defenders and attackers alike. The exploit exists, it works, deal with it. And nobody’s going to pay for an exploit that’s already public. I wanted to burn them as fast as possible. That was my hacktivism. Legal.
Contributed to Metasploit
This one happened by accident. LeakIX had found a vulnerability in Vinchin Backup at the time, and I thought “why not write a Metasploit module for it, could be fun.” The RCE itself was literally a curl one-liner, barely any code. So I figured writing a module for it would be easy.
It wasn’t.
And then I hit a wall. The review process was brutal. My code got torn apart. I struggled. A lot. I even asked the Metasploit staff directly if there were courses or resources to learn how to write modules. The answer was:
The documentation, and us.
That’s it. No cert, no course, no bootcamp. Just the docs and the people who review your code. That’s when it clicked. The people reviewing my PRs are the ones maintaining the most complete public exploitation framework in the world, and they’re telling you exactly what’s wrong with your code. People call it “free”. It was never free. It was transmission. Once I understood this, I kept coming back. And each module got better than the last.
I was reviewing Metasploit PRs, writing exploits, and PoC’ing n-days from the back of the classroom. I clearly did not care.
My Metasploit contributions are going on standby. For how long, I don’t know. But I want to say this clearly:
That team was family to me.
And I don’t use that word lightly. They shaped how I write code, how I think about reliability, how I approach exploitation. The contribution process itself, the code quality standards, the review cycles, the way you structure a PR - school didn’t teach me any of that. School is cool, thanks for the basics, but you don’t become an expert by relying on school alone. The field did that. I owe them a lot.
Found and reported CVEs
Started small. A PHP CMS nobody uses. Then bigger targets. Each CVE builds your track record and teaches you a different attack surface.
I went from simple XSS to full RCE chains over time. Not overnight. Over years.
Wrote about everything
I used to read advisories from Horizon3 and watchTowr a lot. Their deep dives were incredible. Shoutout to both teams for their exceptional work. I wanted to do the same thing. Not just “here’s the exploit, good luck”, but actually showing the process:
- How I found it
- How I thought about it
- What I tried that didn’t work
- What rabbit holes I went down
The goal was to show the HOW, not just the WHAT.
And by reading other people’s deep dives, you also learn how they got there, their thought process, their reasoning. That’s worth more than any course.
People underestimate how much this matters. Your writeups show how you think. And every blog post you publish ends up on Twitter, gets shared, gets read. The community feeds on this. It’s the same workflow most people already have: check Twitter, check new Metasploit PRs, check GitHub repos for new research. Your writeup becomes someone else’s intel.
There’s nothing magic about it. You just have to be on the other side of it, producing instead of just consuming.
Built tools
Every tool I made started the same way: something annoyed me and I wanted to fix it myself. Or I had an idea and couldn’t let it sit in a corner, I had to dig into it, understand it, build it.
Not because the world needed another scanner, but because that’s how I learn. You understand the protocols, the edge cases, the failures. And sometimes your tool actually becomes useful to others.
Kept my workflow stupidly simple
My vuln monitoring is basic:
- Search Twitter for
"CVE-2025","CVE-2026" - Follow the right accounts (you learn who matters over time)
- Let the recommendation algorithm do the rest
When an advisory drops, I read the patch, understand the bug, and try to weaponize it. No fancy threat intel platform, no paid feeds. Just Twitter search and curiosity.
I’ve been doing this every single day for years. I don’t even read books normally, but this stuff I consume like crazy.
Most people overcomplicate this. The information is right there, publicly, for free. You just have to look.
Used AI
I’ve been using AI since 2023. For everything. Exploits, research, labs, documentation. When I had a suspicion about a piece of code, I’d paste it and ask questions. When I needed a Docker lab, I’d generate it. When I was writing an exploit, I’d use it to speed up the boring parts. It does the job.
The important thing is knowing what to ask and understanding the output.
AI doesn’t replace your brain. It replaces the tedious parts so your brain can focus on what actually matters: getting your shell.
On Community
I’ll be honest here. I’ve never really been part of the French infosec community. I tried, I contributed to some French projects, but when I looked at Twitter I saw the international scene, people doing incredible things every single day, and I didn’t want to limit myself. The exploit dev market in France barely exists, it’s extremely limited. So I naturally gravitated towards the international community.
That’s a choice. I work alone, mostly. Always have. I didn’t join communities to “network”. I contributed to projects I cared about and the connections happened naturally. The people I’ve worked with are people I met through code, not through conferences or Discord servers.
If you’re like me and social interaction isn’t your strong suit, that’s fine.
Let your work speak. It’s louder than any introduction.
But don’t isolate yourself completely either. Open source is the perfect middle ground: you collaborate through code, not small talk.
Some of the most important connections in my career started with a pull request or a vulnerability report. Not a handshake.
When It Started Getting Serious
At some point with Metasploit contributions and everything else, I started thinking: this is getting serious. Could I actually do this as a job one day?
But I didn’t obsess over it. It was more like: keep working, keep enjoying it, keep getting better, and worst case it’ll always be useful. And it was. During pentests I was the only one who actually understood how an exploit worked and what it did under the hood. Your average pentester launches an exploit without reading the code first. When it breaks production, they don’t know why. When it fails, they don’t know how to fix it. Most pentesters don’t read the exploit before running it. And that’s a problem.
When you’ve written exploits yourself, you understand why it works, why it breaks, and how to adapt on the fly.
That gap alone made the difference.
On Certifications
I have certs. It was a personal need. When I wanted to learn something and couldn’t figure it out alone with online resources, I’d get a cert to structure it. That’s it. Not for HR, not for my CV. Just “I want to understand this topic and I need a framework to guide me.”
It’s clearly not mandatory though.
What Actually Matters
Not certifications. Not degrees. Not who you know.
What matters is a body of work that someone can look at and verify:
- A GitHub with real exploits
- A blog with real research
- CVEs with real impact
- Contributions to frameworks that people actually use
- Tools that people actually download
When you have that, you don’t need to convince anyone. The work does it for you.
Someone once told me:
“Results speak first.”
That stuck with me. Everything else is noise.
To Anyone Starting Out
The honest truth: it’s a hard path and not everyone makes it. There are no guarantees.
But don’t stress about that. If you genuinely love this stuff, just enjoy the process. Keep hacking. Keep learning. Keep publishing.
The opportunities come to those who are visible and consistent.
You need proof that you can do the work. Build that proof in public, and the rest follows.
I started in 2020 knowing nothing. It took years of grinding, failing, learning, and building. But the path exists. I walked it.
And I’m still walking.
One More Thing
Never rest on your laurels. Ever.
Stay humble. Remember where you came from. Enjoy the process. Don’t overthink it.
The moment you think you’ve made it is the moment you stop growing.