A useful answer.
Before you fund the work.
The free novel-architecture assessment explains what we observed, what is likely recoverable, what still depends on runtime evidence, and what an accepted engagement would deliver.
Synthetic file and findings. This page demonstrates the report format; it is not a customer result or a coverage claim about another binary.
The requested decision path is likely recoverable.
The sample contains a coherent virtual instruction pointer, repeatable dispatch boundaries, and handlers with observable state effects. Those signals support a scoped recovery engagement. A runtime-derived key prevents us from promising complete static coverage before the trace is captured.
Your questionWhich request reaches the protected identity decision, and what conditions control the result?
Four signals define the recovery path.
- Entry layerUnpacking must happen before handler recovery can be trusted.
A packed native entry reconstructs the working image before control reaches the VM.
- Execution modelThe architecture is recoverable, but it does not match a known automated profile.
A register-based dispatcher advances an encoded instruction pointer through handlers.
- State dependencyA bounded trace is required for paths that depend on that key.
One key is derived from values only present during an authorized execution.
- Expression layerRecovered expressions need simplification and equivalence checks before delivery.
Arithmetic expressions contain mixed Boolean-arithmetic substitutions.
An estimate with reasons, not a decorative percentage.
This range describes the agreed roots in the synthetic example. It is not the final ledger and it does not imply that every behavior in the file is recovered.
- Strongest evidence
- Stable dispatch and repeatable handler state changes
- Runtime dependency
- Key material for one branch family
- Permanent bound
- Unreached behavior outside the accepted roots
Recovery follows the evidence.
Capture the boundary
Recover the unpacked image and record the transition into virtualized code.
Recover the machine
Identify context fields, instruction movement, dispatch, and handler effects.
Lift the requested roots
Translate the agreed functions into readable control flow and typed calls.
Verify and package
Compare recovered behavior, record unresolved paths, and prepare the deliverables.
A feasibility estimate is not delivered proof.
- It does not claim complete behavior coverage before analysis.
- It does not turn a timeout or missing trace into a successful proof.
- It does not include behavior outside the written scope.
- It does not authorize use of the service against software you may not analyze.
The useful report is yours either way.
Review the findings and formal offer in your workspace and email. Accept to fund the agreed work, or decline without opening a paid engagement.
An unfamiliar architecture? Start in your account.
Upload for free feasibility review in your workspace. We email the report and quote before paid work begins.
Create your workspace
Create an account, verify your email and upload your file. We review custom work and email your scope and quote.