Jump to content

rEFInd feat. Ozmosis

12 posts in this topic

Recommended Posts

Hello everybody,

I’m using Ozmosis with a Gigabyte H81M-HD3 but unfortunately this board hasn’t enough space in it’s ROM to store the apfs.efi, too.
Than I have a second machine, my ZBox-Nano that not even has the space for the really necessary stuff.
Sure, Clover is able to solve all this problems but I want to go with Ozmosis :)

Here comes rEFInd into the game: http://www.rodsbooks.com/refind/
This boot loader could be installed into the ESP.
rEFInd is not only able to detect apfs formatted partitions but also to load uefi drivers!
And after some weeks of testing, I claim that rEFInd is doing his job very well.

rEFInd is open source so I take a look into it and found a good starting point to learn a little more about the UEFI. The result is a rEFInd version with some additions, that should make life easier and more colorful …. ;)

I’m using this „enhanced“ version in two different setup’s.

First the H81M, that comes with ozmosis, hfsplus, fakesmc and a patched dsdt inside the ROM.
Here rEFInd is only loading apfs.efi and scanning for macOS. The Oz directory on the ESP is not in use.

Second the ZBox. I only replaced the FileSystem driver with EnhancedFat and patched the ROM to unlock the MSR.
rEFInd is loading hfsplus, apfs and ozmosis and is scanning for macOS.
Ozmosis is loading dsdt, ssdt, kext and defaults from the Oz directory on the ESP.

If you like to test it: Installation is easy but do it at your own risk!
Unzip the download and open the directory in Finder.
It comes with rEFInd, ozmosis.efi, apfs.efi, hfsplus.efi and a Oz directory with mac mini defaults and fakesmc.kext.
Goto Efi/Oz and adapt it, to suit your needs.
Goto Efi/Boot/drivers_x64, if you have ozmosis or hfsplus installed into your ROM, delete it from the drivers directory because you don’t need to load it again.

If you are ready to go, mount your ESP and copy shellX64.efi and the Efi directory into the ESP root.
Btw.: This is a EDKII shell, that comes with some functions, which are needed by the nsh scripts I used for changing rEFInd’s configuration from the boot menu.

This is a round up of the changes I made, but after some more testing I will create a fork on GitHub.
Until then I can provide a patch against the current refind source, if someone is interested.

rEFInd 0.11.2-enhanced

Changes / Additions

A. Configuration

rEFInd is showing a message while scanning for devices.
To disable this message use:
hide_scan_msg 1

Boot Splash is an extra banner used only with timeout -1
This banner is splashing centered at the boot screen.
boot_splash banners/banner-black.png

Color Mode can be any combination from the following
1=icon_auto, 2=icon_value
4=font_auto, 8=font_value
16=menu_auto, 32=menu_value

color_mode 0 <- function is disabled (default)
color_mode 21 <- icons, text and selections are tinted automatic
background color from the banner
color_mode 85 <- icons, text and selections are tinted automatic
background color from value (for transparent banner)
color_mode 101 <- icons, text are tinted automatic
menu / selection color from value
background color from value (for transparent banner)

*_auto generates the color from the current background color
*_value enables the corresponding rgb(a)_color
rgba colors are in hex RED, GREEN, BLUE, ALPHA
rgb colors are in hex RED, GREEN, BLUE

rgba_color_icon f3,f3,f3,5e
rgba_color_menu d3,d3,d3,5e
rgba_color_font d3,d3,d3,5e
rgb_color_back 0c,6f,b8


Space between icons in pixel

# big-icons(0-256) small-icons(0-64) y-spacing(0-64)
icon_spacing 64 32 24 

B. Behaviour

The unmodified rEFInd is scanning all devices at start.
Then it loads the drivers if any detected and scans the devices again.
This is good for Mac's but we want to load the drivers for sure, so I change this a little.
Now rEFInd only scans for the ESP to know it's location.
Then it reads the config, load the drivers and start scanning devices.

Also this version is able to detect the 'macOS Install Data'.
This is necessary for installing and updating macOS on partitions formatted with apfs.

New embed banner, arrows and selections.
New embed font (Ubunutu-Mono 18pt and 28pt).
New os_icons from https://github.com/munlik/refind-theme-regular
New tool and function icons.
Visual changes for creating the boot entries.
Changed icon spacing
And some more ... :)


Update (14.12.07):

- adaptable icon spacing

- apfs.efi from macOS 10.13.2



Have Fun!



Share this post

Link to post
Share on other sites

Yes I now (see ozmosis thread), but I want a GUI because LibreElec is running Kodi on the ZBox, too. 

Than changing CSR from the GUI is also sweet and the boot entries are gone with every oz reset and every os update you have to do load the installer by hand and so on ...

With timeout set to -1 rEFInd needs a second or so to load apfs and detect the macOS. In short, I like it this way.

Share this post

Link to post
Share on other sites

​00:000 00:000 Ozmosis 1.03.167X-CPWN RELEASE (2015-12-24 09:12:07 VS2013x86) on 2017-12-09 06:52:59

Apfs.efi is from macOS 10.13.1 and I applied this patch http://www.insanelymac.com/forum/topic/327584-apfsefi-without-verbose-boot/page-4?do=findComment&comment=2530477

For testing I use VirtualBox with a 1GB Fat formatted disk image. Developing / compiling and can be done in a 10GB Lubuntu image and gnu-efi or edk2 from tianocore. I used edk2. 


I just recognized that one script is missing in the archive above :(

shell-mode.nsh from the tools folder.

This is called from most of the other nsh scripts for setting the shell mode if the script is executed

@echo -off
mode 128 40
so create tools/shell-mode.nsh by yourself or uncomment the line in the other scripts if you get an error message.

Maybe it is better this way because you can test which mode is supported with your setup and then adapt the script to fit best.


And I know it now ;)


Edit: Not much interest on this topic but anyway, I update the archive with the missing nsh script and a new oz defaults.plist (removed CpuType).


Some Tipps:

To create unique serials for your defaults.plist: https://github.com/al3xtjames/MacGen

A UUID for the HardwareSignature can be generated with 'uuidgen' from Terminal.app

Don't forget to change HardwareAddress to your MAC address!

Share this post

Link to post
Share on other sites
Thank you [mention=121674]STLVNUB[/mention].
I'll do a test using a USB stick.
My Laptop uses the 7-series.

So how did it go

Sent from my iPhone 5S using Tapatalk

Share this post

Link to post
Share on other sites
58 minutes ago, STLVNUB said:

So how did it go

I can't test now.


Because I'm using the Notebook for hard work, so test per hour it's not a good idea hehe

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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By glasgood

      PREREQUISITE: Two physical discs ( SSD’s or HDD’s )
      STEP 1 - Clover dual boot configuration 
      Open config.plist with Clover Configurator
       Legacy = PBR Timeout = True ( will remove the Timeout countdown, from Clover boot menu)  

      Scan / Custom
       Entries = True  Tool = True  Legacy = False ( removes extra Windows 10 entries )  
      Hide Volume
      - Preboot ( macOS Preboot )
      - Recovery ( macOS Recovery )

      So at boot you will have two options: boot macOS Mojave or Windows 10 
      STEP 2 - Using a drive without Windows 10 installed
      Disconnect system drive that contains your macOS Mojave install from computer ( This is so that Windows does not overwrite existing macOS Mojave boot loader )
      Proceed with a Windows 10 UEFI install.  
      After installation reconnect macOS Mojave Drive, the Windows installation should now be detected and usable in Clover. 
      If Windows 10 is not detected or able to boot,  then verify you installed Windows 10 as UEFI and not MBR ---->  ( Read step 2 - For a drive with Windows 10 installed )
      STEP 2 - Using a drive with Windows 10 already installed
      Verify your Windows install is  GPT / UEFI or MBR / Legacy BIOS.   
      If Windows install is GPT UEFI then Windows 10 install is ready to use at Clover boot menu, you should be able to boot into Windows directly from Clover boot screen. 

      But if  Windows drive is detected at Clover boot screen, but when booting Windows you get a black screen with a cursor on the top left,
      then this is most likely because Windows drive is MBR ( Legacy BIOS ).  You can easily convert MBR to GPT using  Windows MBR2GPT tool ( this saves hours work having to reinstall Windows 10 and setting up all your applications again  ) 
      If Windows 10 install is MBR / Legacy BIOS  then simply convert to GPT / UEFI  following instructions below ( read video summary and view video )
      ** To use Windows 10  MBR2GPT tool  you must have Windows 10 version 1703 ( creators update  ) or later and less than 3 partitions on 
      the Windows 10 drive **
      Video summary:
      Confirm Windows 10 drive is MBR Legacy BIOS ( in Windows Disk Management ) Reboot into Windows PE ( Advanced Startup ) Convert from MBR Legacy BIOS to GPT UEFI ( using commands below ) mbr2gpt /validate mbr2gpt /convert Restart Verify Windows 10 drive has changed to GPT UEFI ( in Windows Disk Management )  
      After conversion Windows 10 is ready to use at the Clover boot menu 
    • 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
    • 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.
      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.
      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.