Hm... What's the difference if the flasher can still decrypt the dump using the same key? Code: f:\->hewprsa.exe -d 0183AF25.BIN -o 0183AF25.BIN.DEC -s 0183AF25.BIN_RSA.SIG Processing... This might take a few seconds. Header: BIOS_OFFSET:20[14] BIOS_SIZE:5242880[500000] BIOS_SIGN_SIZE:256[100] Finding signature key... OpenSSL errors can be ignored. verify sha1sum with no key verify signature with key 0 5016:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is no t 01:.\crypto\rsa\rsa_pk1.c:100: 5016:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:.\c rypto\rsa\rsa_eay.c:721: 5016:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is no t 01:.\crypto\rsa\rsa_pk1.c:100: 5016:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:.\c rypto\rsa\rsa_eay.c:721: verify signature with key 1 Signature was signed with key: 1 f:\->hewprsa.exe -e 0183AF25.BIN.DEC -o 0183AF25.BIN.DEC.DOD -s 0183AF25.BIN_RSA .SIG Processing... This might take a few seconds. f:\->hewprsa.exe -t 0183AF25.BIN.DEC.DOD Processing... This might take a few seconds. Header: BIOS_OFFSET:12[c] BIOS_SIZE:5242880[500000] BIOS_SIGN_SIZE:256[100] Finding signature key... OpenSSL errors can be ignored. verify sha1sum with no key verify signature with key 0 4816:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is no t 01:.\crypto\rsa\rsa_pk1.c:100: 4816:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:.\c rypto\rsa\rsa_eay.c:721: 4816:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is no t 01:.\crypto\rsa\rsa_pk1.c:100: 4816:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:.\c rypto\rsa\rsa_eay.c:721: verify signature with key 1 Signature was signed with key: 1 +++ And I don't understand switch -s at all... Code: f:\->hewprsa.exe -e 0183AF25.BIN.DEC -o 0183AF25.BIN.DEC.DOD Processing... This might take a few seconds. f:\->hewprsa.exe -t 0183AF25.BIN.DEC.DOD Processing... This might take a few seconds. Header: BIOS_OFFSET:12[c] BIOS_SIZE:5242880[500000] BIOS_SIGN_SIZE:256[100] Finding signature key... OpenSSL errors can be ignored. verify sha1sum with no key Signature was signed with key: -1 +++ Ooops... When use -s key: 1 Without it key: -1
Edit? Yes, we do it many times. But signed only udpdate, and when it decrypted - You can do with it what You want. We are talk about how sign modifed dump for flash it by original flasher. I don't need it. I have hardware programmator, I'm working in service center P.S. Original hewprsa.exe can't decrypt update above we talk (and much more like this), so some time ago I make some patches to skip errors like Code: 5016:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is no t 01:.\crypto\rsa\rsa_pk1.c:100: and so on.
I have a hardware programmator too but i dont like to dissect a laptop for bios udpating, my gol was add ozmosis into laptop bios
Dump/modify/flash may work and may not, it depens on the state of Intel Boot Guard tech, which is used for Intel boards with ultra-mobile Core-i processors. If so called "measured boot" is enabled, unauthorized modifications will not be possible, but those cases are rare, so I recomend to try and see the result.
It's not possible to replace the whole module, because the program searches only in bodies of the sections, not in the headers, so right now you can't replace the whole FFS file or alter it's structure. But it will be implemented if you need it, it's easy to do so. Many patches in a single row is not a bad idea either, but what to do if one of them present and others not? Must the whole line be considered faulty or just patches that not present? Other options are possible of course, but I can't say I have much time to implement all possible options. If you need something particular - please tell me about it.
I have got this problem when I tried It, the patch is based on code (or hex value) pattern and the program search for these all and many times It happens that there are many of them and It try to patch all , so to avoid this issue and the program can do a wrong patch I have had to use longer pattern to individuate exclusively offset ! I think It will be perfect to add offset possibility too, so in this way It will be possible to use pattern (longer) and pointing offset to modify only these bytes ! e.g. a row with module GUID and offsetest_data Dobledots indicates offset on left and data to right (using multiples patches on same row) FE3542FE-C1D3-4EF8-657C-8048606FF670 082E:7400 0848:0F8400000000 09B4:9090 In the future I hope You will implement the Module Replace function e.g. a row with module GUID twice OR using R option 7E374E25-8E01-4FEE-87F2-390C23C606CD 7E374E25-8E01-4FEE-87F2-390C23C606CD so the Tool can search into root folder and if It find the module can replace It to the original one ! I think in this way We can organize the Bios Mod using your Patch.txt files for every Bios Version and save only these files with some Mod descriptions into comments fields : Actualy # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84D6000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 4839440A300F84D6000000488B1556D6 4839440A300F8400000000488B1556D6 # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84A2000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 4839440A300F84A2000000488B442470 4839440A300F8400000000488B442470 Next # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84D6000000 + 0F84A2000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 082E:0F8400000000 0842:0F8400000000 # SLIC Header | Slic 2.1 RSA key + Marker 2.1 | Acer TravelMate P255-MG | Module replace 7E374E25-8E01-4FEE-87F2-390C23C606CD 7E374E25-8E01-4FEE-87F2-390C23C606CD OR # SLIC Header | Slic 2.1 RSA key + Marker 2.1 | Acer TravelMate P255-MG | Module replace 7E374E25-8E01-4FEE-87F2-390C23C606CD R I hope in You my friend !!! Many thanks anyway Regards
ritzcarltn, it's not an UEFI image, but AMIBIOS8-based legacy BIOS, so it can't be opened by UEFITool.
Small mistake - its not AMI Core 8 bios; its Phoenix-Award. Gigabyte never used legacy AMI Core 8 bios in their consumer class mobos.