Skip to content

Whitepaper · Reverse engineering · Hardware, software and neural networks

Every claim verified on hardware. That is the whole method.

When the documentation is missing, the vendor is gone, or the blob is the product, we recover what the silicon actually does — from disassembly, from traces, from the air — and prove it with a harness that answers yes or no. We have used IDA since the 1990s; the automation is newer, the discipline is not.

Send us the binary and the question How an engagement works

427 of 427 encoder kernel functions replaced by readable C, validated by trace comparison against the original
18 Wi-Fi adapter types driven from userspace after one chipset's firmware protocol was specified from sources and the air
30,000 lines of decompilation read to recover one vendor's upgrade protocol — and the undocumented account inside it

Each result validated on the target hardware or a bit-exact model of it; the harnesses are shown on the call.

You depend on something you cannot read

A kernel blob that pins you to an old kernel. A radio firmware with an interface nobody documented. A model file the vendor will not explain. A device whose upgrade path you have to trust. The vendor's answer is a newer blob, or no answer at all.

Reverse engineering with a tool that guesses is worse than none. We have watched a language model write a fluent, wrong story about a binary. So every recovered fact is checked against running hardware — registers compared, packets witnessed on air, outputs matched byte for byte — before it enters the report.

A decompiler tells you what the code might do. The harness tells you what it did.

What we bring

Four things, each one measured on the hardware.

Blobs become source

Kernel drivers and firmware you can build, patch and carry to the next kernel. We replace the binary function by function and prove parity by comparing traces.

Proof, not narrative

Each deliverable ships with its oracle: a register-parity check, an on-air witness with a positive control, a byte-identical output. If a claim cannot be tested, we say so.

Neural networks included

Binary model formats, encrypted SDKs, modified weights. We recover layouts down to the register map and modifications down to the exact layers changed — and hand the running of them to our Edge AI team.

Faster than it used to be

AI-assisted decompilation and an in-house decompiler with type recovery let one engineer cover what used to take a team. The hardware still has the last word.

What we have recovered

Silicon

Two video-encoder kernel blobs became C, all 427 functions, verified by trace comparison on a desktop model of the chip. Cleanroom drivers for the same vendor's vision and neural engines came out byte-identical to the originals, and the firmware builds them on a current kernel.

Radio and protocols

A mainstream Wi-Fi chipset's firmware protocol was specified from vendor sources, validated on air, and now drives 18 adapter types from userspace. A camera vendor's undocumented upgrade protocol — and the account hidden inside it — became a written specification. A motorised-lens protocol was reversed the same way, for autofocus.

Models

A camera NPU's binary model format was dissected to its register map. An encrypted commercial licence-plate SDK gave up its model layout from a running container. A modified language model was compared weight by weight and the modification recovered exactly, to the layer.

Targets and harnesses

ARM & MIPS firmwareKernel blobsWi-Fi & USB devicesCamera NPUsNeural models

Harnesses we build to prove the work: chip models that run vendor code on the desktop, kernel probes, USB monitors, register-parity oracles, on-air witnesses with positive controls, and conformance suites for the protocols your product speaks.

How an engagement works

01

Target assessment

Fixed price, five working days. You send the binary, firmware image or device, and the question you need answered. You get what is recoverable, the harness we would build to prove it, the risks, and a fixed quote for the recovery.

02

The project

Harness first, then the recovery against it — driver, protocol, format or model — with every claim traceable to a test that your team can rerun.

03

Keep

Source, specification, harness and oracles are yours. After every change, the proof runs again.

Send the binary and the question. In five days you will know whether the answer can be proven.

One mail with four lines: what the target is, what you need from it, what you can share, and the deadline. Under NDA from the first reply. An engineer answers, not a sales script.

Write to business@openipc.org Ask in the chat

Commercial support, OEM licensing and the other services are on the business page.