Comparing two eMMC/SPI dumps: hashes and differences
A dump is only useful if it is a faithful copy. Two reads of the same chip should match bit for bit; if they do not, something is wrong with the contacts, the power or the reader. Hashes and a byte comparison tell you which.
Part of the Firmware and dumps guide.
When you need to compare
- Right after reading a chip: copy 1 against copy 2.
- Before and after a repair: what did the TV change in its own memory?
- A working unit against a faulty one with the same board.
- After writing: read back and compare with the file you wrote.
Step by step
- Read the chip twice without touching anything between reads. For the first-time workflow see reading an eMMC dump and the SPI flash SOIC8 pinout.
- Check the file sizes. They must be identical. A different size means a read was cut short or the wrong region was read.
- Compute a hash of each file. CRC32 is quick and fine for detecting accidental errors; MD5, SHA-1 and SHA-256 are better for recording a reference. Equal hashes mean identical files.
- If hashes differ, run a byte-by-byte comparison to get the list of differing ranges (offset and length).
- Interpret the pattern, then fix the cause and read again.
Reading the differences
| Pattern | Likely meaning |
|---|---|
| Few scattered single bytes or small blocks, different on every read | Unstable contact or marginal power; reseat the wires and shorten them |
| Large region of 0x00 or 0xFF in one copy | Read failed or stopped; check the reader and supply |
| Same few areas always differ between two TVs | Unit-specific data (serials, MAC, calibration) or logs; expected |
| Differences only at the end | Sizes differ; the common part matches and the tail is reported separately |
If a TV is running while you read an eMMC in circuit, its own firmware can write to the chip during the read, so two valid reads can differ. Read with the main system not running, and never assume that a difference in a log area means a bad read.
Typical mistakes
- Comparing a dump with a firmware package and expecting a match. They are different things.
- Trusting one read. A single read can hide a bad contact that only shows on the second.
- Comparing after “fixing” a dump by hand. Hash the original first and keep it.
- Ignoring the size check.
How this is done in FW Tool
- “Reference, Hex tools” computes CRC32, MD5, SHA-1 and SHA-256 in one pass over a file, with progress and cancel for large dumps.
- The compare function works byte by byte, streaming, and returns the number of differing bytes and a list of ranges (offset, length); the list is capped, and the program tells you when it was truncated. If the sizes differ, the common part is compared and the tail is counted separately.
- The same tab can search for a hex pattern or a text string (ASCII and UTF-16) and show a classic hex view with offsets and ASCII.
- In the “eMMC dump” tab, writing to a dump is off by default and enabled by a checkbox; make a copy and verify its hash before enabling it. See all features.
Once your copy is verified, you can examine it as in how a USB firmware package is built.
FAQ
Is CRC32 enough?
For catching a bad read, yes. For a long-term reference record, store a stronger hash as well.
Two good reads differ in a few places. Is the dump bad?
Not necessarily. Look at where: logs, counters and timestamps change on their own. Repeat the read and see whether the same ranges differ.
Can I compare an eMMC folder of partition images?
Hash and compare file by file. Partitions that match can be ticked off individually.
Keeping a record
For each device write down the chip marking, the size of the dump, the hash and the date. Store the original dump read-only, and work only on copies. When you later receive the same model, a hash lets you check at once whether a dump you were sent is identical to yours, without opening it. If you service many TVs of one model, a collection of verified dumps becomes a reference library for faults where the memory content, rather than the hardware, is suspect.
A second use of comparison is after a repair attempt. Read the chip, change one thing, read it again and compare: the list of ranges shows exactly which areas the TV rewrote. It is a simple way to learn which partitions hold settings and which hold the system, and to decide what you can safely restore from a backup.
Finally, remember that a matching hash proves only that two files are the same, not that the content is good. Two identical reads of a chip with a failing cell, or of a chip read through a consistently faulty contact, will agree and still be wrong. Where possible, confirm the dump by checking that the partition table is readable and that file systems open, as described in the eMMC dump article.