Thinkpads Forum

gtxaspec wrote:Perhaps these remaining missing keys are able to be remapped in windows? Can anyone share any success stores regarding this (if attempted)? I use Fn-Space quite often, it handles the Lenovo Zoom utility to lower the resolution on the fly to enlarge the screen (useful when you need extra detail, or if your eyes are bad like mine.)

The Fn-Space might actually work - the key has been patched, and it generates a keypress event, but I dont have any software that uses it - since it generates a keycode, you could try remapping it in windows

The Fn+Battery key is patched in one of the key-tables, but I dont remember it generating a keypress event (I should go and test that again) - so it would not be possible to try remapping using windows.

The Fn+Hibernate key is not patched as it was unclear what the correct values would need to be - I didnt want to go experimenting, in case that caused problems. It doesnt generate any keypress event, so again not possible to remap in windows.

gtxaspec wrote:
Do you mind sharing any more detail on which problems you encountered in the keyboard mapping tables in regards to the keyboard matrix?

I have been meaning to add some documentation with details of the various tables we found in the firmware to the git repository - so now that you are asking I'll just have to try and find the time to write that up...

So... how would one go about trying to get the whitelist bypass working similar to the battery bypass? I'm a developer and a hacker, but don't have a clue as to how the battery bypass works. Any pointers or tips? I'd love to try Hackintoshing a T430s, but the Wifi seems to require rebranding an Atheros card, and that's really hit-or-miss (and a lot of work!)

plympton wrote:So... how would one go about trying to get the whitelist bypass working similar to the battery bypass? I'm a developer and a hacker, but don't have a clue as to how the battery bypass works. Any pointers or tips? I'd love to try Hackintoshing a T430s, but the Wifi seems to require rebranding an Atheros card, and that's really hit-or-miss (and a lot of work!)

Fixing the WIFI whitelist is - unfortunately - a much more complex beast than the embedded controller. Mostly this is a bunch of vague pointers from some reading I did months ago...

Firstly, I saw several threads on patching the image (one example), but this needs you to extract the binary from one of the files in the compressed UEFI/BIOS archive "capsule" and then re-create that archive with your patched binary - I have not tested any of this, so cannot comment on success or difficulty.

Once you have a patched UEFI/BIOS image, you then currently need to use a hardware programmer to re-program that into the bios flash. Nobody has worked out the encryption / checksums needed to make the pached image look valid to the dosflash.exe tool - unlike with the embedded controller.

The problem for whitelist removal is the rather effective lockdown in place to prevent in-system flashing of unauthorised BIOS images: http://forum.thinkpads.com/viewtopic.ph ... 60#p780656

If you are willing to use a hardware programming tool then the procedure to remove the whitelist check isn't that different from previous Thinkpads.

cros wrote:The problem for whitelist removal is the rather effective lockdown in place to prevent in-system flashing of unauthorised BIOS images: http://forum.thinkpads.com/viewtopic.ph ... 60#p780656

If you are willing to use a hardware programming tool then the procedure to remove the whitelist check isn't that different from previous Thinkpads.

I was hoping that there could be a fix similar to the battery whitelist check which I assume installs somethings like "if bad battery do nothing" instead of "if bad battery print 'blah blah bad battery'"

USB wifi adapters are cheap and small enough now that I could live without it. It's just that a t420s hackintosh is almost 100% native. Getting a t430s 100% native is just an hacking challenge at this point.

Edit: make that a FHD IPS classic keyboard t430s i7.

plympton wrote:So... how would one go about trying to get the whitelist bypass working similar to the battery bypass? I'm a developer and a hacker, but don't have a clue as to how the battery bypass works. Any pointers or tips?

You can read on how the battery check was hacked here:

http://www.zmatt.net/unlocking-my-lenovo-laptop-part-1/
http://www.zmatt.net/unlocking-my-lenovo-laptop-part-2/
http://www.zmatt.net/unlocking-my-lenovo-laptop-part-3/

hhhd1 wrote:

plympton wrote:So... how would one go about trying to get the whitelist bypass working similar to the battery bypass? I'm a developer and a hacker, but don't have a clue as to how the battery bypass works. Any pointers or tips?

You can read on how the battery check was hacked here:

http://www.zmatt.net/unlocking-my-lenovo-laptop-part-1/
http://www.zmatt.net/unlocking-my-lenovo-laptop-part-2/
http://www.zmatt.net/unlocking-my-lenovo-laptop-part-3/

Whew. That was a tough read, quite over my head. I think I've accepted that a $10 USB wifi adaptor will work until some smarter than I comes along and figures it out. From what I read, I wager that inserting the NOP instructions on the checks should work.

Hi, thanks for all the information in this thread so far!

I've followed the guide on the wiki so far, but I haven't been able to get it working.

So far, I've gotten an X220 palmrest and keyboard, I took apart the keyboard and put the tape on the pins, put the keyboard back together, and then installed it into my X230. So far, so good.

I cloned the repository and ran "make patched.x230.img". That seems to work fine. I then dd that image onto my USB stick and then reboot.

Here's where I run in the first issue. When I try to flash the image, it says "An update is not necessary at this time. The process has been canceled.". A little weird, so I Google this. I don't find anything super enlightening, but I see a few people suggest downgrading to an older version and then trying again.

So I download an older BIOS, flash that (successfully), and then I try the new (patched) one again, and it does indeed let me flash it this time. However, once I boot and start using it, the keyboard still behaves exactly as if I hadn't flashed it (all the Fn keys in the wrong place, Delete is Home, PgUp is Delete, etc.)

It's almost as if the patch isn't applying at all, of if it is, it isn't doing anything. I wonder if that explains the initial error I got as well: maybe the "an update is not necessary at this time" is because the EC I wanted to flash is exactly the same as what's already there? i.e, the patch did nothing?

Has anybody else run into this? Am I missing something really obvious?

duairc wrote:When I try to flash the image, it says "An update is not necessary at this time. The process has been canceled.".

This is the message that the unpatched firmware gives when you do not need to upgrade the BIOS.

It thus sounds like something has gone wrong with your build. Can you paste the output from "make clean patched.x230.iso" - there hopefully will be an error message somewhere in that that we can use to debug things.

It just looks like the "autoexec.bat" file is being completely ignored.

Here is the output of :

duairc wrote:It just looks like the "autoexec.bat" file is being completely ignored.

Here is the output of

Code: Select all

make clean patched.x230.iso

:

Code: Select all

...
Your build has completed with the following details:
echo Buildinfo: v1-9-g83d4bb (20160622) clean patched.x230.iso
echo Built: bb3419027a915cf3dbbaf91f857211bdfda5625e  x230.G2HT35WW.s01D3000.FL2

Well, no errors there - and the build info matches what I get here too.

Can you test that build in a virtual machine with a "make patched.x230.img.test" and tell me if the screen it pauses at looks different to what you get when you try on a real system?

It does seem to be ignoring the autoexec.bat, but if the update to that file didnt make it into the built image, then the update to the firmware might not have made it into the built image either.

Additionally, if you insert the USB key that you created and look at the files on it, you could confirm the contents of the /autoexec.bat and the sha1sum of /flash/G2ETA6WW/$01D3000.FL2

It's okay, I figured it out! I had my BIOS set to boot "UEFI First". I changed it to "Legacy Only" (probably "Legacy First" would have sufficed, I didn't check). Once I enabled "Legacy Only" it ran the autoexec.bat script fine and now everything works as I expected! I changed the boot order back to "UEFI First" afterwards because my OS is set up to boot from UEFI.

Thanks for all the help and for developing this! I now have my dream laptop pretty much.

Maybe there should be a note added to the wiki about UEFI/Legacy booting for doing the BIOS mod?

duairc wrote:It's okay, I figured it out! I had my BIOS set to boot "UEFI First". I changed it to "Legacy Only"
...
Maybe there should be a note added to the wiki about UEFI/Legacy booting for doing the BIOS mod?

Well, that is certainly a good point!

I'll go one better and also delete the UEFI boot file from the created image, thus making it impossible to use that way.

Great work you guys have done here.

Just to be sure, could you test if there are differences in battery life with the classic keyboard if the pins were or were not covered?

derball2008 wrote:Great work you guys have done here.

Just to be sure, could you test if there are differences in battery life with the classic keyboard if the pins were or were not covered?

I had originally thought to do some tests like that - but once I investigated my keyboards closely enough, I was able to see that they had permanently burnt through the tracks connected to those pins - which is good news for the battery! But you run the risk that my experience of a small, neat and benign burnt-through is not the one you get - nitrocaster has some possible outcomes in his warnings upthread

hamish wrote:

derball2008 wrote:Great work you guys have done here.

Just to be sure, could you test if there are differences in battery life with the classic keyboard if the pins were or were not covered?

I had originally thought to do some tests like that - but once I investigated my keyboards closely enough, I was able to see that they had permanently burnt through the tracks connected to those pins - which is good news for the battery! But you run the risk that my experience of a small, neat and benign burnt-through is not the one you get - nitrocaster has some possible outcomes in his warnings upthread

I haven't looked at the dasher schematics line by line yet, but do we know why the X230 burns the pins on the x20 keyboards? I remember reading someone else mentions on this keyboard they get shorted to ground, do these relate to the back-light?

gtxaspec wrote: I haven't looked at the dasher schematics line by line yet, but do we know why the X230 burns the pins on the x20 keyboards? I remember reading someone else mentions on this keyboard they get shorted to ground, do these relate to the back-light?

Yes, it is the keyboard back-light.

On the x220, there are three keyboard pins labeled as "kbdid0" (and #1 and #2) - so I make the assumption that they intended to detect different keyboard types and act appropriately. It seems that the x220 idpins were all shorted to ground in the keyboard. On the x230, they needed some spare pins for the backlight, so they used these kbdid pins. One of them is permanently connected on the motherboard to a relatively high current +5v power supply used for the backlight - so we get a short circuit in the keyboard, with enough current to melt the (thin and narrow) flexible printed circuit in the keyboard.

I just performed the mod, with pins 25, 27, and 29 taped according to the render on the wiki. The X220 keyboard, with the EC mod, works fine. However, the trackpoint buttons do not. The original x230 keyboard's trackpoint buttons are fine.

Any tips on what to do?

Bibin wrote:I just performed the mod, with pins 25, 27, and 29 taped according to the render on the wiki. The X220 keyboard, with the EC mod, works fine. However, the trackpoint buttons do not. The original x230 keyboard's trackpoint buttons are fine.

Any tips on what to do?

One of nitrocaster's earlier comments indicated that the short circuit was near the circuit traces used for the trackpoint buttons - so if you didnt isolate the pins correctly, perhaps those traces have become damaged?

Do you have access to a x220 to test your keyboard?

hamish wrote: One of nitrocaster's earlier comments indicated that the short circuit was near the circuit traces used for the trackpoint buttons - so if you didnt isolate the pins correctly, perhaps those traces have become damaged?

Alternatively, wrong pins were covered.

I took apart the X220 keyboard and made sure only the relevant pins were covered, but there was no change. It is entirely possible this keyboard just has a problem to begin with. However, a friend ended up purchasing the machine with the original 6-row keyboard, so the issue is more or less a "will not fix".

@hamish:

First, thank you for your good work. I could swap my old Keyboard from my x220t to the new T530 all keys are working fine...

But I have another question, where you could help me maybe: Is it possible to change the ec firmware on my x220t so i could use all of the keys from the "new" keyboard (out of the t530)?

thanks and best regards

alex

onkelalex wrote:@hamish:

First, thank you for your good work. I could swap my old Keyboard from my x220t to the new T530 all keys are working fine...

Good news! Always glad to hear about people using our tools.

onkelalex wrote: But I have another question, where you could help me maybe: Is it possible to change the ec firmware on my x220t so i could use all of the keys from the "new" keyboard (out of the t530)?

Like all good questions, the answer is both "yes" and "no" - we have all the details needed to patch the keyboard tables on the x220t EC firmware (they might take a bit of fishing in the binary to find, but I have identified and marked the matching tables on the x220 firmware binary, so you would just need to search for the same byte strings)

This would be enough if you have access to a hardware programmer (however, as far as I am aware, the H8S chip used in the xx20 series does not use a documented programmer interface - and so, this is not a method that I would expect to be straight forward).

Using the lenovo dosflash tool to flash the EC firmware would require us to find the encryption keys used by the x220 firmware - it uses a different key than the xx30 series firmware does. Once we had those keys, we could then check if the inner checksum methods are the same as the xx30 series. Annoyingly, one of the key parts that could be used to find the encryption keys is a hardware programmer, so this option is also difficult.

However, if you can find someone online that has posted a hardware firmware dump from their H8S chip on a xx20 series, it might be possible to try (FYI, zmatt got his break-through with the xx30 firmware when he found that someone had posted a firmware dump from a x230i)

Cheers,
Hamish.

hey hamish,

thanks for your fast an detailed answer. i thought that there would be an easy way to do so...

i'll look around in the www - and maybe i'll find something.

thanks for your help

best wishes alex

haven't done the mod yet, but does the backlight keyboard combo still work? the combo is fn+space but apparently it has some other meaning on the classic keyboard.

derball2008 wrote:haven't done the mod yet, but does the backlight keyboard combo still work? the combo is fn+space but apparently it has some other meaning on the classic keyboard.

On the classic keyboard, the backlight sequence is Fn+PgUp - which works with the patch.

It is possible to change these mappings around, but that would require hacking on the patches. I've got the notes needed to understand the FN key mapping tables, but I have not written them up into documentation yet :-S

Here's a link to some related KB gobbledygook that might help: https://ideechaniz.wordpress.com/page/5/

Just did this mod on my T430. This is awsome!
Thanks hamish, and anyone related to this great project.
Your work is really appreciated.

So I finally got the EC keyboard mod to work on my t430s, now how do I make a build that removes the battery check? I understand that I have to modify the .FL2 file but I'm not sure how, any guidance is appreciated. Thanks.

BrothahHeffay wrote:So I finally got the EC keyboard mod to work on my t430s, now how do I make a build that removes the battery check? I understand that I have to modify the .FL2 file but I'm not sure how, any guidance is appreciated. Thanks.

In Linux you need to cd to the t430s directory and rename the battery patch file - it is marked disabled or something similar. Just rename it like the others and make the iso or img file again. I just did it for my latest t430s but shut down and do t have Ubuntu handy at the moment. It's pretty straight forward.

mv is the rename command in Linux.