Any idea how I can extract a BIOS image?

[jamhill]

Pat,

Did you do anything special to get BIOSCOD5.rom ? I only have BIOSCOD0.rom in my decomp. Can you post the hex output of your whitelist? I bet its the same for both of our machines, so I figure if I search for one of your PCI IDs I will find the location.

I have tried searching for 86 80 24 42 and various combinations starting on different bit boundaries, all to no avail.

Thanks!
J

[patfla]

Hi jamhill,

That's why I asked you what kind of machine you have?

Different machines have different modules and different numbers of such.

What might be helpful is if, in addition to giving us your mch type, you also give a file listing of all the names that phnxdeco extracted?

pat

[jamhill]

Im using an IBM X41 (non tablet).

Here is the list of files:
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

[patfla]

Hi Jamhill,

Here's the hex dump of my whitelist from BIOSCOD5.ROM. (I use hexl-mode in Emacs for quick reading [but it won't write]).

Whitelist starts on byte 0x30. The pattern is 8 bytes; a zero byte; 8 bytes; a zero byte. Etc. (each 8 bytes corresponding to an adapter that is).

168c (swap the bytes) is Atheros which I assume to be an IBM branded mini-PCI adapter.

pat

00000000: 4243 d6f1 0031 3105 421b 0540 1507 00c0 BC...11.B..@....
00000010: aa00 0000 0000 0000 0000 00e9 ed68 8c16 .............h..
00000020: 1410 1410 7e05 0086 8020 4286 8011 2700 ....~.... B...'.
00000030: 8680 2042 8680 1227 0086 8024 4286 8010 .. B...'...$B...
00000040: 1000 8680 2442 8680 1110 0086 8024 4286 ....$B.......$B.
00000050: 8012 1000 8680 2442 8680 1310 008c 1613 ......$B........
00000060: 0068 1408 0400 0000 0000 0000 0000 0005 .h..............
00000070: 7605 0074 0504 7405 0700 00eb 02f9 c3f8 v..t..t.........
00000080: c300 0000 0000 0000 0000 001e 0600 2106 ..............!.
00000090: 0024 0600 2706 0033 0600 3006 0036 0600 .$..'..3..0..6..
000000a0: 7a04 007d 0400 8004 0007 0500 0f03 006a z..}...........j
000000b0: 0500 d800 0096 0000 9900 003f 0000 1503 ...........?....
000000c0: 007c 0200 8304 0086 0400 8904 000f 0600 .|..............
000000d0: 6405 0067 0500 6f00 0093 0000 6702 0066 d..g..o.....g..f
000000e0: 0000 6900 006c 0000 ae00 008a 0000 8d00 ..i..l..........

[patfla]

Hi, maybe I can get some help here. I've done my share of hex over time, but this BIOS (4-byte) checksum has me flummoxed so far.

I twiddled one bit in the BCPOST section via the Phoenix BIOS Editor (possibly a crucial bit for this particular problem [1802]). Then rebuilt a new BIOS via PREPARE and CATENATE. Here are the results.

original

00 01 FF FF

45 58 54 44 (EXTD CKSM)

modified

00 81 FF FF

19 2f 54 44 (EXTD CKSM)

I've tried to format things as best I can given the limitations of this editor.

According to Sladen's page the way the global BIOS checksum works is that all 4 byte sequences are added up (with presumably bits rolling off the top and getting lost). And then a 4 byte sequence (the cksm) is added just after 'EXTD' that causes the whole (4 byte) value to go to zero.

Fine.

The bit I twiddled (above) is byte 2 (or 1 if you want to byte-swap) from 01 to 81.

Now it's nice to know that (in some sense)

00 01 FF FF went to (cksm) 45 58 54 44

and in the modified version

00 81 FF FF went to 19 2f 54 44.

That is, the 8 in 81 is in the first two bytes, and the last two bytes, which should preserve their translation do so with FF FF translating to 54 44.

But how the heck does the change from

00 01 to 00 81

take you to

45 58 translating to 19 2f

I've tried all sorts of combinations (trial-and-error) as well as trying to reason the thing through and so far can't figure it out.

Oh. I do feel pretty sure that the new checksum is right (so what I'm chasing is real).

Hope someone can explain this to me.

Of course, I've read the checksum section in Sladen's page many times.

Although there's one thing.

In what universe does

(0x51+0x27 = -0x2a) ! from Sladen's page

As it happens this does work

(0x51-0x27 = 0x2a)

Or is there something I'm missing (say with rollover [into negative territory])?

pat

[patfla]

Ah.

Windows command

fc /b file1 file2

I can see the bit I twiddled. I can see actually 3 bytes worth of changed CKSM.

And I can see just one more location, near neither BCPOST nor EXTD, that had one bit twiddled (by CATENATE.EXE).

The mists are clearing.

pat

[patfla]

Largely ignore all the numbers 2 posts above.

The new (correct ) numbers are as follows:

00 01 FF FF
00 81 FF FF


00 00 00 84 FF FF FF FF
00 00 00 04 FF FF FF FF

old
99 2e 94 d6


new
19 2f 14 d6

What got twiddled is a the top. There are two changes - 1 bit each.

'old' and 'new' refer to how the CKSM has changed.

You can see the differences (in the CKSMs) of 8 (topmost bit) when comparing 99 with 19 and 94 with 14.

What I can't yet fully account for is the change, in the CKSM, from 2e to 2f.

Still, there is all just verification. I feel reasonably confident that CATENATE is doing its job correctly. That is, based on what's outside
EXTD HH HH HH HH HH HH HH HH CKSM, changing the first four HHs that are inside appropriately. To bring the whole thing to zero.

And learned more along the way. Finally definitely found the 'famous' JMP to be found at the top of the ROM. Address ffff0h as advertised.

I'm looking at various emulators (say, BOCHS off sourceforge) to see if I can actually step through my T43 ROM image.

pat