From Firmware to Full Systems: Why I'm Studying Penetration Testing
I've spent years working with embedded systems in a security context, and I love it. There's something uniquely satisfying about exotic architectures, soldering (or occasionally releasing the magic smoke when things don't go as planned), and the bridge between software and the physical world. Watching systems break in completely unexpected way - sometimes mind-bogglingly complex, sometimes equally mind-bogglingly simple ("how did I never think of this?") - never gets old.
But that's not the only thing that keeps me engaged. I also find real satisfaction in seeing how my work connects to day-to-day business operations. It's motivating to know that something I built is actually being used by a customer, that it solves a real problem for them, and that my work wasn't just theoretical. That connection between technical depth and practical impact matters to me.
Beyond my professional work, I'm also a bit of an IT enthusiast. I run my own home lab - networking, compute, storage, virtualization, Docker, the works. What can I say? I enjoy not just writing software, but building systems and exploring different operating systems and configurations. It's where I experiment, break things safely, and learn how infrastructure actually works.
All this to say: my professional interests extend beyond vulnerability research.
Expanding the Scope
Recently I caught myself thinking: what if I could integrate these interests more deliberately? What if there was a way to combine security with business context, networking, IT infrastructure, and also introduce more variety in the types of problems you solve?
Turns out penetration testing fits that description remarkably well.
Penetration testers apply a similar methodology to security researchers, but they zoom out. Instead of focusing on a specific component or service, they look at an entire organization - its network, its applications, its people, its physical security. The discipline expands beyond bits and bytes to include the human element, business processes, and environmental factors. I find that fascinating.
It's not just about identifying what's broken - it's about proving what an attacker can actually accomplish. That shift in perspective, from isolated bugs to chained impact, resonates with how I already think about security, but applied at a broader scale.
A Structured Challenge
For this reason, I decided to make good use of my spare time and challenge myself. I looked over the various penetration testing certifications and courses available, and settled on CPENT by EC-Council. The training material is structured and high-quality, and both the coursework and the final exam are hands-on and practical - which was important to me. I'm not interested in memorizing definitions; I want to build skills I can actually use.
I'm currently working through the material, and it's been a useful exercise in formalizing concepts I've encountered informally. For example, the CPENT methodology breaks engagements into three phases: Pre-Attack (reconnaissance and intelligence gathering), Attack (exploitation and privilege escalation), and Post-Attack (impact assessment and reporting). It also draws a clear distinction between vulnerability assessment - identifying potential flaws - and penetration testing, which is about proving whether those flaws can actually be exploited to achieve specific objectives. This maps well to how I already approach security problems, but it provides a clearer framework for thinking about dependencies and attack paths.
I believe my existing experience - reverse engineering, proof-of-concept development, low-level systems analysis - will be an asset as I work through this material. At the same time, I'm hoping to expand my perspective and develop new skills, particularly around network-level exploitation, Active Directory environments, and the kinds of infrastructure I don't typically encounter in embedded work.
What's Next
This blog is part of that process. I'm planning to use it as a space to document what I'm learning, share technical insights, and explore the intersection between the low-level security work I've done and the broader offensive security mindset I'm developing.
Thanks for reading. More to come.
Feel free to drop a comment on the LinkedIn post for this article.