Whitelist

[edmalho]

Can this project be expanded to whitelist cards, or even unlock overclock?
I can provide the changes needed on the FL1 file.

[hamishcoleman]

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

[m-kozlowski]

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.

[hamishcoleman]

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.

[edmalho]

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!

[hamishcoleman]

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.

[rad4day]

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.

[hamishcoleman]

@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.

[edmalho]

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.

[edmalho]

https://drive.google.com/drive/folders/1C-60q2ndgsqU4J1NZqyiwrCvRM4vNDKL?usp=sharing

[edmalho]

some intel me info:
www . mediafire . com/?iwscmnadf5icnxq

[edmalho]

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

[edmalho]

this is the patch file(UEFIPatch) to implement the wifi whitlist, advance tab, cpu multiplier and hackintosh power.
patches.txt

[edmalho]

This one change the Date Tab with the Advance Tab
#SystemFormBrowserCoreDxe | W530

32442D09-1D11-4E27-8AAB-90FE6ACB0489 10 P:04320b483cc2e14abb16a73fadda475f:778b1d826d24964e8e103467d56ab1ba

[edmalho]

ok for cpu multiplier management:
F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:30488b4338f6000874080fba6c243014:30488b4338f60008eb080fba6c243014

[edmalho]

Hackintosh Power management:
F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:44243080fb0175080fbae80f89442430:44243080fb01eb080fbae80f89442430

[edmalho]

the only thing i don't know is how to kill the write protection

[patrickhgb]

@edmalho do you mean write protection = secure flash?

Secure flash can only be defeated by hardwarely flashing your modified bios.

[edmalho]

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]

I can confirm this behaviour on the T430s.

[edmalho]

@rad4day do you have the bios with write protection disable? can you send me the dump?

[rad4day]

@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

[rad4day]

@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 ;)

[edmalho]

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

[JCBuck]

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

[edmalho]

@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

[edmalho]

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)

[edmalho]

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

[pgera]

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 ?

[rad4day]

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

[JCBuck]

@rad4day Yeah, I do have hardware to manually flash need be. @pgera yes that can work too, i think in my case i wasn't able to find an operation that was setting the flockdn register in the boot script, but I'd have to check again i may have just missed it since i too had to set the pr0-pr4 early in the script.

…

On Sat, Sep 1, 2018, 9:15 AM pgera ***@***.***> wrote: I was able to unlock the protected regions too. There is a separate flockdn register that needs to be reset early in the boot script. This was the command for that: sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6008,0x2 Once you do this, you can reset the protection registers from the OS. You don't need s3 boot scripts for that. I haven't tried flashing anything yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGna9lFOQ0jCDHXqi85ULKyHnoFKPn0ks5uWrKTgaJpZM4SssSR> .

[pgera]

@JCBuck , how do you move to a later bios in this mechanism ? Once the registers are unlocked, you can flash the modified version of the same bios (or even a newer one?) with fptw64, but that is just the bios region. How do you get to a newer fd region ? When you update from the regular update utility, that updates the fd regions too, right ? Also, what is the difference between the fl1 and fl2 files. When I downgraded, I ran winflash64 with the fl1 file. When does the fl2 file come into play ?

Edit: So the flash descriptor region itself is probably not updated between even full bios updates, but I'm guessing that the ME region is. My current flashrom output is
FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Management Engine region (0x00003000-0x004fffff) is locked.
I'm guessing that the first one can be ignored, but we need to figure out how to get to the latest BIOS+ME with software only.

[JCBuck]

Right, I believe you cannot actually configure the FD since they're read from the SPI flash itself, which means I think you have to use a hardware programmer. There is another mechanism used for OEM manufacturers that if you short a specific pin on the southbridge? or SPI flash chip? it will unlock all of the FD for that boot.

FL2 is the EC firmware, FL1 is UEFI bios i believe with some header information iirc

[pgera]

So we cannot get to the latest patched bios using this method ? I get that unlocking the FD would need a programmer, but if you just want to apply the bios patches and leave the rest as is at the latest versions, is that doable ? The BIOS_CNTL can already be unlocked. If we patch flockdn in the bios too, would that allow us to use the vendor utilities to flash a patched FL1 file ? If that brings the rest of the stack up to the latest versions, that should be good enough

[JCBuck]

I'm not sure what you mean by latest versions, (of which?) what do you mean by vendor utilities? (lenovos' default winflash package?) Yes you can certainly patch latest bios versions from Lenovo to prevent them from toggling BIOS_CNTL and SMM_BWP, FLOCKDN etc

there's a separate EFI program that is used to flash a new bios in a capsule after a restart that is loaded by winflash and I believe it verifies if it has a valid signature

[pgera]

@JCBuck I don't know if the ME/GBE/FD regions are updated when you update the BIOS using the regular lenovo's winflash. Are those things a part of the FL1 file ? Essentially, we can only update the BIOS region using fptw/flashrom. When we do a rollback, is it also rolling back other regions ? The end goal is to have latest patched BIOS + latest ME/GBe/FD.

[JCBuck]

No, I don't believe lenovo update those regions with their bios updates. Generally ME/GBE don't get updated, and a separate tool from Intel is used for those. I think even then, they cannot be updated if the FD is configured to lock them down. I believe users who wanted to update those regions, for the purpose of say, getting a newer generation of Intel processors working on an older chipset or something, it needed to be hardware flashed from what I read.

some more info here:
https://www.win-raid.com/t3553f39-Guide-Unlock-Intel-Flash-Descriptor-Read-Write-Access-Permissions-for-SPI-Servicing.html
edit: it seems depending on the OEM/ODM it is possible (E3 E4 E5 E6)

[pgera]

Ok. In that case, I believe this method is good enough for updating or rolling back the BIOS region, and patching it as desired. For those who want to use the chipsec method, here's the summary of all the commands:

# Tested on W530 with BIOS g5uj21us. 
# You can rollback to older BIOS with winflash64.exe /sd /file <path_to_.fl_file> after disabling rollback protection in the bios settings

# BIOS_CNTL
sudo chipsec_main -m tools.uefi.s3script_modify -a add_op,pci_wr,0x1f00dc,0x9,1

# FLOCKDN
sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6008,0x2

# S3 suspend after this. Can be done with systemctl suspend

# After resume:
sudo chipsec_util mmio write SPIBAR 0x74 0x4 0xAAF0800
sudo chipsec_util mmio write SPIBAR 0x78 0x4 0xADE0AD0
sudo chipsec_util mmio write SPIBAR 0x7C 0x4 0xB100B10
sudo chipsec_util mmio write SPIBAR 0x80 0x4 0xBFF0B40

# Test with this:
sudo chipsec_main -m common.bios_wp
# Expected output:
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x09 << BIOS Control (b:d.f 00:31.0 + 0xDC)
    [00] BIOSWE           = 1 << BIOS Write Enable 
    [01] BLE              = 0 << BIOS Lock Enable 
    [02] SRC              = 2 << SPI Read Configuration 
    [04] TSS              = 0 << Top Swap Status 
    [05] SMM_BWP          = 0 << SMM BIOS Write Protection 
[-] BIOS region write protection is disabled!

[*] BIOS Region: Base = 0x00500000, Limit = 0x00BFFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (74)     | 0AAF0800 | 00800000 | 00AAF000 | 0   | 0 
PR1 (78)     | 0ADE0AD0 | 00AD0000 | 00ADE000 | 0   | 0 
PR2 (7C)     | 0B100B10 | 00B10000 | 00B10000 | 0   | 0 
PR3 (80)     | 0BFF0B40 | 00B40000 | 00BFF000 | 0   | 0 
PR4 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0 

[!] None of the SPI protected ranges write-protect BIOS region

I'll wait for a programmer before more experiments. I think most of the problems are solved in principle. The main thing left is self-signing.

[JCBuck]

Yup, after this I use fptw64 to dump the current uefi bios, then apply patches (such as turbo bin overclocking, bios protect, advanced menu) using uefitool and uefipatch and can reflash it with fptw64 then restart (but really any utility that can do spi flashing could work)

[pgera]

But fptw64/flashrom work with raw dumps. So everytime you want to upgrade, it has the additional step of first flashing the latest version and reading back the dump. Then you go back to old version and flash the patched dump. Is it possible to extract the relevant region from FL1 file, patching it, and flashing that with fptw64 ? That would also simplify maintaining and validating patches against FL1 files.

Edit: You mentioned bios_protect. Are you patching FLOCKDN ? If you don't patch that, but only patch BIOS_CNTL, does it allow you to flash ?

[JCBuck]

@pgera
yes i believe you can extract the bios out of the FL1 file from what i read. I think somebody has just cut the part out and worked as the FL1 is the same with some header information prepended. Uefitool can read both raw dump and the FL1 i believe, but i'm no expert i'd have to do some more research.
No, you must be able to prevent FLOCKDN from being set or else the protected range registers cannot be cleared and fptw64 will complain

[pgera]

I wasn't able to find where FLOCKDN is set in the bios. If someone has time to look, it would be helpful for internal switching between coreboot and lenovo bios (i.e. bios -> coreboot. Other way round is fine). Again, this is for development purposes. Not recommended to leave everything unlocked otherwise. The bios_cntl location in File_DXE_driver_2EE81ACB-64B2-41AE-8635-7030D16C4AA8_PchBiosWriteProtect.efi_body is known, but that alone won't be sufficient without FLOCKDN. I tried looking for immediate value 0x4 in same file since FLOCKDN is SPIBAR + 0x4, but I'm not sure if it's set there.

[pgera]

It was taking too long for the programmer to arrive. So I decided to flash it internally with fptw64. Everything went as expected. @edmalho 's instructions for fixing the TPM hashes were very helpful. The advanced bios menu also has an option to disable the ME. This seems to be a temporary disable mode, which is not exactly the same as the HAP/soft-disable mode. Here's the output from intelmetool:

MEI found: [8086:1e3a] 7 Series/C216 Chipset Family MEI Controller #1

ME Status   : 0x1e030185
ME Status 2 : 0x12280106

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Soft Temporary Disable
ME: Error Code              : No Error
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Clean global reset
ME: Progress Phase State    : ME in temp disable

ME: Extend SHA-256: [long hash here]

ME: failed to become ready
ME: failed to become ready
ME: GET FW VERSION message failed

[pgera]

Just an update on the patches. I found that the hackintosh msr patch causes stability issues with linux. It causes random reboots on my w530. I had to revert it. The other two patches seem to be fine. It's either the patch itself, or something else in my environment or setup. I didn't have time or motivation to investigate it since I don't use hackintosh.
Was likely something else. Also did a reset of bios settings, which might have helped.

[azanwaqas]

hi how to make patch file t440s

[ludufre]

I have created a more detailed guide teaching to reassign the BIOS: https://www.insanelymac.com/forum/topic/337333-guide-fix-insyde-h2o-bios-signature-5-beeps-on-lenovo/ @edmalho

[azanwaqas]

How to make Lenovo bios patch for Lenovo supervisor password unlock

[pgera]

@edmalho , I have noticed a downside to this approach. After patching, you cannot clear or take ownership of the tpm chip. The tpm chip continues to work in its previous configuration before patching, but you will not be able to reset it. If you want to take ownership, you need to go back to the stock bios.

[a-hurst]

Just as an update to this for anyone trying to follow along, someone's put together a very good and detailed guide on how to remove BIOS write protection from a xx30-series ThinkPad without a hardware flasher using chipsec.

The guide/process could definitely be streamlined a bit further (e.g. recommending a bootable USB Linux distro to follow along with, since the one I had installed didn't have a new enough flashrom to make a BIOS backup and I had to jump through a bunch of extra steps trying to get a newer version working), but for the most part it was pretty straightforward to follow.

What's still missing at this point is a guide/script for patching the stock Lenovo BIOS (there's a post detailing and explaining a bunch of the possible patches here). Because xx30 BIOS mods until now have required hardware flashing over the whole chip, and apparently each chip has a bit of code unique to each machine, people have had to:

1. Dump the full contents of the BIOS chip with a hardware flasher
2. Create an account on bios-mods.com, post your dumped BIOS in the x230 thread along with a list of the patches you'd like applied, and wait for one of the people there to patch it and PM it back to you
3. Flash the patched BIOS onto the chip, again using the hardware flasher

Of course, now that we've figured out removing flash protection from the stock BIOS without a flasher, it should be possible (based on my understanding, at least) to just modify the stock .FL1 file from the official Lenovo BIOS .iso and make a universal modified BIOS image that can be flashed the same way thinkpad-ec is (since the BIOS update only flashes over part of the chip and not the whole thing, so machine-specific regions aren't an issue). I guess the main work that'd need to be done here would be making sure the patches work across the BIOSes for different xx30 models and summarizing the patching / checksum fixing process into a step-by-step process (and eventually a script).

[JCBuck]

Thanks for the update. The link seems to point to the ec patch instructions instead of the bios wp bypass instructions. As for patching the bios images,the free and open source tool uefitool or uefipatch works quite well in reading in raw firmware dumps and doing byte replacements to apply fixes such as whitelists or overclocking support. Theoretically it can be automated. I don't remember exactly, but I did try to modify the stock bios, but it does require a bit of work to unpack it.

…

On Mon, Dec 9, 2019, 10:05 AM a-hurst ***@***.***> wrote: Just as an update to this for anyone trying to follow along, someone's put together a very good and detailed guide <gch1p/thinkpad-bios-software-flashing-guide#1> on how to remove BIOS write protection from a xx30-series ThinkPad without a hardware flasher using chipsec. The guide/process could definitely be streamlined a bit further (e.g. recommending a bootable USB Linux distro to follow along with, since the one I had installed didn't have a new enough flashrom to make a BIOS backup and I had to jump through a bunch of extra steps trying to get a newer version working), but for the most part it was pretty straightforward to follow. What's still missing at this point is a guide/script for patching the stock Lenovo BIOS (there's a post detailing and explaining a bunch of the possible patches here <https://www.bios-mods.com/forum/Thread-REQUEST-Modify-X230-BIOS-with-clip?pid=104503#pid104503>). Because xx30 BIOS mods until now have required hardware flashing over the whole chip, and apparently each chip has a bit of code unique to each machine, people have had to: 1. Dump the full contents of the BIOS chip with a hardware flasher 2. Create an account on bios-mods.com, post your dumped BIOS in the x230 thread along with a list of the patches you'd like applied, and wait for one of the people there to patch it and PM it back to you 3. Flash the patched BIOS onto the chip, again using the hardware flasher Of course, now that we've figured out removing flash protection from the stock BIOS without a flasher, it *should* be possible (based on my understanding, at least) to just modify the stock .FL1 file from the official Lenovo BIOS .iso and make a universal modified BIOS image that can be flashed the same way thinkpad-ec is (since the BIOS update only flashes over part of the chip and not the whole thing, so machine-specific regions aren't an issue). I guess the main work that'd need to be done here would be making sure the patches work across the BIOSes for different xx30 models and summarizing the patching / checksum fixing process into a step-by-step process (and eventually a script). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=ABI2O2Y57EEAQWO7FC22SETQXWRVPA5CNFSM4EVSYSI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGHSYEA#issuecomment-563031056>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABI2O22V6572JCLKPACECLTQXWRVPANCNFSM4EVSYSIQ> .

[a-hurst]

Apologies, I believe I've fixed the link in my post. I've discovered the UEFITool/UEFIPatch utilites and have found some partial guides on how to use them, but I'm also wanting to be sure the patches posted here and elsewhere will work (and not break anything) with my particular model / BIOS version in case any of the patched code differs between models/versions (I'm being extra cautious here because I don't have a hardware flasher on hand).

As for extracting the stock BIOS from the official Lenovo image, it's actually dead-easy on Linux: just extract the DOS flashing image from the .iso with

geteltorito -o ./bios.img stock_lenovo_bios.iso

and mount the resulting bios.img, the .FL1 containing the stock image can be found in the mounted .iso's ./FLASH/G1ET93WW/ folder (the exact folder name differs between bios versions but will resemble that one).

[pgera]

@a-hurst , 1) Get a programmer first no matter what. 2) If you don't have an nvidia card, I would strongly recommend coreboot instead of patching the bios. While bios patching works, it's not a long term sustainable solution since you need to do the back and forth every time the bios is updated. Also, it breaks TPM provisioning.

[a-hurst]

@pgera I don't have an NVidia card (it's an x230 so integrated-only), but unfortunately I don't think Coreboot is an option since the one-and-only purpose for the cheap x230 I bought is to run macOS, and based on what I've read I don't think the Coreboot video blobs play nice with it (I'll do some more research though). An external programmer is definitely a good idea, I've just been reluctant to drop over 20$ + shipping on a Pomona SOIC8 clip + 10$ for a CH341A for a computer that's not really mission-critical for me (once the whitelist is gone, I'll get a macOS-compatible Wi-Fi card and it'll eventually replace my X220, but until then it's not getting used).

On another note, something else I found that's relevant to the thread is this incredible blog post, where the poster goes through the process of reverse-engineering and patching the whitelist out of the stock T430 BIOS in great detail with images from radare2 & explanations of exactly what the patch is changing in the BIOS logic.

[pgera]

You should try a single patch first that does just the wifi whitelist. The patches posted earlier in the thread are fine. It's a one line command with uefi patch. You'll get the beeps at boot, but you can deal with that later if you care about them by following the other detailed instructions. They are not essential. So your high level steps are 1) Disable write protect 2) Read from chip 3) Patch 4) Write to chip

[a-hurst]

Thanks, I'll likely attempt this over the holidays.

Actually, does anyone have known-working pre & post patch BIOS files they can share? I'm curious because I've found what appears to be a scriptable Python equivalent of UEFITool/UEFIPatch called uefi-firmware-parser, and it seems to work fine for parsing stock X230 BIOS extracted from the official Lenovo .iso, but it's not documented super-well and I want to make sure I can reproduce the working patches that UEFIPatch does before flashing anything it creates.

The major upside to this (if it works) is that Python's hashlib has built-in SHA1 support and it also has a solid regex library, meaning that we could potentially script both the patches and the SHA1 fixes to remove the beeps, making the whole process massively easier.

[coaxial]

Stock BIOS v2.73: flashregion_1_bios.tar.gz (BIOS region only)

Modified BIOS v2.73: 20180922_141118_bios.rom.tar.gz (entire ROM but I don't remember if it was with or without unlocking the ME etc regions)

Several modifications enabled in this BIOS, including whitelist bypass.

[coaxial]

To add, someone much smarter than me did a 3 part writeup about removing the whitelist:

• https://erfur.github.io/2019/01/28/down_the_rabbit_hole_pt1.html | archived version
• https://erfur.github.io/2019/02/16/down_the_rabbit_hole_pt2.html | archived version
• https://erfur.github.io/2019/03/28/down_the_rabbit_hole_pt3.html | archived version

In particular, from part 3:

I dumped the current BIOS and patched it using UEFIPatch tool. I’ve created a pattern to patch the image:

79E0EDD7-9D1D-4F41-AE1A-F896169E5216 10 P:0AFFFFFF:20010000

Maybe this helps?