@ibsajc - Sorry, no, I didn’t check that file, I asked you what it was and you didn’t comment so I wasn’t sure.
From your images, looks like you missed MAC ID #2 in GbE area (that would be 2000h on straight hex file, or 1000h on extracted GbE region) - But stock BIOS does not contain GbE like a dumped, you need to extract his GbE, edit MAC ID x2, and swap into your target file
Now, checking file… >>
Confirmed GbE comments above, you need to swap in that entire region, then replace your MAC ID x2 (I only see Davidm71’s MAC ID there x1, and rest of GbE missing).
Extract GbE region from Davidm71’s BIOS using UEFITool 25.0, in hex editor at 0h put your MAC ID, and then at 1000h put your MAC ID again, then save and replace this GbE region into your mod BIOS
Then, on the entire file as a whole in hex, at 0x2D4000h, you need to fix this entire block with your serial, UUID, and MAC ID. And at 0x2F0FE0h same needs done.
So basically, I think you uploaded the wrong file for me to check, or you never saved your intended changes maybe? This file from end of post #554 (new.bin) system info-wise is untouched Davidm71’s info
Ohhh! I see what you did, you replaced blank areas in stock BIOS, with Davidm71’s info and not your own as test edit, correct? If yes, all look like it’s done properly, but you just need to do it with your Serial/UUID/MAC.
And you need to to the GbE extract edit I mentioned - extract, edit, replace, instead of editing the stock GbE
In post #558 I clearly specified what the new.bin file represents. I asked you to check it because it’s the first time I’ve done this and I did it on my own.
[quote="Lost_N_BIOS, post:561, topic:30834"] If yes, all look like it's done properly, but you just need to do it with your Serial/UUID/MAC. [/quote]
This is what I intend to do. HxD offers the possibility of "Search for" and "Replace with" and I think that I am able to do it myself.
[quote="Lost_N_BIOS, post:561, topic:30834"] Confirmed GbE comments above, you need to swap in that entire region, then replace your MAC ID x2 (I only see Davidm71's MAC ID there x1, and rest of GbE missing). [/quote]
Right, here I will make the correction.
The MAC address issue for the second network card remained unresolved, didn't it?
Yeah, sorry, I missed that, due to when I went to check now, I didn’t look at 558 only what you mentioned at the post where BIOS link was.
You can do this much easier with UEFITool 25.0, if you want me to show you image of what/how to extract for edit and then you replace same way, let me know.
MAC Address, unknown about 2nd port, he does not have that board anymore, nor a Ethernet/MAC issue / we assume there was not LAN issue when he dumped it.
And, it’s normal for same MAC ID to be in GbE region twice, actual board dumped BIOS has double GbE region often, stock BIOS does not as it’s meant to be a partial in-place update to current in-bios contents.
Do as I mentioned, extract GbE region from his BIOS, edit the MAC ID at 0h and 1000h with your main first MAC ID only, then replace back into file. Later you can test putting second MAC ID at second location, but I’ve never seen that be how these MAC ID’s are stored with dual Ethernet boards.
2nd MAC ID is probably stored in the chip FW
Thank you. I downloaded UEFITool_0.28.0_win32 and I see that the "Replace as is …" option is activated. When you know exactly what you need to replace and where it’s OK as you suggest, but I’m learning now.
Yes, I also read somewhere that the second MAC address is stored in the FW chip.
Thanks for all the help. It seems that I still enjoy learning new things besides managing networks and servers (Windows & Linux).
I am also fascinated by the work of @plutomaniac , I am particularly interested in the Intel CSME part.
The most important lesson learned now is that the first thing after removing an SPI chip is to perform a backup (dump)!
@ibsajc - Please use 25.0 as mentioned, newer can cause issues on BIOS rebuild. Probably not in this case due to where you are editing, but I did not check if that second volume with FD44 module has any problems when using 28 or not.
The padding and GbE module should not be an issue, but that FD44 module inside volume may be, so best to stick with 25.0 until you know how to check to be sure it’s OK. Best practices, you know, until you know how to check post-edit vs pre-edit for issues. 
For doing the actual edit with UEFITool, you need to extract only #1 from davidm71’s BIOS, the other two # below, you edit the stock one to match davidm71’s for that entire small block area in each instance, except with your data at the specific info locations
1. Extract davidm71’s GbE As-Is and then edit, then replace As-Is to your target stock BIOS.
2. From the stock target BIOS, Main padding between volumes in BIOS region, extract As-Is and replace As-Is
3. From the stock target BIOS, FD44 module (aka SMBIOSFlashData / FD44820B-F1AB-41C0-AE4E-0C55556EB9BD) expand to RAW area, select that, extract body, edit, replace body.
Main thing to keep in mind, always replace the same way you extracted. If any header checksums of modules you edit need corrected UEFITool will do that on rebuild
Yes, plutomaniac is a ME FW genius!! 
And yes, always make backup, and then have someone check it to be sure it’s OK and valid if you don’t know for sure how to check, before you do any erase or writes
@Lost_N_BIOS when you have time can you make me a BIOS according to your method starting from the original ASUS (3204 from post #547) but with SN, UUID and the MAC address from davidm71’s dump. I would like to compare it with what I did and maybe I will learn something more.
Here I have problems with the BIOS region, new2.rom is the BIOS file modified by me and dump.bin is that of davidm71 (see the attached image).
For points 1. and 3. I managed to make the replacement successfully.
Anyway I don’t know very well how to mod a BIOS yet!
@ibsajc - Sorry, I forgot to mention, on stock BIOS that first padding is placeholder for backup NVRAM volume which is not in stock BIOS. You’ll be extracting and editing the second padding, you can tell which is correct based on size
Don’t swap this padding from one BIOS version to another, there is vBIOS copy in there that may differ between BIOS versions, so always extract from target, edit the sys info part, then replace back in. Just FYI
Here is 3204 BIOS test edited as you requested, but why use old BIOS version??? You should use 3602
http://s000.tinyupload.com/index.php?fil…174209096595275
Intuitively, I did that too, although I didn’t understand why!
With my method of editing directly in the .bin file, it seemed to me that the two BIOS files were a bit different. With your method "always extract from target, edit the sys info part, then replace back in" it can be done from different versions. I think I understand your method and why you do it, but that shows the difference between what you know and what I know now - the difference between an expert and a novice.
@ibsajc - Only the padding one you have to extract, edit, put back, into same version, but yes, you can make the sys info edits same across any version, just be sure you extract and edit in that info block and then replace
GBE and the FD44 module you can swap in from other versions, provided FD44 module is same size in each (I didn’t check), but it’s not best practice to get yourself used to editing like that (neither is straight on hex edit of entire file)
Best to not edit this as a direct .bin file, due to the FD44 module being inside a volume, that module header checksum would be changed, and that volume checksum would need changes, and that wouldn’t happen in a straight hex edit
Now I put together everything I learned from you (some things you recommended from the beginning but I was not able to understand them at that time) after rereading a few times everything you posted and I managed to transfer SN, UUID and MAC address in the original BIOS 3602 version from ASUS as it should be done.
I haven’t been so excited for about 20 years since I first came in contact with the Linux operating system.
I would have one more step to learn, how to check if what I did is OK. Do you have any advice for that too? Why should I consider and what tools to use for verification?
@ibsajc - Great to hear you’ve got it all sorted out now!
I use UEFITool 51 NE, side by side with stock BIOS (extracted from Capsule in Asus Case) vs mod BIOS. and then check ALL volumes which you touched (in this case =1) and make sure all match inside module-wise, no added or removed padding or other modules
Also make sure “Parser” tab at bottom matches, and “FIT” tab When doing other edits, also always check any sub-volume you touch just like I mentioned above. Plus always double click on FIT first entry and it will take you to FIT location in file, make sure padding above/below it always same before and after
Then search GUID >> 17088572-377F-44EF-8F4E-B09FFF46A070 << This = microcode volume/s, some BIOS have 1, some have 3-5, when several usually one is empty. Anyway, compare all these locations side by side, make sure padding is above, in before, after, or not, side by side - should always match.
Other than that, I’d have to explain specific issues, things to check on case by case basis per some specific edit. The above is my general, always check all this, before/after for all mod BIOS.
Anytime you see “Parser” differences, or an added or removed padding, or non-UEFI/Pad file, that can = bricked BIOS, sometimes, but not always, and only way to know is test flash, so not ideal unless you have programmer.
So, in such cases you find issue, work around, use other tool, other method, make sure it does not happen
Also, any time you see FIT blank at mod BIOS side, or partially blank, vs stock (Which should not be blank, but sometimes manufacturer 
), that should be fixed as well
Here in-depth guide to fix, I need to update, there is easy way now
Been reading these forums for the past couple of weeks so I can try and fix my MSI Mortar b350. There has been some really useful information, so thanks!
I’ve managed to get a programmer (CH341A + 1.8v adaptor) and flash a file using flashrom which completes and verifys i’ve successfully flashed something but my computer still doesn’t post.
The chip is MX25U12873F but identifys as MX25U12835F in flashrom and CH341A.
I want to double check the image i’m trying to flash is correct. I tried downloading the latest non beta bios from https://www.msi.com/Motherboard/support/B350M-MORTAR, extracting the bios file and flashing that. I then thought perhaps this file was just an update rather than the full bios so I tried v1 which still doesn’t post either.
Is anyone able to confirm that these are the right images or perhaps provide me with one?
Alternatively do you have any ideas why the computer turns on but just has a locked CPU led and doesn’t post. The GPU briefly spins up but then stops.
@Lost_N_BIOS
Regarding #571 thanks again for your advice.
For now, I think I will stop with the BIOS mod to have time to deepen what I know.
Updating the microcode version in BIOS from what I read in your link is a bit more complicated and my working principle is to choose the safest and easiest way.
There are other solutions related to updating the processor microcode (I am now speaking as a network administrator):
1. in Windows there are already installation packages (.msu) for Intel microcode updates depending on the type of processor (CPU ID) here. They can be downloaded here.
2. Linux has a specific microcode update mechanism at system initialization (initrd-early loading) extremely easy to use.
https://www.kernel.org/doc/html/latest/x86/microcode.html
For both operating systems this solution does not involve any risk, both can be brought to the initial state, by uninstalling the update in Windows or removing it from the initrd in the case of Linux.
@bib - For MX25U12873F use one in folder of package below named >> CH341A v1.31(1.4) (CH341AFree), be sure to choose correct chip type (25) and size before you start doing anything.
http://s000.tinyupload.com/index.php?fil…213094641136166
** And, see also, this post about version/method, see end of post #126, (DO do the erase, he already did is why he skipped) - https://www.badcaps.net/forum/showpost.p…5&postcount=126
Send me your original dump of BIOS chip from BEFORE you did anything, so I can compare to the stock BIOS and see if those are partial or full BIOS files.
The downloaded BIOS from MSI looks complete, but I don’t look at AMD as often as Intel, so I can’t be 100% sure without seeing dump from your board first.
@ibsajc - You’re welcome! The more you play, the more you learn Yes, updating microcode can be tricky sometimes, several ways to do it, but the guide I linked was more about fixing FIT after that.
Other times it’s simple, use MMTools and confirm FIT OK, then confirm all rest OK and you’re done. All depends on the BIOS.
No one wants windows controlling microcodes, plus Win10 already does it automatically if you don’t use a newer one than theirs in BIOS, or disable them from being able to do it.
Linux, yes, you can do similar, if you want.
@Lost_N_BIOS https://filebin.net/8mnop6k6mw6vneqi/backup.bin?t=m0ztlskg
Chances are this file is broken in some way as it was taken when I think my clipper cables were too long as I couldn’t get a clear write. Since shorterning the cable i’ve been able to get verifys. I just ran a flash using CH341A 1.31 free and it wrote but failed to verify. Booting gave me no beeps and just the CPU led showing with no post.
I’ll try another flash.
Flashed and verified but still doesn’t post or beep
@bib - Do you have power cables connected, or not? If yes, remove them, if not, try with them connected. Some boards need one way or the other, sounds like you may be running into this issue because 1.31Free has been confirmed working for this BIOS
To confirm your write is actually OK do this >> Select correct chip type (25) then correct size, always do that first.
Then >> Erase chip, blank check, then open BIOS file, write, verify, then close the program. Open, pick correct size/type, read, verify, save and compare that saved file with what you wrote in hex editor, if 100% match then write is OK
Flashrom also works, here is Linux/Ubuntu method/guide - [GUIDE] The Beginners Guide to Using a CH341A SPI Programmer/Flasher (With Pictures!)
And here is Windows version someone made (post 510) - [Guide] Using CH341A-based programmer to flash SPI EEPROM (34)
Yes, your dump is corrupted, from bad dump method (wrong software, version, setup for the board/BIOS as mentioned above re power), not from bad BIOS flash
BIOS download does look like a complete BIOS though, I just hoped to double check to confirm with your dump, but that’s not an option now.
I’m 99.999% sure it’s bootable 100% complete BIOS on their site, pretty much confirmed by others recovering similar MSI B350’s in google via programmer using stock BIOS
Thanks, i’ll specifically try the power cable approach later today and do a dif of the rom to the dump.
I have tried cable in and outs before but only when using flashrom in Lubuntu, so i’ll try it again with CH341A in Windows.
I’ve probably flashed the chip 20 times now between flashrom and CH341a, so i’m fairly comfortable with the flashing process.
The original dump was taken with flashrom, which detects the chip. I’m fairly sure the issue was cable length, as I kept getting errors when verifying and once I shortened the cable this stopped happening.
------------------------------------
Interesting. So CH341a verified my write with the file I was flashing but doing a diff there are empty blocks, missing parts from the original.
I tried that just now with nothing connected to the computer for power.
Previously I did have an issue where cable length seemed to effect writing but since shortening the cable, verifies started work
------------------------------
Re-reading and saving gives me a different dump, that had far fewer differences… So I can’t be sure that it’s actually reading it correctly.
Interestingly starting the computer gives me behaviour from when I tried to do the first flash.
Computer turns on briefly, CPU led comes on and then CPU fan slows down and then seeds up with led going on and off.
Taking all sticks of ram out makes it beep.
So perhaps the flashed has worked now and something else is bust.
@bib - see my edit at 574 - And please use edit instead of making multiple posts in a row - thanks
Detecting the chip, and looking like OK operation does not mean anything, if not compatible, read or write can verify but still be corrupted << As you just notice happen
When you do dump to compare like this, make sure you close the app, then re-open, and DO NOT try to power on system between write and this read/verify/save to dump and compare.
Yes, it’s possible something else is bad, but I would try again until you can get a write, then a manual dump/compare to work 100% properly, then you will be 100% sure the BIOS write was OK.
See my edit above about 1.18 (and note what I mentioned, always do erase then blank check, he didn’t erase before blank because he did it previously)
Thanks. I’ve now tried another motherboard and it behaves in the same way with CPU led on and computer not posting and restarting. Think the CPU might be broken so I’m starting a warranty request. Thanks for your help.
@bib - Sorry to hear CPU may be dead! But, maybe that is good, you will get new CPU and board will be OK once programmed again.
The new board, was it’s BIOS up to date, and should be OK with the CPU you tested? If yes, then as you mentioned, probably bad CPU 