After some research I found some interesting results of bios verification process.
At early stage of research I have found 11 256 bytes keys, and soon will figure out how they are responsible to volumes included in bios rom.
I did post a lot of info at my techpowerup thread about modding WX4150 and WX4170 vbioses.
So will share all new ideas here!
The goal of this project is simple: inject new GOP in bios, modify EC firmware to solve problems with GPU fan.
As that is long process but after few months of research I have good feeling.
Any ideas support is welcome!
1 Like
Some new data.
Padding the beggin___RSA-shorted___.zip (51.8 KB)
Padding with EC FIRMWARE.zip|attachment (3.76 MB)
Padding with RSA-shorted.zip|attachment (59.6 KB)
Okay. I have done few tests to figure out what would be IF
1. Update of cpu microcode = microcode execution is disabled. Recovery process start on power off.
2. Boot without EC recovery spi = successful
3. Replacement of nvram volume = successful boot
4. ME region patch = successful boot.
Anyway SureStart is fully EC software. So it could be executed on internal arm cpu
What is good? Arm architecture is one that can be easy identify. The bios contain at least 6 arm subprograms. Some of that programs have low level decrypt algorithms. We know that EC firmware is protected by rsa 256 bytes signature. So that’s where we should begin. That is the beginning of recovery in case of failure.
The next sequence of IF:
1. Patch one byte of EC firmware and see what happens.
2. The firmware possibly shrieked and doesn’t contain bootloader,
So bootloader isn’t protected, but it must have helper subprogram who can confirm that bootloader is healthy. If those two programs are successfully boot, then third one should start to encrypt the rsa utility and load it to ram!!! If that app isn’t unloaded from ram after boot process, we can get it from it.
And I am sure that this type of security is chain sequence of operations, but it running on arm.
Also need more research of arm core present there
@bigguygeo
Hello. I noticed your recent activity, so I think you will be interested. I know nothing about RSA, but I want to help and believe that RSA check modules have the GUID: 9780ADF1-7950-4E7D-B2C6-C5A0361B5C51. A 256 byte key is 100 characters long in decimal. This value is transferred somewhere at the entry point of this module.
Hi! That’s possibly program that checking bios update. But the problem is that all volumes are locked for modding by rsa signed signature. But what is could be useful is offsets from entire bios. Anyway someone should read that data. I think that is made by encrypted program image. As updates of that image are only affected on few bytes, there is a hope that this program is not compressed.
I will try to replace few subprograms from different updates to see how they are protected.
I think that that encrypted program is using some sort of noise encryption, as bytes of strange characters are always in one place. I will try to make some data analysis that can clean unmodified bytes and reveal some sort of algorithm.
Anyway that signature verification is made by Nuoton Embedded controller, but it has no documentation. If we would know a arm core, we could use libraries of that architecture to safe decompile it and see what is there
I got your opinion. But don’t you think the following of your convictions sounds like an excuse?
Oh, if we just would know… (this may never happen).
No offense, but I have reasons to say otherwise:
1. Previous types of protection from different HP UEFI BIOS were always in PEI vol. and its copies;
2. Their modules were very close to padding with keys;
3. They had only single occurrences of text strings containing "public" or smth.
Hi! Comparing bootloader subprograms for different cpu I have found some interesting fragments of SureStart code.
Hp knows that and that’s why they deleted all non rsa updates.
If we will get non rsa hp bios and rsa, we can beat rsa protection
At 2015 they implement SureStart to all bios updates
after comparing of EC firmware, found that few of them are running by SMSC EC controllers. And those are:
ARM ® Cortex®-M4 Processor Core
- 32-Bit ARM v7-M Instruction Set Architecture
Also a few used by HP Nuoton EC are ARM M4 too, so i think if we can find EC M4 bootloader and non RSA firmware, we can bypass security check!
Also have good news of confirm that Zbook G2 15 is using SMSC MEC1322 controller. And i think it would be easier to find same EC firmware from other laptop.
Adding more: after comparing of EC firmwares of different HP laptops, confirm that every laptop has same security structure. So i think HP using some software for building bios update image. Also EC seems to be universal (only partial differences). So that is confirms that all of them are running by Cortex-M4.
Reporting: successfully replaced encrypted subprogram. Result: able to boot OS, no POST errors
Reporting: replacement of EC firmware success. System boot without POST errors. That’s a proof that Embedded controller is the what is need to be patched!
I think that encrypted part of padding is nothing more than bootloader of arm. I was watching some videos of reverse engineering cortex m cpus and structure is looking same. The radar2 the only tool that can read addresses of the bootloader.
If we could capture traffic for spi while the system powering on, we could get more answers
Also cortex contains algorithms for rsa checksum calculations.
As internal ram of cortex is small, then cortex will made security check step by step
Unfortunately I don’t have any idea regarding this topic.
with this I can set the vram of my igpu at 512mb in my 2072la f.2.a bios insyde?
According to your theory, this is a broader topic than I imagined. So, I’m confused.
@sagael
BIOS of ZBook’s and the BIOS of your Pavilion g4 are completely different. ZBook’s are equipped with AMI. Besides, a solution to the RSA problem for your BIOS has already been found.
@Sweet_Kitten didn’t know, do you have a link for more information? I am interested in limiting the vram of the igpu
Okay, I get partial success: we have 10 rsa 256 bytes keys.
The theory:
1 key is protected the EC firmware. And is checking by bootloader sub program: if this one is fine, then firmware will be loaded.
5-6 keys protected volumes and checking made by firmware, if they are okay, then the EC will start system.
The next keys are validated by cpu, and concept is next: all previous keys are protected by the other keys. If all sequence is okay, then system will POST and continue boot.
What I have done?
The theory is based on: I took a volume from update and copy the rsa and volume to bios dump. The result was better then previous: the cpu voltages rises and usb voltages too.
In few days I will receive logic analyzer and will capture spi read sequence to EC, then capture the chipset read sequence from EC.
I want to confirm that bios chip transfer data to chipset through EC (Embedded controller).
Almost forgot to added: the firmware rsa is not protected by other keys: I have replaced firmware from different updates
And firmware doesn’t read spi labeled EC on logic board, the firmware only check if this one present there
Early mapping of spi signals. (incorrect)
Will look for boardview of hp SureStart logic boards. Interesting how spi is connected to other ICs.
adding board view of laptop with similar EC controller
DA0X81MB6E0 Board view and Schematic.zip (1.68 MB)
Today I received a spi logic analyzer and planing to do capture sequence next week.
Example tutorial:
https://youtu.be/EXcSlo9EDTU
Also BIOS ROM contain TPM firmware and connected to that IC.
https://arstechnica.com/gadgets/2021/08/…-in-30-minutes/
https://www.youtube.com/watch?v=NFQ22SBlejk