Any idea how I can extract a BIOS image?

[patfla]

Either from one of the downloads at the IBM/Lenovo model-specific 'downloads and drivers' site.

Or from the machine itself?

I have a T43/p model 266889u. I can 'dig inside' the various things to be found at the download site. And I'm pretty sure that it (the BIOS image) is in something called (in my case) 1YUJ13US.IMG. I can pull this into Emacs; change to hex-mode and read a bunch of intriguing things in the ASCII translation column.

But judging by the patterns I see elsewhere in this file the BIOS image itself is compressed. But with what scheme?

etc.

Another cool idea (for which I've yet to find any evidence on the Web) is to extract it directly from the chip on the mobo.

But that presumes one knows the memory map; where the BIOS is mapped; or if it's even mapped at all (once the OS is up and running). And throw into that mix that, by virtue of having a T43, I'm now on PCI Express where, potentially things have moved around quite a bit.

pat

[LtTPfan]

This LINK should provide you the information needed to extract your own BIOS image. This thread at Anandtech may give you additional help.

[patfla]

Thanx LtTPfan,

Actually I had the first link already. That's what I wanted to do (and why I asked here about how to extract a BIOS image). I want to put a 'non-supported' wireless card into my T43's mini-PCI slot.

The instructions in the first link (Paul Sladen's) seem to indicate that one should use PHNXDECO (from a programmer in Russia) to extract the BIOS image. Moreover only the very latest version of PHNXDECO will succeed in extracting a Phoenix FirstBIOS BIOS which is what's in the latest Thinkpads.

I've tried PHNXDECO on everything I can get my hands on (by way of something that should contain the BIOS image). In particular of course, downloading both the diskette and non-diskette versions of the BIOS install from the drivers and downloads area for my model (266889u).

Nothing's worked. PHNXDECO says it can't recognize any of the things I throw at it. I've tried pretty much all of PHNXDECO's switches (options).

If you dig down under Paul's page you don't find an email anywhere. It seems he prefers IRCs. Tried using these but never found him. (he's in the UK).

There's a futher problem. I'd love to just use no-1802.com file. I looked at that person's assembly code. Downloaded the images (these are 'old-DOS-style' EXEs but with a .COM extension).

The problem is that if you search for 1802 through these forums, I found many places where people had found that this procedure no longer works as of T43s.

T43s move to a completely new bus architecture. Away from the old PCI/AGP architecture to the new PCI-Express. Which of course in most ways is much better.

But my guess is is that this has changed the memory map very considerably. And both the mapped ROM code, and the bit in it that needs to be set, have moved to a different location than the one assumed in no-1802.com.

Any experienced PHNXDECO users - pls raise your hand.

Or rather I'd be very interested to hear from anyone who has succeeded in using PHNXDECO to extract a FirstBIOS BIOS from 'something' (and what?).

pat

[patfla]

I extracted the ROM from my T43 using WinPhlash and the technique described here:

http://www.short-media.com/forum/printthread.php?t=218

(in the post by 'Borg Number One').

I inspect what I extracted in a hex editor and find many of the things I expected (strings). IBM, 1YET59WW (IBM's name for 1.24), and many BCP (Bios Configuration Parameter) sections

In addition, phnxdeco will decode the file and shows me reasonable looking modules.

One thing that I didn't expect (although maybe I should have), and that may be a show-stopper. Many strings:

"RSA Buffer" andh
"Certificate"

followed by what appears to be a certificate:

LI_04007A44-9D05-431E.SIGLI_04007A44-9D05-431E.PKY.CD001

(or some subset of this may be the certificate [time to read up on RSA]).

Reading around the Web this may be BIOS support for TPM (Trusted Platform Module - biometrices etc).

But it might also serve to encrypt parts of the BIOS itself. In which case I either have a much harder or impossible task before me.

Anyone know if IBM/Lenovo is now encrypting parts of the BIOS with RSA?

pat

[LtTPfan]

Most likely the compression used is LZSS.

I spent several hours yesterday trying to get PHNXDECO and PHLASH16 to work. Most likely the reason they didn't work is for the same reason WinPhlash wouldn't work at first, it wants to read in a BIOS file before it will extract your BIOS, even if you choose the backup only option. I have no clue why but it won't work unless you have an image it can read first. To solve this you can download the diskette version of the driver for your system from IBM and create the diskette. Run WinPhlash and select the image file (mine was $0186000.FL1 for my T30) for the "Specify new BIOS file" text box. I tried using the non-diskette version but WinPhlash balked at the .img file. Select the Backup BIOS Only radio button then start the backup.

I'm working on disassembling my T30 BIOS now trying to solve the 01C9 "too many ethernet controllers" error. Once (if) I figure that out, figuring out how to fix the 1802 and 01C9 errors for the newer systems should be easy.

[patfla]

RSA is encryption not compression. And a considerably tougher nut to crack.

In addition the compresion standard used with FirstBIOS is LZINT not LZSS. Phnxdeco confirms this (with my BIOS).

Does your T30 use FirstBIOS or some earlier version of Phoenix BIOS?

When I pulled 1YUJ13US.EXE into PE Editor, under Dependencies what I found was LZ32.DLL from Microsoft. Have no idea of what flavor of Lempel Ziv that provides.

pat

[LtTPfan]

But judging by the patterns I see elsewhere in this file the BIOS image itself is compressed. But with what scheme?

I said compression is most likely LZSS as information I found at phoenix.com indicates newer BIOS are compressed with LZSS.

[patfla]

Hi LtTPFan,

I do appreciate having at least one correspondent on this.

Here's a copy of "-ls" on my T43/p BIOS.

(if I could put this into a fixed width font, the table below would all line up properly [it's not too bad the way it is]. Or if you copy from here and into, say, Word, then switch to a fixed width font [e.g. Lucida Console] you'll see it lined up that way as well).


phnxdeco bios2.bak -ls

-=PhoenixDeco, version 0.31 (DOS)=-

Filelength : 10127A (1053306 bytes)
Filename : bios2.bak
PhoenixBIOS hook found at : EF260
System Information at : EF287
BootBlock : 10000 bytes
BankSize : 1024 KB
Version : 1YET59WW
Start : E83DD
Offset : F0000
BCP Modules : 23
BCPFCP : 1A01B
FCP 1st module : 6325 (16325)
Released : 07 November 2005 at 14:40:06
/* Copyrighted Information */
Phoenix FirstBIOS(tm) Notebook Pro Version 2.0 for IBM ThinkPad
/* ----------------------- */

================================== MODULE MAP =================================
Class Code
. Instance
. .
C I LEVEL START END LENGTH RATIO LINK TO FILEOFFSET
---- ----- --------- --------- ------ ----- --------- ----------
X 0 NONE FFFE 83DD FFFE FFF7 7C00 100% FFFE 7758 E83DDh
D 0 LZINT FFFE 7758 FFFE 83DC C6A 67% FFFE 4F2D E7758h
C 0 NONE FFFE 4F2D FFFE 7757 2810 100% FFFE 4E95 E4F2Dh
A 0 LZINT FFFE 4E95 FFFE 4F2C 7D 51% FFFE 4E47 E4E95h
A 1 NONE FFFE 4E47 FFFE 4E94 33 100% FFFE 4DF9 E4E47h
A 2 NONE FFFE 4DF9 FFFE 4E46 33 100% FFFE 4D9B E4DF9h
A 4 LZINT FFFE 4D9B FFFE 4DF8 43 81% FFFE 4D70 E4D9Bh
B 0 LZINT FFFE 4D70 FFFE 4D9A 10 0% FFFE 0005 E4D70h
X 1 NONE FFFE 0005 FFFE 4D6F 4D50 100% FFFD C4D8 E0005h
S 0 LZINT FFFD C4D8 FFFE 0004 3B12 40% FFFD C08D DC4D8h
G 0 NONE FFFD C08D FFFD C4D7 430 100% FFFD 06BE DC08Dh
R 0 LZINT FFFD 06BE FFFD C08C B9B4 56% FFFC BED2 D06BEh
R 1 LZINT FFFC BED2 FFFD 06BD 47D1 59% FFFC 6391 CBED2h
R 2 LZINT FFFC 6391 FFFC BED1 5B26 59% FFFC 1B10 C6391h
E 0 LZINT FFFC 1B10 FFFC 6390 4866 40% FFFB E21C C1B10h
T 0 LZINT FFFB E21C FFFC 1B0F 38D9 45% FFFB 380C BE21Ch
M 0 LZINT FFFB 380C FFFB E21B A9F5 67% FFFA 8C6C B380Ch
Q 0 LZINT FFFA 8C6C FFFB 380B AB85 49% FFFA 7D36 A8C6Ch
V 0 LZINT FFFA 7D36 FFFA 8C6B F1B 9% FFFA 2DC1 A7D36h
A 3 LZINT FFFA 2DC1 FFFA 7D35 4F5A 36% FFFA 2D7D A2DC1h
A 5 LZINT FFFA 2D7D FFFA 2DC0 29 82% FFFA 2D1D A2D7Dh
A 6 LZINT FFFA 2D1D FFFA 2D7C 45 76% FFFA 2CD4 A2D1Dh
A 7 LZINT FFFA 2CD4 FFFA 2D1C 2E 76% FFFA 04B9 A2CD4h
L 0 LZINT FFFA 04B9 FFFA 0516 43 54% FFFA 0440 A04B9h
L 1 LZINT FFFA 0440 FFFA 04B8 5E 17% FFFA 0393 A0440h
L 2 LZINT FFFA 0393 FFFA 043F 92 20% FFFA 0304 A0393h
L 3 LZINT FFFA 0304 FFFA 0392 74 37% FFFA 02C1 A0304h
L 4 LZINT FFFA 02C1 FFFA 0303 28 74% FFFA 0281 A02C1h
L 5 LZINT FFFA 0281 FFFA 02C0 25 88% FFFA 01FE A0281h
L 6 LZINT FFFA 01FE FFFA 0280 68 19% FFFA 0172 A01FEh
L 7 LZINT FFFA 0172 FFFA 01FD 71 21% FFFA 00E6 A0172h
L 8 LZINT FFFA 00E6 FFFA 0171 71 21% FFFA 005B A00E6h
L 9 LZINT FFFA 005B FFFA 00E5 70 21% FFF9 FFD1 A005Bh
L A LZINT FFF9 FFD1 FFFA 005A 6F 20% FFF9 FF9C 9FFD1h
L B NONE FFF9 FF9C FFF9 FFD0 1A 100% FFF9 FF3F 9FF9Ch
L C LZINT FFF9 FF3F FFF9 FF9B 42 37% FFF9 CB13 9FF3Fh
L D LZINT FFF9 CB13 FFF9 FF3E 3411 19% FFF9 C7F8 9CB13h
L E LZINT FFF9 C7F8 FFF9 CB12 300 18% FFF9 BF46 9C7F8h
L F LZINT FFF9 BF46 FFF9 C7F7 897 27% FFF9 BA8C 9BF46h
L 10 LZINT FFF9 BA8C FFF9 BF45 49F 9% FFF9 B42D 9BA8Ch
L 11 LZINT FFF9 B42D FFF9 BA8B 644 11% FFF9 7551 9B42Dh
H 0 LZINT FFF9 7551 FFF9 B42C 3EC1 71% FFF9 724D 97551h
< 0 LZINT FFF9 724D FFF9 7550 2E9 53% FFF8 7232 9724Dh
/ 0 NONE FFF8 7232 FFF9 724C 10000 100% FFF8 1217 87232h
. 0 NONE FFF8 1217 FFF8 6631 5400 100% FFF8 0F85 81217h
F 0 LZINT FFF8 0F85 FFF8 1216 277 61% FFF7 EF6A 80F85h
- 0 NONE FFF7 EF6A FFF8 0AE6 1B62 100% FFF7 A831 7EF6Ah
K 0 LZINT FFF7 A831 FFF7 EF69 471E 49% FFF7 A608 7A831h
K 1 LZINT FFF7 A608 FFF7 A830 20E 88% FFF7 A5CE 7A608h
* 0 NONE FFF7 A5CE FFF7 A607 1F 100% FFF6 9EA3 7A5CEh
B 1 LZINT FFF6 9EA3 FFF7 4FF1 B134 69% FFF6 037D 69EA3h
B 2 LZINT FFF6 037D FFF6 9EA2 9B0B 71% FFF5 A536 6037Dh
B 3 LZINT FFF5 A536 FFF6 037C 5E2C 68% FFF5 88A1 5A536h
B 4 LZINT FFF5 88A1 FFF5 A535 1C7A 60% FFF5 2CEF 588A1h
B 5 LZINT FFF5 2CEF FFF5 88A0 5B97 53% FFF2 0000 52CEFh
? 0 NONE FFF2 0000 FFF2 0C40 C26 100% 0000 0000 20000h
Total Sections: 56

[danage]

Your BIOS does not seem to be compressed. The way you usually go is to find out your MiniPCI ID. Right click on my computer, go to management, go to device manager, go to properties of your wireless adapter, select the tab "details", highlight the long strange looking line and press ctrl-c to copy the information to the clipboard. Then, paste the line into an editor (notepad e.g.) to take a closer look.

With that information and this site http://www.paul.sladen.org/thinkpad-r31 ... i-ids.html you can figure out which string you have to find and then change in your rom dump. Just a little bit of combination cleverness required :) (Intel little endian format, subsys flipped, you'll figure it out).

Then, flash it all back on there. I used phlash16, it worked fine for me.

No warranties, do on your own risk!

[patfla]

Hi Danage,

First, what model do you have? I'm suspecting that things have changed relative to the information in Sladen's Web page (and perhaps in no small part beause of it!).

Actually I was already able to figure out my Mini-PCI ID from here:

http://www.thinkwiki.org/wiki/Intel_PRO ... CI_Adapter

My Thinpad is a T43 266889U and so the wireless adpapter is an Intel 2915 a/b/g. The Mini-PCI ID given above (from thinkwiki) is PCI 8086:4224

Which sort of makes sense since if you look at Sladen's page, he gives you the Mini-PCI ID for what I take to be Intel's previous card, the Intel 2200BG, as 8086:4220.

So they bumped it up by 4 (in the last position). That would seem reasonable.

OK so I have these numbers. And one would expect the T43/p to support not just the 2915 but, to some extent be backwards-compatible, and support the 2200 as well.

The problem then is the following: I can search through the ROM code (in a hex editor) for either 8680 2442 or 8680 2042 (that's the little-endian byte-swapping [I'm a programmer and while these days I do, say, OLAP design, some time ago I wrote device drivers and many of these things are quite familiar to me]). Anyway, I find find neither string (mini-PCI ID).

According to Sladen, these numbers should probably shortly follow the string 'BCPUSB'. BCP being (from Sladen) 'BIOS Configuration Parameter'. I can find BCPUB in my ROM (and many other BCPs) but there's nothing like a Mini-PCI ID following it - mostly blank bytes. And before long another BCP - so you assume that BCPUSB is finished.

Since I got symied there, I've tried a couple other things and with interesting results. There's a free version of a tool called IDA.

www.datarescue.com/idabase/

This will accept the ROM (you have to change the ida.cfg however) and disassemble the code.

And it seems to recognize functions within the code! Very encouraging.

So while it may seem tedious, I'm actually making progress in tracing the flow-of-control (program path) through the BIOS. Hoping somewhere I'll find a reference to the 1802 error string. And then see if I can NOP the location that gets triggered to spit out the string. That is, the code that causes your machine to halt on any 1802 error.

And that's only a part of the story. Still any help of any kind appreciated.

Pat

[phewtoo]

Nice to see someone 'playing' with this!

<Off topic>
I have only just found out how my T43p is really not -in the manufacturers eyes- mine at all!!
...and it p**sed me off a LITTLE...and all I wanted to do was increase my HD size.
<Back on topic>

Having used the above info. to get a 'picture' of the Bios, I am into helping where I can in mapping it somehow.

From looking at the '$0197000.FL1' that I used to upgrade; there seems to be two distinct areas that look to have compression...assuming the larger is the actual Bios...any idea of what the smaller may be?

Keep digging

[patfla]

Phewtoo,

Hi. May I ask what you used to see the 'two compressed areas' in $0197000.FL1?

Yes $0197000.FL1 was also what I used (in combination with WinPhlash) to eventually extract my BIOS.

An idea occurs to me. If you search the topics here for, say, FL1, you'll see a number of references. It appears that most people in the past, when they would pull apart the diskette BIOS flash kit, would get multiple FL1, 2s or 3. That it, they would typically get either an FL1 and an FL2 or an FL1 and FL3 (all beginning with $).

These translated (you'll see in the posts) into two files: BIOS.ROM and PLATFORM.BIN. PLATFORM.BIN also plays an important role (although I don't know exactly how it works [yet]).

Since there's only 1 'FL file' to be found now in the kits, may I suggest that the first compressed area you saw was BIOS.BIN (your BIOS) and the other PLATFORM.BIN.

I believe most varieties of phlash.exe (whether phlash16.exe or phlash.exe [32 bit I assume]) require both files.

Again, would like to know how you saw this?

thanx.

pat

[phewtoo]

>Again, would like to know how you saw this?
Nothing more than an observation I made while scrolling through the file in an hex editor.

There is a DOS tool that decompresses the issued files called PHCOMP.EXE, I used phcomp /d $0197000.fl1 to decompress.

It only produced 1 file though, so maybe my 'two' compressed areas idea is wrong.

The produced file was 12(dec) bytes longer than the dump; the extra bytes added to the end as 0xC300....00.

[patfla]

Phewtoo,

OK I confess. Now I'm doubly stumped. What pattern(s) does one look for when one eyeballs code in a hex editor as evidence of compression (I think I read somewhere around here: high bit set much more often than should be the case)?

And second. PHCOMP.EXE. I've looked around the Web (and elsewhere). I've found one reference in something from 'Borg Number One' (who seems to do a lot of BIOS stuff). This indicated that it was maybe in the WinPhlash kit. I have a WinPlash kit and there's no PHCOMP.EXE to be found in it.

So where does PHCOMP come from? (the name PH would almost certainly indicate Phoenix - but I don't find this particular Phoenix-related name anywhere).

I try (as I do also where I work) that when I refer to some complicated matter, the details of which others may not (probably don't) know, I actually provide the details. This came (and seems to still come) as a revelation to other programmers that I work with. I seek neither to mystify nor to hide what I know.

pat

[phewtoo]

patfla

I had PM'd you with some info but here is the thread linking to phcomp.exe

http://www.wimsbios.com/phpBB2/viewtopic.php?t=5763&

[patfla]

thanx Phewtoo,

I'm sorry. Apologize for my inappropriate tone.

pat

[patfla]

A slight aside. If you look at my phnxdeco output above, you'll see that it claims that the ROM has a boot block (of some 10,000 bytes).

Does that mean that Thinkpads support the bad BIOS flash boot block recovery method as described here?

http://www.wimsbios.com/HTML1/faq.html#q9

I'd think, though, that if Thinpads did support this recovery method, I'd have read about it here in the thinkpads forums. Instead I've read of bad flashes leaving dead and unrecoverable machines.

And yet this boot block recovery method (as I read around on the Web) seems to be pretty standard in newer laptops.

pat

[jamhill]

Pat,

Looking at the file structure for PHNXDECO it shows the following, but when I decompress the bios I only get 43 files. There are 49 listed below. According to Paul Sladens site, the PHNXDECO does not recognize the TCP files in the bios, so apparantly it jsut does not decompress them. Maybe this is where the whitelist now resides? In the newer laptops maybe they moved the whitelist to the TCP section of bios.

Anyway, if I pull up the full rom in a hexeditor, and compare it to the output from one of the decomped files, they are different. So it appears that even though winphlash or phlash16 says they pull a decompressed bios, the individual parts are still compressed.

Im trying to find the source for PHNXDECO. It shouldnt be hard to cut and paste and add some routines so they recognize and thus decomress the /,*,X etc modules.

FYI. Im on an X41, and want to swap the miniPCI for one that linux and os x will support. The no-1802.com does not work on this either.

Any Ideas?? Anyone?

TIA,
J

-=PhoenixDeco, version 0.31 (DOS)=-

Filelength : 80776 (526198 bytes)
Filename : bios1.0.bak
PhoenixBIOS hook found at : 6F250
System Information at : 6F282
BootBlock : 10000 bytes
BankSize : 1024 KB
Version : 74ET30WW
Start : 68189
Offset : 70000
BCP Modules : 146
BCPFCP : 75EAB
FCP 1st module : 2285 (72285)
Released : 31 January 2005 at 10:27:06
/* Copyrighted Information */
Phoenix FirstBIOS(tm) Notebook Pro Version 2.0 for IBM ThinkPad
/* ----------------------- */

================================== MODULE MAP =================================
Class Code
. Instance
. .
C I LEVEL START END LENGTH RATIO LINK TO FILEOFFSET
---- ----- --------- --------- ------ ----- --------- ----------
X 0 NONE FFF6 8189 FFFE FFEF 7E4C 100% FFFE 7506 68189h
D 0 LZINT FFF6 7506 FFFE 8188 C68 67% FFFE 70BB 67506h
G 0 NONE FFF6 70BB FFFE 7505 430 100% FFFE 6283 670BBh
V 0 LZINT FFF6 6283 FFFE 70BA E1D 9% FFFE 61EB 66283h
A 0 LZINT FFF6 61EB FFFE 6282 7D 51% FFFE 619D 661EBh
A 1 NONE FFF6 619D FFFE 61EA 33 100% FFFE 614F 6619Dh
A 2 NONE FFF6 614F FFFE 619C 33 100% FFFE 60F1 6614Fh
A 4 LZINT FFF6 60F1 FFFE 614E 43 81% FFFE 60AD 660F1h
A 5 LZINT FFF6 60AD FFFE 60F0 29 82% FFFE 604D 660ADh
A 6 LZINT FFF6 604D FFFE 60AC 45 76% FFFE 6004 6604Dh
A 7 LZINT FFF6 6004 FFFE 604C 2E 76% FFFE 5F8B 66004h
L 1 LZINT FFF6 5F8B FFFE 6003 5E 17% FFFE 5EDE 65F8Bh
L 2 LZINT FFF6 5EDE FFFE 5F8A 92 20% FFFE 5E4F 65EDEh
L 3 LZINT FFF6 5E4F FFFE 5EDD 74 37% FFFE 5E0C 65E4Fh
L 4 LZINT FFF6 5E0C FFFE 5E4E 28 74% FFFE 5DCC 65E0Ch
L 5 LZINT FFF6 5DCC FFFE 5E0B 25 88% FFFE 5D49 65DCCh
L 6 LZINT FFF6 5D49 FFFE 5DCB 68 19% FFFE 5CBD 65D49h
L 7 LZINT FFF6 5CBD FFFE 5D48 71 21% FFFE 5C31 65CBDh
L 8 LZINT FFF6 5C31 FFFE 5CBC 71 21% FFFE 5BA6 65C31h
L 9 LZINT FFF6 5BA6 FFFE 5C30 70 21% FFFE 5B1C 65BA6h
L A LZINT FFF6 5B1C FFFE 5BA5 6F 20% FFFE 5AE7 65B1Ch
L B NONE FFF6 5AE7 FFFE 5B1B 1A 100% FFFE 5A8A 65AE7h
L C LZINT FFF6 5A8A FFFE 5AE6 42 37% FFFE 576F 65A8Ah
L E LZINT FFF6 576F FFFE 5A89 300 18% FFFE 4EBD 6576Fh
L F LZINT FFF6 4EBD FFFE 576E 897 27% FFFE 4E7A 64EBDh
* 0 NONE FFF6 4E7A FFFE 4EBC 28 100% FFFE 0005 64E7Ah
X 1 NONE FFF6 0005 FFFE 4E6F 4E50 100% FFFD C746 60005h
S 0 LZINT FFF5 C746 FFFE 0004 38A4 40% FFFD 9F1B 5C746h
C 0 NONE FFF5 9F1B FFFD C745 2810 100% FFFD 1458 59F1Bh
R 0 LZINT FFF5 1458 FFFD 9F1A 8AA8 54% FFFC CC6C 51458h
R 1 LZINT FFF4 CC6C FFFD 1457 47D1 59% FFFC 712B 4CC6Ch
R 2 LZINT FFF4 712B FFFC CC6B 5B26 59% FFFC 2914 4712Bh
E 0 LZINT FFF4 2914 FFFC 712A 47FC 41% FFFB F0C1 42914h
T 0 LZINT FFF3 F0C1 FFFC 2913 3838 46% FFFB 4733 3F0C1h
M 0 LZINT FFF3 4733 FFFB F0C0 A973 67% FFFA 9EE0 34733h
Q 0 LZINT FFF2 9EE0 FFFB 4732 A838 49% FFFA 4C46 29EE0h
A 3 LZINT FFF2 4C46 FFFA 9EDF 527F 36% FFFA 242B 24C46h
L 0 LZINT FFF2 242B FFFA 2488 43 54% FFF9 EFFF 2242Bh
L D LZINT FFF1 EFFF FFFA 242A 3411 19% FFF9 EB45 1EFFFh
L 10 LZINT FFF1 EB45 FFF9 EFFE 49F 9% FFF9 E4E6 1EB45h
L 11 LZINT FFF1 E4E6 FFF9 EB44 644 11% FFF9 A67F 1E4E6h
H 0 LZINT FFF1 A67F FFF9 E4E5 3E4C 71% FFF9 A4EF 1A67Fh
< 0 LZINT FFF1 A4EF FFF9 A67E 175 62% FFF8 A4D4 1A4EFh
/ 0 NONE FFF0 A4D4 FFF9 A4EE 10000 100% FFF8 A242 A4D4h
F 0 LZINT FFF0 A242 FFF8 A4D3 277 61% FFF8 8227 A242h
- 0 NONE FFF0 8227 FFF8 97C4 1583 100% FFF8 7FFE 8227h
K 1 LZINT FFF0 7FFE FFF8 8226 20E 88% FFF8 6000 7FFEh
B 0 LZINT FFF0 6000 FFF8 7FFD 1FE3 24% FFF7 E7E5 6000h
Total Sections: 49

[patfla]

Hello jamhill,

Could you provide use with the file names. I'm trying to reconcile what you have with what I have.

The (acceptable) mini-PCI card whitelist in the TCP (Trusted Computing) modules - yes, it seems possible.

And I believe (I should go back and check) that the phnxdeco source was at the same location as the EXE (.ru). What you propose seems worthwhile.

In the meanwhile I'm headed of in some different directions. This may seem meager but I've actually been able to reconcile what's in the BCPOST section (part of the Bios Configuration Parameters module as sen in the Phoenix BIOS Editor) with what I find in the ROM itself in hex (byte swapped of course).

And I twiddled one bit; output it to a new version of the BIOS (but hadn't changed EXTD yet [the checksum]). And sure enough found my mod.

And a perhaps not uninteresting bit at that. In the Phoenix BIOS Editor open your ROM and go to the subwindow with 'BIOS Configurations Parameters'. Select POST from the drop-down. The very first section (2 bytes) has the value 0100h. The section is called:

Errors to ignore

(hmm this sounds good). I don't see PCI explicitly referred to among any of the 16 (2 bytes) items.

But there is an 'Other Error'. This is the bit I set.

Well I suppose this could wreak all kinds of havoc (or maybe not). The key is to be able to back up (recover from a damaged BIOS).

And for that I'd refer to my earlier post about 'boot block recovery'. After considerably trawling of the Web, IBM does indicate that certain machines have 'boot block recovery'. But does my T43?

I'm planning on calling IBM Tech Support tmw.

Duh! (sometimes it helps to start by trying the obvious).

I've found the guys in Atlanta to be very good. And helpful.

Thinkpads, even now under Lenovo, will receive IBM support for the next yr, two, whatever.

pat

[patfla]

Provided one figures out what to change and where (hint, hint), how then do you put it all back together?

I can think of two options.

1. PREPARE and CATENATE. This runs over the modules output by phnxdeco. The problem is is that phnxdeco, currently, is not outputting the modules associated with the Trusted Computing stuff. (E.g. <,?,Q,V, etc). So one assumes this would be incomplete and thus this method a non-starter (unless one can find the .31 source).

1a. And I looked (per someone above). On the Russian phnxdeco web site you can supposedly find the source to all pre .31 versions (although, looking quickly, I didn't see where the sources were). In the downloads for .31, which is of course the only one that will do FirstBIOS, there's no source.

2. Phoenix BIOS Editor. This ‘complains’ when reading in the Trusted Computing modules. But they are there in some sense. And when you do a Build ROM and then output it, it’s the right size. And if you then pass phnxdeco over that, the trusted modules are all there.

2a. The problem with this is that Phoenix BIOS Editor, while it allows you to edit some of the modules, doesn’t seem to allow me to edit the module in which I’ve found the mini-PCI wireless whitelist for my T43.

Another question, I seem to have found indications various places, that CATENATE (if you can get it to work [in this case, have all the modules]) will handle the checksum itself (EX TD aa bb cc dd 00 00 00 00 CK SM - fill in the aa bb cc dd part)?

pat

[jamhill]

Interesting you have Phoenix Bios editor working with your image. When I try to load it I

get all of the TCP module errors, but then it gets stuck in an apparant loop with the

errors:
Bad record number
Subscript out of range
repeat...

I have not created a macro to "Ignore" all of these errors indefinitly to see if it just

does not like something in the rom and will eventually get to the end of the errors and load the file. But im not too confident that the output would be useful even if it did load.

Same issues here locating the .31 source. I have not checked IRC or the torrents, but

those are next.

It seems the Bios on my old X30 and X41 are almost identical so I dont anticipate that

they are doing anything more on the X41 vs X30 in terms of miniPCI whitelist checking. So

if we can find the actual list, it should be easy to mod. In theory anyways. according to

Sladen's site, the checksum is only for the entire rom. So it "should" not be too

difficult to modify to account for the changes.

Im not familiar with PREPARE and CATENATE, but will look into these.

Interesting note about the bit flipping. When you say you found your mod, where did you

find it? I assume you recompiled the modules into the rom and then opened it up in a hex

editor and found it?

As far as putting it togather PHNXDECO builds a rom.scr file that they claim is for

recompiling the rom. However I have not figured out how it invoke this yet. Maybe phnxdeco rom.scr -p???

For the PHNXDECO file outputs I get the following from:
phnxdeco bios.bak -xs > biosfiles.txt

-=PhoenixDeco, version 0.31 (DOS)=-

Filelength : 80776 (526198 bytes)
Filename : bios1.0.bak
PhoenixBIOS hook found at : 6F250
System Information at : 6F282
BootBlock : 10000 bytes
BankSize : 1024 KB
Version : 74ET30WW
Start : 68189
Offset : 70000
BCP Modules : 146
BCPFCP : 75EAB
FCP 1st module : 2285 (72285)
Released : 31 January 2005 at 10:27:06
/* Copyrighted Information */
Phoenix FirstBIOS(tm) Notebook Pro Version 2.0 for IBM ThinkPad
/* ----------------------- */

BootBlock ... O'k
X.0 ROMEXEC0.rom ... O'k
D.0 DISPLAY0.rom ... O'k
G.0 DECOMPC0.rom ... O'k
V.0 User-De0.rom ... O'k
A.0 ACPI0.rom ... O'k
A.1 ACPI1.rom ... O'k
A.2 ACPI2.rom ... O'k
A.4 ACPI4.rom ... O'k
A.5 ACPI5.rom ... O'k
A.6 ACPI6.rom ... O'k
A.7 ACPI7.rom ... O'k
L.1 LOGO1.rom ... O'k
L.2 LOGO2.rom ... O'k
L.3 LOGO3.rom ... O'k
L.4 LOGO4.rom ... O'k
L.5 LOGO5.rom ... O'k
L.6 LOGO6.rom ... O'k
L.7 LOGO7.rom ... O'k
L.8 LOGO8.rom ... O'k
L.9 LOGO9.rom ... O'k
L.A LOGOA.rom ... O'k
L.B LOGOB.rom ... O'k
L.C LOGOC.rom ... O'k
L.E LOGOE.rom ... O'k
L.F LOGOF.rom ... O'k
*.0 User-De0.rom ... O'k
X.1 ROMEXEC1.rom ... O'k
S.0 STRINGS0.rom ... O'k
C.0 UPDATE0.rom ... O'k
R.0 OPROM0.rom ... O'k
R.1 OPROM1.rom ... O'k
R.2 OPROM2.rom ... O'k
E.0 SETUP0.rom ... O'k
T.0 TEMPLAT0.rom ... O'k
M.0 MISER0.rom ... O'k
Q.0 User-De0.rom ... O'k
A.3 ACPI3.rom ... O'k
L.0 LOGO0.rom ... O'k
L.D LOGOD.rom ... O'k
L.10 LOGO10.rom ... O'k
L.11 LOGO11.rom ... O'k
H.0 User-De0.rom ... O'k
<.0 User-De0.rom ... O'k
/.0 User-De0.rom ... O'k
F.0 FONT0.rom ... O'k
-.0 User-De0.rom ... O'k
K.1 User-De1.rom ... O'k
B.0 BIOSCOD0.rom ... O'k
Total Sections: 49

The interesting part here is that whatever modules phnxdeco does not recognize it

decompresses them as User-De0.rom, and guess what, there are mulitple files it does not

recognize so the previous ones just get overwritten. So out of 49 modules, I get 43. There

are 7 User-De0.rom's outputted so 6 are simply overwritten, which explains the missing 6

files.

J

[LtTPfan]

Have you found any indication there is no longer a flag bit in CMOS as there has been for earlier models (the nexus for the no-1802 fix)? It would seem odd that IBM would forgo this. It seems more likely they just changed the location for one reason or another. Finding the flag bit and changing it seems by far the safer approach than modifying the BIOS and wouldn't require going thru the same steps with each BIOS upgrade. If you have a dissassembly you could look for instructions similar to these:

MOV DX,0070 ; port address for CMOS (system clock)
MOV AL,6A ; offset to desired byte in CMOS--6A bit 7 has 1802 flag in earlier TPs
OUT DX,AL ; to read CMOS you must 1st write to port 70
MOV DX,0071 ; setup to read CMOS
IN AL,DX ; here the CMOS byte is actually read from port 71

We know from the fact that no-1802.com doesn't work that 6A.7 is not the proper bit but another bit in 6A could be used, or another byte altogether. The above instructions would likely be followed by (AND AL,??), where ?? is a bit mask so the proper bit(s) are isolated.

If you don't find a similar set of instructions in your disassembly it may be that you don't have a good disassembly as in order to get a proper disassembly you have to start at the right place, starting just one byte off can completely skew the disassembly.

[LtTPfan]

I forgot to mention to be sure to disassemble as 16 bit, not 32 bit. The BIOS program is always run in 16 bit as the devices to enable 32 bit operation have yet to be initialized.

[jamhill]

How do you disassemble the CMOS? Im sure there are utilities, any idea where I can find them? Google didnt yield anything useful.

[LtTPfan]

You don't disassemble the CMOS, it just contains data. You disassemble the program areas of the BIOS. The BIOS contains both program and data areas. That presents one of the biggest challenges in reverse engineering, figuring out what is code, what is data, and what is the starting point of the code.

CMOS is usually 128 bytes and contains the system clock (the first 14 bytes) as well as configuration data such as how many and what types of hard drives, floppy drives, etc. It also contains user space, that which the manufaturer uses for flags etc. such as for ignoring certain errors like 1802, keyboard, or whether to use onboard cache and speedstepping, etc.

If you are looking for a starting point of your BIOS code, consider the line from above "PhoenixBIOS hook found at : 6F250." Another term commonly used for "hook" is "interrupt vector." Sometimes you'll find small segments of code but often there is just an address to where the code starts, or it might actually be the starting point of code. That's something you'll have to figure out based on what's there, and your knowledge and experience with code.

If you don't find the strings I indicated in my previous post in the disassembly it might be because the disassembler has confused it with data, or that the disassembly started at the wrong place. Here is the actual machine code:

BA 70 00 B0 6A EE BA 71

I heard it mentioned that the BIOS is byte reversed. That's not true, it's just that the editor used is reading/displaying "words" not "bytes" from the file. It just depends on what you are viewing the file with.

The above could be shown as:

70BA B000 EE6A 71BA

Of course that assumes the indicated code starts on a word boundary. It could also be:

0070 6AB0 BAEE

Remember though, the 6A could be any value but will likely be between 40 and 7F.

[patfla]

I've found the whitelist for the my T43, but people have asked about the CMOS solution and so I've been looking into that as well.

For one, download the IBM Hardware and Maintenance Manual for your machine type. I find that my CMOS is no longer the standard 128 bytes but rather 252! That's interesting. Wish I knew what they were putting in there.

The other half, as it were, of the CMOS equation, is figuring out where it's accessed in the BIOS code. One would think that the 1802 error (or rather what provokes it) would be in the 'POST' code. Well one can find BCPOST easily, but this (small) section consists of definitions and, I'm assuming, not the POST code itself (although maybe a part of it is a pointer off to the start of the main body of POST code?). This also requires better disassembly than IDA has been giving. And so have been trying to improve on that as well.

Making progress in a number of ways, but have had less time for fun and games recently, and progress is slow.

pat

[jamhill]

Where did you find the whitelist? What module was it in? Did you use phnxdeco?

I feel ya man, work has had me covered. Have not had much time to dig on this. However seems I may have both a faulty video card and a bad Intel Nic. That means corporate hardware replacement! So no better time to test the BIOS edits.
Ill be looking into this more this weekend.

Any recommendations on a disassembler? I havnt programmed assembly since college (where I did it alot), but it shouldnt be to hard to get back up on it.

J

[jamhill]

I installed IDA Pro Freeware.

You may already have seen this, but just in case,
Check out:
http://www.wimsbios.com/phpBB2/viewtopic.php?p=32840&

about getting the BIOS to disassemble.

[patfla]

My T43 (266889u) whitelist is at the beginning of BIOSCOD5.ROM (as extracted by phnxdeco .31).

The EXTD (checksum) stuff is near the start of ROMEXEC0.ROM.

I'm not sure that you need to compute the checksum for yourself per Sladen's web page. I believe that proper use of PREPARE.EXE and CATENATE.EXE will do this for you. You can always rebuild your BIOS in this fashion and then go into ROMEXEC0.ROM and verify that the new checksum is correct.

So that's cool. But I'm worred about a bad flash or a bad ROM period. Still researching "boot block recovery".

And found this very intriguing thing at www.sourceforge.net:

https://sourceforge.net/projects/abios-rtool

IBM did tell me that a bad BIOS would cost me a new mobo at (something like) $725. Must be a better way.

pat

[patfla]

And yes I'm using IDA.

Learning curve, but actually making pretty good progress.