First of all, and before I start describing the matter, I would like to congratulate this community for the amazing work you are doing. I have been reading threads for a couple weeks and it is really incredible the amount of high quality technical information you have posted over time. Simply … WOW.
That being said, I would like to describe a BIOS related problem I am dealing with, and possibly pick your heads on what I can do (if anything can be done).
Dealing with BIOS roms is a new world to me, though dealing with roms in general is not. I work in Data Recovery and I am used to do some microsoldering and firmware edition for hard drives and SSDs (so basically ARM firmware). I have been trying to do the homework by reading the forums but I am in a situation where I think some guidance would be useful, if not necessary.
Essentially, what happened is the laptop went through a BIOS update which was interrupted, resulting on a corrupted BIOS and a bricked device (it’s an Asus UX370UAF-AS laptop).
The first thing I did was to unscrew the bottom case and inspect the board in search of serial flash memory chips, which is the type you can mostly find in HDD PCBs (you can find parallel memories in really old HDDs, and in some other cases, the ROM is embedded in the main controller). The only one I found was a Winbond W25Q64FV WSON 8 legged chip, that I assumed contains the BIOS code (please, correct me if this assumption is wrong).
I unsoldered the chip and read/dumped the content using a programmer device (please, find the backup attached in this link if you want to take a look: https://www.filehosting.org/file/details…BIOS-backup.BIN). Then, I went to Asus’ site and downloaded the vendor’s BIOS image. The first thing I noticed is the files sizes do not match (backed up BIOS is ~8MB while the vendor’s image is ~6.5MB - I am attaching the vendor’s image as well in the following link: https://www.filehosting.org/file/details…UX370UAF-AS.310). I guess the update process moves segments around and possibly uncompresses files and adds paddings, but honestly, I have no idea about how that works (since this is my first BIOS project).
I took some time inspecting and comparing both files in hex, but finally heard of UEFITool and gave it a try (what an amazing tool). I can see a few things:
1) Confirmation that the dumped BIOS code is corrupted in the parser.
2) Overall structure is different in both files (see attached UEFITool-1.png). Backed up BIOS contains regions that cannot be found in the vendor’s ROM image, and paddings and offsets are different.
3) Volumes and files are almost identical (I have checked them 1 by 1: general description information, header and body checksums match), though the “tail part” of the backed up BIOS is different (my guess is the corruption mainly affected this area - see attached UEFITool-2.png). There are a bunch of missing files and a non-uefi region I assume contains the corrupted files.
The questions I have are:
- Is it possible to rebuild the BIOS to a working state with the corrupted backup and the vendor’s BIOS image?
- Should I use the structure (paddings, ordering …) from the backed up BIOS and rebuild the “tail part” extracting the missing files from the vendor’s image (I am planning to do so either with UEFITool or hex copy-pasting, but your advice would be an excellent guide)?
That is pretty much it for now. Thank you very much for your help!
@MarcosD - Asus and Microsoft (mainly) need to stop this Auto-Windows-Update BIOS crap!!! I assume it’s this, correct? If yes, then you’re probably the 5-6th person I’ve helped through this in past month or so, just the past month or two, unsure how many previous to that but I know it started adding up so much last month at BIOS-mods forum that we started discussing and gathering affected users into a single thread to scream about it
Sorry to hear you only find WSON BIOS That is it, if you do not find any SOIC8. Luckily it sounds like you know how to easily handle, remove, replace etc, so great! I cannot check your files, please upload to a free to download host, here is one I use often - http://tinyupload.com/
Once I can look at your backup I can further advise. In general, yes, that is normal about the sizes, often Asus only give a BIOS region download online (and it’s partial, so never program in unless you don’t have a dump from before or other system etc, only as last resort) From your image, looks like maybe only the bottom half of the BIOS is corrupt, so hopefully we can salvage out your NVRAM, board specific details, serial, UUID and LAN MAC ID etc.
Yes, I can rebuild for you, or help you to do it (easier for me to redo). As for how to do, I cannot advise until I can see your BIOS file myself and then check where details are stored, what needs done etc. Basically though, you will copy out your board specific details, and NVRAM volumes if in place and not corrupted, and place these into the stock downloaded region from Asus, then rebuild back into a full BIOS image at your BIOS dump.
Thanks for your prompt reply, and sorry for my late reply. Either option works for me, you rebuilding the BIOS or sending me instructions on how to do it.
If rebuilding is easier for you, just go ahead, but please, send me a link on how to do it so that I can learn and contribute in the future.
With these instructions and your final result, I can reverse what you did.
@MarcosD - Sorry for my delay this time, I’m always getting buried in BIOS As for all the shouting Asus users, I’m not sure where that thread is, buried as I go Next time I run across it I’ll try to remember to come back here and link you up. I tried to tell them to get on facebook, twitter, and Microsoft’s forum and scream about it, you know that’s about the only way to get things done with companies these days (twitter rants and rage gets all the views ) I’m not sure if any of them ended up doing it or not, but it’s been piling up this past month or two, probably only to get worse
Intel is likely partially to blame for this too, but only Microsoft and board manufacturers can stop it, mainly Microsoft as they’re the pusher in these cases. It’s just the kind of thing that shouldn’t be pushed through automatic updates, it’s bad enough when user updates stock BIOS manually and it bricks, no reason for this to be done without a choice to deny the update. This is especially true due to stock BIOS can often brick when user update themselves, so you know adding Windows update and some in-windows invoked process to it only adds to the possible ways it can be messed up.
Before we go any further, what is your chip ID and what software version did you use to make the above dump? It’s incorrect size (larger than chip = impossible), so we need to find version that dumps correctly, that way you know it will write properly too. Some BIOS ID’s need to use other than exact ID, and some need certain software version used. This can be easily fixed manually, in the file, but as explained above it’s the writing back we’re concerned with here, so proper dump needs to be taken so you have best chance of proper writing back to the chip. Ohh! Sorry, I see you mentioned the chip ID. For W25Q64FV you need to use software version 1.30 or 1.34 and ID W25Q64BV, try again with those, here is software package - http://s000.tinyupload.com/index.php?fil…257455007472602
I dumped the WSON chip content with a TL866 programmer device, not using a software package. The dump binary is 8MB (8,192 KB), such as the WSON chip size. Please, see attached datasheet for mentioned WSON8 W25Q64FV chip:
@MarcosD - I knew you used programmer, not software like a BIOS flashing tool, I was referring to the programmer software itself. I just assumed CH341A programmer, not TL866. So, for your TL866, are you using the only/latest software for it? If yes, is that the only software it can use, or can you use any other general programmer software, such as software for CH341A? The dump you provided is larger than the chip, it’s 8,183KB and 800300h. This is 968bytes/300h bytes longer than chip can possibly contain, that is why I thought there may be an issue when you try to write back too. I can fix this manually on my end, but again, as I mentioned, it may try to write that length too since it dumped that length. I guess we’ll have to see what happens, it may be fine, but if it fails to boot then we know the issue may lie there.
I’ll remove this extra and carry on, hopefully it will write properly! I’ve seen this before, it may be common issue with your programmer and some chips, I don’t remember what programmers I’ve seen it with but I’ve seen it several times Working on BIOS now. I see the main issue here, aside from this BIOS being corrupted during the process (end cut, stopped mid flash or something etc). The stock 310 BIOS is broken, watch for it to be removed from Asus site, or silently replaced with different version, as soon as someone lets them know.
@MarcosD - Ahh, sorry! Bootguard enabled system, nothing we can do to edit and fix anything then usually, unless you replace PCH (South bridge chip) with a PCH that does not have burned in key for bootguard. You’re only option is to program back the original dump you sent me, and then do nothing except look at paperweight , since you do not have a working dump from before.
Unless, one more edit will make it OK, but I doubt it, usually when bootguard is enabled you can’t edit any single byte, let alone editing every single volume like I’ve done here. I didn’t swap the first volume of your dump which contains main BIOS volume, since it looked corrupted in stock 310, however, you can try with that back in there, but I doubt it will boot as I’m 99% sure it’s corrupted in the stock 310. But that’s an edit too, no matter what is done here it’s going to be an “Edit/change” to bootguard, so anything we try to do will fail.
First Test BIOS with only FD changes, I unlocked your FD for easier flashing later, not knowing bootguard was enabled here. So that may be what’s setting it off now, but I doubt, lots was edited across the entire image, every single volume was edited
First test FixedM2FD - this is BIOS I sent you before, but with FD back locked how it was in stock package Then test FixedM3 - this is all edits same as above, except put back in your original main BIOS volume - I assume will fail to, but this may be only one that is OK (but please do test all, so we know) FixedM4 - this I assume will fail to boot, this has the main BIOS volume from stock 310 which I believe is corrupted (From Asus!) http://s000.tinyupload.com/index.php?fil…906065394130674
Intel SUCKS for creating this Bootguard crap and not allowing end user to disable if they way. Not that it would help here, since you probably wouldn’t have disabled before all this, but you get the rant I’m sure
Next time I run across it I’ll try to remember to come back here and link you up.