Jump to content
Andy Vandijck

Secure boot signing tools for OS X (sbsigntool-0.6-Clover_V3 with updates and Apple based libraries)

30 posts in this topic

Recommended Posts

I ported and updated the secure boot tools from Linux.

This means we have tools to make signature lists, sign the signature lists, sign EFI files, ...

I updated also most tools (for example the signature list signer in order to be able to sign multi-signature databases) to work optimal and properly in OS X.

Recently I updated the sources for libuuid (1.0.3) and openssl (1.0.1i) so that it builds against the latest versions.

I built 32 and 64 bit versions.

Also included is my bioskeydump tool to dump PK, KEK, DB and DBX files and also their signature if they are signed.

Everything is compiled to run very fast (-O3).

Source is included.

Built results and Clovers signing certificate are included under Build.

 

Enjoy :D

 

@Slice: You might want to include these in Clover to sign the EFI files in the CloverPackage dir, I also included a recursive script and this can be slightly adapted to run sbsign from another directory.

This cloversign.sh script can sign any file you feed to it directly (even multiple files).

 

EDIT: New version V3 for Yosemite built with Apple optimisations.

ZLIB 1.2.8 58 with apple extensions, libuuid-1.0.3 with Xcode build project, OpenSSL 1.0.1j 52 with apple extensions and GMP 6.0.0 are used as renewed libraries in the installer.

The uuid library now has an Xcode project and is built with full optimisations on same as the ZLIB and OpenSSL parts.

Package build script is included in the Makefile under src/pkg.

One make installer command in this folder will generate and installer package automatically but you would have to edit the Makefile for changing the installer package signing identity.

Installer package included with Apple dev cert signed binaries and package.

All works optimal and fast, build flags are -g0 -arch x86_64 -Ofast which means no debugging, 64-bit intel and fastest possible code.

Enjoy this enormously fast release. :D

 

EDIT2:

Added a github repo.

https://github.com/andyvand/sbsigntool_osx

sbsigntool-0.6-Clover_R2.zip

sbsigntool-0.6-R3-installer.zip

sbsigntool-0.6-Clover_R3.zip

Share this post


Link to post
Share on other sites
Advertisement

awesome, i have no words :-)


I have PK, KEK, DB and DBX, Dumped from my Laptop, how do i sign Clover? sbsign somehow doesn't work for me, but maybe im doing something wrong, so thats why i ask you for an example...

 

I can update my PK, KEK, DB, and DBX in the laptop too, directly in the bios from a file... if that helps...

Share this post


Link to post
Share on other sites

Awesome, Andy, thanks for this. So what do we gain from using secureboot with a signed Clover? Doesn't Clover's ability to boot multiple operating systems defeat the purpose of secureboot?

Share this post


Link to post
Share on other sites

awesome, i have no words :-)

I have PK, KEK, DB and DBX, Dumped from my Laptop, how do i sign Clover? sbsign somehow doesn't work for me, but maybe im doing something wrong, so thats why i ask you for an example...

 

I can update my PK, KEK, DB, and DBX in the laptop too, directly in the bios from a file... if that helps...

sbsign is used to sign .efi files.

You can sign them using:

sbsign --key /path/to/something.rsa --cert /path/to/something.pem --output new_efi_file.efi old_efi_file.efi.

 

For appending Clover's certificate's to your BIOS keys, look in the package.

I included my custom PK, KEK, DB and DBX files and also the Clover-key.rsa and Clover-cert.pem files you need to sign the binaries.

You can just use my bioskeydump tools to look at the contents.

sbsiglist can make a new entry file (.siglist) containing a certificate.

You can then just append that to your database by concatenating it in the database.

NOTE: The type of certificate needed to make a signature list need to be in .der format.

My KEK contains Clover's exchange certificate, my DB contains Clover's certificate (with what it is signed) and PK is a self-signed Clover platform key.

These you can update thus in the BIOS.

PK: No mods, just use mine

KEK: Append Clover exchange certificate

DB: Append Clover signing certificate

Then use your BIOS menu to install these keys, after signing Clover and boot.efi of Apple you should have secure boot...

NOTE2: In order to be able to edit boot.efi in /System/Library/CoreServices you need to first unlock it using Terminal...

sudo chflags nouchg /System/Library/CoreServices/boot.efi

Should do the trick nicely (if you look then in the Finder, the lock item will be gone...)

Have fun :D

Share this post


Link to post
Share on other sites

Where is the DBX File? :-)

Not included.

I have no modules to block...

DBX = Unauthorized Database and is used for preventing certain drivers (signed with the certs included in the DBX) from loading.

Share this post


Link to post
Share on other sites

New hyper optimized version for Yosemite (V3).

Majorly updated with latest Apple based updates and other optimisations... ;)

Share this post


Link to post
Share on other sites

Hi,

 

Thanks for these great tools, I have a few questions. I have my files dumped and can look at them with your bioskeydump tool. I have keytool image on a usb drive and can add certs to the various keys etc. I Just need to know how to proceed. Do I use my current dumped files as the base then add the clover-exchange cert to KEK(the canonical-isle of man cert from your KEK?) and clover-signing cert(from src?) to db, then at the end put the PK you provided in place to secure it? Do I have to do anything else to the keys like sign one with another etc? I then just sign all of the .efi binary files from my boot loader and the boot.efi from apple, as described above? You also mentioned that the boot.efi wouldn't verify and might need stripped? IF so how to do that? Or, should boot.efi still run as is once signed?

 

thanks.

 

 

Q

Share this post


Link to post
Share on other sites

I was able to use the sbsign tool provided here to get secure boot enabled on my Surface Pro 2. No More Red Screen!

 

First I had to download the software provided above as I have Mavericks installed I chose version 3, should also work for Yosemite. I just used the pre-built executables by moving them into my /usr/bin I made sure to have newer versions of openssl, etc. installed. Any how once I signed all my Binaries in my Clover folder and Boot Folder. And added Policy <string>Deny</string> and Secure <true/> to by boot section of config.plist, I still couldn't figure out how to make it work.

 

So I installed the latest version of shim-signed from my ubuntu VM.

 

sudo apt-get install shim-signed

 

I copied over shim-signd.efi to my EFI/Microsoft/Boot folder

and named it bootmgfw.efi

 

I already had a copy of Cloverx64.efi there so I re-named that first to grubx64.efi which is what shim looks for.

 

The original microsoft bootmgfw.efi I renamed to bootmgfw-orig.efi, I created a custom entry in my config.plist that points to it.

 

Surface Pro 2 is tricky as it doesn't come with the UEFI 3rdParty CA installed so I had to find this tool online and download it. It is a series of scripts and files that you can use in windows to upgrade and add the 3rd party DBs so that you can use the signed shim to chain-load Clover.

 

It usually needs mokmanager to install its certificates. But I found it easier to use a keytool.efi USB key that I was able to create from an easy to find image that is out there.(Google)

 

I converted the clover signing certificate to a format that shim could use using openssl

 

openssl -x509 -in /path-to-clover-sign.pem -inform PEM -out /path-to-converted-clover-cert.cer -outform DER

 

or something like that.

 

Keytool needs the file to be named .cer in order to use it even though it is DER format.

 

So the procedure to lock down the surface pro 2 once all the binaries are signed is:

 

-Clear all of the secure boot section by disableing secure boot.

 

-Open the long named UEFI script that installs the microsoft dbs with right-click>edit,

 then in powershell eliminate the final line that talks about the PK. save as OnlyDBs.ps1

 

-Close and open the same long ass file as above, this time eliminate everything except the final line about the PK, save as OnlyPK.ps1

 

-Then run the OnlyDBs script with a comand prompt as admin. It should run without any errors.

 

-Copy over all of the .cer files you can find in the sbsigntool package. to the usb keytool stick including the new one that you created above.

 There should be one called cannonical that is used to sign the KEK and DB, another one under /src called Clover-signed.der(Re-name it to .cer)

 

-shutdown and boot up into the usb keytool. Use the Edit keys>Add to find the .cer files you copied over. The main cert that you used to sign the binaries then converted is the one to add to Mok db. Add all of them, one at a time, to DB, adding is the same as appending. Then the Kek is only getting the Canonical one added.

 

-Then reboot up into windows and run the OnlyPK.ps1 script. using the Admin Cmd prompt.

 

-Reboot into UEFI bios and enable secure boot. Save>Re-boot.

 

Should see black screen. then Clover.

 

The reason we have to use Shim is cuz it's one of the few trusted loaders that Microsoft decided to sign. So by chain loading Clover with it we can eliminate the red screen. Which we wouldn't be able to do using a self signed key of our own.

Share this post


Link to post
Share on other sites

I was able to use the sbsign tool provided here to get secure boot enabled on my Surface Pro 2. No More Red Screen!

 

...

Awesome job, man! by chain loading Clover with Shim, it works in non secure boot at the moment for me. I signed Cloverx64.efi with sbsign and rename to grubx64.efi under the same folder of shim.efi, then enrolled the clover certificates using mokmanager. With secure boot on, it shows "binary is whitelisted" and does not load the secondary bootloader(clover in my case). You have any ideas?

 

Could you help me to about the long named UEFI script (OnlyDBs.ps1) you mention in the instruction please. I did not find it in any resources. I am also interested about what it does in windows's cmd.

Secondly, is it necessary to sign the boot.efi in /System/Library/CoreServices ?

Last, I am on a surface pro 3, it seems to come with the UEFI 3rdParty CA installed, does it mean I will only have to register the clover certificates using mokmanager (or keytool)?

Share this post


Link to post
Share on other sites

Richard,

 

Hello, the script I edited with powershell to install only the DBs is originally named InstallSecureBootWithMsftUefiCertAuthToDB.ps1, so a long name for sure. Yes it is a part of the special tool MS came up with for the Surface Pros 1 & 2. Since you use a Pro 3 you may not need to find the special Tool for UEFI CA, but I like the control it gives us for customization. Keytool only lets you update .cer files to the DB while in setup mode. If your built in UEFI bios lets you add in the DBs separate from the PK, then no problem, otherwise do as I did above and find the tool to add CA to the early Surface Pros. Edit it similar to me then you can use keytool, which I find easier to use. Keytool will only allow adding certs in setup mode which means the system will be in un-secure mode. Once PK is added it will not allow you to add in the .cers to the Db and KEK.

 

Mokmanager may let you add the .cers to MOK and try that as an alternative, you never know it may work for the DBs to have then there instead of in the MS DBs? Then you can lock down everything and see if you have Clover and Black screen.

 

Yes you need to sign the boot.efi with sbsign as the example towards the top of this thread. Also any boot.efi you might have in a recovery partition.

 

Also, sbsign everything .efi under /EFI/Clover and /EFI/Boot

 

as far as shim-signed, make sure it's from a recent version of Ubuntu or equiv. 64 bit version. I used the one from 14.04, I had trouble with an earlier shim I originally found on the internet.

 

The UEFI CA tool from MS also has a savepk.ps1 script which can be edited to save all current DBs and the PK. That is usefull once you have all the cool new certs added and you want to save everything in the combined .bins it creates from the new combined dbs. The original script only saves the current dbx and PK.

 

You can then create a new lockdown.ps1 script that is based on the newly created combined db.bins. When you download the UEFI tool look at the documentation that comes with it and the scripts themselves to determine how to edit them for this type of customization. The new lockdown.ps1 could then have the PK line added back into it once all the newly combined DBs and Kek are created. Greatly simplifying application in the future.

 

I have since updated my machine to Windows 10 and both the upgrade, and a further update overwrote my shim-signed(re-named to bootmgfw.efi) in /EFI/Microsoft/boot. So keep a copy of it handy to move back over to SYSTEM each time.

Share this post


Link to post
Share on other sites

I finally managed to secure boot CLOVER on surface pro 3, no more red screen. Thanks Andy for the amazing signing tool and Quattro for the detail instruction&help !!!

 

I boot directly from CLOVER, no shim.efi is required. (Specifically, chain loading with shim.efi dosen't work for me somehow, dunno why). And since sp3 already have the UEFI 3rdParty CA installed, one have to first delete all the platform key in order to start from scratch.

 

There are the steps I followed:

1. Use sbsigntool to sign all the necessary binary (*.efi) under /EFI/Clover (also /EFI/Boot/ if on a usb key), /System/Library/CoreServices/boot.efi, Recovery HD/com.apple.xx/boot.efi

2. Use Microsoft's OEM_PK_Surface to backup current dbs and PK.

3. go into bios and delete all the platform key.

4. back into window use modified Onlydbs.ps1 script to first append OEM db, KEK , dbx.

5. boot from keytool USB key and append all the cert files from sbsigntool into db and KEK. (one clover signing certificate convert from pem using openssl,  two *.der files under /src, and all the rest *.der is under /src/EFI_SECDB. change extension name from der to cer)

6. back into window use modified OnlyPK.ps1 script to add the finishing PK key.

7. use EasyUEFI to create a new entry pointing to /EFI/CLOVER/CLOVERX64.efi on SYSTEM partiotion, move it above Microsoft's boot entry. (This is a work around than renaming CLOVERX64.efi to bootmgfw.efi, so that future windows update will not break it)

8. reboot, voila! secure boot enabled and Clover is up.

9.(optional) as suggested by Quattro, in Windows backup the new KEK, db, dbx and PK using a modified SavePlatformKey.ps1 script.

Share this post


Link to post
Share on other sites

Hello. I have a surface pro 3 that i purchased from ebay. They never gave me the uefi password But I can install windows just fine. Should I be able to sign the clover bootloader and efi files to install osx and then boot off of the usb every time if I want to run osx? Many thanks.

Share this post


Link to post
Share on other sites

WM,

 

Your best bet is to follow the instructions on Surface Pro OSX, android and Windows triple boot thread to get OSX installed and working correctly, which means dis-ableing secure boot for now. When all of those other things are working to your satisfaction then come back here to lock it down.

 

EDIT: or in your case one of the Surface Pro 3 OSX threads ; )

Share this post


Link to post
Share on other sites

Thank you for your reply! But since i do not have the uefi password as stated in my first post.. I cannot disable secure boot :/ I can boot off usb.. (only in secure mode). I do not want a selectable system at boot.. only when i plug in the usb and boot from clover usb. so basically my osx partition will stay hidden or unused unless i plug in the propper usb. I have 7 100% running hackintosh systems so i will not have a problem installing once I get a clover usb to boot.. All i want to know is can i get an osx usb with the clover bootloader in the /efi partition to boot in secure mode. Thank you so much for your input.

Share this post


Link to post
Share on other sites

Hi again WM,

 

If you can boot now off of USB in secure mode it is a secure USB key right? Then maybe all you need is a way to get a secured clover on a USB stick? Sounds to me like you'd have to do this anyway just to create the proper OS X insall USB key. So yeah once that is created installing OS X is the easy part. You may need another computer to help troubleshoot the USB key creation.

Share this post


Link to post
Share on other sites

Correct. All I need is a secured clover on a usb stick. Since I have never created a "secure" version of clover for usb booting I gues that is where my problem lies. This secure business is where I am running into some confusion. I see where you daisy chained a few bootloaders to work on your surface pro.. but that was only to boot your system without any external drive right? I shouldn't have the same issues with a usb clover should I? Forgive my ignorance.. but I think all I have to do is run this tool on the clover efi files and I should be golden right? Or am I missing a big step(s)? Many thanks for your help and sorry for my lack of understanding in this. 

Share this post


Link to post
Share on other sites

Hi WM,

My experience is that even on a usb drive if a bootloader is not properly signed (or signed but uncertificates in the uefi), my surface pro 3 won't be able to boot it. it will show binary unauthorized error and boot the second entry which is Windows. While getting Clover to boot in secure mode not only require a signed .efi, but also adding the certificates you use into UEFI databases. The latter step absolutely requires an access to uefi. I don't think there is much you can do if you can not go into bios to disable the secure boot or remove all the platform key.

Installing OSX will not be any issue after you fix the bios, i.e either by getting the uefi password, or maybe there is a hidden OEM way to do a hard reset.

Share this post


Link to post
Share on other sites

I am actually able to boot ubuntu with a live usb (latest). I wonder if I daisy chain shim to clover if It will work Kinda like how quattro74 got his to work but just on the usb level. Does that make sense? Anyone else think I should go for it? I think I will try this weekend. Messy messy hack lol

Share this post


Link to post
Share on other sites

Wm,

 

You still have no way to access the uefi and install the certificates to your db? If not you won't be able to get to clover regardless where it is installed. That is your main issue. Get the certificates into the db and you can do what you want. Having a working Ubuntu means you can get a working shim-signed and get that to boot OK from where-ever but you can't get past it w/o the clover certs being added.

Share this post


Link to post
Share on other sites

Hi, can someone please post an example of how to sign and a list of certs in the sbsigntools as the V3 installer only works in 10.10 and the ubuntu way keeps saying file not found ..

   thanks!

Share this post


Link to post
Share on other sites

Have you tried copying the pre-built executables? Once I had the right programming env on my 10.9.2 install I was able to just run the sbsign tool after copying it and any .lib files it needs over to the /use/bin and /use/lib directories, respectively. If it is still giving you an error about 10.10 then maybe it won't work on your Mavericks version. Don't try to run the installer and compile your own. Much too hard. It might still fail due to needing some other .libs though. Good luck.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Slice
      Since rev 4844 Vector Themes are supported and there are ready-to-use Clovy by Clovy, cesium by Slice and BGM_SVG by Blackosx.
      You may see it's structure to create own theme
      -------------------------------------------------------------------------------------------------------------------------------------------------------
       
       
      Now I want to add vector graphics support in Clover. See rev 4560 and later.
      It is not working yet but designers may begin to create Vector Themes.
      It supposed to consist of SVG elements and has design size. It will be rendered to any screen size scaled from design size.
       
      What application in macOS can create SVG graphics?
      Inkscape is not working in macOS 10.11+. Pity.
      LibreOffice Draw works with SVG but buggy.
      Boxy SVG cost 10$ but looks good enough. It creates the best in simplicity files and have more then enough features.
      Illustrator is good but expensive.
       
      How to improve SVG file?
      Clover has restricted support for SVG. It is your job to make compatible file and as small as possible to speedup rendering.
      Some helps:
      Help:Inkscape – From invalid to valid SVG Inkscape files
      From invalid to valid SVG Adobe Illustrator files
      From invalid to valid SVG files of other editors: BKchem, ChemDraw and CorelDRAW
      Help:Illustrator – Assistance with creating and saving SVG images in Adobe Illustrator that will pass W3C validation
      User:Quibik/Cleaning up SVG files manually
      Later I will write own instructions specific to Clover abilities.
       
      How to create SVG fonts?
      You can google to find ready-to-use SVG fonts.  I found some problems with too beaty fonts: slow rendering and overflow crash. Be careful.
      You can get ttf or otf fonts and convert them into svg by using online WEB services. Not a problem to google.
      But then I want to find a way to simplify the font to reduce a size and speedup rendering.
      You can create own font by FontForge It is opensource and available for Windows, Mac and GNU+Linux. It creates otf font which you can convert to svg font.
       
      Pictures from Badruzeus
      https://www.insanelymac.com/forum/applications/core/interface/file/attachment.php?id=301597
    • By corbrink
      Hi,
      I have the following system:
      - Gigabyte Z370M-D3H M-ATX
      - Core i7-8700K Coffee Lake
      - Gigabyte Radeon RX 560 4GB
      - Crucial Ballistix 16GB DDR4
      - 960 EVO 1TB NVMe SSD
      - 850 EVO 500GB SSD
      - Crucial 500GB SSD
      - The 2 500GB SSD's run in Raid for data storage.
      - Western Digital 3TB HDD - Time machine
      - EFI here (too large to attach): EFI.zip

      Questions:
      1. I have a dual screen running from Radeon card, 1 on DP and 1 on HDMI. The one screen on DP goes randomly blank from time to time. Any ideas?
      2. I've read that the kexts should preferably be installed in /library/extensions. I would like to know what kexts should remain in the EFI. I read that you should install FakeSMC in both locations (EFI and L/E). If I follow this route must I change something in the config.plist?
      3. USB info in System Information (attached does not seem correct. I've followed the changes suggested but I'm not sure if this is the best it can be.
      4. Are there something in the EFI and config.plist I don't need or doing wrong?

      Feedback will be appreciated.


    • By ludufre
      [GUIA] Correção de assinatura BIOS Insyde H2O
       
      Recentemente comprei um notebook Lenovo L440 pra instalar o macOS Mojave e fui substituir a placa wireless pela DW1560 porque a atual não é compatível. Descobri que existia uma whitelist de placas permitidas que as fabricantes estão adotando recentemente (no meu caso utiliza uma bios Phoenix Insyde BIOS H2O).
       
      Procurei em fórums de BIOS MODDING e encontrei pessoas que fizeram o patch pra mim. Só que após substituir a BIOS notei que o computador ficava apitando 5 vezes todas vez que ligava e fui me aprofundar no caso. E foi aí que descobri como resolver isso e por isso criei esse guia baseado nas informações que achei em alguns fóruns russos.
       
       
      Prefácio
       
      Quando a BIOS falha no teste te integridade, algumas funcionalidades Intel AMT param de funcionar e é emitido uma sequência de 5 apitos duas vezes no boot.
      Após modificar para remover whitelist (habilitar placas WI-FI não autorizadas), destravar MSR 0xe2 (hackintosh), habilitar menu avançado, etc. a BIOS não vai passar no teste de integridade causando esse problema.
      Essa verificação de integridade é feita através da assinatura RSA do bloco da BIOS chamado TCPABIOS (mais informações abaixo) com a chave pública no formato modulus 3 também armazenada na BIOS.
      Esse bloco TCPABIOS armazena os checksums de cada volume da BIOS.
       
      O que faremos é gerar novos checkums para esses volumes que foram modificados, gerar um para de chaves RSA (privada e pública), assinar esse bloco com a chave privada e substituir a chave pública.
       
       
      Ferramentas necessárias
       
      - 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
       
      Passo a passo
       
      Vamos abrir a BIOS modificada, localizar o bloco TCPABIOS e entender sua anatomia.
       
      1. Abra a BIOS no HxD
       

      (Vamos utilizar nesse guia a BIOS modificada no fórum MyDigitalLife.com pelo usuário Serg008 para o notebook Lenovo B590)
       
      2. Busque a palavra TCPABIOS:
       


       
      3. O bloco começa com TCPABIOS e termina com antes de TCPACPUH
       

       
      4. Anatomia:
       
      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
       
      Cinza: Nome e informações do bloco
      Vermelho: Informações dos volumes (Checksum e Cabeçalho)
      Azul: Separação da lista de volumes para a assinatura do bloco
      Verde: Assinatura do bloco TCPABIOS são os últimos 128 bytes
       
      Lista de Volumes:
       
      Cada volume tem o formato: 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
                                                      (prefixo 3 bytes + checksum 20 bytes + offset 4 bytes + tamanho do volume 6 bytes + separador do fim 6 bytes)
       
      Os volumes são enumerados e utilizam o primeiro byte no prefixo para isso (00 FD 27), começando do 0.
      A BIOS utilizada nesse exemplo possui somente um volume, mas no caso de mais de um volume, seria: 00 FD 27 .., 01 FD 27 ..., 02 FD 27 ...
      - Checksum é o cálculo SHA1 do volume.
      - Offset é a posição do volume dentro da BIOS. Os bytes ficam invertidos, nesse caso seria 00 00 00 48 ou seja: 48h
      - Tamanho do volume também está com os bytes invertidos, então: 1F18CEh
       
      Então é isso. Precisamos corrigir essas informações (checksum, offset e tamanho)
       
      5. Para extrair os volumes abra a BIOS com o UEFITool e veja como identificar os volumes (nosso exemplo há somente um volume, se houvessem outros estariam também dentro de EfiFirmwareFileSystemGuid):
       

       
      Na BIOS original, circulado em vermelho podemos ver o nosso volume.
      Observe que em azul temos Offset e verde o tamanho. Exatamente como verificamos acima no HxD. Já na BIOS modificada vemos que está diferente o tamanho:
      Oridinal: 1F18CEh
      Modificada: 1F12D5h (vamos precisar disso mais tarde)
       
      6. Vamos extrair esse volume escolhendo a opção “Extract as is...”
       
       
       
      7. Utilize esse comando para obter o checkum desse volume: fciv.exe -sha1 File_Volume_image_FvMainCompact.ffs
       

       
      Agora temos o checksum que é 396e0dc987219b4369b1b9e010166302ce635202
       
      8. Substitua as informações no bloco TCPABIOS:
       

       
      Observe que o tamanho do volume precisa ter os bytes invertidos, então se o total são 6 bytes e é 1F12D5h, fica D5 12 1F 00 00 00 no lugar de CE 18 1F 00 00 00.
      Se o offset for diferente, também realizar o mesmo procedimento invertendo os bytes.
      Checksum alterar de 34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B 77 F9 82 58 para 39 6E 0D C9 87 21 9B 43 69 B1 B9 E0 10 16 63 02 CE 63 52 02
       
      Faça esse procedimento para cada volume na BIOS.
       
      9. Agora precisamos gerar o checksum de todo o bloco TCPABIOS mas sem considerar os últimos 131 bytes, ou seja desconsiderar de FF FF 83 + 80 bytes da assinatura anterior.
       
      Copie para um novo arquivo no HxD e salve como tcpabios
       

       
      Utilize o comando para gerar o checksum desse bloco: fciv.exe -sha1 tcpabios
       

       
      Checksum do bloco TCPABIOS: 0da6715509839a376b0a52e81fdf9683a8e70e52
       
      Crie um novo arquivo no HxD e adicione 108 bytes com 00 e cole o checksum no final e salve como tcpabios_sha, ficando assim:
       

       
      10. Agora vamos gerar a chave privada RSA com modulus 3: openssl genrsa -3 -out my_key.pem 1024
       

       
      Assinar o arquivo tcpabios_sha: openssl rsautl -inkey my_key.pem -sign -in tcpabios_hash -raw > tcpabios_sign
       

       
      Agora aproveite para gerar a chave publica: openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der
       

       
      E gerar modulus 3 da chave pública: openssl rsa -pubin -inform der -in my_key_pub.der -text -noout
       

       
      Copie e cole a chave em um arquivo de texto para utilizar daqui a pouco. Remova todos os “:” e coloque tudo em uma única linha, ficando assim:
       

       
      11.   Abra o arquivo tcpabios_sign no HxD, copie o conteúdo e substitua a assinatura no final do bloco TCPABIOS:
       
       
       
      12. Agora vamos localizar na BIOS o local da chave pública e substituir. Essa chave começa com 12 04 e termina com 01 03 FF e fica após o bloco TCPABBLK.
       
      A chave fica assim: 12 04 + 81 bytes + 01 03 FF. Faça uma busca por 01 03 FF para localizar mais facilmente. Verifique se antes dos 81 bytes tem os bytes 12 04 para ter certeza que achou.
       

       

       
      Agora substitua pela chave pública que ficou anotado no arquivo de texto anteriormente, ficando assim:
       

       
       
      Salve e está pronto. Sua BIOS está assinada e pronta.
       
    • By ludufre
      [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
       

      (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:
       


       
      3. The block starts with TCPABIOS and ends before TCPACPUH
       

       
      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):
       

       
      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 ..."
       
       
       
      7. Use this command to get the checksum of this volume: fciv.exe -sha1 File_Volume_image_FvMainCompact.ffs
       

       
      Now we have the checksum that is 396e0dc987219b4369b1b9e010166302ce635202
       
      8. Replace the information in the TCPABIOS block:
       

       
      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
       

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

       
      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:
       

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

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

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

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

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

       
      11.   Open the tcpabios_sign file in HxD, copy the contents and replace the signature at the end of the TCPABIOS block:
       
       
       
      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.
       

       

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

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