Firmware entropy analysis: detecting encryption, compression and packing

A firmware image is rarely one uniform blob — it's a bootloader, a kernel, one or more root filesystems, configuration data, certificates and often a vendor update mechanism, all concatenated into a single binary. Each of those has a different statistical character. Code and text have structure: certain byte values (ASCII letters, common opcodes, null padding) repeat far more often than others, so a window of plaintext code sits well below the theoretical maximum entropy for its byte width. NIST SP 800-90B, written to formally define and validate entropy for random-number generators rather than for firmware, states the underlying mathematics plainly: "the maximum possible value for the min-entropy of a random variable with k distinct values is log2 k, which is attained when the random variable has a uniform probability distribution." For a byte stream, k is 256 possible values, so that ceiling is exactly log2(256) = 8 bits per byte — reached only when every byte value is about equally likely, which is precisely what a well-encrypted or well-compressed stream looks like, because a good cipher or compressor removes exactly the structure that would otherwise bias some byte values over others.

No — and this is the single most common misreading of an entropy graph. ReFirmLabs' binwalk documentation puts the ambiguity directly: "Both compressed and encrypted data is, by nature, very random." A SquashFS partition, a gzip-compressed kernel, a JPEG splash screen and a genuinely encrypted update blob can all land in the same high-entropy band, because compression and encryption both aim to remove redundancy — one so the data takes less space, the other so an attacker can't exploit patterns. Lyda and Hamrock's widely cited 2007 IEEE Security & Privacy paper, Using Entropy Analysis to Find Encrypted and Packed Malware, demonstrated the same effect at malware-analysis scale: entropy reliably singles out packed and encrypted executables as statistical outliers against a large reference set of ordinary, unpacked code, but the entropy value by itself doesn't say which kind of outlier you're looking at. Separating "legitimate compressed filesystem" from "deliberately packed or encrypted payload" takes a second signal — a compression header or magic-byte sequence a signature scanner recognizes, or simply attempting to decompress the region and checking whether coherent structure comes out.

In practice, entropy analysis is run alongside, not instead of, signature scanning. binwalk's -E (or --entropy) option slides a window across the image, computes the Shannon entropy of each window, and plots the result as a graph; its default signature scan (-B) separately looks for known magic bytes marking filesystem headers, compressed archives, certificates and the like. Overlaying the two is the useful part: a high-entropy region that lines up with a recognized filesystem signature is very likely just compression doing its job, while a high-entropy region with no matching signature at all is the one that deserves the closest look — binwalk's documentation notes that entropy analysis "can even help to identify unknown compression or encryption" that signature matching, which only recognizes headers it already knows, would otherwise miss completely. That gap matters: a region using a proprietary or simply unrecognized wrapping scheme produces no signature hit, and entropy is often the only signal that something is there at all.

Entropy analysis is normally one of the first passes in a binary-analysis workflow, run before the deeper work of unpacking file systems, identifying components and matching them against known vulnerabilities — the process our firmware SBOM guide covers in more detail. A region that scores low-to-moderate entropy, with no encryption in the way, is a strong candidate for actually being unpacked, identified and carried into normal component and CVE matching. A region sitting at the entropy ceiling, with no compression signature a tool recognizes, most likely can't be unpacked further without a key nobody on the review has — the correct outcome there is to record it as an unidentified, encrypted region with a stated confidence level, not to silently drop it from the inventory or guess at its contents.

Entropy also has a second, security-specific use beyond inventory: spotting tampering. CISA, the NSA and the FBI's joint advisory on BlackTech threat actors hiding custom firmware in network edge devices recommends that defenders "periodically take snapshots of boot records and firmware and compare against known good images" specifically to catch unauthorized modification. An entropy map is a cheap way to do a coarse version of that comparison — a region that was low-entropy plaintext in a known-good baseline image and shows up high-entropy in a field image is worth investigating regardless of whether anything else about the firmware looks different, the same reasoning that applies to weak or unexpected cryptography more broadly in our weak cryptography in embedded firmware guide and to verifying what a device's secure boot and hardware root of trust actually protects.

An entropy score is not an AI output. A sliding-window Shannon-entropy calculation is a fixed, deterministic statistic: the same firmware image produces the same numbers every time, with or without a model anywhere near the process. What does benefit from more than a spreadsheet of numbers is triage — turning a few hundred flagged windows across a multi-megabyte image into a short, readable list of "these regions are almost certainly just the compressed filesystem, these are worth a human's time, and these are encrypted and we can't say more without a key."

That's the narrow, evidence-bound role AI plays here, and it's the same rule SoftWSP applies to every report it produces: code produces the score, AI only interprets it, and every sentence it writes has to cite the specific evidence behind it — in this case, the window offset, size and entropy value a deterministic pass already calculated — rather than a number the model invented itself. An engineer reviews those citations before anything goes out. For firmware engagements that need this kind of binary-level unpacking, that AI narrative layer is what turns a raw entropy graph and a signature-match log into a readable summary of what a binary-analysis pass actually found, what it could identify, and what it had to leave marked "encrypted, unidentified" — never the reverse, where a model decides on its own that a region is malicious with nothing underneath that claim to check.

See device & firmware security services for how binary-level firmware analysis, including this kind of triage, fits into a full review.

This guide draws on binwalk's entropy-analysis documentation (ReFirmLabs), NIST SP 800-90B, Lyda and Hamrock's 2007 IEEE Security & Privacy paper on entropy analysis for malware, and CISA/NSA/FBI's joint advisory AA23-270A, read directly 2026-11-09.