Disassembly translates bytecode into instruction-level mnemonics, which is useful for low-level inspection and debugging. Decompilation goes further by lifting instructions into structured JavaScript with variables, control flow, and higher-level constructs such as loops and conditionals. For app review, decompilation usually gives the faster path to understanding behaviour, while disassembly helps fill gaps and validate edge cases.
Why Disassembly and Decompilation Reveal Different Things in Hermes Analysis
When teams analyse hermes bytecode, the distinction is not academic. Disassembly shows the instruction stream exactly as the runtime sees it, which is useful for tracing execution and confirming how a function is encoded. Decompilation aims to reconstruct readable JavaScript, which improves comprehension but can introduce interpretation errors when the bytecode uses optimisations, obfuscation, or patterns that do not map cleanly back to source. For reviewers, the key issue is trust: a readable output can be persuasive even when it is only an approximation. In practice, many security teams encounter hidden logic only after they compare a decompiler’s output with the underlying instruction sequence.
How Analysts Use Each View During App Review
Disassembly is the better starting point when the goal is to understand exact operations, branching, and data movement. It exposes the primitive actions present in the bytecode, so it is valuable for validating whether a behaviour really exists, whether a branch is reachable, or whether a suspected API call is actually present. Decompilation is more efficient when the goal is to understand intent at scale, because it reconstructs variables, loops, and conditionals into a form that a human can read quickly.
In practice, the two views answer different questions. Disassembly helps an analyst answer, "What instructions are here?" Decompilation helps answer, "What does this logic appear to do?" A disciplined review usually starts with the decompiled view to build a fast mental model, then drops back to disassembly when the code is ambiguous, incomplete, or intentionally confusing. This is especially important in mobile reverse engineering, where bytecode may be packaged, transformed, or lightly obfuscated before analysis.
A useful workflow is to compare the same function in both forms and look for mismatches in control flow, constants, or call boundaries. If the decompiler smooths over a conditional, inlines a helper, or invents variable names that oversimplify behaviour, the disassembly becomes the source of truth for verification. The reverse is also true: a clean decompilation can reveal intent that would be tedious to infer instruction by instruction. NIST’s control guidance is useful here as a reminder that analysis quality depends on disciplined handling of evidence and controlled access to sensitive artefacts, not just tooling speed; see NIST SP 800-53 Rev 5 Security and Privacy Controls.
The practical limit is that neither view is guaranteed to be perfect when bytecode has been intentionally shaped to mislead analysis.
Where the Difference Matters Most in Edge Cases
Tighter reconstruction often improves readability, but it also increases the chance that an analyst trusts a simplified model instead of the underlying instructions. That tradeoff matters most when bytecode is obfuscated, partially corrupted, or generated by tooling that does not preserve source-level structure cleanly.
There is also a genuine consensus gap in tooling quality: some decompilers recover structure well for straightforward application logic, while others struggle with unusual control flow, packed constants, or compiler artefacts. In those cases, disassembly remains the safer reference point for edge conditions such as unreachable branches, short-circuit logic, and indirect calls. Decompilation can still be very useful, but it should be treated as an interpretation layer rather than a definitive reconstruction.
Another edge case is review depth. If the question is behavioural triage, decompilation usually saves time. If the question is evidentiary, such as validating an exact operation or confirming that a suspicious path is not an artefact of the decompiler, disassembly carries more weight. Analysts should resist treating one output as universally superior; the best results come from using the decompiled view for speed and the disassembled view for certainty.
Risk and Threat Considerations
The main risk in Hermes analysis is over-trusting reconstructed JavaScript when the underlying bytecode has been shaped to conceal intent. Obfuscation, control-flow flattening, and non-standard compiler output can make decompilation look cleaner than the original logic really is, which creates false confidence during app review.
Failure mechanism: An analyst accepts the decompiler’s reconstructed structure as authoritative, then misses a branch, a call path, or an inline operation that is only obvious in the instruction stream. Adversaries and app authors can benefit from that gap by hiding sensitive behaviour in patterns that survive execution but do not round-trip cleanly into readable source.
Impact: Reviewers may misclassify the app’s behaviour, overlook data access or network activity, and fail to validate the exact conditions under which logic executes. That can weaken malware triage, privacy review, and integrity checks on mobile applications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Hermes bytecode review often needs to handle intentionally obscured logic. |
| Recommendation — Map suspicious encoding patterns to T1027 and validate the underlying instructions directly. | ||
| CIS Controls v8 | 8 — Audit Log Management | Bytecode analysis benefits from preserving review evidence and traceability. |
| Recommendation — Retain analysis artefacts and traceability so reviewers can compare decompiled and disassembled evidence. | ||
| NIST CSF 2.0 | DE.CM-1 — Monitoring for Unauthorized Activity | Comparing bytecode views supports detection of unexpected or risky app behaviour. |
| Recommendation — Use DE.CM-1 to monitor for behaviour that differs from the reconstructed logic. | ||
Practitioner Guidance
What to prioritise: Use decompilation first for speed, then confirm any security-relevant branch, call, or constant in disassembly before you rely on it. The verification step matters most when the code path affects permissions, data handling, or external communication.
What practitioners underestimate: The biggest error is treating readable output as proof. A decompiler is an interpretation tool, so analysts should treat mismatches between the two views as an investigation trigger, not a formatting issue.
Practitioner takeaway: Decompilation is usually the better lens for understanding intent, but disassembly is the better lens for proving behaviour.
Related resources from NHI Mgmt Group
- What is the difference between analysing phishing emails with multiple specialised agents and using a single classifier?
- What is the difference between NHI and machine identity?
- What is the difference between an identity, a credential, and a secret?
- What is the difference between static and dynamic credentials?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
