romfile block structure * I try keep post small enough to easy to understand and easy to edit. romfile consists of sections: Module chains (type A, B, C - see below) uncompressed AND compressed modules * Module chain can have one module only. Standalone modules, like: Boot record modules (AA 55) (uncompressed) BIOS recovery module BIOS entry module - should be uncompressed, contains uncompress code and obviously perform other modules un-compression. I cannot explain why, but for D620/D630 the module contains uncompress code is compressed itself AND actually is “DUMP UTILITY FOR I/O, MEMORY AND PCI” (i.e. BIOS recovery) module It means it should be another uncompress code module somewhere… * If section length not divisible by 2KB (2048B) it’s padded by FF (almost always) Module chains: Modules are saved in the chain structure (as described by shakeyplace) I saw 3 chain types so far: For HDR starting with 00000000 24 52 42 55 54 01 $RBUT. Aka $RBUT01 (A) 2 bytes module length + 1 byte module type (OptiPlex GX620, Dimension 4600, i.e. older models, without SLIC) (B) 1 byte module type + 4 bytes module length (Latitude D620) For HDR starting with 00000000 24 52 42 55 54 02 $RBUT. Aka $RBUT02 (C) 4 bytes module length + 1 byte module type * Chains (B) and (C) may contain pubkey and marker
compression algorithm compression algorithm is a combination LZSS & RLE To understand try to match red codes in "Compressed piece" and "Uncompression log" * BIOS modders can skip this part - it's for programmers mostly Code: Compressed piece Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------------------- Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 F0 00 43 6F 70 79 72 69 67 68 74 20 31 39 38 35 ð.Copyright 1985 00000010 2D 02 04 F0 0F 38 20 50 68 6F 65 6E 69 78 20 54 -..ð.8 Phoenix T 00000020 65 63 68 6E 6F 6C 6F 67 69 65 73 20 4C 74 64 2E echnologies Ltd. 00000030 20 20 20 0C 2F F0 00 38 2D 32 30 30 38 20 44 65 ./ð.8-2008 De 00000040 6C 6C 20 49 6E 63 03 1F 00 41 02 0A 04 4F 01 31 ll Inc...A...O.1 00000050 90 72 65 73 65 72 76 65 64 2E 00 E0 0A 00 FF E0 reserved..à..ÿà 00000060 FF E0 FF E0 FF E0 FF E0 FF E0 FF E0 FF E0 FF E0 ÿàÿàÿàÿàÿàÿàÿàÿà Code: Uncompressed piece Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 43 6F 70 79 72 69 67 68 74 20 31 39 38 35 2D 31 Copyright 1985-1 00000010 39 38 38 20 50 68 6F 65 6E 69 78 20 54 65 63 68 988 Phoenix Tech 00000020 6E 6F 6C 6F 67 69 65 73 20 4C 74 64 2E 20 20 20 nologies Ltd. 00000030 43 6F 70 79 72 69 67 68 74 20 31 39 38 38 2D 32 Copyright 1988-2 00000040 30 30 38 20 44 65 6C 6C 20 49 6E 63 2E 20 20 20 008 Dell Inc. 00000050 41 6C 6C 20 72 69 67 68 74 73 20 72 65 73 65 72 All rights reser 00000060 76 65 64 2E 00 00 00 00 00 00 00 00 00 00 00 00 ved............. 00000070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 00000080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 00000090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 000000A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Code: Uncompression log 000000 <- 000000lit 000F : F0 00 00000F <- 000011cpy 0003/000004 : 02 04 000012 <- 000013lit 001E : F0 0F 000030 <- 000033cpy 000D/00002F : 0C 2F 00003D <- 000035lit 000F : F0 00 00004C <- 000046cpy 0004/00001F : 03 1F 000050 <- 000048lit 0001 : 00 000051 <- 00004Acpy 0003/00000A : 02 0A 000054 <- 00004Ccpy 0005/00001F : 04 1F 000059 <- 00004Ecpy 0002/000031 : 01 31 00005B <- 000050lit 000A : 90 000065 <- 00005Bdup 000B : E0 0A 000070 <- 00005Dlit 0001 : 00 000071 <- 00005Fdup 0100 : E0 FF 000171 <- 000061dup 0100 : E0 FF 000271 <- 000063dup 0100 : E0 FF 000371 <- 000065dup 0100 : E0 FF 000471 <- 000067dup 0100 : E0 FF 000571 <- 000069dup 0100 : E0 FF 000671 <- 00006Bdup 0100 : E0 FF Code: Uncompression log / operation structure 000000 <- 000000 lit 000F : F0 00 ^^^^^^ ---------------------------------- uncompressed file offset ^^^^^^ ------------------------ compressed offset offset ^^^ --------------- operation ^^ ^^ -- operation parameters There are 3 operations lit, cpy, dup lit [length] - copy next length bytes as is (literally) cpy [length][offset] - go back offset bytes, copy length bytes. dup [length] – duplicate previous byte length times
compression algorithm explained * BIOS modders can skip this part - it's for programmers mostly Code: Each operation encoded into 1, 2 or 3 bytes: 1st byte - determines opration type AND contains opration parameters XXXX YYYY (XXXX - "hi nibble", YYYY - "lo nibble") ^^^^ == 0x0 -> copy from stream / literal != 0x0 -> copy from buffer / copy from buffer / reference copy from stream / might have additional length paramater -> requred 1 or 2 bytes XXXX 0000 (lo nibble == 0, hi nibble != E) XXXX != 0xF -> copy XXXX+1 bytes (00 - copy 1 byte ... D0 - copy 14 bytes) (* E0 is duplicate operation) XXXX == 0xF -> read next byte (length), copy length + 0x0F bytes. Example: 0000 0000 -> copy 1 byte (0 + 1) from stream 0011 0000 -> copy 4 bytes (3 + 1) from stream 1111 0000 0000 0000 -> copy F bytes (0xF + 0x00) from stream 1111 0000 0000 0011 -> copy 12 bytes (0xF + 0x03) from stream duplicate last byte / always has length paramater -> requred 2 bytes 1110 0000 (E0) read next byte (length), duplicate last byte length + 1 times Example: Command is E0 01 -> duplicate last byte 2 times (01 + 1) copy from buffer / always has length paramater, might have additional length/offset paramater -> requred 2 or 3 bytes XXXX YYYY (lo nibble != 0) YYYY -> length = YYYY+1 (0 - copy 1 byte ... E - copy 15 bytes) YYYY != 0xF -> read next byte (offset) YYYY == 0xF -> read next byte (length), read next byte (LengthOffset) LengthOffset byte AAAA AABB ^^ -> high size nibble ^^^^^^^ -> offset high byte Example: XXXX 0011 HHHH HHHH offset byte = HHHH HHHH means copy 4 bytes (0011 + 1) from offset XXXX HHHH HHHH XXXX FFFF HHHH HHHH AAAA AABB Offset byte = HHHH HHHH SizeOffset = AAAA AABB means copy 00BB XXXX + 2 bytes from offset 00AA AAAA HHHH HHHH
uncompression algorithm code samples Code: Code from d610_a06.hdr ; ds = in seg, si = 0 ; es = out seg, di = 0 ; dx = compressed size 000045C3: 6603D6 6add edx,esi 000045C6: 6633C9 Dxor ecx,ecx 000045C9: 663BF2 cmp esi,edx 000045CC: 736F jnc 00000463D --↓9 000045CE: 67AC lodsb 000045D0: A80F test al,00F 000045D2: 752B jnz 0000045FF --↓A 000045D4: 3CE0 cmp al,0E0 ;'р' 000045D6: 7418 jz 0000045F0 --↓B 000045D8: 3CF0 cmp al,0F0 ;'Ё' 000045DA: 740B jz 0000045E7 --↓C 000045DC: C0E804 shr al,4 000045DF: 8AC8 mov cl,al 000045E1: 41 inc cx 000045E2: F367A4 Erep movsb 000045E5: EBDF jmps 0000045C6 --↑D 000045E7: 67AC Clodsb 000045E9: 8AC8 mov cl,al 000045EB: 83C10F add cx,00F 000045EE: EBF2 jmps 0000045E2 --↑E 000045F0: 67AC Blodsb 000045F2: 8AC8 mov cl,al 000045F4: 41 inc cx 000045F5: 26678A47FF mov al,es:[edi][-1] 000045FA: F367AA rep stosb 000045FD: EBC7 jmps 0000045C6 --↑D 000045FF: 8AC8 Amov cl,al 00004601: 80E10F and cl,00F 00004604: 80F90F cmp cl,00F 00004607: 7421 jz 00000462A --↓7 00004609: FEC1 inc cl 0000460B: 2AE4 sub ah,ah 0000460D: C1E004 shl ax,4 00004610: 67AC lodsb 00004612: 668BDE Fmov ebx,esi 00004615: 668BF7 mov esi,edi 00004618: 660FB7C0 movzx eax,ax 0000461C: 662BF0 sub esi,eax 0000461F: 664E dec esi 00004621: F32667A4 rep movsb 00004625: 668BF3 mov esi,ebx 00004628: EB9C jmps 0000045C6 --↑D 0000462A: 8AC8 7mov cl,al 0000462C: 67AD lodsw 0000462E: 8AEC 8mov ch,ah 00004630: C1E904 shr cx,4 00004633: 83E13F and cx,03F ;'?' 00004636: 41 inc cx 00004637: 41 inc cx 00004638: C0EC02 shr ah,2 0000463B: EBD5 jmps 000004612 --↑F 0000463D: C3 9retn Code: And one more from D4600A12.hdr (quite older version) ; ds:si -> start of chain type A ; es:si -> where to store uncompressed module ; bl = module type to find and uncompress 0006C712: FC cld 0006C713: 8BC6 5mov ax,si 0006C715: C1E804 shr ax,4 0006C718: 8CDA mov dx,ds 0006C71A: 03D0 add dx,ax 0006C71C: 8EDA mov ds,dx 0006C71E: 83E60F and si,00F 0006C721: AD lodsw 0006C722: 8BD0 mov dx,ax 0006C724: AC lodsb 0006C725: 3AC3 cmp al,bl 0006C727: 7404 jz 00006C72D --↓4 0006C729: 03F2 add si,dx 0006C72B: EBE6 jmps 00006C713 --↑5 0006C72D: 03D6 4add dx,si 0006C72F: 2AED sub ch,ch 0006C731: 3BF2 9cmp si,dx 0006C733: 7356 jnc 00006C78B --↓6 0006C735: AC lodsb 0006C736: A80F test al,00F 0006C738: 7521 jnz 00006C75B --↓7 0006C73A: 3CE0 cmp al,0E0 ;'р' 0006C73C: 730A jnc 00006C748 --↓8 0006C73E: C0E804 shr al,4 0006C741: 8AC8 mov cl,al 0006C743: 41 inc cx 0006C744: F3A4 Brep movsb 0006C746: EBE9 jmps 00006C731 --↑9 0006C748: AC 8lodsb 0006C749: 8AC8 mov cl,al 0006C74B: 7405 jz 00006C752 --↓A 0006C74D: 83C10F add cx,00F 0006C750: EBF2 jmps 00006C744 --↑B 0006C752: 41 Ainc cx 0006C753: 268A45FF mov al,es:[di][-1] 0006C757: F3AA rep stosb 0006C759: EBD6 jmps 00006C731 --↑9 0006C75B: 8AC8 7mov cl,al 0006C75D: 80E10F and cl,00F 0006C760: 80F90F cmp cl,00F 0006C763: 7415 jz 00006C77A --↓C 0006C765: 2AE4 sub ah,ah 0006C767: C1E004 shl ax,4 0006C76A: AC lodsb 0006C76B: 41 Dinc cx 0006C76C: 8BDE mov bx,si 0006C76E: 8BF7 mov si,di 0006C770: 2BF0 sub si,ax 0006C772: 4E dec si 0006C773: F326A4 rep movsb 0006C776: 8BF3 mov si,bx 0006C778: EBB7 jmps 00006C731 --↑9 0006C77A: 8AC8 Cmov cl,al 0006C77C: AD lodsw 0006C77D: 8AEC mov ch,ah 0006C77F: 80E503 and ch,3 0006C782: C1E904 shr cx,4 0006C785: 41 inc cx 0006C786: C0EC02 shr ah,2 0006C789: EBE0 jmps 00006C76B --↑D 0006C78B: C3 6retn Code: * Note the difference: d610 works with wide registers 000045C3: 6603D6 6add edx,esi d4600 does not: 0006C72D: 03D6 4add dx,si Code: It’s easy to find the code inside HDR by looking for following byte sequences: C0E8048AC841F3A4 C0E8048AC841F367A4 C0E8048AC86641F367A4 d610 000045DC: C0E804 shr al,4 000045DF: 8AC8 mov cl,al 000045E1: 41 inc cx 000045E2: F367A4 Erep movsb d4600 000F15D5: C0E804 shr al,4 000F15D8: 8AC8 mov cl,al 000F15DA: 41 inc cx 000F15DB: F3A4 rep movsb d430 0000C3BB: C0E804 shr al,4 0000C3BE: 8AC8 mov cl,al 0000C3C0: 6641 inc ecx 0000C3C2: F367A4 6rep movsb Why we might possibly need to find it? To make sure it’s actually can uncompress our custom packed modules. I have a little suspicion, in the past it might be only 2 bytes version of “copy from buffer” command, because I saw HDR file with modules compressed using only 2 bytes “copy from buffer” command, but same HDR file contains “uncompress code” capable to understand both 2 and 3 bytes “copy from buffer” commands…
Concept proof Got a Dell laptop and did quick “concept proof” Wrote a program to replace BIOS module in chain section. Replaced SLIC and compared result with andyp “Phoenix SLIC Tool” The only difference was one byte in the middle and all crc32 values. So I change program to make same one byte change ‘7’ -> ‘9’ “DELL M07 found at 2D006 and replaced with DELL M09” And the resulting new HDR file was exactly the same is andys! Flushed it and checked with SLIC_ToolKit_V3.0 - got SLIC 2.1 (saved SLIC to file!) Obviously, nothing new so far. Restored original BIOS – SLIC rolled back to 2.0. Repeat same steps, but used SLIC 2.1 recompressed to 169 bytes. (original SLIC 2.1 size is 170 and SLIC 2.0 - 169) Flushed – checked with SLIC_ToolKit_V3.0 - got SLIC 2.1 Saved it and compared with previously saved one – no difference! Next step – replace some other module – namely PXE/RPL Preboot Execution Environment (PXE)/Remote Program Load (RPL) BIOS has two PXE modules, both have strings: Broadcom NetXtreme Ethernet Boot Agent v10.0.9 Broadcom UNDI PXE-2.1 v10.0.9 MBA v10.0.9 I got similar modules from previous Dell model: Broadcom NetXtreme Ethernet Boot Agent v8.3.0 Broadcom UNDI PXE-2.1 v8.3.0 MBA v8.3.0 Replaced first module, than second – flushed – booted from NIC – Got “Broadcom NetXtreme Ethernet Boot Agent v8.3.0” on the screen! Wrote one more separate program to fix crc32 after editing. I do not posting programs, because… I haven’t wrote any descriptions yet. Besides, what I did can be easily done with WinHex. One thing you need to keep in mind though. If new module is bigger than old one – we overwrite (borrow!) 0xFF bytes at the end of the chained segment, right? Similarly, if new module is shorter, and we shift subsequent modules toward the file start, we need to fill the gap (empty space) with very same 0xFF bytes. If we didn’t do chain got broken – 0xFF is “end of chain block” flag! I don’t have a clue how to edit RSDT tables, so I simple don’t know how to insert SLIC into old BIOS – i.e. without one. Sorry…
That is really a pity, I was hoping that there could be a way to add SLIC to older (non-slic) machines ie. GX620 sebus
Absolutely - although I don't know how, it doesn't mean nobody knows it too. Yen should be the one you looking for!
BIOS update exe file structure I Test subject D430_A00.EXE Open it in WinHex and go to the very end Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000F5D60 6D BF ED EB 5A 93 28 FD 5F FF FF FF FF 60 00 11 m¿íëZ“(ý_ÿÿÿÿ`.. 000F5D70 00 00 D0 03 00 ..Ð.. 00 D0 03 00 - last 4 bytes is an offset to DellBIOS or PyldBioz structure DellBIOS structure Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0003D000 44 65 6C 6C 42 49 4F 53 00 EA 5F 8D 0B 00 60 00 DellBIOS.ê_..`. 0003D010 11 00 1F 8B 08 00 00 00 00 00 00 00 EC DB 69 58 ...‹........ìÛiX 0003D020 13 57 FF 38 FC 33 67 26 0B 01 92 49 58 14 54 18 .Wÿ8ü3g&..’IX.T. 00 EA - some kind of checksum? It’s different for same model BIOS revisions 5F 8D 0B 00 - gzip-ed HDR size // 757087 60 00 11 00 - un-gzip-ed HDR size // 1114208 1F 8B 08 00 - gzip header start // well known info Test subject XPS420-A07.EXE Code: PyldBioz structure Similar to above, (may contains more than one gzipped file?) Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0003D000 50 79 6C 64 42 69 6F 7A 03 00 E3 01 F8 DB 06 00 PyldBioz..ã.øÛ.. 0003D010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0003D020 C8 DB 06 00 5C 00 0E 00 00 00 00 00 00 00 00 00 ÈÛ..\........... 0003D030 1F 8B 08 00 00 00 00 00 00 00 AC 7D 0B 7C 13 55 .‹........¬}.|.U 03 00 E3 01 F8 DB 06 00 – no idea... F8 DB 06 00 => 06DBF8 06DBF8 - 06DBC8 = 30 – the size of PyldBioz structure 3D000 + 06DBF8 = (EOF - 4) - might be offset to the next PyldBioz structure or EOF / can PyldBioz have more than one gzip-ed content? C8 DB 06 00 - gzip-ed HDR size // 449480 5C 00 0E 00 - un-gzip-ed HDR size // 917596 After "gzip -d" check location of HDR file header (0x54 bytes) at the end of the file followed by crc32 checksum (0x04 bytes) Header has to be moved to the beginning of the file: Before: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 C3 57 00 00 2C 00 00 00 4D 5A 90 00 03 00 00 00 ÃW..,...MZ..... ... 000E0000 94 94 65 B3 24 52 42 55 54 01 00 01 43 6F 70 79 ””e³$RBUT...Copy 000E0010 72 69 67 68 74 20 78 78 78 78 20 44 65 6C 6C 20 right xxxx Dell 000E0020 49 6E 63 2E 20 20 20 20 20 20 20 20 20 20 20 20 Inc. 000E0030 20 20 20 20 41 30 37 00 00 00 00 00 00 00 00 00 A07......... 000E0040 15 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000E0050 00 00 00 00 00 00 00 00 53 34 BA C6 ........S4ºÆ After: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 24 52 42 55 54 01 00 01 43 6F 70 79 72 69 67 68 $RBUT...Copyrigh 00000010 74 20 78 78 78 78 20 44 65 6C 6C 20 49 6E 63 2E t xxxx Dell Inc. 00000020 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00000030 41 30 37 00 00 00 00 00 00 00 00 00 15 10 00 00 A07............. 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 C3 57 00 00 2C 00 00 00 4D 5A 90 00 ....ÃW..,...MZ. ... 000E0050 FF FF FF FF 94 94 65 B3 53 34 BA C6 ÿÿÿÿ””e³S4ºÆ See next post about PyldBioz multi-part gzip-ed exe Again, sorry about reposting well known info...
BIOS update exe file structure II I didn't bother with highlighting this time, sorry... Code: Z600_A01.EXE Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00042000 50 79 6C 64 42 69 6F 7A 00 86 51 77 0F 00 5C 00 PyldBioz.†Qw..\. 00042010 1A 00 1F 8B 08 00 ...‹.. ... 00139750 5C \ 00139760 00 1A 00 50 79 6C 64 4D 65 5F 7A 00 F4 5F 09 17 ...PyldMe_z.ô_.. 00139770 00 A0 AC 1D 00 1F 8B 08 00 . ¬...‹.. ... 002AA0C0 00 00 00 C0 FF CB B7 91 0B D4 FE 0F FF FF FF FF ...ÀÿË•‘.Ôþ.ÿÿÿÿ 002AA0D0 A0 AC 1D 00 00 20 04 00 98 17 00 00 00 02 02 00 ¬... ..˜....... 002AB860 82 55 C5 DC D5 1D A5 69 D5 7F AA 00 00 00 00 00 ‚UÅÜÕ.¥iÕª..... --------- @00042008 = 00 86 – checksum ? @0004200A = 000F7751 // 1st gzip-ed fragment length & offset to next fragment? @0004200E = 001A005C // 1st ungzip-ed fragment length? @00042012 = 1F 8B 08 00 // gzip signature ... @0013975F = 001A005C // gziped stream always end with its content length ... 42012 + 0F7751 = 139763 = start of 2nd PyldBioz block @0013975F = 00 F4 – checksum ? @0013976D = 0017095F // 2nd gzip-ed fragment length? @00139771 = 001DACA0 // 2nd ungzip-ed fragment length? @00139775 = 1F 8B 08 00 // gzip signature @002AA0D0 = 001DACA0 // gziped stream always end with its content length 139775 + 17095F = 2AA0D4 – end of 2nd gzip-ed fragment @002AA0D4 = 42000 = offset to 1st PyldBioz fragment @002AA0D8 – very long VeriSign signatute – i.e. the exe is signed certificate issued by VeriSign to Dell? Plus code to verify it, most likely? Numbers below do not match... 0F7751 + 17095F = 2680B0 // total gzip-ed length? 1A005C + 1DACA0 = 37ACFC // total ungzip-ed length? Z600_A01.hdr 37AD0E Z600_A01.hdr.gz 268CA0 // got from gzip -n Z600_A01.hdr 37AD0E – 37ACFC = 12 Code: Z600_A02.EXE Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00042000 50 79 6C 64 42 69 6F 7A 00 A0 2D 81 0F 00 5C 00 PyldBioz. -..\. 00042010 1A 00 1F 8B 08 00 ...‹.. ... 0013A130 5C 00 1A 00 50 \...P 0013A140 79 6C 64 4D 65 5F 7A 00 A7 1F F9 16 00 3C AE 1D yldMe_z.§.ù..<®. 0013A150 00 1F 8B 08 00 ..‹.. ... 002A9A60 3C AE 1D 00 <®.. 002A9A70 00 20 04 00 00 00 00 00 98 17 00 00 00 02 02 00 . ......˜....... 002A9A80 30 82 17 87 06 09 2A 86 48 86 F7 0D 01 07 02 A0 0‚.‡..*†H†÷.... ... 002AB200 BB 7E 42 B2 8A B9 42 BB 2F D8 00 00 00 00 00 00 »~B²Š¹B»/Ø...... --------- @00042008 = 00 A0 – checksum ? @0004200A = 000F812D // 1st gzip-ed fragment length & offset to next fragment? @0004200E = 001A005C // 1st ungzip-ed fragment length? @00042012 = 1F 8B 08 00 // gzip signature ... @0013A13B = 001A005C // gziped stream always end with its content length ... 42012 + 0F812D = 13A13F = start of 2nd PyldBioz block ... @0013A147 = 00 A7 – checksum ? @0013A149 = 0016F91F // 2nd gzip-ed fragment length? @0013A14D = 001DAE3C // 2nd ungzip-ed fragment length? @0013A151 = 1F 8B 08 00 // gzip signature ... @002A9A6C = 001DAE3C // gziped stream always end with its content length ... 13A151 + 16F91F = 2A9A70 – end of 2nd gzip-ed fragment ... @002A9A70 = 42000 = offset to 1st PyldBioz fragment @002A9A74 – very long VeriSign signatute... Numbers below do not match... 0F812D + 16F91F = 267A4C // total gzip-ed length? 1A005C + 1DAE3C = 37AE98 // total ungzip-ed length? Z600_A02.hdr 37AEAA Z600_A02.hdr.gz 268471 // got from gzip -n Z600_A02.hdr 37AEAA - 37AE98 = 12 again... Where 0x12 is coming from??? Actually, it looks like there are 2 completely independent parts there: Code: Unpacked 1st part is a normal HDR file with all crc32 in place: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 24 52 42 55 54 01 00 01 43 6F 70 79 72 69 67 68 $RBUT...Copyrigh 00000010 74 20 32 30 30 39 20 44 65 6C 6C 20 49 6E 63 2E t 2009 Dell Inc. 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 41 30 31 00 00 00 00 00 00 00 00 00 C8 10 00 00 A01.........È... ... 001A0040 00 00 00 00 E9 3D FE 00 00 00 00 00 00 00 00 00 ....é=þ......... 001A0050 00 00 00 00 31 B4 EF 87 4B 06 91 EC ....1´ï‡K.‘ì Unpacked 2nd part is something I never seen before: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 04 00 00 00 A1 00 00 00 00 00 01 00 00 00 00 00 ....¡........... 00000010 86 80 00 00 05 03 09 20 DB 00 00 00 24 4D 41 4E †€..... Û...$MAN 00000020 01 00 00 00 04 00 01 00 0A 00 16 04 00 00 00 00 ................ ... 001DAC80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 001DAC90 FF FF FF FF FF FF FF FF FF FF FF FF FA 05 41 22 ÿÿÿÿÿÿÿÿÿÿÿÿú.A" And together they form the file which can be extracted with Z600_A01.EXE –writehdrfile command Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 24 52 42 55 54 01 00 01 43 6F 70 79 72 69 67 68 $RBUT...Copyrigh 00000010 74 20 32 30 30 39 20 44 65 6C 6C 20 49 6E 63 2E t 2009 Dell Inc. 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 41 30 31 00 00 00 00 00 00 00 00 00 C8 10 00 00 A01.........È... ... 001A0040 00 00 00 00 E9 3D FE 00 00 00 00 00 00 00 00 00 ....é=þ......... 001A0050 00 00 00 00 31 B4 EF 87 4B 06 91 EC 49 6D 61 67 ....1´ï‡K.‘ìImag 001A0060 4D 65 5F 5F 10 00 89 00 B0 AC 1D 00 04 00 00 00 Me__..‰.°¬...... 001A0070 A1 00 00 00 00 00 01 00 00 00 00 00 86 80 00 00 ¡...........†€.. 001A0080 05 03 09 20 DB 00 00 00 24 4D 41 4E 01 00 00 00 ... Û...$MAN.... 001A0090 04 00 01 00 0A 00 16 04 00 00 00 00 00 00 00 00 ................ ... 0037ACF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0037AD00 FF FF FF FF FF FF FF FF FA 05 41 22 00 00 ÿÿÿÿÿÿÿÿú.A"..... Any comments?
Impressive work so far! I don't have any access to Dells at all, but if you can get the PXE code replaceable, we can probably use a WindSLIC variant to get the job done. I'm sure this question is probably answered in the previous posts, but how much slack space is in modern Dell BIOSes for use? I'm researching keeping the original PXE and prepending WindSLIC onto it to not lose the PXE capability, etc. Again, most impressed, -tij-
I agree, nice work! There are few challanges left (!), (older) Dells being one, HP/Compaq being another... Keep at it! Andy
Thanks alot, Andy! >(older) Dells being one To compete it - we need a help from somebody who know how to mod BIOS without any SLIC. If you know any good (and concise!) tutorial about it, let me know, please? >HP/Compaq I think, I saw a post about HP/Compaq ROMPAQ decompressor, didn't actually check what's inside...