Help with UEFI on Surface Pro

where do i find the system info, sku, etc on a bios dump.

@eknsibby - Can be in lots of places, padding files, SMBIOS modules, other SMxxx Modules, DMI modules, FID Modules

Hey so I recently had my surface pro bricked from a failed bios update. I got a new chip and found a good bios and flashed it. My only issue is than when I do a firmware update or any Microsoft surface updates I get a “this is not a surface pro 4” and when I run msinfo32, under Manufacturer and mode I see OEMAP. I am thinking this is the reason why I can’t do the updates. Any help will be appreciated. Also is there a way to reflash the bios chip after it has already been installed and the surface pro already put back together?

@Lost_N_BIOS Hey, thanks for reply. I found the info, just not sure how I would write it to the bios/uefi without having to take the surface pro apart.

Do you have your backup BIOS from the other chip? If yes, upload it and send link I will check.

Reflash can maybe be done via FPT, did you unlock the FD when you first put back in the recovery with programmer? Do you have programmer, or did you just order new programmed chip?

Check BIOS main page, or with HWInfo64 in large window, on left in motherboard section, do you see ME? If yes, what is ME Firmware version?

@eknsibby - I’m going to combine your two threads, since it all covers same topic

Here is a link to original dump. . Not sure if FD was unlocked. I sent the original to someone and they did everything. I have a CH341A Mini Programmer. Here is the links to HWInfo64.

Thanks @eknsibby - give me some time and I will dig through your dump and try to find/extract all your original info. That dump is of the BIOS before it was fixed to current version correct?
You have ME V11, please download Intel ME System Tools package from section C in this thread - Intel Management Engine: Drivers, Firmware & System Tools
Inside you will find Flash programming Tool folder and then inside that find a Windows or Win32 folder. Select that Win32 folder, hold shift and press right click, then type the following commands and then zip up any and all files created (There may be errors on some, it’s OK, onto the next)

FPTw.exe -d bios.bin
FPTw.exe -bios -d biosreg.bin
FPTw.exe -desc -d fd.bin
FPTw.exe -gbe -d gbe.bin

Yes the dump was the original untouched.
Here is a link to files asked for.

So you got errors with both commands below? If yes, it’s OK/normal, aksing to be sure
FPTw.exe -d bios.bin (No read/write access to ME region so expected error or partial dump without ME here)
FPTw.exe -gbe -d gbe.bin (no GbE region, so OK Error)

Thanks, I will get on this shortly!

@eknsibby - Wow, they signed everywhere in that BIOS, 20+ or more modules signed with OEMAP signed certificate, that’s crap. It’s not what you’re seeing and needing changed though, but it make this more difficult and rude of them to do even though they fixed your system for you (It’s spam overload)
Is your LAN MAC ID correct now, I haven’t check into that yet, but since no GbE region I assume it’s within the BIOS and probably wrong now. Do you have working onboard LAN/Ethernet?

Yea I got errors with both commands.

@Lost_N_BIOS - yes indeed OEMAP on everything. Shows no serial number, no model number, no manufacturer. Etc. When I first booted it up I was having issues with WIFI. But after a few reboots it started working. And I havent checked the LAN MAC but I’m pretty sure its wrong. Do you think they are stealing my info from me using the spam. Also did you want me to send you the “fixed” bios file that I flashed to chip?

@eknsibby - Ohh, I think I misread, or forgot, what you said initially. I thought you sent this off to be fixed, and that was how the OEMAP got everywhere.
That never happened, and you simply purchased a new BIOS chip and reprogrammed it correct? If yes, where did you get this “Fixed” BIOS you mentioned to program back onto the chip?
That is the issue/source of the OEMAP, this “Fixed” BIOS. So, no, I don’t need that, and you already send me a copy via the above biosreg.bin file (BIOS region), that’s how I see all the OEMAP (present in literally 20-30+ modules and 6-10x in each)
Is this a 16MB file, or some EXE? The few “Stock” BIOS I’ve looked at this where all huge 100-200+ MB EXE’s, that are of course tons of other files not just the BIOS. Last time I tried to find for someone, Microsoft did not offer a “BIOS only” download

I don’t know what is possible with how they’ve done all this in the BIOS, but I doubt a backdoor is made they’re stealing info with, however you never know.
I mainly meant that I was surprised to see this, and felt it was spam for their company, no reason to do (Signing) etc on any of the files and no reason to put in OEM/DMI area either.
However, if you grabbed this BIOS as a “Working” Dump from somewhere and used that it may be normal, and this might just be how that company sets up their systems and has all their Surface tablets programmed like that.

Yes, please check and see if LAN MAC is working, I doubt it is. Do you think you can find your original MAC ID from your router logs? If not, maybe I can find in your original dump, but it would be easier to find and put back if you knew the ID and could give me.
Is your windows activated properly still?

I can fix all this for you from your original dump, but due to that BIOS being the cause of your device bricking it wont may not be safe to swap out all the modules with OEMAP in them, but I will be able to safely put all the system details and serial/Asset tag ID’s back stuff like that.
If I were to change out all the modules that are signed OEMAP it may be putting back the source of your bricked state initially, so it’s not ideal but we could try that if you wanted, if it’s a brick after that then it would take 20-30 different BIOS build tests removing a module one at a time until you found one that didn’t brick.
So you can see how that doesn’t sound ideal I’m sure.

It all started with forgetting my password for the UEFI. I use this for personal and work and in order to use with company files and stuff I had to put in more security. Well they decided to buy all employees that used them brand new pro 5 because of security issues with some employees. So I didnt use my pro 4 for like a year or so and I decided to reinstall windows and then I couldn’t because of the uefi password. So I found someone to help me with the password issue and I sent him the original dump and he said he removed the password.
I do see a physical address for the LAN Adapter.

Thanks for the info @eknsibby - so that person did all this to the BIOS then, which was absolutely not necessary to remove a password. I guess since you last used this a year or more ago, you wont be able to find the original MAC in your router logs.
On the LAN, can you use it though, it’s working? Please test, and then send me that MAC so I can see if it’s same one as your original. IF it’s not, then that person changed with bad intentions, or simply sent you back some random dump they found with no password (more likely).
I see model, manufacturer, products, SKU, family, version, serial, ID’s etc all changed, so I bet he didn’t try to remove your password at all, simply sent you a known working dump they had on hand. Unless they were up to something nefarious?

I see your wifi MAC address in the original dump, but not in the OEMAP dumped BIOS (No entry at all for this in NVRAM)

Are you referring to the Local Area Connection as the ethernet port? If so I dont have one on the surface pro. But there is a adapter that has to be purchased to convert to ethernet which I dont have to test. I might have a USB to ethernet adapter but iI would have to find it. There is a Wireless LAN adapter Local Area Connection *1 and the address is BE:83:85:23:AB-52.
I can see if I have any dumps from my router from a year ago. Not sure I will though.

OK, then we don’t need to worry about LAN MAC ID. I meant Ethernet port, that you’d plug a cat5 cable into. If adapter is used, then we don’t need to worry about that.
Your original dump’s Wifi MAC address = BC:83:85:23:AA:53 - so this is even changed, I think he just handed you a random known working dump instead of using the file you sent and removing the password. That ID you gave is not in the BIOS either, anywhere (but no wifi module MAC entry anyway so not there for sure)
Or maybe that is not the root port connection. Run this command and show me image >> Ipconfig /all

I’ll get this all sorted out with the original system ID details shortly, then you can try BIOS update again with fingers crossed Do you plan to try the same update that killed it, or are you now going to try another different BIOS update exe?

Here is the link to the ipconfig.
And no I wont be flashing the bus the corrupted it.

Thanks, now I see the one I found in your original BIOS dump. See it, there in the middle under Main Wireless LAN Wifi - BC:83:85:23:AA:53 This is good, it means even without wifi entry in your NVRAM in BIOS, this MAC is used, must also be stored in the actual wifi adapter module itself too.
They usually are like that, but since I see that entry for wifi in your original BIOS dump I assumed maybe it also needed to be there, but since we can see it and it’s working all is fine without a BIOS entry

So, I will now make changes to two SMBIOS modules, and change all the NVRAM entries back to their original values for family, SKU, brand, type etc.

BUS Corrupted flashing? What’s that mean? You should be able to flash an update after we fix all these details. I assumed you’d flash in the corrected BIOS, and then try a new BIOS update (not one that originally bricked it)

Oh ok that’s good. Thanks a lot for your help. I have been trying to learn little by little but its complicated. So much information.

I meant I would not be doing the update that bricked it.

You’re welcome! Yes, some of this can be complicated if you are not used to doing it all the time.

Big surprise! I go to change out your SMBIOS (This usually where all boards keep a main DMI (system ID stuff) details entry copy) And I see OEMAP in your original backup! But I see it’s “generic” info like 123123, 456456, 789789. And this module is identical to the one in the current problem BOS


So maybe Microsoft sometimes uses this OEMAP in some way, but the way your other messed up BIOS is signed OEMAP and has actual numerical details like a real serial number instead of 123456 etc means that other BIOS must have been setup/used on something before.
I will leave this module as it is for now, most data/ID will be pulled from NVRAM which is not saturated with OEMAP everywhere in your original BIOS dump

I think you can either re-try that update, since you can recover, it could have been a random glitch that caused it, or find a newer version if possible. Were you sure you had the correct update?

Oh ok so Microsoft uses The OEMAP in some way.
I highlighted in this screenshot what I was able to find.