My ASUS N56VZ's BIOS recently got corrupted because of changing a boot order. I saved changes and did a reboot. The computer did power on but the screen was pitch black. Plugged in HDMI, nothing. Tried restoring BIOS via the "Ctrl + Home" with a 1GB thumbdrive formatted with FAT and multiple renames of the latest BIOS inside the drive, nothing.

I bought a CH341A (MiniProgrammer) / (Black edition) and backed up the original contents of the BIOS chip (Ver. 217). The marking on the chip is "W25Q64FV". I proceeded to restore the BIOS with a new firmware by following this guide "[GUIDE] N56VZ bios replacement with CH341A ISP programmer" on My Digital Life forums.

Summary:

Zitat

---

1. Backup (Read) your error bios from the eeprom chip.
2. Download bios 217 from asus webpage, using hxd delete address 000-7FF.
3. Using HxD (or any hex editor), copy 0x00000000-0x00200000 from that backup of error bios to header of 217.
4. Save your patched bios, your file size should exactly be 8MB (8,388,608 bytes)
5. Flash it back to the eeprom and let's the magic work.

---

The computer did finally boot but the keyboard light that was supposed to light up during POST does not light up. Serial number, MAC Address, UUID was also gone.

Windows CMD output:

Zitat

---

C:\windows\system32>wmic nic get macaddress
MACAddress
00:11:22:33:44:55

C:\windows\system32>wmic csproduct get uuid
UUID
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

C:\windows\system32>wmic baseboard get serialnumber
SerialNumber
BSN12345678901234567

---

I've attached the original BIOS dump (after the BIOS became corrupt) below
I never had the original BIOS dump before the BIOS became corrupt as I was not aware of simple actions such as changing the boot order can even render the BIOS firmware corrupt.

Good work to make a backup of the non- working chip content!

Look into your backup with UEFIToolNE- machine specifi data are in second padding of bios region - 0x230000 to 0x280000. If I remember right most ASUS notebooks of this age didn't use GbE for MAC, so it might be OK that there's the standard value.

The region mentioned in your guide would be the firmware regions missing (FD/ME) in the ASUS stock bios which contains only the bios region , bios being stock bios without any specific data and empty NVRAM- the latter normally getting filled automatically.

Your dumped bios region is identical to latest stock in static volumes, so error has to be in NVRAM which would be consistent with your story.

You might transfer the second padding to the bios you flashed and flash it again by programmer, or try to flash the bios region with fpt (Intel ME 8 tools), if not protected, or just the corresponding section of the bios.

So what I understand from your post is that basically the firmware region of the backed up BIOS is fine (except for the NVRAM region which stores the BIOS settings, if I'm not mistaken) and I can copy the required details, Serial number and UUID or copy the entire second padding from the backed up BIOS and copy it over to the new firmware. I'll try it out and report back here.

That's correct.

Intel ME 8 tools can be found in this thread Intel (Converged Security) Management Engine: Drivers, Firmware and Tools

Options:
1.) Work on the firmware you created
2.) Dump your working firmware with fpt "fpt(w(64)) -d spi.bin" and work on it
3.) Dump your working bios region with fpt "fpt(w(64)) -bios -d biosreg.bin" and work on it
4.) Try to overwrite just the padding with fpt

Extract the padding 'as is' with UEFItoolNE from your backed up firmware

For 1.) to 3.) Open firmware or bios region in UEFItool025, 'replace as is' the padding with the padding you extracted from your backed up firmware

- flash back the complete firmware with programmer, or
- flash back the complete firmware with fpt: "fpt(w(64)) -f spifixed.bin", or
- flash back the bios region with fpt: "fpt(w(64)) -bios -f biosregfixed.bin" or

For 4.)
- try to rewrite just the padding with fpt: "fpt(w(64)) -f padding.bin -A 0x230000 -L 0x50000"
Check syntax first by dumping the padding/ maybe some more bytes to be sure you get the area right: "fpt(w(64)) -d check.bin -A 0x230000 -L 0x50000" dumps 50000 from 280000, "fpt(w(64)) -f padding.bin -A 0x230000 -L 0x50000" writes 50000 from 280000

Working on a fresh dump would back up your settings in NVRAM when working on bios region or complete spi. Filenames were just examples.

There might be locks on ME (locked in ME) or bios region (protected memory regions) which will keep you from flashing with fpt, but I think there's a good chance for 4.) to work. But you have to read first, maybe read some bytes before and after that padding region, too, so that you can be sure that the addresses are right. Anyway- you have a working backup which you can flash back with programmer if software flash fails...

Thanks for the extensive and detailed reply. I can confirm that your method 100% works!

I've copied the 2nd padding of the BIOS region over to a fresh new BIOS (erase the capsule of the latest BIOS from ASUS and copy paste the first 2MB of the backup BIOS over to the new BIOS). The Serial number, MAC Address, Keyboard lights and UUID is back. I noticed that the last portion of the UUID contains the MAC address of the GbE. The ethernet controller is a Qualcomm Atheros AR8161 Gigabit Ethernet Controller, which seems quite advanced for a laptop that is made back in 2012. I've also edited the GbE region to include the MAC address of the ethernet.

I opened up the back cover of the laptop and connected the CH341A programmer to the BIOS chip and flashed it with the reworked firmware. Everything works in 1 try!

Good to hear that it worked For my Samsungs the bios chip is located under the board, so it means disassembling the complete machine, but if the spi chip is easily accessible the programmer is as easy as software flash...

The BIOS chip is actually sandwiched between the keyboard top case and the motherboard. Disassembling the whole laptop just to get to the BIOS chip and the CMOS is really a pain. I've dissembled the whole computer about 6-7 times now and it got to the point where multiple screw hole got stripped and I had to 2 part epoxy glue them. Since fixing this laptop is absolutely necessary, I had no choice but to disassemble the whole laptop.

Well, I guess both of our laptops are just the same.

In this case I would have tried software, you got a valid backup and a programmer at hand, so even if it doesn't work/ bricks again you would have a way to recover.....

Anyway, it works now, so hopefully this will never happen again. But take care of your last firmware with board specific information, just in case...