[AMI Aptio] How do I safely verify if my mod has been flashed?

[0x0]

Hello, I'm currently trying to mod the UEFI/BIOS of a notebook to enable hidden features such as Intel vt-d and I'm having trouble to tell if my modified ROM was actually flashed or if the mod was actually applied correctly to the ROM file in the first place.

Now I'm wondering if there is a safe of to verify these things. (I was thinking about something like changing the version number that is displayed in the UEFI/BIOS setup.)

Here is all the information on what I used/did:

Notebook: Gigabyte P35X v4
OS: Windows 10 (x64)
BIOS/UEFI info:

• AMI APTIO 2.17.1249. Copyright © 2018 American Megatrends, Inc.
  
• Project Name: P35V4
  
• BIOS FW Version: FD0C
  
• Build Date and Time: 07/31/2018 12:30:16
  
• EC FW Version: F01A
  
• ME FW Version 9.1.30.1008
  
• Access Level: Administrator
  

Modding tool: AMIBCP v5.0.1 (x64)
Tool to extract the ROM from the self-extracting archive: 7-Zip

What I did:

• I downloaded the latest "BIOS" (Version: FB0C FD0C - 2018/08/03) from the official download page
   
  
• I flashed it by simply running the downloaded exe (a self-extracting archive) and clicking OK.
   
  
• After a reboot, I manually extracted the self-extracting archive that I just ran, using 7-Zip.
   
  
• I found two ROM files (P35V4BF.B0C and P35V4BF.D0C) in this folder: \extracted_files\BIOS\BIOS.BIN\ each 8.192 KB in size.
   
  
• I started AMIBCP and opened the first ROM and in the "Setup Configuration" tab navigated to \\Setup\Advanced\ and changed the "Access/Use" of the Control Group Structure "Hidden Function" from Default to USER. Then I simply saved it, overwriting the the original ROM file.
   
  
• Then I did the same with the second ROM file.
   
  
• And finally I launched a powershell in \extracted_files\ and ran .\SmartFlash.exe
   
  
• I got the same prompt that I got for flashing the official ROM and accepted by clicking OK. The upload progress etc looked fine, I got no errors.
   
  
• After a reboot I checked the UEFI/BIOS setup and it looked exactly the same. No new functions no new Build version or date.
   
  
• I booted into Windows again and opened the two ROM files with AMIBCP again and my changes still appeared to be there.
   
  
• I also tried flashing the ROMs by copying them into \extracted_files\BIOS\AUFUEFI\WIN64\ opening a powershell in the directory and running .\afuwinx64.exe .\P35V4BF.B0C and .\afuwinx64.exe .\P35V4BF.D0C but again no errors and the UEFI/BIOS setup looked the same.
  

So it seems to me like the ROM has been modified, but maybe wasn't actually flashed OR maybe changing the "Hidden Function" from "Default" to "USER" doesn't actually enable these features as other people have said it would.

Any help would be greatly appreciated.

Edit: It indeed didn't get flashed. There seems to be some sort of security check. I guess you can only flash ROMs that are signed. Well, I figured out how to bypass that with afuwinx64.exe, but ended up bricking the notebook for now. I assume this is because there are two ROM files... maybe they have to be flashed to different memory regions? I don't know. I hope I can figure out how to flash the ROMs using an SPI programmer.

[Lost_N_BIOS]

It was possibly flashed, but the changes you made may not be what you think, or don't work that way for this BIOS etc.
.BOC BIOS is for non-RAID setup board (Launched by P.Bat)
.DOC BIOS is for RAID enabled board (Launched by RAID.Bat)

Gigabyte rarely if ever implements security check or signatures etc. Nothing in the BIOS or flashing tools appears to look for a security check or signature etc. Probably incorrect AFU used, or incorrect options used with AFU, or could be incorrect AMIBCP edit done, hard to know for sure, but yes, you will be able to recover with a flash programmer and SOIC8 test clip cable.

Don't write anything to either chip before you get a verified and validated dump from each, checked by opening in BIOS tools and making sure it looks like a BIOS and is not simply FF or 00. Programmer software can verify an invalid BIOS dump, so you have to check to be 100% sure you have a good backup made before you write anything, this way you can try to save your board specific details and put back in new BIOS before you program (Serial, UUID, LAN MAC ID etc)
Here's a guide on getting setup and using - https://www.bios-mods.com/forum/Thread-G...programmer

As for your actual edit, "Hidden Function" is enabled by default, so the only change you need to make, if any, would be to disable that if you want it disabled. Setting user visibility would only let you see the option setting, which is enabled by default. I checked setup module, AMITSE/SetupData, and both NVRAM entries for this and it's enabled at every location, so you already have whatever you thought it was going to give you. The only other thing you can do with this is disable it, and yes you can make it visible if you want to see the option enabled in the BIOS on Advanced page, but you should use AMIBCP 5.02.0023 or 5.02.0031, the 5.01 is much older than these and could be the cause of the brick (if not the AFU Flashing method)

[0x0]

It was possibly flashed, but the changes you made may not be what you think, or don't work that way for this BIOS etc.
.BOC BIOS is for non-RAID setup board (Launched by P.Bat)
.DOC BIOS is for RAID enabled board (Launched by RAID.Bat)

Gigabyte rarely if ever implements security check or signatures etc.   Nothing in the BIOS or flashing tools appears to look for a security check or signature etc.  Probably incorrect AFU used, or incorrect options used with AFU, or could be incorrect AMIBCP edit done, hard to know for sure, but yes, you will be able to recover with a flash programmer and SOIC8 test clip cable.

Don't write anything to either chip before you get a verified and validated dump from each, checked by opening in BIOS tools and making sure it looks like a BIOS and is not simply FF or 00.  Programmer software can verify an invalid BIOS dump, so you have to check to be 100% sure you have a good backup made before you write anything, this way you can try to save your board specific details and put back in new BIOS before you program (Serial, UUID, LAN MAC ID etc)  
Here's a guide on getting setup and using - https://www.bios-mods.com/forum/Thread-G...programmer

As for your actual edit, "Hidden Function" is enabled by default, so the only change you need to make, if any, would be to disable that if you want it disabled.  Setting user visibility would only let you see the option setting, which is enabled by default.  I checked setup module, AMITSE/SetupData, and both NVRAM entries for this and it's enabled at every location, so you already have whatever you thought it was going to give you.  The only other thing you can do with this is disable it, and yes you can make it visible if you want to see the option enabled in the BIOS on Advanced page, but you should use AMIBCP 5.02.0023 or 5.02.0031, the 5.01 is much older than these and could be the cause of the brick (if not the AFU Flashing method)

Thank you so much for your reply. I'm up and running again. Flashing with the test clip worked flawlessly.

I actually just need to have Intel VT-d enabled. At the moment the only related option I have in the setup is "Intel Virtualization Technology", but that is apparently just Intel VT-x.
I was hoping the option would appear if I changed the Hidden Function thing in some way. But maybe that option isn't what I am looking for at all.
I think this one might be what I need:



But from what I can tell it is enabled already which is kind of weird because when I boot into Linux I can't use the feature as if it was disabled.

Any ideas?


Oh and one more thing, I found features related to iGPU <-> dGPU muxing do you know what exactly these do?  
I'm planning to fully assign one of the GPUs to a virtual machine and it would be neat if I could e.g. change which GPU is directly connected to the internal monitor and which is connected to a specific external output.

[Lost_N_BIOS]

I checked, and VT-d is enabled by default in NVRAM/AMITSE/SetupData (What you change with AMIBCP), and it's enabled b default in the setup module as well. So yes, even if you cannot see this it's enabled by default. Virtualization is also enabled by default, and this must be enabled for VT-d function to work, so leave enabled.

Here is explanation on the GPU settings you asked about
http://leshcatlabs.net/forums/printthread.php?tid=55

Can you see "Chipset" in the BIOS? If yes, can you see "Chipset >> System Agent" page? If not, I can enable those for you.
Does your CPU support VT-d, if you are unsure what is your CPU?

[0x0]

I checked, and VT-d is enabled by default in NVRAM/AMITSE/SetupData (What you change with AMIBCP), and it's enabled b default in the setup module as well.  So yes, even if you cannot see this it's enabled by default.  Virtualization is also enabled by default, and this must be enabled for VT-d function to work, so leave enabled.

Here is explanation on the GPU settings you asked about
http://leshcatlabs.net/forums/printthread.php?tid=55

Can you see "Chipset" in the BIOS?  If yes, can you see "Chipset >> System Agent" page? If not, I can enable those for you.  
Does your CPU support VT-d, if you are unsure what is your CPU?

Thank you, that link was very helpful! Also, you seem to correct about VT-d being enabled. After further investigation the feature actually seems to be available to my Linux system. The reason why I can't use it might be that  secure boot is enabled... at least people have reported that disabling secure boot solved the problem for them.
But I'm a bit scared that I won't be able to boot into my Windows when I do that. The only available option that I can see right now was names something like "Delete all secure boot variables".
Is there maybe a way to simply get a switch in the setup to enable/disable secure boot without deleting things that I don't even understand?


And can you explain why some options don't have names or appear multiple times? E.g.:

[Lost_N_BIOS]

I thought so, about VT-d. Disable secure boot is fine, as far as windows loading after that. You do not need to delete the keys, but you can if you want, next time you go to enable you'll have the option to reload stock keys, but it's fine to leave them as-is you only need to disable secure boot if that is what you found you need to do for VT-d

Duplicates in AMIBCP are ones not used, or hidden/suppressed, often with different available options (But not always). Blank items are often spaces, but can also be hidden/suppressed/unused entries as well. YOu can tell the space ones as they'll be the same "Handle" in all areas of the BIOS you go into.

On disabling secure boot mode, you should see an option for this on your actual BIOS security page (One up from your image above.
"Default Secure boot on" If you do not see in the BIOS, set "User" on access level for that setting. If it still does not show up send me an image of your BIOS security page and I'll tell you what to do next. Mainly this will be enable the "Secure Boot Menu" at bottom of the main security page by setting it's access level to User, then inside set User for access level on secure boot and secure boot mode.

[0x0]

I just modified the ROM like you told me to. And tried to flash it by simply running the SmartFlash.exe utility that comes with the BIOS update, but it doesn't actually flash it. When I do the same thing using the original ROM file, the flash works though.

Flashing using the "afuwinx64.exe" that came with the BIOS update didn't work either and even throws an error:

Code:

PS C:\users\pc\Downloads\modded_bios2> .\afuwinx64.exe .\P35V4BF.D0C /p /b /n /l
+---------------------------------------------------------------------------+
|                 AMI Firmware Update Utility  v3.04.03                     |
|      Copyright (C)2012 American Megatrends Inc. All Rights Reserved.      |
+---------------------------------------------------------------------------+
Reading flash ............... done
- ME Data Size checking . ok
Secure Flash enabled, recalculate ROM size with signature...
- FFS checksums ......... ok
bd - Error: Requested Rom Hole not available in ROM file.

I'm unsure if I should force the flash by doing ".\afuwinx64.exe .\P35V4BF.D0C /GAN" again because that's how I bricked it previously.
I could of course open the notebook up again and flash the chip externally again if it bricks again, but I'd like to avoid that.

Here's a photo of the "Security" page in the setup:

[Lost_N_BIOS]

Yes, often you cannot flash mod BIOS with stock utility, this is normal and expected. /GAN should not be required, Gigabyte does not usually setup security blocks that would require that, and /GAN only works on some versions and in some BIOS instances

Your error is explained by AFU, one of the /switches you are using is invalid (/L)
Here is the default command line >> afudos %ROMIMG% /p /b /n /s /r /oemcmd:1 /k /shutdown %1 %2 %3

You can use/try that, or simply >> afudos biosfilename.DOC /p /b /n /s /r /k

Thanks for the image, here is what you need to mod in AMIBCP


If you still can't get it, we can flash BIOS region via FPT. For that, you need to download ME System Tools package V9 from this thread, down in section "C"
https://www.win-raid.com/t596f39-Intel-M...Tools.html

Inside you will find flash programming tool folder, inside that a win/Win32 folder, select that win folder, hold shift and press right click, choose open command window here (not power shell). Then run the following command >> FPTw.exe -bios -d biosreg.bin

Then, modify that file, then reflash using this command >> FPTw.exe -bios -f modbiosreg.bin

[0x0]

No success so far. Here is what I tried:

I ran opened a powershell as administrator and then executed:

Code:

.\afuwinx64.exe P35V4BF.D0C /p /b /n /s /r /oemcmd:1 /k
+---------------------------------------------------------------------------+
|                 AMI Firmware Update Utility  v3.04.03                     |
|      Copyright (C)2012 American Megatrends Inc. All Rights Reserved.      |
+---------------------------------------------------------------------------+
- Sample Message: OEM CMD Before Flash Run is OK !!
Reading flash ............... done
- ME Data Size checking . ok
Secure Flash enabled, recalculate ROM size with signature...
- FFS checksums ......... ok
- System ROM ID = P35V4031
- System ROM GUID = 3e99fcdf-51a2-5403-47f6161e47cc528b
- Sample Message: OEM CMD Start to Flash Run is OK !!
Loading capsule to secure memory buffer ... done
18 - Error: Unable to start a Secure Flash session.
- Sample Message: OEM CMD After Flash Run is OK !!
- Sample Message: OEM CMD Before End Run is OK !!

Code:

.\afuwinx64.exe P35V4BF.D0C /p /b /n /s /r /k
+---------------------------------------------------------------------------+
|                 AMI Firmware Update Utility  v3.04.03                     |
|      Copyright (C)2012 American Megatrends Inc. All Rights Reserved.      |
+---------------------------------------------------------------------------+
Reading flash ............... done
- ME Data Size checking . ok
Secure Flash enabled, recalculate ROM size with signature...
- FFS checksums ......... ok
- System ROM ID = P35V4031
- System ROM GUID = 3e99fcdf-51a2-5403-47f6161e47cc528b
Loading capsule to secure memory buffer ... done
18 - Error: Unable to start a Secure Flash session.

Then I saw that the BIOS update actaully contains the fpt program and uses it like "fpt -f %ROMIMG% -ME" in the "flashRAID.BAT".
So I simply used that and ran:

Code:

.\fptw64.exe -f P35V4BF.D0C -ME

Intel (R) Flash Programming Tool. Version:  9.1.10.1000
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) HM97 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

   --- Flash Devices Found ---
   MX25L6405D    ID:0xC22017    Size: 8192KB (65536Kb)

PDR Region does not exist.
GBE Region does not exist.

- Reading Flash [0x200000] 2044KB of 2044KB - 100% complete.
- Erasing Flash Block [0x003000] - 100% complete.
- Programming Flash [0x003000]    4KB of    4KB - 100% complete.
- Erasing Flash Block [0x005000] - 100% complete.
- Programming Flash [0x005000]    4KB of    4KB - 100% complete.
- Erasing Flash Block [0x009000] - 100% complete.
- Programming Flash [0x009000]    4KB of    4KB - 100% complete.
- Erasing Flash Block [0x015000] - 100% complete.
- Programming Flash [0x015000]   40KB of   40KB - 100% complete.
- Erasing Flash Block [0x045000] - 100% complete.
- Programming Flash [0x045000]    4KB of    4KB - 100% complete.
- Verifying Flash [0x200000] 2044KB of 2044KB - 100% complete.
RESULT: The data is identical.

FPT Operation Passed

Then I ran what you suggested:

Code:

.\fptw64.exe -bios -d biosreg.bin

Intel (R) Flash Programming Tool. Version:  9.1.10.1000
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) HM97 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

   --- Flash Devices Found ---
   MX25L6405D    ID:0xC22017    Size: 8192KB (65536Kb)


- Reading Flash [0x800000] 6144KB of 6144KB - 100% complete.
Writing flash contents to file "biosreg.bin"...

Memory Dump Complete
FPT Operation Passed

Modified the biosreg.bin as explained in your screenshot.
AMIBCP said something like "Saving secured ROM as non secured ROM" when I hit save, I accepted by clicking OK.
And then I flashed it with the f flag as you suggested:

Code:

.\fptw64.exe -bios -f biosreg.bin

Intel (R) Flash Programming Tool. Version:  9.1.10.1000
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) HM97 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

   --- Flash Devices Found ---
   MX25L6405D    ID:0xC22017    Size: 8192KB (65536Kb)

PDR Region does not exist.
GBE Region does not exist.

- Reading Flash [0x800000] 6144KB of 6144KB - 100% complete.
- Erasing Flash Block [0x251000] - 100% complete.
- Programming Flash [0x251000]    4KB of    4KB - 100% complete.
- Erasing Flash Block [0x27E000] - 100% complete.
- Programming Flash [0x27E000]    4KB of    4KB - 100% complete.
- Erasing Flash Block [0x421000] - 100% complete.
- Programming Flash [0x421000]  424KB of  424KB - 100% complete.
- Verifying Flash [0x800000] 6144KB of 6144KB - 100% complete.
RESULT: The data is identical.

FPT Operation Passed

Then I rebooted and checked the setup, but it was still the old one...


Edit:
After the reboot I ran the ftp commands you suggested from a normal commanline (opened as administrator) again and this time it actually worked.
I probably shouldn't have done all these different flashes without a reboot inbetween. Or maybe it actually was the fact that I used powershell instead of the traditional commandline at first.

Well, I have the enable/disable secure boot options in the setup now! Thank you so much!



Is there a way to simply make all available options visible in the setup? Like what would happen if I changed the access on all options to "USER"?

[Lost_N_BIOS]

None of this can/should be ran in PowerShell, use Admin Command prompts only.

FPT Should not be used in this way!! YOu need to make a FPT backup first, then use that, or you will loose your board serial, UUID, and possibly MAC ID etc. Please be careful, or wait, until I direct you on just how to use FPT properly and safely.

I see there at end, you did use FPT as I suggested, so you should be OK! Yes, command prompt only for FPT or AFU

Yes, for anything inside a menu you can already see in BIOS (Main, Boot, Advanced etc) you can set user access level and it will then appear (usually, sometimes other edit might be needed).