When binwalk finds nothing: unpacking proprietary formats

binwalk -eM handles a surprising amount of the market, and when it fails people often stop. It shouldn’t be the end of the road.

What to do when extraction comes up empty:

1. Check whether it’s encrypted or just unknown. Entropy near 1.0 across the whole image means encrypted. Mixed entropy with no recognized signatures means a custom container.

2. Map the header by hand. Open it in a hex editor and look for:

  • Magic values at offset 0 — vendor-specific but consistent across firmware versions
  • Length fields — look for 4-byte values that match the file size or a plausible section size
  • Offset tables — sequences of increasing 4-byte values
    Diffing two firmware versions of the same device is enormously helpful here: the fields that change are lengths, offsets, and checksums; the fields that don’t are magics and version constants.

3. Get the bootloader. If the image is encrypted, something has to decrypt it. That something is usually U-Boot or a vendor first-stage loader, and it’s often readable in flash even when the main image isn’t. Dumping flash directly over SPI beats fighting the update file.

4. Look for the update client. The device’s own updater knows the format. Reversing it is often faster than reversing the format from the outside.

Anyone got a favorite example of a format that looked custom but turned out to be something standard with a header bolted on?