§ Writing · essay mostafa.dk · 2026-04-02

I find vulnerabilities the same way I find dawn

Refusing to accept the model is the entire job.

On reverse-engineering, atmospheric simulation, and why both jobs are the same job — refusing to take the documented answer at face value.

  • Essay
  • Reverse engineering
  • Physics
  • Method

There’s a small voice that comes up at age 22 asking why I keep doing the same thing. Reverse-engineer a binary. Decompile a firmware. Simulate an atmosphere from photon physics. It looks like four different jobs. It’s one job.

§ The same instinct in three places

When I look at Meson Network’s “encrypted” payloads and find that they’re a single byte of XOR with a 0x00 first plaintext byte — there is no encryption, only a substitution cipher dressed up — I’m doing the same thing as when I look at the prayer times my phone shows me and think, “who picked this number?”

The answer in both cases is: someone who didn’t want to do the work. The Meson developers didn’t want to ship real cryptography because it’s annoying to integrate. The 1986 calendar committee didn’t want to model the atmosphere because the math was hard on a 6502.

In both cases, the result is a load-bearing assumption nobody re-tests. And in both cases, ten minutes of skepticism collapses the assumption.

§ The job

Most of what I do for money is one of three things:

  1. Decompile a binary the vendor said is open source, and find that it isn’t.
  2. Re-derive a physical model the textbook says is “good enough,” and find that it isn’t.
  3. Profile a system the docs say is fast, and find that it isn’t.

It is genuinely the same skill. The skill isn’t “binary analysis” or “atmospheric physics” or “performance engineering.” The skill is refusing the wrapper. Whatever the system tells you about itself, you don’t accept it as given. You reach past the wrapper and check.

§ What the wrapper hides

A vendor’s “open-source” claim hides a binary. A spec’s “depression angle” hides a missing model. A protocol’s “encryption” hides an XOR. A library’s “constant time” hides a branch. A datasheet’s “typical” hides a worst case. A SoC’s “spec sheet” hides a thermal cliff. The pattern repeats.

When you’ve found enough of these, you stop being surprised by them. You start expecting them. You learn to work backwards from “this seems too clean” to “what wasn’t measured?” and almost always something wasn’t measured.

§ Why this matters in 2026

The number of systems that present a confident exterior over a sloppy interior is going up, not down. AI-generated code makes the exterior more confident faster than the interior gets cleaner. The gap between “what the docs say” and “what the binary does” widens every quarter.

This is good news if you have the instinct to look past the docs. It is less good news if you’re an operator depending on the docs.

The job is the same job it was in 1986: refuse the wrapper. The opportunities just keep getting better.

§ What I’m working on now

The same instinct keeps pointing at the same kinds of targets: cellular basebands (vendor-blessed eSIM is a fiction we should test), atmospheric models that cardinal directions of the religious world depend on, decentralized infrastructure protocols that ship a tarball and call it open source.

If your system is presenting a confident exterior over an interior you suspect isn’t right — talk to me. The interior is usually where the interesting story lives.

Let's take the housing off something.

Reverse-engineering, Web3 infrastructure, firmware teardowns, consulting. I answer email inside 24 hours.