Writing a BIOS image takes a minute. Recovering from the wrong image can take an afternoon — or end with a board that will not boot until you start over. A few minutes of checks before every write catch nearly all of the common mistakes: the wrong board, the wrong size, a half-empty file, someone else's identity data. This is the checklist we use.
The checklist at a glance
| # | Check | Tool | Pass when |
|---|---|---|---|
| 1 | Size | File properties | Exactly the chip size |
| 2 | Board and model | Hex editor string search | Board code or model name found and correct |
| 3 | BIOS version | Hex editor or image tool | A plausible version for the board |
| 4 | Region layout | UEFITool | Descriptor and regions match your original |
| 5 | ME version | ME analysis tool | Same version and type as your original |
| 6 | Identity data | Hex editor | Your serial number and MAC, not a donor's |
| 7 | Blank areas | Hex editor | No large unexpected blocks of FF or 00 |
| 8 | Difference from original | Binary compare | Only the parts you meant to change differ |
| 9 | EC image (if any) | Size and source | Correct file for the EC chip, not the BIOS chip |
Each step takes a minute or less once you are used to it.
1. Size
A full image must match the chip capacity exactly: 8,388,608 bytes for an 8 MB chip, 16,777,216 bytes for 16 MB, and so on. If it does not, it is a region, an update package or a file with a header — not something to write directly. Formats are explained in BIOS File Formats: .bin, .rom, .cap and .fd Explained.
2. Board code and model
Search the file in a hex editor for:
- the model name (for example the laptop's marketing name);
- the platform or project codename if you know it;
- the vendor name.
Finding them confirms the image belongs to the right family. Finding a different model name is a reason to stop and check the source.
3. BIOS version
Look for a version string. Most images contain one near the model name. Compare it with the version the board was running, if you know it, and with versions listed on the vendor's site. An image that claims a version that never existed for that model is suspicious.
4. Region layout
Open both your original backup and the new image in UEFITool. On Intel boards:
- both should show a descriptor, an ME region, a BIOS region and, where used, a GbE region;
- the start and size of each region should be the same in both.
Different layouts mean the images were built for different configurations. Do not mix them.
5. ME version
Check the ME firmware version and type in both images with an ME analysis tool. They should match, and the new image should ideally contain a clean ME region if it came from another board. Background in The Intel ME Region Explained for Laptop Repair.
6. Identity data
Search for your board's serial number (from the sticker or your backup) and the MAC address. In a properly prepared image, they are your values. If you find a different serial number, the image still carries a donor's identity — transfer your data in first, as described in Serial Number, UUID and MAC Address in BIOS: How to Preserve Them.
7. Blank areas
Scroll through the image or use the hex editor's statistics. Some empty space (all FF) is normal — unused flash is filled with FF. But an image whose BIOS region is mostly FF, or which ends in megabytes of 00, is incomplete. That is a common result of interrupted reads.
8. Compare with your original
A binary comparison shows exactly where the new image differs from your board's original:
fc /b original.bin new.bin > diff.txt
cmp -l original.bin new.bin | wc -l
On Linux, cmp -l lists every differing byte; the count gives you a sense of scale. Graphical binary diff tools show the differences by region. What you want to see:
- differences in the region you intended to replace (for example the BIOS region);
- no differences in the descriptor, GbE region or identity areas, unless you changed them on purpose.
Unexpected differences in other regions mean the image is not what you think it is.
9. EC images
If the archive contains an EC image, confirm its size matches the EC flash and that it is for the same board code. Never write an EC image to the BIOS chip or the other way round.
Checksums from the source
Some uploaders publish a checksum of their file. If they do, compare it with your download:
certutil -hashfile new.bin SHA256
A mismatch means a damaged or altered download. Most repair files come without checksums, which is why the content checks above matter more.
Example: the check that caught the wrong file
A technician downloads a "working BIOS" for a customer's laptop. The file has the right size and the board code appears in its name.
- Strings: the model name inside the image is a sister model with a discrete GPU; the customer's board is the integrated-graphics version.
- Region layout: the descriptor shows a larger ME region than the original backup.
- ME version: a different type from the one on the customer's board.
Three checks out of nine failed, any one of which would have been reason enough to stop. The technician found another image, this time for the integrated-graphics variant, which passed every check after the customer's identity data was transferred in. Writing the first file would have produced a board that, at best, booted strangely and, at worst, not at all — and the diagnosis afterwards would have been confusing because "the board code was right".
What the checklist cannot tell you
Even a file that passes every check may not boot if:
- the board uses hardware boot verification and the image's BIOS region is modified;
- the image is for a different revision with incompatible hardware changes;
- the EC firmware does not match the BIOS version.
That is why the original backup must always be kept: if the new image fails, you can return to where you started.
A routine worth keeping
Make the checklist part of every BIOS job and write the results in your job notes: "size OK, model string OK, ME 11.8 matches, serial transferred, diff only in BIOS region". It turns flashing from a gamble into a controlled change, and it gives you a record if a customer's machine comes back.
FAQ
Is a file from a trusted collection safe to write without checks?
The collection may be trustworthy; the specific file may still be for another revision, carry another machine's identity data or be incomplete. Check every file.
Can a BIOS file contain malware?
A raw image is data for the chip, not a program for your computer, but a malicious firmware image is theoretically possible. Prefer images from vendor packages or your own board, and be cautious with files of unknown origin.
What if my original backup is unreadable?
Then the checks against the original are not possible. Rely on size, strings, layout and ME version, and enter identity data from the stickers.
Do I need all these tools?
A hex editor, an image viewer such as UEFITool and a checksum command cover almost everything. They are free and quick to learn.
Bottom line
Size, strings, layout, ME version, identity data, blank areas and a diff against the original — run through them before every write. They take minutes, and together with a verified backup of the original chip, they make BIOS work safe and repeatable.