Deterministic Hermes bytecode decompilation changes React Native review

At a glance

What this is: This is a research release describing a deterministic decompiler for Hermes bytecode that reconstructs readable JavaScript, control flow, and Metro modules from React Native app binaries.

Why it matters: It matters because application security teams need to review shipped code, not just disassembly output, and this changes how they assess hidden logic, embedded dependencies, and review coverage in mobile apps.

By the numbers:

• The decompiler covers 60 Hermes bytecode versions, from HBC 40 to 99.
• 359 programs

👉 Read Symbiotic Security's research release on deterministic Hermes bytecode decompilation

Context

Hermes bytecode decompilation addresses a familiar application security gap: production mobile code often ships in a form that is much harder to inspect than source. When React Native apps are compiled into Hermes bytecode, reviewers lose the straightforward visibility they expect from readable JavaScript, which makes manual analysis slower and less reliable. In this case, the primary keyword is Hermes bytecode decompilation, and the practical issue is auditability rather than exploitation.

For application security, the core problem is not whether bytecode can be disassembled, but whether the recovered output is structured enough to support real review decisions. That becomes especially relevant where code review feeds vulnerability analysis, supply chain assurance, or downstream governance of app logic. It is a technical review problem with a genuine security governance angle, and that makes the topic relevant to teams that need evidence, not just opcode listings.

Key questions

Q: How should security teams review React Native apps when source code is not available?

A: They should treat the shipped binary as the review target and use tooling that can recover structured logic, not just disassemble instructions. The goal is to understand control flow, module boundaries, and embedded dependencies well enough to make security decisions on the artifact that actually ships.

Q: Why does deterministic output matter in decompilation workflows?

A: Deterministic output lets analysts reproduce the same recovered code from the same binary, which makes findings easier to validate, compare, and audit. It reduces ambiguity created by heuristic reconstruction and gives reviewers a stable basis for evidence-based security assessments.

Q: What do security teams get wrong about bytecode review?

A: They often treat disassembly as if it were equivalent to readable source, even though it leaves too much manual reconstruction to the analyst. That creates blind spots around control flow, module structure, and hidden logic that can affect security conclusions.

Q: How should teams govern AI-assisted reverse engineering tools?

A: They should treat them as privileged workflow dependencies with scoped access, logging, and review controls. If a tool can be called from an MCP server or similar integration point, the workflow must be governed like any other sensitive analysis environment.

Technical breakdown

How Hermes bytecode decompilation restores reviewable control flow

Hermes bytecode decompilation starts by parsing the binary format, extracting headers, string tables, and raw instructions before translating them into opcodes. The more important step is lifting those instructions into an intermediate representation, where registers become variables and jumps become a graph. That graph is what makes structure recovery possible. Without it, reviewers see execution fragments. With it, the tool can rebuild if, while, and for constructs that are otherwise hidden inside low-level control transfers.

Practical implication: teams should evaluate whether their analysis tooling can reconstruct structured control flow, not just display disassembly.

Why deterministic output matters for security review

Deterministic decompilation matters because security review needs repeatable evidence. If the same binary yields the same recovered code, analysts can compare findings, validate assumptions, and trace a construct back to the original bytecode without guessing which transformation step altered the result. The article also says names are marked as read from the binary or inferred from usage, which is useful because reviewers can separate proven recovery from heuristic reconstruction. That distinction reduces ambiguity in audit workflows.

Practical implication: security teams should require provenance markers in recovered code so they can distinguish direct recovery from inferred structure.

What MCP support changes in AI-assisted analysis workflows

The inclusion of an MCP server means the decompiler can sit inside an analysis workflow that tools and agents can call at runtime. That does not make the analysis autonomous, but it does make the decompilation step easier to chain into broader review pipelines. For security teams, the identity angle is indirect but real: once an AI-assisted workflow can call code-analysis tools, access to binaries, outputs, and traces needs governance like any other privileged workflow dependency.

Practical implication: teams should treat AI-assisted reverse engineering workflows as governed toolchains with scoped access and traceable execution.

NHI Mgmt Group analysis

Deterministic decompilation is a review-enablement problem, not a silver bullet. The article addresses a real blind spot in mobile security, where reviewers often stop at disassembly because the recovered output is too fragmented to reason about. A deterministic pipeline changes the quality of evidence, but it does not remove the need for analyst judgment. For application security teams, the practitioner conclusion is that auditability must be measured by the readability and traceability of recovered code, not by whether a tool can emit JavaScript.

The named concept here is bytecode auditability debt. When production apps ship in compiled bytecode, security teams accumulate review friction that makes code inspection slower, less repeatable, and easier to defer. The article shows that the debt is partly structural, because control flow and module boundaries are obscured by compilation. That means organisations need to assess whether their mobile review process can still produce defensible findings when source code is not available in plain form. The practitioner conclusion is to measure audit coverage on the shipped artifact, not the source repository.

MCP integration extends the security concern from analysis quality to workflow governance. Once a decompilation capability is exposed as a tool that AI systems can invoke, the analysis pipeline itself becomes a governed dependency. That is relevant to NHI and agentic AI governance because the workflow now includes machine-to-tool interactions that may touch sensitive app binaries and findings. The practitioner conclusion is that teams should scope and log access to reverse-engineering workflows as they would any privileged analysis service.

This kind of tooling will raise the bar for mobile security review expectations. As recovered code becomes more readable, teams will have less room to rely on incomplete inspection or manual sampling. That does not eliminate false confidence, but it does shift the baseline for what a credible review should contain. For practitioners, the key question becomes whether their current program can consume richer evidence without creating a backlog of unreviewed mobile assets. The practitioner conclusion is to align review depth with the fidelity of the recovered artifact.

What this signals

Bytecode auditability debt: mobile teams increasingly need to treat compiled artifacts as first-class review inputs, because the security value is in the reconstructable evidence, not the binary alone. That aligns with application security programmes that already use structured controls such as NIST Cybersecurity Framework 2.0 and stronger code review evidence.

If decompilation is embedded in AI-assisted analysis, the workflow inherits the same governance concerns that apply to other sensitive machine-enabled tooling. The practical signal for practitioners is to log access, restrict binaries, and keep chain-of-custody intact from input artifact to final finding.

Richer recovery output will expose more hidden logic, but it will also expose weak triage processes. Teams that can consume deterministic evidence will improve review quality; teams that cannot will simply create a larger backlog of unreadable findings.

For practitioners

• Audit against recovered control flow, not disassembly alone Update mobile review procedures so analysts inspect structured control flow, reconstructed modules, and inferred identifiers rather than treating raw opcodes as the final evidence set.
• Track provenance of inferred names and structures Require tooling output to distinguish values read directly from the binary from values inferred through analysis, so reviewers can judge confidence correctly.
• Govern AI-assisted reverse-engineering workflows If the decompiler is wired into an MCP-enabled workflow, scope access to binaries, outputs, and logs, and record every tool invocation for auditability.
• Prioritise high-risk React Native assets for deeper review Use deterministic decompilation on apps that carry sensitive business logic, embedded secrets, or third-party SDK risk, then feed findings into application security triage.

Key takeaways

• Hermes bytecode decompilation changes the review problem from low-level inspection to structured code recovery.
• Deterministic output and version coverage turn decompilation into an evidence-quality issue, not just a tooling feature.
• Once decompilation enters AI-assisted workflows, access to binaries and outputs needs the same governance discipline as other privileged analysis services.

Key terms

• Hermes Bytecode: Hermes bytecode is the compiled binary form of JavaScript used by React Native applications. It improves runtime performance, but it also makes application logic harder to inspect directly because reviewers are no longer looking at human-readable source.
• Deterministic Decompilation: Deterministic decompilation is the process of converting bytecode back into structured source-like output in a repeatable way. For security teams, the value is not perfect source recovery, but stable output that can support validation, comparison, and audit trails.
• Control Flow Graph: A control flow graph is a structural model of how code paths move through a program. Static analysis uses it to trace how data and logic can interact, which helps identify reachable vulnerabilities and distinguish exploitable paths from harmless patterns in isolation.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.

What's in the full report

Symbiotic Security's full research release covers the operational detail this post intentionally leaves for the source:

• The five-stage decompilation pipeline, including parsing, disassembly, IR generation, analysis, and code generation
• The public round-trip corpus used to validate output across 359 programs
• The specific Hermes loop-inversion and structure-recovery cases handled by the tool
• The GitHub repository and paper for teams that want to inspect implementation details directly

👉 Symbiotic Security's full paper covers the reconstruction pipeline, version coverage, and validation corpus in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle topics that support broader security review work. It is suitable for practitioners who need to connect identity governance to operational security programmes.