Replacing a module seemed to be quite an easy job, providing we have another similar compressed module to replace with. Going back to SLIC subject - apparently, both pubkey and marker resides in their own modules and have corresponding module types. I still have a feeling if we simply insert pubkey and marker into $RBUT01 type (A) chain, it won’t show up in XSDT structures. I.e. it might show up in BIOS, but won’t be linked to any XSDT structures… Again, it’s not clear to me, how this linkage is done. I.e. a module responsible to unpacking BIOS might work like this: 1. Get next module. 2. Unpack it. 3. If it’s pubkey and marker – adjust/include it into XSDT structure. The point is – the older unpacking module might not know how to deal with those new (pubkey and marker) module types… (I might be completely wrong about it - sorry don’t know much about this stuff) I guess, we definitely have people in these forums who know quite well how XSDT structure works. I hope they will comment too… From the other hand quite more promising looks a replacement of “Intel(R) RAID for SATA” rom. I.e. if you have stripped of SATA rom - can create mirror (RAID1) only, not stripe (RAID0) or RAID5. We can try to replace is with full version from different model. Ok. That’s it for now – will be waiting for shakeyplace to comment. BTW: I wrote a simple program to unpack known sections.
One last thing: Apparently, unpacking module itself should be somewhere in the HDR too. And, obviously, it should not be packed. By indentifying and studying it we will understand compression algorithm and might be able to change it to recognize new modules types. It might be as simple as replacing that older version of the module with newer one. Naturally, it has to be one of the first in execution chain. And it’s well known address, where CPU starts execution after power reset. Unfortunately, my skills are not good enough to find that module… Anybody can help?
IMO, that should be quite easy. Again, OptiPlex 745 - o745-263.hdr Below is a CompuTrace V80.845 Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------------------- 00000000 F0 20 55 AA 2A EB 15 43 6F 6D 70 75 54 72 61 63 ð Uª*ë.CompuTrac 00000010 65 20 56 38 30 2E 38 34 35 A1 1D 00 E9 5C 01 50 e V80.845¡..é\.P 00000020 43 49 52 17 19 34 12 00 00 18 00 00 06 00 00 2A CIR..4.........* 00000030 00 E0 10 00 17 04 12 30 01 00 FF FF 02 1B 10 92 .à.....0..ÿÿ...’ 00000040 CF 06 07 F0 06 00 00 9C FA 66 60 1E 06 0F A0 0F Ï..ð...œúf`... . #01 (2C) 00AEA3 <= 000054-00AEFC #02 (01) 0062CB <= 00AEFC-0111CC #03 (02) 005804 <= 0111CC-0169D5 #04 (03) 008876 <= 0169D5-01F250 #05 (12) 000760 <= 01F250-01F9B5 #06 (32) 00093F <= 01F9B5-0202F9 #07 (05) 010A4D <= 0202F9-030D4B #08 (28) 00A075 <= 030D4B-03ADC5 #09 (08) 00ADC6 <= 03ADC5-045B90 #10 (21) 00768D <= 045B90-04D222 #11 (0B) 008D64 <= 04D222-055F8B #12 (35) 000627 <= 055F8B-0565B7 #13 (17) 00236C <= 0565B7-058928 #14 (15) 004AFB <= 058928-05D428 #15 (14) 015480 <= 05D428-0728AD #16 (16) 00137A <= 0728AD-073C2C #17 (0F) 000439 <= 073C2C-07406A #18 (33) 012479 <= 07406A-0864E8 #19 (29) 00009E <= 0864E8-08658B #20 (2A) 0000AA <= 08658B-08663A #21 (34) 0052B5 <= 08663A-08B8F4 <- CompuTrace V80.845 #22 (1D) 00057E <= 08B8F4-08BE77 #23 (1A) 000A5B <= 08BE77-08C8D7 #24 (1B) 0002D8 <= 08C8D7-08CBB4 #25 (23) 00092E <= 08CBB4-08D4E7 Should be piece of cake to cut it out and shift up all modules below it. The module is ~10.3 KB Obviously – it’s 2 ways to adjust padding to 2KB boundary 1. Remove 10KB 2. Fill 10KB with FF #1 looks better. I was wondering, who exactly wants to remove CompuTrace module? The only thing comes to mind, if we need to clear some space to replace a smaller module with a bigger one, right?
Where is the XSDT located? Usually the XSDT links to SLIC dynamically allocated. Therefore the XSDT needs a 64 bit address entry to call the SLIC. If you would insert a pubkey and marker module you would need code to build a SLIC. Then the SLIC has to be mapped dynamically and XSDT has to link to. Another way would be to inject a complete SLIC (uncompressed) and extend the XSDT +8 bytes to call the SLIC at calculated EEPROM address 'super static'. To have a look we need to figure how the XSDT is created. If you want to get more info I suggest to you to get the acpi specifications. Also it would be nice to know how the other acpi tables are stored. Some bioses have a special acpi table containing module, which will be mapped dynamically if added to the bios, without to alter the XSDT (except to match the OEMIds of the SLIC)
Yen, I will try to 'describe' again what was done and where are we now - nothing much or new actually… We are able to identify modules inside BIOS sections – they are still compressed (don’t know how), but we can replace one to another – exactly the same way AndyP tool works. I guess, we can insert pubkey/marker too. It won’t help, most likely, since older BIOSes don’t know how to link them into XSDT (same thing you wrote) I guess, what could be done is to insert a new uncompressed module (with AA 55 signature ?) and have BIOS to execute it. The module should implement ‘super static’ method you mentioned. Doesn’t NIC SLIC insertion works very same way? Or if we understand, what module is responsible for other modules uncompressing and most likely XSDT creation/linking too – we might be able to replace this module as whole. Once found it’ll help us to crack module compression algo. As I wrote early – I’m not able to identify it, but hopefully, it should be a problem for pro. Anyway – we were rather to try to update RAID module or delete some other one to make sure we understand BIOS structure properly. In order to do it we need a volunteer with Dell (laptop?) who knows that dell BIOS recovery works fine on his stuff. I guess, I can try it on some of mine old dells too. Still waiting for Shakey to show up as I have few questions to him before we can proceed.
The NIC SLIC code is executed via PXE boot. Therefore you need to modify the code with the original Vendor and device IDs of your LAN adapter in order to execute the code. The code works in between the bios basic initialisation and the step when bios calls the bootsector. You may say it's a pre-loader. Therefore it patches the RSDT OEMTable and TABLEID, introduces the SLIC dynamically and makes RSDT link to. The advantage is that you don't need to alter any acpi table containing module, you just have to replace the original PXE boot agent at its module. The big disadvantage is the compatibillity. The acpi tables are already mapped when the PXE SLIC code runs to modify the RSDT and introduces the SLIC. It's dependant on the layout of the acpiTables. The success rate is not high. At Award it works at best. The superstatic call works if the SLIC injection works. At some bioses you just have to copy and write a SLIC into the biosimage. You even don't need a module therefore, no sums to be corrected. You just have to make sure the SLIC reaches the EEPROM. But to link to from RSDT /XSDT you need to decompress the RSDT /XSDT containing module and have a look if it would be possible to modify it in order th call the SLIC. At Phoenix bioses it's not possible, at AMI and AWARD it is.
Ok. Since we don’t know compression algo (yet!) we can do only dynamic modification of RSDT/XSDT. And there is no any reliable dynamic modification for Dell Phoenix BIOS as of now, right? Does it mean our best bet would be to locate “the module responsible for other modules uncompressing and most likely XSDT creation/linking too” What else could we do, except try to replace some other not SLIC related modules?
Update – wrote another little program to unpack Dell BIOS modules. Algo is really simple, but I'm missing some FSM codes... It does unpack marker and pubkey properly, but didn’t work quite right on bigger modules. To fix it I need to get packed and unpacked and run unpack/compare. Still waiting for Shakey – I know, he has what I need.
It would be great to have a look at the uncompressed code where RSDT /XSDT is created. Is the PXE boot module compressed as well? By remaining the module type (option rom) would it be possible to insert the uncompressed PXE SLIC code instead of for a try? The SLIC code is much smaller and should fit uncompressed. Is there a indicator byte (compressed, uncompressed)? Is the header structure fully known already? Some months ago I have tried several hours to find delldeco, a already written decompressor...it seems to be disappeared...I never had the time and the chance to research about Dell module structures..Award, AMI, Phoenix and EFI took too much time....I'm not very skilled regarding Dell... Will check this thread again...
I cannot decompress big modules yet… PXE boot module is compressed. >Is there a indicator byte (compressed, uncompressed) No. I think the unpacker has some table and know which modules are compressed and how to link marker/pubkey into SLIC for example. Or compression flag could be defined for whole section, not for individual modules. I don’t know how to identify sections reliably yet… >Is the header structure fully known already? I wrote about it already see post #40 above. Again, it’s only my speculations… >Some months ago I have tried several hours to find delldeco, a already written decompressor... it seems to be disappeared... Author has pulled it out from everywhere for unknown reason… And speaking about PXE module again – is we can find unpacked one matching compressed in any Dell BIOS – it’ll help to fix compress algo! One below has 4.1.06 IBA PXE 2.1 Build 083 RPL V2.74 Intel web site has following versions now: 14_7 14_5 14_3 13_5 Code: Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000096 03 6B 10 67 0D 03 71 F0 1D 0D 0A 43 6F 70 79 72 .k.g..qð...Copyr 00000112 69 67 68 74 20 28 43 29 20 31 39 39 37 2D 32 30 ight (C) 1997-20 00000128 30 32 2C 20 49 6E 74 65 6C 20 43 6F 72 70 6F 72 02, Intel Corpor 00000144 61 74 69 6F 6E 02 2C B0 49 6E 69 74 69 61 6C 69 ation.,°Initiali 00000160 7A 69 6E 67 05 20 F0 04 28 52 29 20 42 6F 6F 74 zing. ð.(R) Boot 00000176 20 41 67 65 6E 74 20 56 65 72 73 02 2A A0 20 34 Agent Vers.* 4 00000192 2E 31 2E 30 36 00 49 42 41 06 0A 20 20 53 6C 02 .1.06.IBA.. Sl. 00000208 24 00 30 E0 02 02 73 F0 07 50 58 45 20 32 2E 31 $.0à..sð.PXE 2.1 00000224 20 42 75 69 6C 64 20 30 38 33 20 28 57 66 4D 02 Build 083 (WfM. 00000240 12 F0 01 30 29 00 2C 20 52 50 4C 20 56 32 2E 37 .ð.0)., RPL V2.7 00000256 34 0D 0A 1A 14 F0 18 54 53 41 46 01 00 F2 E6 00 4....ð.TSAF..òæ.
Checked few relatively long unpacked modules with AA 55 signature - they have CRC8 equal 0. One of the AA 55 modules doesn't have CRC8 at all - all last bytes are 0... Anyway - let me know if you want to unpack a particular model BIOS
Hi, Well it might be better to upload the tools and info you created (and maybe a readme) somewhere with a lot of mirrors.. At least this way it cannot dissapear from the internet like DellDeco. (Have never seen anything like it, it has existed on the internet, but no traces of it can be found..) Allegro16 P.S: I would be interested in the Dimension 8300 bios, but have no clue if your tool (or DellDeco) will help getting it a SLIC in the future..
Will see what I can do. Might be in the future. Somebody experienced in BIOS modding can use it to extract modules. There is no tool to compress them back yet. And there is no tool to replace modules in HDR file either – I’ll write one, but I need some help from Shakey first.