Jump to content
Welcome to InsanelyMac.com - No more ads! And some exciting news... Read more... ×
ludufre

[GUIDE] Fix Insyde H2O BIOS signature (5 beeps on Lenovo)

13 posts in this topic

Recommended Posts

[GUIDE] Fix Insyde H2O BIOS signature (5 beeps on Lenovo)

 

I recently bought a Lenovo L440 laptop to install the Mojave macOS and I replaced the wireless card with the DW1560 because the current one is not compatible. I discovered that there was a whitelist of enabled cards that manufacturers are adopting recently (in my case it uses a Phoenix Insyde BIOS H2O).

 

I searched the BIOS Modding forums and found people who did the patch for me. But after replacing the BIOS I noticed that the computer keep beeping 5 times every time I boot. So, I went deeper into this issue and that's when I figured out how to solve it. Then I created this guide based on the information I found in some Russian forums.

 

Preface

 

When the BIOS integrity test fails, some Intel AMT functionality stops working and a sequence of 5 whistles is issued twice at boot.

After modifying to remove whitelist (enable unauthorized WI-FI cards), unlock MSR 0xe2 (hackintosh), enable advanced menu, etc. the BIOS will not pass the integrity test causing this problem.

This integrity check is done through the RSA signature of the BIOS block called TCPABIOS (more information below) with the public key in modulus 3 format also stored in the BIOS.

This TCPABIOS block stores the checksums of each BIOS volume.

 

What we will do is generate new checksum for those volumes that have been modified, generate a RSA (private and public) key pair, sign that block with the private key, and replace the public key.

 

 

Tools needed

 

- EFITool NE alpha 54: https://github.com/LongSoft/UEFITool/releases

- HxD 2.1.0: https://mh-nexus.de/en/hxd/

- OpenSSL: http://gnuwin32.sourceforge.net/packages/openssl.htm (Download -> Binaries)

- Microsoft File Checksum Integrity Verifier (FCIV.exe): https://www.microsoft.com/en-us/download/details.aspx?id=11533

 

Step by step

 

Let's open the modified BIOS, locate the TCPABIOS block and understand its anatomy.

 

1. Open the BIOS with HxD

 

image.png.9bd20639628631149f820fde57e42233.png

(We will use the modded BIOS in the MyDigitalLife.com forum by the Serg008 user for the Lenovo B590 laptop in this guide)

 

2. Find the word TCPABIOS:

 

image.png.931aa98e383f2b3b9273b3956d6a0236.png

image.png.8cef4f91211ce1eafafcb7af51297583.png

 

3. The block starts with TCPABIOS and ends before TCPACPUH

 

image.png.51262f4653917f3ed1ab1ee74d45006e.png

 

4. Anatomy:

 

54 43 50 41 42 49 4F 53 48 31 38 34 61 31 31 2F

32 36 2F 31 33 49 42 4D 53 45 43 55 52 00 FD 27

34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B

77 F9 82 58 48 00 00 00 CE 18 1F 00 00 00 03 00

00 00 00 00 00 00 27 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 FF FF 83 04 D4

52 52 95 C5 D7 21 55 78 0E 5C AD 47 EE C4 3D 1D

C1 EC 69 03 2B 51 A5 42 61 96 22 F9 7B 88 57 B7

A8 9D D0 20 DB 5B 11 10 55 07 84 6C 62 DF FA 2F

6A A8 43 0C 8A 40 AF 79 0D 31 DB 5A 5D C8 2F EB

F8 7C 87 B0 A6 3D 2A 88 AE 91 9D 88 E3 AA 85 E3

5A B3 91 7F 28 68 1F BA 92 C4 7E 10 F5 1A 7E 75

A9 6F CE C0 4F BA FA 79 A5 98 2B 50 60 BA 09 73

7B 03 D1 0C 3E A2 9C 44 DF E9 F2 92 34 7B

 

Gray: Name and Block Information

Red: Volume Information (Checksum and Header)

Blue: Separation of the list of volumes and the block signature

Green: Signature of the TCPABIOS block are the last 128 bytes

 

List of Volumes:

 

Each volume has the format: 00 FD 27 34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B 77 F9 82 58 48 00 00 00 CE 18 1F 00 00 00 03 00 00 00 00 00

                                        (Prefix 3 bytes + checksum 20 bytes + offset 4 bytes + volume size 6 bytes + end delimiter 6 bytes)

 

The volumes are enumerated and use the first byte in the prefix for this (00 FD 27), starting at 0.

The BIOS used in this example has only one volume, but in the case of more than one volume, it would be: 00 FD 27 .., 01 FD 27 ..., 02 FD 27 ...

- Checksum is SHA1 calculation of the volume.

- Offset is the volume position within the BIOS. The bytes are inverted, in this case it would be 00 00 00 48, equals to 48h

- Volume Size is also with the bytes inverted, then: 1F18CEh

 

Then that's it. We need to correct this information (checksum, offset and size)

 

5. To extract the volumes open the BIOS with the UEFITool and see how to identify the volumes (our example there is only one volume if there were others would also be inside EfiFirmwareFileSystemGuid):

 

image.thumb.png.ccbcc129e633036cbcbcec60deae5771.png

 

In the original BIOS, circled in red we can see our volume.

Note that in blue we have offset and green the size. Exactly as we checked up on HxD. In the modified BIOS we see that the size is different:

Original: 1F18CEh

Modified: 1F12D5h (we'll need this later)

 

6. Let's extract this volume to calculate the checksum by choosing the "Extract as is ..."

 

image.png.4f6c6b44f33f610326329f01a22db1a8.pngimage.png.69537d20c3a7e5adc3194e404d65ce3c.png 

 

7. Use this command to get the checksum of this volume: fciv.exe -sha1 File_Volume_image_FvMainCompact.ffs

 

image.png.cbc530b6859dad3b6b46d1bfbbc9e6d8.png

 

Now we have the checksum that is 396e0dc987219b4369b1b9e010166302ce635202

 

8. Replace the information in the TCPABIOS block:

 

image.png.fce7e2fe4f5b9861cfcfe8b0aece8459.png

 

Note that the volume size must have the bytes inverted, so if the total is 6 bytes and is 1F12D5h, becomes D5 12 1F 00 00 00 in place of CE 18 1F 00 00 00.

If the offset is different, also perform the same process by inverting the bytes.

Checksum change from 34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B 77 F9 82 58 to 39 6E 0D C9 87 21 9B 43 69 B1 B9 E0 10 16 63 02 CE 63 52 02

 

Do this for each volume in the BIOS.

 

9. Now we need to generate the checksum of the whole TCPABIOS block but without considering the last 131 bytes, that is to dismiss FF FF 83 + 80 bytes from the previous signature.

 

Copy to a new file in HxD and save as tcpabios

 

image.png.fe2cb4ed07464785c8469c30b32541bf.png

 

Use the command to generate the checksum of this block: fciv.exe -sha1 tcpabios

 

image.png.5325dcc1c6b630c0ff1423adc4c723d4.png

 

Checksum of TCPABIOS block: 0da6715509839a376b0a52e81fdf9683a8e70e52

 

Create a new file in HxD and add 108 bytes with 00 and paste the checksum at the end and save as tcpabios_hash, thus:

 

image.png.3abfadf19cea0a41a461661fa7cb3fc7.png

 

10. Now let's generate the RSA private key with modulus 3: openssl genrsa -3 -out my_key.pem 1024

 

image.png.1aa571bb1c48113d1630cfb1e676bbe5.png

 

Sign the file tcpabios_hash: openssl rsautl -inkey my_key.pem -sign -in tcpabios_hash -raw > tcpabios_sign

 

image.png.f6aa958f87b2a012aaa679c32cc44c12.png

 

Now enjoy to generate the public key: openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der

 

image.png.0b46c643e8aa32dc899f20e080c7b982.png

 

And generate public key modulus 3: openssl rsa -pubin -inform der -in my_key_pub.der -text -noout

 

image.png.de85889394db5266570e9f4e84420dc8.png

 

Copy and paste the key into a text file to use soon. Remove all ":" and put everything on a single line, thus:

 

image.png.e319dc1c7338214857a669eb52f44036.png

 

11.   Open the tcpabios_sign file in HxD, copy the contents and replace the signature at the end of the TCPABIOS block:

 

 image.png.b4d270f8674000ee94ea2d538f0d8ac0.pngimage.png.3e3bf21863474216a6464d9918f86013.png

 

12. Now let's locate the location of the public key in the BIOS and replace it. This key starts with 12 04 and ends with 01 03 FF and is after the TCPABBLK block.

 

The key looks like this: 12 04 + 81 bytes + 01 03 FF. Search for 01 03 FF to locate more easily. Verify that before the 81 bytes have bytes 12 04 to make sure you found.

 

image.png.7c068048eb8c61f246a1a4a6ab5249a3.png

 

image.png.f5e676b7c1ddf88d85cd3f3428f3e60a.png

 

Now substitute for the public key that was annotated in the text file previously, thus:

 

image.png.0c27ad6e4301b03208ca8cd57f77e44b.png

 

 

Save and you're ready. Your BIOS is signed and ready.

Share this post


Link to post
Share on other sites

I have succeeded on T440P and failed on X250. I now have whitelist removed, deleted anti theft/computrace and can edit any module after this long process.

 

On newer bios the volume image is not what is checksumed; the entire FFsV2 is computed with SHA1 instead. You have to run ftic on entire EfiFirmwareFilesystemGuid.ffs... fortunately it makes the generation of the checksum much easier. I removed/changed so much and yet it stayed the same.

 

On systems with bootguard, like the X250, it looks like bootguard key is used to sign the bios and the second volume so this modification is not possible. In fact, every attempt to modify modules failed.Maybe with a downgrade at least editing would be possible? I failed to backup the original bios and ended up with a "secure" newer one because I foolishly upgraded it.

 

On the 440P I only used the bios 2.50, before I saw in the changelog all the fixes for Tianocore "vulnerability".

Share this post


Link to post
Share on other sites

Here is what I have running on it. I don't know if downgrading would prove fruitful in order to get the mods working.

 

http://s000.tinyupload.com/index.php?file_id=72243378644638634752

Share this post


Link to post
Share on other sites

This is Lenovo s540
comet lake    400 Series Chipset Family
Modifying BIOS content is different tcpabios cannot be found

Share this post


Link to post
Share on other sites

I have good news on the X250 front... I downgraded to 1.32 with dosflash (skip checks) and now I can modify the bios again. Unfortunately when I did the signature I think it trips bootguard.

 

Share this post


Link to post
Share on other sites
On 11/16/2019 at 10:58 AM, nsafarm said:

I have succeeded on T440P and failed on X250. I now have whitelist removed, deleted anti theft/computrace and can edit any module after this long process.

 

On newer bios the volume image is not what is checksumed; the entire FFsV2 is computed with SHA1 instead. You have to run ftic on entire EfiFirmwareFilesystemGuid.ffs... fortunately it makes the generation of the checksum much easier. I removed/changed so much and yet it stayed the same.

 

On systems with bootguard, like the X250, it looks like bootguard key is used to sign the bios and the second volume so this modification is not possible. In fact, every attempt to modify modules failed.Maybe with a downgrade at least editing would be possible? I failed to backup the original bios and ended up with a "secure" newer one because I foolishly upgraded it.

 

On the 440P I only used the bios 2.50, before I saw in the changelog all the fixes for Tianocore "vulnerability".

i am trying to checksum a t440p with 2.53 bios and i get lost in the FFsV2 step because how you said the whole FFs2 is computed, can you help me?

Share this post


Link to post
Share on other sites
On 11/17/2019 at 4:50 AM, ludufre said:

Could you send me a dump of your X250 BIOS so I can analyze? I haven't seen anything about Bootguard yet.

 

Here same issue with my t450S bios which is mod for LCD whitelist.
Can you please help me to fix this? My bios-file is at this location : https://gofile.io/d/jdmXi0

 

Thx for now!

Share this post


Link to post
Share on other sites

Hello, can I add a friend? I need your help to unlock the Advanced menu. I will be very grateful

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By y010204025
      Update: On October 24, 2020, using clover to solve the macOS11 beta10 boot problem, you can now enjoy macOS11beta10, and the compatibility of subsequent versions is not guaranteed.
      HIDPI uses a modified version. You can directly execute the hidpi script to get a better experience. If you lose the repair, it is not within the scope of my support.
      Support upgrades without destroying the integrity of the original image.
      There seems to be a problem with the shortcut keys. If you can help solve it, thank you for your contribution.
       
      Perhaps it was the first NEC (Lenovo) Lavie Z HZ550 to install hackintosh. I hope more people who like Lavie Z series can experience Hackintosh at HZ550. She is really great.
       
      I found HZ550 & HZ750 on the Chinese website, which is amazing. It weighs only 790g, 13.3 inches, and the standard 2k screen, which is too attractive to me. I am a Hackintosh enthusiast. I think HZ550 or HZ750 with MacOS is the best Unfortunately, the Lavie Z series is not listed in China, only exists in the Japanese and American markets, and in the Japanese market is the NEC brand, while the American market uses the Lenovo logo.
       
      Fortunately, I got an HZ550 from Taobao. Yes, not HZ750. In comparison, HZ750 has more touch screens and 360 ° flip. These are hard to attract me. More importantly, HZ750 is about 200g heavier than HZ550 That's why I chose HZ550. Well, because he is only 2,000 RMB.
       
      The specific introduction can refer to NEC Japan official website:http://nec-lavie.jp/products/hz13b/
       
      The HZ550 hardware list I obtained:
                                    
                       -/+:.          [email protected]
                      :++++.          OS: 64bit Mac OS X 10.15.5 19F96
                     /+++/.           Kernel: x86_64 Darwin 19.5.0
             .:-::- .+/:-``.::-       Uptime: 19m
          .:/++++++/::::/++++++/:`    Packages: 1
        .:///////////////////////:`   Shell: zsh 5.7.1
        ////////////////////////`     Resolution: 3840x2160
       -+++++++++++++++++++++++`      DE: Aqua
       /++++++++++++++++++++++/       WM: Quartz Compositor
       /sssssssssssssssssssssss.      WM Theme: Blue (Dark)
       :ssssssssssssssssssssssss-     Disk: 11G / 108G (12%)
        osssssssssssssssssssssssso/`  CPU: Intel Core i7-5500U @ 2.40GHz
        `syyyyyyyyyyyyyyyyyyyyyyyy+`  GPU: Intel Iris Graphics 6100
         `ossssssssssssssssssssss/    RAM: 4376MiB / 8192MiB
           :ooooooooooooooooooo+.    
            `:+oo+/:-..-:/+o+/-     
       
       
      Advantages: small size, light weight, 2K screen, 8G memory, 512g SSD, keyboard feels good, and wireless network card can be replaced, which is unimaginable in today's thin and light books.
      Disadvantages: The sound is small, almost the same as the mosquitoes.
       
      Ok, bragging is over!
      In order to use the wireless network, I changed the wireless network card from inter 7265 to BCM94352ZAE. Some people called it DW1560. It is uncomfortable that in China, this card and his elder brother DW1830 were hyped to a high price of 480RMB. of. Fortunately, I bought it early, and this card is also very stable under win10, and there is no high delay and outage. The hard disk should be PM951 of Samsung, not PM981, which is lucky.   Before installing Hackintosh: You need to prepare a 16G U disk, SanDisk is not a rough choice for making MacOS installation disk, I used the latest MacOS Catalina 10.15.5, got config.plist from Rehabman, and put together an EFI, the latest version of clover and kext drivers. Thanks to Rehabman and the developers of the Black Apple community. I do n’t like that OC team very much.
      Make an installation disk: If you have a computer running MacOS, you can use the command line to make it, if you do n’t have a computer running MacOS, you can try VMware, I know that the insanelymac forum allows discussion, or use ether to write the image to U disk, use the EFI I provided to boot into the installation process.   BIOS setting: Press F12 at boot to enter the BIOS settings, Tab switches to "Security-Secure boot", set to "DISable", this is what we need, and switch to "Boot -Boot devices", set the U disk as the first boot item You can directly enter the clover guide interface, please follow it for google it.
      It is worth noting that the remaining space of your EFI partition needs to be greater than 200M, otherwise, the disk format will be wrong. In addition, the format partition format is APFS, do not choose to encrypt, your data is not valuable, at least you must have this awareness of Hackintosh, the file safe is also the same, do not enable, do not use to find your mac, otherwise, change the machine, OK .   Fortunately, no additional ssdt patch is required. All the patch functions are implemented through clover. The flat Apple is turned on. This is to solve the problem of the flower screen. You can find a solution yourself.
      Experience your black apple, this will bring a better experience than MacBook Pro.  
       
    • By miliuco
      What is CFG Lock and MSR 0xE2?
       
      CFG Lock is a BIOS setting that allows writing to a specific register, in this case MSR E2 (MSR = Model Specific Register). An MSR consists of one or more registers in blocks of instructions used to do certain tasks on a CPU. MTRs are also used to control CPU's access to memory ranges. Commands capable of reading and writing to MSR work with elevated privileges (the operating system, primarily).

      Many motherboards come from factory with MSR E2 region locked (read but not write) and quite a few of them even hide this option in BIOS user interface. In those that do show the option to block or unblock this variable, it is usually called CFG Lock. CFG Lock is a bit with 2 values, 0x1 or 0x0. When it is 0x1, macOS cannot write into this region and kernel patches are required.

      macOS wants to write this registry, both the Kernel and AppleIntelPowerManagement. It defines the C-states of the CPU, which is why it is essential for macOS. Without the ability to write to MSR E2, all or most of the CPU power management is lost and the system does not boot.

      In Clover 2 patches have been used: KernelPM (for AppleIntelPowerManagement.kext) and KernelXCPM (for the kernel). In OpenCore 2 others have been used: AppleCpuPmCfgLock (for AppleIntelPowerManagement.kext) and AppleXcpmCfgLock (for the kernel). These patches fix the problem but the registry is still read-only. To ensure native CPU power management, CFG Lock bit must be set to 0x0.

      To achieve this, the firmware must be modified to support writing to MSR E2. This method is preferred over Clover and OC patches, it generates greater system stability and the CPU power management more closely resembles that of a real Mac. The methods that are usually proposed for this task are too complex for most users who do not have a high level of knowledge, requiring specialized tools and even modified Grub.

      Below I comment on an alternative method that is much simpler and that, at least in my case, seems to have been successful. Like any of the methods that modify this bit, it has the risk of not working or even damaging the BIOS, so if you try it it is under your entire responsibility.

      CFGLock.efi

      User @Brumbaer has a tool called CFGLock.efi (see post). It is an EFI application, it has to be installed in OC Tools folder (Misc - Tools in config.plist) and in this way it is available in the OC menu next to Reset NVRAM. It should be accompanied by another tool included in the OC package called VerifyMsrE2.efi that reports current status of CFG Lock (locked / unlocked).

      When CFGLock.efi runs, it displays information (CFG variable found, varstore in which it resides, current reading and requests user intervention to make the change from 0x1 to 0x0 or vice versa). Then you have to restart. With VerifyMsrE2.efi we can check if the change has been successful.

      Both EFI applications can be run by selecting them directly in the OC menu but it is also possible, by installing OpenShell.efi tool, to run this shell and running them from there. Information for handling OpenShell.efi is available in OC and elsewhere.
       

       
      After CFGLock.efi

      I have tried CFGLock.efi and apparently it has worked well.
       
      macOS boots up and works fine with the OC patches AppleCpuPmCfgLock and AppleXcpmCfgLock disabled.
        VerifyMsrE2.efi reports "This firmware has UNLOCKED MSR 0XE2 register!".
        Hackintool in Utilities - Get AppleIntelInfo displays this text: AppleIntelInfo.kext v3.0 Copyright © 2012-2017 Pike R. Alpha. All rights reserved. IA32_MISC_ENABLES................(0x1A0) : 0x850089 ------------------------------------------ - CFG Lock............................. : 0 (MSR not locked) Note: Hackintool current version (3.4.6) doesn't show text after Get AppleIntelInfo in Big Sur beta 10. It's got from Catalina.
        Intel Power Gadget - Frequency graph shows variations between maximum and minimum suggestive of CPUPM.  

    • By qmgoqwe
      I have installed MacOS and Windows on the following hardware:
       
      AMD Ryzen 7 3700X MSI B450M Mortar Max Sapphire Radeon Pulse RX 5600 XT 6G Samsung 860 QVO, 1 TB SSD (PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x1)/Sata(0x5,0xFFFF,0x0)) - MacOS on this disk Kingston A2000 SSD 1TB M.2 2280 NVMe (PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,15-AD-CD-26-28-B7-26-00)) - Windows on this disk  
      OpenCore 0.6.1 MacOS 10.15.7 both disks GPT UEFI  
      Both OSs boot nicely and work as a charm when selecting either of the disks as boot disks in the BIOS.
       
      However, trying to boot Windows 10 from the Opencore Bootmanager (no matter whether PickerMode=internal or OpenCanopy) causes a Windows Blue Screen ("SYSTEM THREAD EXCEPTION NOT HANDLED").
      To be on the safe side, I have added an appropriate entry to Misc->Entries:
      <key>Arguments</key> <string></string> <key>Auxiliary</key> <false/> <key>Comment</key> <string>Not signed for security reasons</string> <key>Enabled</key> <true/> <key>Name</key> <string>Windows 10</string> <key>Path</key> <string>PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,15-AD-CD-26-28-B7-26-00)/HD(1,GPT,2E9695CB-0F9A-4005-AADB-2FF9C96AD02C,0x800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi</string> It points to the Windows 10 bootmanager on the Windows disk's EFI partition.
       
      What's wrong with that? Why does this cause a BSOD? It is not clear to me why it works when booting from BIOS but not here.
       
      config.plist attached (but maybe it has no relevance for the problem).
      config.plist
×