thinkpad-ec
thinkpad-ec copied to clipboard
hamishcoleman
Whitelist
Can this project be expanded to whitelist cards, or even unlock overclock? I can provide the changes needed on the FL1 file.
That sounds useful! It's flexible enough that we could probably add that in, yes.
Nothing in the current build touches the FL1 files, so I think it would end up being a second build output.
Do you have a sample set of FL1 changes? I could look and see if anything suggests itself
As much as I would like you guys to succeed, I'm rather sceptical. I have no experience with unlocking overclocking, but i did remove whitelist from my t430 and t430s and there are few things that in my opinion make automation of this task non-trivial.
The point is to modify few JMPs from single bios module. Simple hex find&replace won't work here, as instruction opcodes differ between the bios versions. But even considering that we could sort this out with some heuristics, resulting module must be repacked back into some propertiary bios format. I don't know any details on this, as i've used this windows tool that did the job for me. I don't know if there are any linux equivalents. You can read more about the procedure here
Another problem is that series xx30 and up "introduced new Intel security features that make it impossible to flash the [unsigned] BIOS using software". So users will end up with FL1 file that fails flashing.
The bios update FL1 file is in a UEFI capsule format, the difficulty in patching it is usually because it needs to be signed (which can be side-stepped if you use a hardware programmer - that is what a lot of people seem to suggest). So at least, there is some hope of automating it - just the signing that is difficult.
If there is a process for creating valid patches, then the repo could just store a different patch for each BIOS version - the moving instructions and limits on find&replace all apply to the EC firmware too, and just keeping a patch set for each version has worked there. Event if we cannot create signed updates, it might be useful to provide a resource for people to create binaries to use with a hardware programmer.
Thanks for the links - I'll have a look at them when I next get a chance.
The UEFIPatch can already change the bios. The thing is UEFIPatch it's a generic tool to change a bit for Hackintosh Power management. I didn't get into the code to understand how it does it, but since the EC is already "unlocked" maybe it isn't so far fetch to try change the bios. I found a russian blog with some modifications explained https://habrahabr.ru/post/211879/ This one https://habrahabr.ru/post/182676/ explain how to get the full unencrypted bios without a programmer. The procedure now is like this: -Read the chip. -Use the UEFITool to extrat the body of the sections we want to modify -Patch the bodies. -Replace the bodies with the patched ones in the UEFITools -And write the moded dump to the chip. UEFITools simply compress the sections and checksum everything. Neat'n easy!
Unfortunately, the BIOS and the EC use completely different "locking" systems. So our success with the EC does not help with modding the BIOS - and I am fairly sure that there is some signature that needs to be correctly added to the BIOS to allow it to be uploaded without an external programmer.
Also problematic is that the UEFITool is a GUI interface that is not automatable.
However, if you had patches that apply to the UEFI sections, there might be a way to add and automate some or all of this.
The only way to really mod the bios on some of the Thinkpads seems to be actually disassembling the Notebook and hooking the chip up to an external flasher. (Which in some cases isn't really possible without a hot air station and desoldering the chip). Which is quite a shame.
@rad4day you are right - but we could still start collecting repository of known patches to help with building a new flash image once you have downloaded (and backed up) your current image.
well i have a w530 and on the schematics i found a solder pad (CN100) on the motherboard with spi and jtag connections. There is no necessity to fully disassembly the laptop anymore, now we only need to remove the palmrest to solder cables and leave them hidden bellow the keyboard. It is possible that other laptops with "hidden" bios chips have this kind of shortcuts. Do you want me to create a list of laptops with easier places to connect a programmer? it is possible to remove the bios write protection, so even we don't find the signature key now we only need to use a programmer one time:
BIOS lock removal What : removal of protection from the firmware of modified UEFI images by the built-in programmer. Why : with a large number of experiments with UEFI get every time the programmer quickly gets bored, and firmware is faster (using QuadSPI protocol instead of the usual SPI in the case of an external programmer). Where to search : in chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect) Modification method : the modification version of PchInitDxe is fully described here in English, so I'll just give an idea. It is necessary to find the BIOS Lock Enable (BLE) bit entry in the BIOS_CNTL register of the chipset and prevent it. You can do this in several places, for example, here: 48 8B 4C 24 40 mov rcx, qword ptr [rsp + 40h]; Load the RCX address of the PchPlatformData structure 48 8B 41 50 mov rax, qword ptr [rcx + 50h]; And in RAX, the address of the child structure of LockdownConfig F6 00 10 test byte ptr [rax], 10h; Check if the fifth bit is set (BiosLock) 74 25 je 0000000180001452; If not installed, jump over the entire code below 8A 50 01 mov dl, byte ptr [rax + 1] B9 B2 00 00 00 mov ecx, 0B2h; E8 A2 5A 00 00 call 0000000180006EDC 4C 8D 87 DC 00 00 00 lea r8, [rdi + 000000DCh]; In RDI, the base address of the LPC chipsets is the base address, and 0xDC is the BIOS_CNTL 33 C9 xor ecx, ecx 4C 8B CD mov r9, rbp 33 D2 xor edx, edx 4C 89 44 24 20 mov qword ptr [rsp + 20h], r8 E8 AA 76 00 00 call 0000000180008AFC; Install the lock You can change JE to JMP, but sometimes, instead of a short jump, you get a long one that has to calculate the offset in addition, so it's better to change the test to any command that sets the ZF flag, for example to xor rax, rax (48 31 C0), and the possible size difference correct commands by adding NOPs. If you did not find the desired code in PchInitDxe, you can change the BiosWriteProtect driver so that you can bypass the registration of the SMI handler located in it, which sets the BLE bit when trying to reset it, and then it is enough to reset this bit to unlock the firmware. I have worked perfectly the above method, so I have not tried this option yet, and therefore I will not describe it in detail.
https://drive.google.com/drive/folders/1C-60q2ndgsqU4J1NZqyiwrCvRM4vNDKL?usp=sharing
Ok it's possible to show the hidden advance tab without rewriting the bios, but its necessary write access to nvram(it's unlock on thinkpads?): https://github.com/bobafetthotmail/insydeH20-advanced-settings-tools
this is the patch file(UEFIPatch) to implement the wifi whitlist, advance tab, cpu multiplier and hackintosh power. patches.txt
This one change the Date Tab with the Advance Tab #SystemFormBrowserCoreDxe | W530
32442D09-1D11-4E27-8AAB-90FE6ACB0489 10 P:04320b483cc2e14abb16a73fadda475f:778b1d826d24964e8e103467d56ab1ba
ok for cpu multiplier management: F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:30488b4338f6000874080fba6c243014:30488b4338f60008eb080fba6c243014
Hackintosh Power management: F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:44243080fb0175080fbae80f89442430:44243080fb01eb080fbae80f89442430
@edmalho do you mean write protection = secure flash?
Secure flash can only be defeated by hardwarely flashing your modified bios.
if you first hardware flash a modded bios with the write protection bypassed the next flash will be allowed and subsequently until you flash a official one again.
@rad4day do you have the bios with write protection disable? can you send me the dump?
@edmalho well I replaced mine with coreboot. But I'm probably able to remove the write protection from the original image. I'll take a look at it in the next days
@edmalho I finally looked over my files. It's pretty easy actually. You have to dump your bios and just use ifdtool to unlock it. The only change which occures on the binary is the following:
$ diff <(xxd T430s.rom) <(xxd T430s.rom.new)
7c7
< 00000060: 0000 0b0a 0000 0d0c 1801 0808 ffff ffff ................
---
> 00000060: 0000 ffff 0000 ffff 1801 0808 ffff ffff ................
As I don't want to post the images publicly (as I'm not sure on the license on those) It would be kind to let me know your Email ;)
https://forum.ixbt.com/topic.cgi?id=17:53248-29
@tiahoj.tar.gz
https://github.com/ValdikSS/thinkpad-shahash
this one found a way to change the Lenovo public key with a personal one
--ONLY FOR x220--
to create the keys run:
openssl genrsa -3 -out my_key.pem 1024
openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der
openssl rsa -pubin -inform der -in my_key_pub.der -text -noout
and then copy (in hex) the modulos part output by lhe last command to a file called my_key_pub
run
./gethashes.py --output recomputed_fw.FL1 modified_fw.FL1
@edmalho Is Lenovo's public key normally used to also verify official UEFI BIOS capsule updates that flash on restart?
If it is then it may be useful to be able to sign our own FL1 and use the official mechanism to update bios (after replacing with our own public key of course)
@JCBuck, ValdikSS discover the way that TPM verifies the bios at startup. so if you mod a bios the TPM validation fails and at startup the laptop beeps in 2 blocks of 5. so if you need the TPM and don't want the annoyance, you have to change the signatures. i don't know what methods they use to verify updates but if it is something like the TPM it would be perfect. Simply change the public key on the firmware and and voyla security and convenience
So the script don't work for me, the bios structure change...
Since ValdikSS didn't explain it very well, i made this howto:
with a hex editor open the bios file and search for TCPABIOS
In TCPABIOS we find a list of sha1 hashs of every file inside the 1st(?) volume called EfiFirmwareFileSystemGuid(and with a GUID 7A9354D9-0468-444A-81CE-0BF617D890DF).
In my case i have only one, FvMainCompact:
after IBMSECUR the entries starts in hex like this: 00 FD 27 (20 Bytes hash) (16 bytes header), 01 FD 27 (20 Bytes hash) (16 bytes header), 03 FD 27 (20 Bytes hash) (16 bytes header)... and so on.
the first byte increases by 1 for every hash/file
FD identifies the type file?
27 identifies the start of the hash
The header:
the 1st 4 bytes is the offset of the file (the bytes order is inverted)
after that is the size of the file, 6 bytes (also inverted)
them comes 03 00 00 00 00 00 (I didn't found what this is...)
The list terminates with 00 00 27 and 36 bytes of 00's
After all the mods, correct the hashs, sizes and offsets of the files that were changed
sha1sum file.efi.ffs
Copy the TCPABIOS block(with all the hashs and continuos 00's) to the file mod_TCPABIOS
Calculate mod_TCPABIOS hash:
sha1sum mod_TCPABIOS
Copy the hash to the file mod_TCPABIOS_hash, like this:
Run:
openssl genrsa -3 -out my_key.pem 1024
openssl rsautl -inkey my_key.pem -sign -in mod_TCPABIOS_hash -raw > mod_signature
Replace the lenovo signature with the custom mod_signature(located between FF FF 83 and TCPACPUH)
openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der
openssl rsa -pubin -inform der -in my_key_pub.der -text -noout
Search FF 12 04 replace the lenovo modulus with the custom. (modulus starts with 00)
i'm trying to find the verification part of the firmware update. what and how it does it, really. I'm posting the flash updater to any interested to help Section_PE32_image_C8AB0F4E_26FE_40F1_9579_EA8D30D503A4_SystemFlashUpdateDriverDxe.efi_body.efi.tar.gz
This thread (https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-W520-BIOS-1-42-whitelist-removal-8BUJ21UC) has quite a bit of information on the various patches. @edmalho already mentioned a few of these. From the remaining ones, these seem to be of interest:
-
BIOS lock removal (EFI IFR too can be modified to get same result)
-
Disable SMI Lock and BIOS Lock (CodeRush AMI Bios Developer)
-
Unlock Firmware Regions (CodeRush Unlock Descriptor, ME, Bios)
Note, all of these still require a hardware programmer, but I think once you flash a modified version, future updates shouldn't require a hardware programmer. It should also be possible to switch back and forth from coreboot and patched BIOS without hardware programmer ? @edmalho, are you able to test these and incorporate them in your patch list ?
@pgera It should also be possible to switch back and forth from coreboot and patched BIOS without hardware programmer ?
It is. As coreboot doesn't set the lock bits for the bios chip regions. You can use flashrom with the "internal" programmer to just overwrite your bios chip while using the laptop. After flashing the original bios, the lock bits will be set again. (unless you modify the image to not be locked)
@rad4day , based on your earlier post that mentions the change from 0b0a to ffff, that seems like the method to unlock protected regions including ME. That is also mentioned in the thread. The other patch in that thread mentions this: "After both modifications BIOSWE=1 and SMM_BWP=0 in BIOS_CNTL register, that allows flashrom to work normally." So, I think both these patches would be needed in the OEM bios if you want to unlock the SPI chip entirely, including the protected regions. This should allow flashing coreboot and me_cleaner with the internal programmer.
As for flashing without SPI programmer, there were some SMM vulns which were patched sometime in 2016. If your BIOS version is older than that, it SHOULD be possible to set the bios control bits. In fact, even with the latest OEM bios, chipsec reports the boot scripts for s3 resume to be unprotected. I tried some of examples in chipsec's tools.uefi.s3script_modify. They don't seem to work, but perhaps someone who knows more can make it work.