IBM non-authorised Mini-PCI wireless card, Sir?

C  I   LEVEL      START       END     LENGTH  RATIO   LINK TO   FILEOFFSET
----   -----    ---------  ---------  ------  -----  ---------  ----------
X  0    NONE    FFFE 85DD  FFFE FFFD   7A06    100%  FFFE 7372    E85DDh
D  0    NONE    FFFE 7372  FFFE 85DC   1250    100%  FFFE 5347    E7372h
C  0    NONE    FFFE 5347  FFFE 7371   2010    100%  FFFE 4EFC    E5347h
G  0    NONE    FFFE 4EFC  FFFE 5346    430    100%  FFFE 4DED    E4EFCh
A  0    NONE    FFFE 4DED  FFFE 4EFB     F4    100%  FFFE 4D9F    E4DEDh
A  1    NONE    FFFE 4D9F  FFFE 4DEC     33    100%  FFFE 4D51    E4D9Fh
A  2    NONE    FFFE 4D51  FFFE 4D9E     33    100%  FFFE 4CE4    E4D51h
L  1    NONE    FFFE 49F5  FFFE 4C21    212    100%  FFFE 4708    E49F5h
L  2    NONE    FFFE 4708  FFFE 49F4    2D2    100%  FFFE 46D3    E4708h
R  0   LZINT    FFFD 0720  FFFD 850A   7DD0     49%  FFFC A705    D0720h
R  1    NONE    FFFC A705  FFFD 071F   6000    100%  FFFC 2EEA    CA705h
R  2    NONE    FFFC 2EEA  FFFC A704   7800    100%  FFFB E9F8    C2EEAh
E  0   LZINT    FFFB E9F8  FFFC 2EE9   44D7     40%  FFFB B16D    BE9F8h
T  0   LZINT    FFFB B16D  FFFB E9F7   3870     48%  FFFA BCF2    BB16Dh
M  0    NONE    FFFA BCF2  FFFB B16C   F460    100%  FFF9 8D77    ABCF2h
Q  0    NONE    FFF9 8D77  FFFA BCF1  12F60    100%  FFF9 42B6    98D77h
A  3   LZINT    FFF9 42B6  FFF9 8D76   4AA6     37%  FFF9 1A9B    942B6h

You'll notice that the files don't have names, but like a Zip file they have start and end locations, lengths and some are compressed. The left-hand two columns are Class and Instance. The single letter can be thought of as the file name and the second column makes sure there are classes. L1 and L2 are the first and second bitmaps Logos in the image. The names translate as follows: (list from phnxdeco source).

case 'A': return("ACPI");		// ACPI AML/Table
case 'B': return("BIOSCODE");           // BIOSCode Group
case 'C': return("UPDATE");             // CPU P6Update
case 'D': return("DISPLAY");            // Display
case 'E': return("SETUP");              // Editor
case 'F': return("FONT");               // 
case 'G': return("DECOMPCODE");		// 
case 'I': return("BOOTBLOCK");          // 
case 'L': return("LOGO");               // Logo Bitmap
case 'M': return("MISER");              // Power Management
case 'N': return("ROMPILOTLOAD");       //
case 'O': return("NETWORK");            // Networking
case 'P': return("ROMPILOTINIT");       //
case 'R': return("OPROM");              // PCI Option ROM
case 'S': return("STRINGS");            // User Interface Strings
case 'T': return("TEMPLATE");           // 
case 'U': return("USER");               //
case 'X': return("ROMEXEC");            // Bootstraping?
case 'W': return("WAV");                // Audio
default: return("User-Defined");

This ThinkPad BIOS also contains additional type/files called '*' 'H' 'K' '<' and 'Q' which all seem to be related to the TCPA (Trust Computing) components in the ThinkPad. The default: statement above means that phnxdeco screws up extracting these weird files. Wish I had the source to the latest version to fix it :-(.

Get to the point!

This long excursion with trying to explode and then recombine the BIOS images was to investigate checksuming. What would happen if we just hex-edited the bytes in an individual module and recombined them? Well, it turns out not much happens, there are no module-specific checksums, but there is a global checksum for the whole BIOS.

000e86c0  45 58 54 44 15 c5 0a b6  00 00 00 00 43 4b 53 4d  |EXTD........CKSM|
                      ^^^^^^^^^^^                                             
                32-bit additive checksum                    Extended  Checksum

The checksum is such that when the entire file is added up, four bytes at a time, the result is zero. To make this happen, the value in-between the Extended Checksum brackets is changed. In short, if you change a value upwards (add), then you need to subtract the same difference from the correctly aligned byte of the checksum.

Putting theory into practice

This information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. When you fry your laptop and have to send it back to IBM, do not blame me!

Remember that wifi card with ID 8086:1043/8086:2527 ? After hexediting the file, the differences in the 1st, 2nd and 3rd columns are zero; but in the 4th column the difference is (0x51+0x27 = -0x2a) meaning that +0x2a must be added onto the checksum in the correct column—the net effect must be ``zero''. (0xb6+0x2a=0xe0):

           1--2--3--4   1--2--3--4  1--2--3--4   1--2--3--4
 0006acb0  53 42 01 01 10 00 06 14  10 2e 05 58 c3 e9 77 1a  |SB.........X..w.|
-0006acc0  8c 16 14 10 ab 17 31 83  00 86 80 43 10 86 80 51  |......1....C...Q|
+0006acc0  8c 16 14 10 ab 17 31 83  00 86 80 43 10 86 80 27  |......1....C...Q|
 0006acd0  25 00 8c 16 13 00 68 14  08 04 00 86 80 20 42 86  |%.....h...... B.|

 000e86b0  44 2a 5c 2a 71 2a 79 2a  8c 2a 94 2a 8e 6c 63 00  |D*\*q*y*.*.*.lc.|
-000e86c0  45 58 54 44 15 c5 0a b6  00 00 00 00 43 4b 53 4d  |EXTD........CKSM|
+000e86c0  45 58 54 44 15 c5 0a e0  00 00 00 00 43 4b 53 4d  |EXTD........CKSM|
 000e86d0  58 09 b4 1b 6a 24 23 27  55 00 e5 00 02 50 d8 80  |X...j$#'U....P..|

Hey Presto, save, burn, flash, insert, boot and congratulate yourself for having beaten Big Blue at their own game—and saved £100.00!

Further Investigation

Nota Bene: Need to confirm the exact ordering of the bytes in all cases (little-endian?). XOR produces a similar result but with an inverted top-bit, proving that the checksum is additive and has carry issues. Following diff was generated using prepare and catenate programs and is known to be correct. The phflash also has a flag for validating that the checksum is correct:

-0008ab60  51 25 00 8c 16 13 00 68  14 08 04 00 86 80 20 42  |Q%.....h...... B|
+0008ab60  68 24 00 8c 16 13 00 68  14 08 04 00 86 80 20 42  |h$.....h...... B|

-000a00e0  8c 2a 94 2a 8e 6c 63 00  45 58 54 44 f4 6e 3e 7b  |.*.*.lc.EXTD.n>{|
+000a00e0  8c 2a 94 2a 8e 6c 63 00  45 58 54 44 dd 6f 3e 7b  |.*.*.lc.EXTD.o>{|

>>> hex(0x5125-0x6824+0xf46e) + ' Correct'
'0xdd6f Correct'
>>> hex(0x5125^0x6824^0xf46e) + ' Wrong'
'0xcd6f Wrong'
>>> hex(0x2551+0x2468+0x6ef4) + ' Wrong'
'0xb8ad Wrong'

In Addition, some of the following could be lines of investigate:

• Find the check routine and NOP it out.
• Find the check routine and alter the PCI-class from 0x0280 (network device) to an unused code so that no card is flagged as something the BIOS should investigate further.

Taking it further, Sravan Ravinutala reports that he had modified his BIOS and accidently flashed it with an incorrect checksum. Thankfully his machine booted fine again and so it would appear that the checksum is only there for the benefit of the flash utility to check integrity of the file and not for the BIOS itself to check. If you flash the image using the `devbios' support under Linux then you should just be able to hex-edit the BIOS image.

Nota Bene: Do not rely on this.

BIOS Flashing under Linux

In 1998, Stefan Reinauer announced a `/dev/bios' device and then announced an update a couple of months later; then again in 2000. It seems to have lived in OpenBIOS CVS since. I got this driver to work on my ThinkPad R31 (it intelligently knows about a whole series of Flash types) and using it was as easily as typing:

# make
# insmod ./bios.o
# cat /proc/bios
# dd if=/dev/bios bs=4k of=./my-bios.img

[no reboot required!] The reason for doing it as a kernel module rather than a userspace program seems to be to guarantee time-critical requirements when writing to a chip, if you were doing the equivalent in userspace, you'd have to do lots of ugly hacks to stop your program with being task-switched to another process in the middle:

• http://www.openbios.org/development/devbios.html
• http://www.openbios.org/bin/devbios-0.3.2.tar.gz (dated 2002-02-19)
• http://www.freiburg.linux.de/~stepan/bios/
• http://www.uwsg.iu.edu/hypermail/linux/kernel/9804.1/0731.html
• http://www.uwsg.iu.edu/hypermail/linux/kernel/9802.1/0205.html

In 2003 Jeremy Jackson ported the code to the Linux MTD (Memory Technology Device) framework which means means [in theory] you can use the flash socket on a network card to reflash your system BIOS. Think of MTD as covering all the types of Flash that aren't Compact Flash/SD Cards. Specifically, MTD devices have to be [silently] erased first and things—yes, I know the name sucks and as always confused me:

• http://lists.infradead.org/pipermail/linux-mtd/2003-March/007274.html

FreeBIOS (aka LinuxBIOS) also appear to have some tools. I have so-far failed to get these to work, even out of CVS:

• http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?... (flash_and_burn and `flash_rom')
• http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?... (Howto)

Paul Sladen and Matthew Garrett. 2004-04-27 → 2004-04-29 by the end of which, Matthew had a working laptop with MiniPCI wireless