I love networking, so I recently decided to add a second WAN to my home network as failover. If I am being honest, my current ISP has been exceptionally reliable! It's not that this is a pressing issue. Still, I love messing with new configs.

The goal was to get a notification and ability to remotely troubleshoot the primary fiber connection in case it fails.

My ISP provides me with a fiber optic cable that runs to my apartment, which I then connect to a Nokia G-010S-A GPON. This GPON exposes SSH, which allows the user to perform relatively low-level diagnosis.

My current gateway is UniFi Dream Router 7, which is excellent, but unfortunately it does not expose much GPON details on the dashboard, and neither does it have the ability to add a second IP to the GPON WAN interface.

Fortunately, this can be overcome with manual SSH commands.

I wrote a small script that SSHs into UniFi, temporarily adds the required IP, opens an interactive GPON shell, and removes the address when I exit. If the fiber link fails while I am away, I can connect through cellular and inspect the GPON directly with minimal effort.

In case this is useful for somebody else, I put this script on my GitHub: https://github.com/shiromiso/ssh-gpon

Feel free to drop a comment on the LinkedIn post for this article.

My physical copy of Eugene Lim's From Day Zero to Zero Day arrived today.

I came across the book on LinkedIn, looked into it, and quickly realized it fit very well with the study path I am building.

What stood out immediately is how practical and technical it seems. It focuses on reading real code, mapping attack surfaces, finding sources and sinks, understanding bug patterns, and turning vulnerability research into a repeatable process rather than a vague skill.

Over the past few weeks, I have been trying to balance full-time work with expanding my vulnerability research knowledge. I watched Alisa Esage's Hypervisor Security Research 101 masterclass and started doing several bug self-studies: finding the vulnerable code in the real repo, locating the fix commit, and explaining the mechanics, reachability, and potential impact.

The goal is not only to understand each specific bug, but to distill it into a more general invariant or pattern I can recognize later.

A few practical observations have already come out of these studies. Bugs often repeat as patterns, not isolated accidents. If a developer makes the same mistake in one place, it may exist elsewhere too, even after one instance is fixed.

They also reinforced how difficult real-world code is to reason about. Values move through long flows, internal types hide important assumptions, and a suspicious pattern may not actually be reachable if earlier code constrains the input or state. Security impact is contextual as well: whether a given behavior is actually a vulnerability may depend on design, deployment, or even regulation, not only on what the code does.

I am looking forward to working through the book and studying the skills, examples, and methodology it presents. One thing many experienced researchers emphasized when I asked for study advice is the importance of self-study in this field. Structured resources are relatively rare, which makes a practical book like From Day Zero to Zero Day especially valuable. Hopefully, it will help me build a stronger foundation, continue studying more effectively independently, and eventually find bugs of my own.

Feel free to drop a comment on the LinkedIn post for this article.

As I work through Zero Day Engineering training, I have been spending more time reading large open-source codebases from a vulnerability-research perspective.

One small thing I kept missing from IDA Pro is the highlight feature: select a token, and instantly see the other matching occurrences nearby. It is simple, but very useful when trying to understand data flow, control flow, and repeated use of variables or fields.

VS Code has some built-in behavior around selection highlighting, but I found it inconvenient for this workflow. I wanted something closer to IDA: automatic, whole-word matching and visually obvious.

I found a useful extension, highlight-selection, which was almost exactly what I needed. Since it was open source, I forked it, made the small changes I wanted, tested it locally in VSCodium, and opened a pull request upstream.

The result is a small quality-of-life improvement: IDA-like selected-word highlighting, but inside my regular source-code editor.

Feel free to drop a comment on the LinkedIn post for this article.

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.