search

hamishcoleman / thinkpad-ec

Infrastructure for examining and patching Thinkpad embedded controller firmware
GNU General Public License v2.0
1.05k stars 116 forks source link

FL2_copyIMG issues with older update files #104

Open swiftgeek opened 5 years ago

swiftgeek commented 5 years ago

Archive contains all public versions of EC firmware updates for regular X200 (Mocha-1) Mocha-1_EC.zip FL2_copyIMG works fine with 7XHT24WW and 7XHT25WW but fails with 7XHT21WW and 7XHT22WW

$ perl FL2_copyIMG from_fl2 7XHT21WW.FL2 7XHT21WW.ROM                                                                                                                                    
Could not determine IMG details for 7XHT21WW.FL2
exit 1
hamishcoleman commented 5 years ago

That looks like you have bumped up against the built-in safety checks. I've added the basic rule to match those two files and the result still looks like a valid firmware extract to me. So you should be good to go.

swiftgeek commented 5 years ago

If this is whitelist based then I will attach FL2 of X60 (KS-Note) and X60 Tablet (Dali-1) Dali-1.zip KS-Note.zip

hamishcoleman commented 5 years ago

Maybe you could check out my patch and see if it is applicable to the X60 firmwares as well?

Is there some value in dealing with such old laptops, or are you just trying to ensure completeness?

swiftgeek commented 5 years ago

Not directly applicable to X60, and both because it's supported by coreboot/libreboot and completeness.

Older ones have srec/ihex EC image directly (again with FL2 extension)

swiftgeek commented 5 years ago

I guess similar change for those X60 images would be 

2102038 => [0x10000, 0x20000],
2102182 => [0x10000, 0x20000],
2102742 => [0x10000, 0x20000],

But that doesn't seem to be enough

hamishcoleman commented 5 years ago

I've just had a look at this and was able to see the issue - there is a second signature check for a block of known "0xff" bytes - so I've paramaterised that.,

Currently, I've only added the signature for one of these sizes - the one that is in the "current" Lenovo firmware download ISO (See 875e43cfbc35)

hamishcoleman commented 5 years ago

Do you have ISO download URLs for the older FL2 files in your attached ZIP archive?

I've had a look and all these files have a common header, so I can update the change I made to a more generic dissector

swiftgeek commented 5 years ago

I used .exe with innoextract/regular archive tool, and that was much easier for me - with iso i need to extract eltorito image, then mount it. With exe i'm just unpacking .exe and get FL1/FL2 files straight away

As far as flashing goes i'm using flashrom + empty file with ec firmware inserted at expected offset + layout file

If i'm guessing correctly ISO should look like Everything below are Intel Napa based thinkpads X60/X60s (KS Note/KS Note-2):

X60 Tablet (Dali-1):

T60 (Davinci: Lisa/Magi): https://support.lenovo.com/gb/en/downloads/migr-63027

R60/Some R60i (Machine types 94xx) (Somehow this has different FW than T60, I thought it was the same board - i guess i will need to recheck EDIT: looks like Wistron RP-1 and related set of boards but not sure). It was also not pruned from website: https://support.lenovo.com/gb/en/downloads/migr-64578

R60e/Some R60i (Machine types 06xx) - disappeared completely from lenovo webpage

Z61* - for some reason those were not pruned - https://support.lenovo.com/gb/en/downloads/migr-64305

hamishcoleman commented 5 years ago

Thanks! I've added all the x60 images and confirmed that one generic extractor works for all of them - you should be able to follow the same pattern to confirm if that works for the other hardware types too.

swiftgeek commented 5 years ago

Tested and working (I checked all extracted roms in hexedit for sanity):

Thinkpads prior to intel napa seem to use srec/ihex format so that just needs srec_cat/objcopy

Now I have tried it on santa rosa thinkpads, taking x61 as example - seems to be located at 0x90000 there

2103350 => [0x090000, 0x20000, 0x00020],  # Seen in X61

That one line seems to work with all EC fws from following models:

Will try to reflash x60s with flashrom later on

hamishcoleman commented 5 years ago

Good news. The last two bytes of the firmware look like a checksum to me - do you know how to calculate it? The tool could use that to automatically add another layer of consistency check on the output.

swiftgeek commented 5 years ago

What I can say about that 2 byte thing in fw is that it appears as far back as T23 EC FW (first device to use final stable version of the framework, X line starts using it only since X40), earlier devices have firmware ending with a single byte.

swiftgeek commented 5 years ago

Tested today flashrom on X60s (KS NOTE-2) with following x60.layout

00010000:0002FFFF ec

Using following command

flashrom -p internal -N -l x60.layout -i ec -w X60-7BHT40WW.img

Image for flashrom created like this

dd if=/dev/zero bs=2048K count=1 | tr "\000" "\102" > ./X60-7BHT40WW.img
dd if=7BHT40WW.rom of=X60-7BHT40WW.img bs=64K seek=1 conv=notrunc

(0x42 padding makes it easier to check in hexedit whether ec fw was inserted at right location, also makes flash of wrong region more evident. 7BHT40WW.rom is the extracted 128KiB EC FW)

Then, on subsequent boot with AC+Battery attached and charged up, BIOS successfully updated EC from 7BHT37WW to 7BHT40WW. (AC/Battery missing will defer update to next power up, and will continue with booting normally). After update was done BIOS erased only first block from EC hole (to prevent further update attempts).

swiftgeek commented 4 years ago

I just tried it with G50 image and it appers to be successful perl FL2_copyIMG from_fl2 7HHT13WW.FL2 7HHT13WW.ROM

swiftgeek commented 4 years ago

@hamishcoleman looks like I failed to read articles carefully enough

$ ./mec_csum_outer -c ../7XHT25WW.IMG 
9c31 9c31 OK

After changing stuff in padding:

$ ./mec_csum_outer -c ../7XHT25WW.IMG
9c31 4a38 FAIL

The tool comes from: https://github.com/eigenmatt/mec-tools/blob/master/mec_csum_outer.c , from article series 1 2 3

It works since T23, images tested 1AHT17WW till 1AHT23WW.

770(EXET09WW), 770Z(IIHT07WW), 600X (IHHT10WW), T20-T22 (IYHT15WW) uses single byte checksum After patching mec_csum_outer.c to work with just 8bit it works fine on those images as well

$ ./mec_csum_outer -c ../IYHT15WW.IMG
0022 0022 OK