StoneTemplePilots Posted September 2, 2013 Share Posted September 2, 2013 I found a setting mismatch in AMIBCP at Main > (Unnamed directory): handle 02FA, BIOS Lock - Enable or disable BIOS lock enable (BLE) bit. 1001 had it disabled and 1103 enabled. amibcp_lock.jpg Altering this setting from Enabled to Disabled and saving a new BIOS using AMIBCP changes one single byte from 0x01 to 0x00 in two different modules: 1) B1DA0ADF-4F77-4070-A88E-BFFE1C60529A - AMITSE 2) CEF5B9A3-476D-497F-9FDC-E98143E0422C - ? To automate the patch we need to figure out how to determine the correct settings byte. Running an unlocked 1104 (an update came out today) right now. Tried reflashing the same version using FPT and it worked. Output from RW-Everything while running FPT: rwe_lock.jpg Edit: This method doesn't seem to work with newer boards from Asus. For example it isn't possible to change the setting using AMIBCP on a Z87-PRO BIOS. Even if this would be possible, there is no way to flash such a modified BIOS without UBF I guess. Awesome! +-----------------------------------------------------------------------------+ | Driver Information | +-----------------------------------------------------------------------------+ | Firmware Volume : 00 Location : 00180800 Length : 020000 | +---+---------------+------------------------------------+--------+------+----+ |NO | FileName | GUID |Location| Size |Type| +---+---------------+------------------------------------+--------+------+----+ |000| |CEF5B9A3-476D-497F-9FDC-E98143E0422C|00180848|01FFB8|RAW | +---+---------------+------------------------------------+--------+------+----+ | Bytes Free : 000000 ( 0 KB) Bytes Used : 020000 (128 KB) | +-----------------------------------------------------------------------------+ I tried that now but fpt still shows: Error 280: Failed to disable write protection for the BIOS space! at least in Windows 7 x64 UEFI, I'll try to flash in CSM mode. Nope, does not change anything for me. Now I'll disable the SMI-Lock above. Link to comment Share on other sites More sharing options...
k3nny Posted September 2, 2013 Share Posted September 2, 2013 I tried that now but fpt still shows: Error 280: Failed to disable write protection for the BIOS space! Did you flash an officially unlocked BIOS before the manually unlocked one? The lock bit can only be unset during a platform reset with a BIOS that does not set it again. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 2, 2013 Share Posted September 2, 2013 Did you flash an officially unlocked BIOS before the manually unlocked one? The lock bit can only be unset during a platform reset with a BIOS that does not set it again. Yes, I flashed 0401.CAP with afudos 0401.CAP /p /b /n /k ... only after flashing 0401.CAP I can flash again with FPT but after upgrading again to the unlocked version of 2204 the same lock error appears. Also I found another place where the locks are set: Link to comment Share on other sites More sharing options...
CodeRush Posted September 3, 2013 Author Share Posted September 3, 2013 Awesome findings, guys. Now we need to figure out, what code reads this setting and actually sets a lock byte, so we can patch it out. k3nny, you are right that there is no way to flash unlocked BIOS on new ASUS boards besides external SPI programmer, but it will be needed only once to flash the initial unlocked version, so it would be great to be able to unlock them too. Keep pushing! More to say, we can also patch SMM driver that is responsible to CAP validation, so it will validate anything. That way the locks can be left untoched. It will be harder to do things that way, so it is plan B. 1 Link to comment Share on other sites More sharing options...
k3nny Posted September 3, 2013 Share Posted September 3, 2013 (edited) ...after upgrading again to the unlocked version of 2204 the same lock error appears. Also I found another place where the locks are set... I only changed the first occurrence in section Main and it is enough here. You could look what exactly changes in these modules after saving with AMIBCP and how the BIOS_CNTL byte looks like in RWEverything after applying the different BIOSes. More to say, we can also patch SMM driver that is responsible to CAP validation, so it will validate anything. That way the locks can be left untoched. It will be harder to do things that way, so it is plan B.I really would like to see that happen sometime! Edit: The place to look is probably B1DA0ADF-4F77-4070-A88E-BFFE1C60529A, which should contain the procedure to load the default values (StdDefaults). Edited September 3, 2013 by k3nny Link to comment Share on other sites More sharing options...
CodeRush Posted September 3, 2013 Author Share Posted September 3, 2013 I think it will be better to find the code, that sets locking bits in to BIOS_CNTL it the first place. It depends on AMITSE/CEF5B9A3 settigns, but there are no such settings on Z87, so it's only a partial solution. PM locking code is easier to find, because 'mov ecx, 0xe2' is not a common instruction, but I hope we can find that code too. Link to comment Share on other sites More sharing options...
CodeRush Posted September 3, 2013 Author Share Posted September 3, 2013 The probable way to find it is looking fo code accesing to PCI device with DF D31:F0 or DID (can be found in datasheet) (LPC I/F), where our beloved BIOS_CNTL is located. There will be much code found, but it is a point to start anyway. 1 Link to comment Share on other sites More sharing options...
k3nny Posted September 3, 2013 Share Posted September 3, 2013 Are you sure there are no settings for it on Z87? Most likely it has a default value preassigned that isn't allowed to be changed. CEF5B9A3 (NVRAM) binaries of Z77/Z87 are very similar. Otherwise I agree. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 3, 2013 Share Posted September 3, 2013 The probable way to find it is looking fo code accesing to PCI device with DF D31:F0 or DID (can be found in datasheet) (LPC I/F), where our beloved BIOS_CNTL is located. There will be much code found, but it is a point to start anyway. 1.png2.png B00 D1F F00: Intel® Z77 Express Chipset LPC Controller - 1E44 [8086-1E44] [NoDB] Offset 000: 86 80 44 1E 07 00 10 02 04 00 01 06 00 00 80 00 Offset 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Offset 020: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 CA 84 Offset 030: 00 00 00 00 E0 00 00 00 00 00 00 00 00 00 00 00 Offset 040: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00 Offset 050: F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Offset 060: 8B 8A 8A 83 90 00 00 00 80 85 8B 86 F8 F0 00 00 Offset 070: 78 F0 78 F0 78 F0 78 F0 78 F0 78 F0 78 F0 78 F0 Offset 080: 10 00 0F 3C 91 02 0C 00 00 00 00 00 00 00 00 00 Offset 090: 00 00 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 Offset 0A0: 18 0E A0 00 09 18 06 00 00 47 00 00 00 00 00 00 Offset 0B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Offset 0C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Offset 0D0: 33 22 11 00 67 45 00 00 CF FF 00 00 2A 00 00 00 Offset 0E0: 09 00 0C 10 00 00 00 00 B3 02 64 04 00 00 00 00 Offset 0F0: 01 C0 D1 FE 00 00 00 00 87 0F 04 08 00 00 00 00 Link to comment Share on other sites More sharing options...
CodeRush Posted September 3, 2013 Author Share Posted September 3, 2013 k3nny, you are possibly right. Modules of ASUS P8Z77-V-LE-PLUS BIOS 0905 with "mov eax,1e44h" Setup / 899407D7-99FE-43D8-9A21-79EC328CAC21 PchSpiSmm / 27F4917B-A707-4AAD-9676-26DF168CBF0D SmmControl / A0BAD9F7-AB78-491B-B583-C52B7F84B9E0 SBDXE / B7D19491-E55A-470D-8508-85A5DFA41974 PchReset / BB1FBD4F-2E30-4793-9BED-74F672BC8FFE ActiveBios / BFD59D42-FE0F-4251-B772-4B098A1AEC85 PchSpiRuntime / C194C6EA-B68C-4981-B64B-9BD271474B20 SaInitDxe / DE23ACEE-CF55-4FB6-AA77-984AB53DE811 AcpiPlatformSmi / DFD8D5CC-5AED-4820-A2B6-5C55E4E640EF SaInitPeim / FD236AE7-0791-48C4-B29E-29BDEEE1A811 PchDeviceGpio / FC1B7640-3466-4C06-B1CC-1C935394B5C2 The most interesting one is PchSpiSmm, I think. Digging into it now. Link to comment Share on other sites More sharing options...
buoo Posted September 3, 2013 Share Posted September 3, 2013 Guys, did you discover how the Asus protection works? What does it control? The size, the hash? If you open an official bios with PhoenixTools and rebuild it without changes will it pass the check? Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 3, 2013 Share Posted September 3, 2013 I think it will be better to find the code, that sets locking bits in to BIOS_CNTL it the first place. It depends on AMITSE/CEF5B9A3 settigns, but there are no such settings on Z87, so it's only a partial solution. PM locking code is easier to find, because 'mov ecx, 0xe2' is not a common instruction, but I hope we can find that code too. CodeRush, which decompiler do you use, is there something free for decompiling efi modules you'd recommend on Linux or Windows? IDA Pro Demo does not decompile anything and I just don't have >$1000 for this excellent piece of software. Link to comment Share on other sites More sharing options...
CodeRush Posted September 3, 2013 Author Share Posted September 3, 2013 Yes, there are some. On linux it's objdump from binutils, on windows - dumpbin from VS 2010 Express or Windows SDK package. Don't forget to cut section header from files in PT's DUMP directory. For searching in many binary files i'm using Swiss File Knife utility with "hexfind -binary /pattern/" option. I also use online assemblers and disassemblers for asm/dasm a single command. 2 Link to comment Share on other sites More sharing options...
MiniHack Posted September 3, 2013 Share Posted September 3, 2013 Hi CodeRush, Cheers for your help in the past. I am attaching my bios from my Zotac H87 ITX board and would welcome your comments on whether it needs to /can be patched. This board is working for me on 10.8.4 (with patched mach_kernel) but I get an instant reboot trying with 10.8.5 or 10.9 I realise it is a long shot that bios patching is an answer to that problem, but either way would welcome your input. Many thanks. APologies, upload is not working for me tonight. Bios is in this location though: http://www.zotac.com/products/mainboards/intel-cpu/zotac-h87/product/zotac-h87/detail/h87-itx-wifi-a-series/sort/product_name/order/DESC/amount/10/section/downloads.html Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 3, 2013 Share Posted September 3, 2013 Hi CodeRush, Cheers for your help in the past. I am attaching my bios from my Zotac H87 ITX board and would welcome your comments on whether it needs to /can be patched. This board is working for me on 10.8.4 (with patched mach_kernel) but I get an instant reboot trying with 10.8.5 or 10.9 I realise it is a long shot that bios patching is an answer to that problem, but either way would welcome your input. Many thanks. APologies, upload is not working for me tonight. Bios is in this location though: http://www.zotac.com/products/mainboards/intel-cpu/zotac-h87/product/zotac-h87/detail/h87-itx-wifi-a-series/sort/product_name/order/DESC/amount/10/section/downloads.html Hi Minihack, looks like it can be patched: $BIOSWORX\pa287>pmpatch A2870719.bin A2870719-pmpatched.bin PMPatch 0.5.13 PowerManagement modules not found. PowerMgmtDxe/PowerManagement2.efi modules not found. Trying to apply patch #1 Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched. Patched module too big after compression. Trying to apply patch #2 Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched. Patched module too big after compression. Trying to apply patch #3 Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched. Patched module too big after compression. Trying to apply patch #4 Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched. Patched module too big after compression. Trying to apply patch #5 Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched. AMI nest module at 00450048 patched. Phoenix nest modules not found. CpuPei module at 007A3A80 not patched: Patch pattern not found. Output file generated. http://rghost.net/48557584 @CodeRush, found something interesting maybe: Link to comment Share on other sites More sharing options...
badaxe2 Posted September 5, 2013 Share Posted September 5, 2013 C:\Users\Mathew\Desktop\New folder>pmpatch afuwin.bios patched.bios PMPatch 0.5.13 PowerManagement modules not found. PowerMgmtDxe/PowerManagement2.efi modules not found. Trying to apply patch #1 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #2 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #3 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #4 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #5 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. AMI nest module at 00050048 not patched: Repacked module can't be inserted. Phoenix nest modules not found. CpuPei module at 0029EB50 not patched: Patch pattern not found. C:\Users\Mathew\Desktop\New folder>pmpatch afuwin.rom patched.rom PMPatch 0.5.13 PowerManagement modules not found. PowerMgmtDxe/PowerManagement2.efi modules not found. Trying to apply patch #1 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #2 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #3 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #4 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. Trying to apply patch #5 Nested PowerManagement module at 003AC614 patched. Patched module too big after compression. AMI nest module at 00050048 not patched: Repacked module can't be inserted. Phoenix nest modules not found. CpuPei module at 0029EB50 not patched: Patch pattern not found. Hey guys, doesnt seem to work on my ami aptio bios... Any idea whats up ? I have attached my bios backed up with afudos in dos.. Also tried renaming from .rom to .bios as per instructions... I get a error also under Os X Mats-Mac:untitled folder mat$ /Users/mat/Desktop/untitled\ folder/PMPatch afuwin.rom patched.rom PMPatch 0.5.13 PowerManagement modules not found. PowerMgmtDxe/PowerManagement2.efi modules not found. Trying to apply patch #1 Nested PowerManagement module at 003AC614 patched. Segmentation fault: 11 Mats-Mac:untitled folder mat$ afuwin.zip Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 5, 2013 Share Posted September 5, 2013 ...................I get a error also under Os X Mats-Mac:untitled folder mat$ /Users/mat/Desktop/untitled\ folder/PMPatch afuwin.rom patched.rom PMPatch 0.5.13 PowerManagement modules not found. PowerMgmtDxe/PowerManagement2.efi modules not found. Trying to apply patch #1 Nested PowerManagement module at 003AC614 patched. Segmentation fault: 11 Mats-Mac:untitled folder mat$ Yep, the tools fails due to the ffs checksum mismatch, needs to be regenerated by hand, I did that for you : ) the manual PM unlock way with mmtools ... I found mmtool failed to reintegrate the module due to broken checksum. After patching 75080fbae80f89442430 to eb080fbae80f89442430 with HxD I cut the ffs header to MZ so I had a native .efi driver and then I regenerated the ffs driver module with matching ffs checksum that way: GenSec -s EFI_SECTION_PE32 -o Powermanagement.pe32 Powermanagement.efi GenFfs -t EFI_FV_FILETYPE_DRIVER -g 8C783970-F02A-4A4D-AF09-8797A51EEC8D -o Powermanagement.ffs -i Powermanagement.pe32 Now I was able to re-integrate the patched Powermanagement.ffs Patched ROM Download »» http://rghost.net/48590491«« Using pmpatch on Windows I saw a little bit more: AMI nest module at 00050048 not patched: Repacked module can't be inserted. Link to comment Share on other sites More sharing options...
badaxe2 Posted September 5, 2013 Share Posted September 5, 2013 Yep, the tools fails due to the ffs checksum mismatch, needs to be regenerated by hand, I did that for you : ) the manual PM unlock way with mmtools ... I found mmtool failed to reintegrate the module due to broken checksum. After patching 75080fbae80f89442430 to eb080fbae80f89442430 with HxD I cut the ffs header to MZ so I had a native .efi driver and then I regenerated the ffs driver module with matching ffs checksum that way: GenSec -s EFI_SECTION_PE32 -o Powermanagement.pe32 Powermanagement.efi GenFfs -t EFI_FV_FILETYPE_DRIVER -g 8C783970-F02A-4A4D-AF09-8797A51EEC8D -o Powermanagement.ffs -i Powermanagement.pe32 Now I was able to re-integrate the patched Powermanagement.ffs Patched ROM Download »» http://rghost.net/48590491«« Using pmpatch on Windows I saw a little bit more: AMI nest module at 00050048 not patched: Repacked module can't be inserted. That is all chinese to me !! Is this file ok to flash now ? Did you change anything else ? Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 5, 2013 Share Posted September 5, 2013 That is all chinese to me !! Is this file ok to flash now ? Did you change anything else ? It's ready to flash. Nothing else done. Link to comment Share on other sites More sharing options...
badaxe2 Posted September 5, 2013 Share Posted September 5, 2013 It's ready to flash. Nothing else done. Cheers mate, I just tried to flash and I get this error - 0x18 Error: Unable to start a Secure Flash session. Any ideas ? Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 6, 2013 Share Posted September 6, 2013 Cheers mate, I just tried to flash and I get this error - 0x18 Error: Unable to start a Secure Flash session. Any ideas ? signed UEFI, try using use intel ftk or DOS flashtool of OEM vendor and flash from DOS! for intel ftk: you have to use the version that matches your chipset. Link to comment Share on other sites More sharing options...
CodeRush Posted September 6, 2013 Author Share Posted September 6, 2013 BonBon6, this problem has notnig to do with checksums, but with LZMA compression parameters. Andy has implemented a nice routine, that tries to fit a recompressed module by tweaking LZMA algorithm parameters, so PhoenixTool can fit a modified module (almost) always. I have no time for PMPatch about 3 months in a row, so I didn't implement such routine, that is why there are some BIOSes with that problem. As for segfault in OS X - I have no idea what is going on with CLang Release configuration on my code. Debug works OK, so next version will be compiled as debug. I don't have OS X installed, so I can't replace it for now. Thank you for patching that BIOS with PT, BTW. Less work for me. badaxe2, try using Intel FPT to flash it. What is your motherboard name? Link to comment Share on other sites More sharing options...
CodeRush Posted September 8, 2013 Author Share Posted September 8, 2013 kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway. Thank you very much. :beer: BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB0 (SMI) and 0xB1 (BIOS) from the beginning of storage. That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure. If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it. 2 Link to comment Share on other sites More sharing options...
k3nny Posted September 8, 2013 Share Posted September 8, 2013 kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway. Thank you very much. :beer: BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB00 (SMI) and 0xB01 (BIOS) from the beginning of storage. That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure. If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it. Very nice. Can you please point me to the place where the locking bits are set? I just would like to know where it is. What about the changes in module "AMITSE", besides NVRAM? Did you take them into account or do you know what they represent? So after all, the write protection was there all the time - it just wasn't enabled. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 8, 2013 Share Posted September 8, 2013 kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway. Thank you very much. :beer: BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB0 (SMI) and 0xB1 (BIOS) from the beginning of storage. That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure. If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it. Bon jour CodeRush, do you think you can implement the unlock in your next pmpatch release? Btw, as you know I own a Z77 board from ASUS, and I'm young willing and able to test it (SPI flasher). Uploaded my ROM << here. Friday my TUMPA arrived from canada. Au jaaa! best regards Link to comment Share on other sites More sharing options...
Recommended Posts