Vulnerability research

Security research means forming hypotheses, building controlled experiments, and recording exactly what was observed. We work on systems we control or where we have appropriate authorization. A hypothesis, a binary symbol, or a laboratory result does not prove an exploitable production vulnerability.

Our discovery flow

We begin with a bounded question. A hypothesis determines what to measure; a local harness makes the input repeatable; observation records bytes, states, and differences. Only then do we describe what the evidence supports and what remains untested. Unexpected results send us back to the hypothesis.

In the Mibo study, this discipline separated a path visible in code, parity with synthetic data, app execution, and an independent connection. Each step answered a different question; none justified claiming a vendor vulnerability.

Areas of investigation

Engines

Question. What happens when an asset, project file, or message between components reaches a boundary the engine expects to enforce? We follow input through the importer, parser, and consuming subsystems, including cases where a failure appears far from the source data.

Method in progress. We isolate inputs in local harnesses, pin the examined version, and compare normal runs with reduced cases. An interesting case needs to be repeatable and tied to the affected boundary; a lone crash does not establish code execution or an impact on players.

Evidence we seek. A minimal input, version and configuration, execution traces, and an explanation of the crossed boundary. We call something a security issue only after checking impact and realistic conditions of use.

Firmware

Question. What boundaries separate a firmware image, its metadata, partitions, and the process that accepts or rejects it? Recognizing a structure in a file does not prove that a device will load it.

Method in progress. We compare formats and versions in local copies, map fields, and prepare isolated reproductions of reading and update flows. We distinguish what a laboratory parser accepts from what a complete boot or update chain permits on hardware.

Evidence we seek. An identified sample and version, a reproducible case, the relevant component’s response, and the limits of the test environment. We do not infer control of a production device from a static image or partial emulation.

Protocols

Question. How do message format, order, and session state change a peer’s response? We separate identity, negotiation, transport, and data because success at one stage does not prove that the next stage worked.

Method. We connect code inspection, synthetic inputs, and observations in authorized sessions. Where possible, an independent implementation checks the next boundary with fresh sockets and its own state. Published captures omit credentials, private addresses, and session material.

Evidence and limit. Our published Mibo protocol study documents the path from an APK to the first frame for an authorized camera. It demonstrates that bounded path, not a vendor vulnerability, general compatibility, or authority over other devices.

Methods in development

We build local harnesses to repeat test cases and compare results. We are also exploring distilled models and tuning for vulnerability research to support triage and hypothesis generation. These projects are in progress: this page does not announce public tools, confirmed findings, or validated model performance.

We publish results when the evidence is sufficient and they can be shared responsibly. To report an issue in our own products, see our security contact page.