What is the difference between disassembly and decompilation when analysing Hermes bytecode?

Why This Matters for Security Teams

hermes bytecode analysis is often the first reliable way to see what a mobile app is actually doing after obfuscation, packing, or runtime checks. Disassembly and decompilation are not interchangeable: disassembly exposes the instruction stream, while decompilation attempts to reconstruct readable JavaScript. That difference matters because security teams need both low-level proof and higher-level intent when reviewing app logic, credential handling, and network behaviour.

For practitioners, the question is not academic. A decompiler may recover enough structure to show data flow, conditional logic, or hidden endpoints, but it can miss edge-case semantics that only appear in the instruction sequence. Disassembly, by contrast, can validate offsets, branches, and bytecode-level anomalies that decompilers may smooth over. This is especially important when investigating applications that rely on secrets embedded in code or on weak handling of tokens, a problem NHIMG highlights in its Ultimate Guide to NHIs — What are Non-Human Identities.

In practice, many security teams encounter the real behaviour only after decompilation has failed to explain a suspicious call path, rather than through intentional bytecode review.

How It Works in Practice

Disassembly is the lower-level step. It translates Hermes bytecode into instruction mnemonics, registers, jumps, and operands, which makes it useful for tracing control flow and validating whether a decompiler has skipped or reshaped anything. Decompilation sits on top of that and tries to rebuild a higher-level JavaScript view with variables, loops, conditionals, and function boundaries. That lift is useful for analysts because it compresses many bytecode operations into something closer to the source logic.

In an app review workflow, the two techniques complement each other. A common pattern is to decompile first to get a readable map of behaviour, then disassemble the same region when something looks suspicious or incomplete. This is consistent with broader reverse-engineering practice and with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises evidence, traceability, and controlled analysis of system behaviour.

• Use decompilation to identify business logic, data handling, and obvious sinks such as network calls or storage writes.
• Use disassembly to confirm branch conditions, stack behaviour, and bytecode sequences where the decompiler output is ambiguous.
• Compare both views when a function appears flattened, renamed, or partially recovered.
• Track suspicious constants, string construction, and indirect calls in both representations.

For teams focused on identity and secret exposure, this matters because bytecode often reveals how API keys, tokens, or session material are loaded, transformed, or transmitted. NHIMG’s research notes that service-account and secret exposure are persistent enterprise problems, and its broader guidance on NHI governance helps frame why reverse engineering often becomes a control validation exercise, not just a code-reading task. These controls tend to break down when the app uses heavy obfuscation, runtime-generated bytecode, or native bridges because the decompiler can no longer reconstruct accurate high-level structure.

Common Variations and Edge Cases

Tighter analysis depth often increases time cost, so teams have to balance speed against confidence. The right choice depends on whether the goal is quick behavioural triage or evidentiary reconstruction.

There is no universal standard for Hermes analysis depth yet, and current guidance suggests treating decompilation output as a best-effort reconstruction rather than ground truth. Some bytecode patterns decompile cleanly, while others collapse into confusing pseudo-code or lose important edge conditions. In those cases, disassembly becomes the source of truth for verifying execution order, exception paths, and opaque predicates.

Edge cases also matter when dealing with generated code, stripped symbols, or anti-tamper logic. Decompiled JavaScript may look complete while still omitting a hidden branch or a post-processing step that only appears in the bytecode sequence. For that reason, experienced reviewers usually cross-check both outputs before making a finding. Where sensitive runtime material is involved, especially secrets or tokens, the safest approach is to assume the more readable view may be incomplete and the lower-level view may be the one that exposes the real risk.

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?