2Atomic / Services / Adversary simulation

// engagement · against your own product · stage 3 of 6

One bug is a finding. A chain is the answer.

We boot your firmware and walk the chain end to end, then say exactly what each step was proven on. No product subscription required.

Scope a simulation → Read the dual-use line first
Chained, not a list of primitives
Walked, not hypothesised
Substrate named on every step
Standalone, no platform license

What this is, and what it is not

The industry uses one phrase for three different products. This is the one that ends in a fix.

If you are comparing quotes, the differences matter more than the price. This is exploit research pointed at a target you own, ending in a reproduction handed to whoever can fix it. It is not a penetration test of your corporate network: no phishing, no directory services, no lateral movement through your office, because our input is a product rather than an estate. It is not a detection exercise measuring whether your analysts noticed, which is a different deliverable for a different buyer. And it is never the sale of offensive capability.

We do this
Prove exploitability

Find the primitives, chain them past the mitigation meant to stop each one, walk the chain to the end state in a system we booted, then name the single change that breaks it. It is usually not the bug you would have prioritized.

We do not do this
Sell the capability

No implant development, no endpoint-detection evasion, no command-and-control frameworks, no exploit sold as a deliverable, and no work against a target that is not yours. This is a standing company rule, not a per-engagement negotiation.

Chain write-up: each primitive, the mitigation it passed, what it was proven on, and the single change that breaks the chain A document page describing an exploit chain step by step. Each row names the primitive, the mitigation it had to pass, how it passed, and whether the step was proven in a booted emulated system or on the device itself. A closing paragraph names the one change that breaks the chain and says which step it breaks. ADVERSARY SIMULATION One chain, what proved it, and the change that breaks it STEP PRIMITIVE MITIGATION PASSED HOW PROVEN ON 1 Info leak ASLR fixed-address SPL mapping EMULATED 2 Relative write stack canary write is below the canary EMULATED 3 Aimable write RELRO GOT is writable, lazy bind EMULATED 4 Control transfer NX return into a mapped stub ON DEVICE Full RELRO breaks this chain at step 3, and step 3 is the only step with no second route: the write has to land somewhere the loader will later read as a pointer. Steps 1, 2 and 4 each have alternatives and closing them individually does not help. Steps 1 to 3 were walked in a booted emulated system. Step 4 depends on the real MMU configuration, so it was re-walked on a device.
Sample Chain write-up: each primitive, the mitigation it passed, what it was proven on, and the one change that breaks the chain The shape of the hand-back, redacted. Yours carries your own findings.

You do not have to ship us the device

We rehost your firmware: the real kernel, the real init, the real daemons, booted under full-system emulation from the image you already publish.

Most of this work happens in a booted emulated system rather than on a bench, and that is a feature of the engagement rather than a compromise in it. A rehosted target starts in minutes, so a chain can be attempted hundreds of times instead of twice. It can be snapshotted mid-chain, which is what makes step three reproducible after step two destroys the heap. It runs under instrumentation no physical board exposes, so a crash is attributed to the write that caused it rather than to the symptom. And it costs you no hardware, no lab shipment, and no customs form: an image and an authorization are enough to start.

  • What emulation proves. That the bug is real, that the primitive works, that the chain composes, and that the mitigation you believed was on is or is not. These are properties of your code and your build, and a booted guest answers them.
  • What it does not prove. Anything that lives in your silicon: a fused key, a secure element, a hardware root of trust, a peripheral with no model, or a timing window that only exists at the real clock. An emulated success is not a silicon claim, and we never promote one to the other.
  • What we do about the gap. Steps that depend on hardware are re-walked on a device, yours or ours where one exists. Where no device can be had, the step is reported as proven in emulation only, with the specific hardware behavior it assumes written down so your own engineers can confirm it in an afternoon.

Every verdict says which substrate it was proven on, because that is what tells you how much weight to put on it when you decide whether to ship a fix.

The end state is the scope

Two things decide what this engagement is worth, and both are settled before any work starts.

  • Where we have to get. Persistent code execution across a factory reset. A key off the device. A signed update you did not sign. Unauthenticated control from the network. Name it, and the engagement has a pass and a fail; leave it as "see what you can get" and you have bought a report nobody can act on.
  • Where the attacker starts. Network-adjacent, a hostile peripheral, a malicious update server, or a device in hand on a bench. The starting position is most of the answer, and a review that assumes a shell on the device has skipped the part you are paying for.

A chain that reaches the end state from a position no attacker holds is interesting and not urgent. We say which it is.

What we go after

Pointed at the layers most reviews declare out of scope, because that is where the assumptions live.

  • Shipped firmware and embedded devices. The daemon on a router, camera or controller, reached from a network position rather than a shell you were given.
  • The boot and update path. A product whose application layer is sound and whose update path is not has one bug, and it is the update path.
  • Memory-safety chains in native code. A write primitive is not an outcome. We take it to a reached end state and say where the chain would have broken if a mitigation had held.
  • The mitigation inventory, measured from the binary rather than from your build system's opinion of it.
  • Agents and their tool graph. Where an autonomous system can be talked into acting, what it may do when it does, and whether the record can be trusted afterwards.

Where a target's interior is sealed behind hardware we do not have, we name the exact step that stops us, so you know where the work ended and why.

How it runs

01
Authorize
A signed scope naming the target, the end state, permitted techniques, blast radius and the people to call. Nothing starts first.
02
Boot it
Your image rehosted until the real system comes up and its services answer. A target that will not boot is the first finding, and it is often about your update path.
03
Chain
Compose the primitives into a path to the end state and walk it, snapshotting each step so the next one starts from a known state. A step we cannot walk is reported as unwalked, with the reason.
04
Close it
The reproduction, the fix, the substrate each step was proven on, and the chokepoint: the one change that breaks the chain even if the other bugs survive.

What you get back

The chain, step by step
Each mitigation it passed, and how
The reproduction
A booted target your engineers re-run
The end state
Reached, with its substrate named
The chokepoint
One change that breaks the chain
Mitigation inventory
Held, absent, or bypassed
Every step we could not walk
Named, with the reason

And the changes that do not help: closing three steps of a four-step chain buys you nothing if the fourth step has no second route.

The dual-use line

Stated here rather than in a terms document, because it changes what you can buy.

Non-negotiable

Exploit research is a capability we keep, not a product we sell. We develop exploits to prove exploitability against a customer's own product, and the working code goes to that customer and to whoever maintains the affected component. It does not go anywhere else, and it is not licensed, brokered or resold.

Every engagement passes a project review. Identity, plus authorization for the specific target. We refuse work that fails this, including work we would find interesting, and including work from a customer we already have a contract with.

A chain we cannot walk is reported as unproven, and an emulated walk is reported as emulated. A hypothesised chain reads better than four steps and a wall, and "we got code execution" reads better than "we got code execution in a guest", which is exactly why we write the weaker sentence. A simulation that found no chain does not mean your product is secure; it means no chain was found from this starting position, under this scope, in this budget.

Vulnerabilities in software we do not maintain go through coordinated disclosure. If we find a bug in a component your product depends on, the vendor gets notified before anyone else, on the clock published in our disclosure policy. We will not sit on it as leverage and we will not publish it to make a point.

Related

Two engagements sit next to this one, and the difference is where each one starts.

Available

Threat research

Starts from an adversary and asks whether their technique reaches you. This page starts from your product and asks whether any chain reaches an end state you named.

Threat research →
Available

Firmware and secure-boot review

Starts from your image and a set of trust decisions. Cheaper than a simulation, and the right first engagement if the boot chain has never been looked at.

Firmware review →