THE FIRST MISTAKE
Opening the binary is not the beginning of the investigation.
Firmware analysis attracts tools with satisfying output. Signature scanners identify embedded archives. String extractors spill URLs, paths, command names, build tags, and forgotten developer comments. Disassemblers produce functions where there used to be anonymous bytes. Entropy graphs suggest compression or encryption. All of that can be useful.
None of it answers the first evidentiary question: what object are you analyzing?
A vendor download, a flash dump, a recovery image, an over-the-air update payload, a package extracted from a mobile application, a chip read through a programmer, and a filesystem copied from a running device are not interchangeable evidence classes. They may contain overlapping code while differing in headers, signatures, bootloader regions, configuration data, calibration values, secrets, bad blocks, padding, encryption, or device-specific state.
If the acquisition class is unclear, every later conclusion inherits that ambiguity.
ACQUISITION
Record how the bytes entered your possession.
Start with the boring material that becomes priceless once the original source changes or disappears.
Record the manufacturer or project; product and hardware revision; firmware version as labeled; download or acquisition URL; retrieval date; original filename; file size; transport or extraction method; device serial or board revision when relevant; operator; and a cryptographic hash of the untouched object.
If the image came from physical hardware, record the read method and toolchain. If multiple reads are possible, compare them. Repeated identical reads are stronger evidence than a single unverified dump. If reads differ, preserve all of them and find out whether the cause is unstable hardware, dynamic regions, error correction, wear-leveling behavior, a bad connection, or a genuinely changing device state.
The acquisition notebook does not need to be ornate. It needs to exist.
ORIGINALS + DERIVATIVES
Never make the only copy do double duty as a workbench.
Cyberdelia’s archive doctrine applies cleanly to firmware: originals remain immutable; analysis products are derivatives.
Keep the acquired image read-only. Hash it. Copy it into a working directory. Run scanners, carving tools, decompression, filesystem extraction, byte patching, decryption experiments, and disassembly imports against derivatives.
A useful tree might separate original/, working/, extracted/, notes/, tool-output/, and repacked/. The exact names matter less than preserving directionality: every transformation should be traceable back toward the source object rather than silently replacing it.
If a tool modifies metadata, normalizes permissions, rewrites timestamps, changes line endings, or repairs an archive, that output is not the original anymore. This is not pedantry. It is how you keep a later discovery from becoming impossible to reproduce.
IDENTITY
Version labels are clues, not unique identifiers.
Vendors sometimes reissue a file under the same human-readable version. Mirrors can carry corrupted copies. Regional builds can share marketing labels while differing internally. A recovery image and an update payload can advertise the same release while containing structurally different material.
Use both human identity and byte identity.
Human identity: product, board, region, channel, version, release date, filename.
Byte identity: exact size and cryptographic hash.
When two files claim to be version 1.4.7 but hash differently, that is not an inconvenience to average away. It is a branch in the investigation.
CONTAINER BEFORE CODE
The first layer may be packaging, not firmware logic.
A firmware file can contain update headers, signatures, certificates, manifests, compression streams, encrypted regions, bootloaders, kernels, device trees, root filesystems, web interfaces, language resources, radio firmware, calibration blobs, and several processor architectures in one package.
Before loading the whole object into a disassembler, identify the container structure.
Look for known file signatures, magic values, archive formats, filesystem markers, partition tables, compression headers, executable formats, certificate containers, and repeating alignment patterns. Tools such as Binwalk are useful because they scan for embedded file and data signatures and can assist with extraction. Their output should still be treated as hypotheses produced by signatures, not revelation.
A false-positive signature inside compressed or random-looking data is possible. Validate important findings by checking offsets, structure, checksums, surrounding bytes, and whether an extracted object behaves like the format it claims to be.
ENTROPY
High entropy tells you something is dense, not why.
Entropy plots are excellent for seeing boundaries and asking better questions. Low-entropy runs can suggest padding, erased flash, tables, text-heavy regions, or repetitive data. Higher-entropy regions may indicate compression, encryption, packed code, already-compressed media, or simply data with broad byte distribution.
The common mistake is jumping from “high entropy” to “encrypted.” Compression can look similar. So can some media and packed data. Entropy is a locator and comparative instrument, not a semantic decoder.
Use it to find transitions. Compare releases. Ask why one region changed while another remained stable. Then combine the clue with signatures, headers, known algorithms, executable structure, update logic, and device behavior.
FILESYSTEMS
Sometimes the highest-value reverse engineering looks suspiciously like ordinary system administration.
Once a filesystem is extracted, stop treating it as a bag of strings and inventory it as a system.
Map startup scripts, service definitions, binaries, libraries, configuration files, web assets, certificates, package databases, device rules, update scripts, scheduled tasks, writable paths, logs, and default data. Identify which files are vendor additions versus upstream operating-system components. Note timestamps carefully, but do not assume extracted timestamps necessarily preserve original acquisition truth unless the format and extraction method justify that assumption.
A firmware filesystem can answer architectural questions before a single function is decompiled: what launches first, what listens for input, what talks to hardware, what persists configuration, how updates are applied, what logs exist, and which components appear shared across product lines.
ARCHITECTURE
Do not force bytes into the wrong processor because the disassembler allowed it.
Architecture identification should accumulate evidence.
Executable headers may state machine type directly. Boot messages, library names, compiler strings, ABI paths, relocation patterns, known vector tables, instruction alignment, and vendor documentation can reinforce the conclusion. Embedded products may contain multiple architectures: a main application processor, a microcontroller, a Wi-Fi or Bluetooth chipset, a management controller, a security element, or programmable logic.
If code looks nonsensical under one architecture, the answer is not necessarily “obfuscation.” Sometimes the analyst selected the wrong language for the silicon.
SIGNATURES + UPDATE TRUST
A signed update and a trustworthy device state are related, not identical.
Firmware update systems often use cryptographic signatures or other authenticated mechanisms to decide whether an image is authorized. NIST’s Platform Firmware Resiliency Guidelines frame the problem around protection against unauthorized changes, detection of changes that occur, and secure recovery.
During analysis, identify where trust decisions appear to happen. Look for signed manifests, certificate chains, public keys, version metadata, rollback controls, recovery images, and alternate update paths. Do not assume the presence of a signature file proves every byte in the package is covered by the signature. Determine the signed region and verification flow if the distinction matters.
Rollback behavior deserves separate attention. A system that accepts authentic but vulnerable older firmware can preserve signature correctness while losing security. Version enforcement and recovery policy are part of the trust model.
COMPARE RELEASES
Diffing versions often beats staring harder at one image.
Two or more firmware versions turn archaeology into comparative anatomy.
Compare file inventories, hashes, region offsets, entropy boundaries, filesystem contents, certificates, kernel versions, library versions, web assets, startup scripts, and executable sizes. Identify what stayed byte-identical and what changed. A small vendor patch becomes easier to isolate when 98 percent of the package is unchanged.
Do not rely only on binary-diff percentage. Recompression can make a logically tiny change appear to alter a huge compressed region. Extract to comparable layers where possible, then compare again.
Version comparison is also useful for provenance. If an alleged release contains components newer than its stated date, or lacks changes known to exist in that version family, the mismatch becomes a question worth pursuing.
EXECUTION
Static curiosity should not quietly become production execution.
Unknown firmware components can contain privileged code, malformed parsers, network services, destructive update logic, credential material, or malware. Do not execute arbitrary extracted binaries on a workstation that contains valuable data because the file had an interesting name.
Use isolated analysis environments appropriate to the target: disposable virtual machines, containers when the threat model permits them, emulation, dedicated lab hardware, segregated networks, snapshots, and explicit rules about what can reach the internet or other internal systems.
Isolation is not ceremonial. Firmware often assumes root-level or hardware-level access. A component designed to rewrite flash deserves more respect than a PDF attachment with delusions of grandeur.
MANIFEST
A useful firmware project should be reproducible by someone who was not in the room.
Minimum project metadata should include:
Source: manufacturer/project, device, board revision, region/channel, firmware version, source URL or acquisition method, acquisition timestamp, original filename, byte count, SHA-256.
Acquisition: hardware/software used, read commands or process, repeat-read agreement, known errors, operator.
Toolchain: scanner/extractor/disassembler versions, plugins, signatures, scripts, containers, architecture assumptions.
Transformations: decompression, carving, filesystem extraction, decryption, normalization, patches, repacking.
Findings: offsets, components, hashes, architecture, filesystem types, update/signature structure, uncertainty, competing interpretations.
Artifacts: logs, extracted trees, screenshots where they add information, machine-readable inventories, comparison reports, and hashes for important derivatives.
This is the difference between “I poked at firmware” and a research package.
FAILURE MODES
Ways firmware analysis lies to the analyst.
False-positive signatures. Random or compressed bytes accidentally resemble known headers. Validate structure.
Wrong acquisition class. An update package is mistaken for a full flash image, or a filesystem backup for complete firmware.
Wrong architecture. Bytes are forced into a plausible but incorrect instruction set.
Timestamp mythology. Extracted filesystem dates are treated as unquestionably original.
Entropy overclaim. High entropy is declared encryption without additional evidence.
Version-label trust. Two different byte sequences are treated as identical because the GUI calls both version 3.2.
Tool-output authority. A scanner label becomes a fact without examining the bytes at the reported offset.
Original contamination. The only copy gets patched, normalized, mounted read-write, or otherwise changed.
Unsafe execution. Unknown privileged code gets launched on a useful workstation. Nature then conducts peer review.
BOTTOM LINE
Preserve first. Interpret second. Execute last.
Firmware reverse engineering gets more powerful, not less exciting, when acquisition and provenance are treated as part of the technical problem.
The disassembler can tell you what these bytes might mean. It cannot tell you whether these are the bytes you thought you acquired.
That responsibility belongs to the analysis process.
SOURCE TRAIL
Technical references.
NIST SP 800-193 — Platform Firmware Resiliency Guidelines
NIST SP 800-193 DOI publication
Binwalk — firmware and embedded-data analysis tool