It should be enough when the marker has changed only and the private /public key pair of the SLIC haven't changed. Dannyres mentioned that the bios corrects the checksum of SLIC found at offset 9 automatically. (It's the z before the OEMID). The SLP2.1 SLIC we have got now has got the same private/public key pair and to exchange the marker data only should work, since the public key data are still the same. Not sure if it still works if the SLP2.1 marker will be another one with another OEMTableID. And I'm not sure if it will work when the public / private key pair have changed at SLIC and you need to replace both, the public key data and marker data. If the bios reads the OEMID and OEMTableID from the marker itself and corrects them as well it will work also. Every marker contains the OEMID and TableID right before the WINDOWS string, so if the bios reads them from there, and corrects them, it will work as well. I'll play with this and try to find a way to use Lzma. Since this is great news, I'll make it sticky.
Ok, some results: We know the pubkey GUID is: 1A1E2341-A2FB-42c7-8D17-3073D08EB21D To find the module code of the pubkey is no problem at all: Decompress the bios as described before. Now search for the start of the pubkey, which is always: 000000009C0000000602000000240000. When found, go back 30h bytes and you'll find the last two groups of the GUID: 1A1E2341-A2FB-42c7-8D173073D08EB21D The 8 bytes before are reversed: 41231E1A FBA2 C742----> 42C7-A2FB-1A1E2341-----> 1A1E2341-A2FB-42C7-8D17-3073D08EB21D Now confirmed the GUID of the pubkey to replace. We know the marker GUID is DD6569A7-E455-4ee5-B2BA-ECDA84ACBC99 To find the marker search for : 01000000B600000000000200 and do the same. DD6569A7-E455-4ee5-B2BAECDA84ACBC99 The 8 bytes before are: A76965DD 55E4 E54E----> 4EE5-E455-DD6569A7---> DD6569A7-E455-4EE5-B2BA-ECDA84ACBC99 Now confirmed the GUID of the marker to replace. So I think the header of each module is at least 38h bytes in size.
Sorry for spamming around, but I'm so excited. I've found an excellent way: The clue: Edit the bios directly at physical memory. -Open *.fd bios with EzH2O.exe -start winhex, go to tools, open RAM -find ezh20 task, primary memory -you'll find the decompressed bios in RAM No need for lzma and stuff... -search for public key and marker, search for what you want. -edit to whatever you want, edit OEMID, table ID change SLIC, do whatever you want, the RAM is edited directly, save!!! That's cool.... -go back to the EzH2O tool and save the bios -the tool rebuilds the bios with all the changes you've made. I've rechecked my changes, using lzma and had a look, they are THERE!!! @911medic You may change the SLIC header with this method as well. Have tried to change HPQOEMSLIC-MPC to _ASUS_Notebook and it worked. But you need to do more changes like patch RSDT OEMIDs.......... Any comments?
Yep, good advances. I have found the RSDT calls, but changing the OEMIDs is going to be something to figure out. They seem to resemble the core 7 AMI tables..at least at first look. I am out of time now, I will continue to look though. I look forward to your findings as well....This is good already!!
Yeah the GUID's are a bit swapped round as Yen mentioned. I've found the GUID's for the logos (at least in the dv5t BIOS). It seems all the logos are in JFIF format (google it). So you can just search for JFIF in the decompressed BIOS and look back a few bytes for the GUID's. The two I found were: 1B89F194-A09E-40B8-AA27-C12AD0023C48 37946B52-EC4B-46AF-AB83-76DBBE1E13C4 (Note this is only in the HP dv5t BIOS - they may vary, I'm not too sure. It seems the HP BIOS's include two logos, HP and COMPAQ. Which one is displayed is determined by the EEPROM settings for model etc) Adding/changing the SLIC for Insyde BIOS's seems to be very simple now! Since HP's new 2.1 SLIC is basically the same you can just swap the marker (and pubkey?) data and it works perfectly - no need to worry about other parts unless we are wanting to change the full SLIC to ASUS for example. I'm also particularly interested in figuring out what other GUID's represent. Most Insyde BIOS's seem to have limits for what PCIe hardware can be added so people don't do their own upgrades so I'd be interested in disabling/updating the white list. Also great work Yen on finding out how we can use Winhex. This means we wont have to worry about the compression algorithm since lzma.exe probably uses a slightly different algorithm than the Insyde tool, which the EFI BIOS may not be able to read. Any ideas on how we can figure out what different modules do? EDIT: the other thing is flas**t.exe includes options for changing the logo if that's all someone wants to do. Since we can now find the GUID by searching for 'JFIF' they can use this tool to patch the logo. (Note I have not tested this as my notebook is in repair atm due to my messing about with the BIOS! It would not even switch on so I couldn't use the normal flash recovery procedure for Insyde BIOS's )
DaTwo what laptop are you using? Here is an idea - post the list of your working PCI card dev ids(e.g. your current WLAN). I will search for them in the BIOS and see what I can come up with.
Ok I've been doing a bit more digging around. It seems modules are packed on 8 byte boundaries (in this case the last 4 bytes FF FF FF FF are not actually part of the modules data). There is a header which is 56 bytes. The first 16 bytes of the header are it's GUID (layed out in the format Yen described above). This is all I've got so far but I'm sure there must be things such as module length, checksum, etc in this header. Here is an example of a full module of length 216 bytes (with GUID 1A1E2341-A2FB-42c7-8D17-3073D08EB21D): Code: 41 23 1e 1a fb a2 c7 42 8d 17 30 73 d0 8e b2 1dA#.....B..0s.... 34 45 02 40 d4 00 00 f8 bc 00 00 02 b0 cd 1b fc4E.@............ 31 7d aa 49 93 6a a4 60 0d 9d d0 83 1c 00 02 001}.I.j.`........ 3f 2b 48 04 a0 00 00 19 00 00 00 00 9c 00 00 00?+H............. 06 02 00 00 00 24 00 00 52 53 41 31 00 04 00 00.....$..RSA1.... 01 00 01 00 5b ab 60 56 bc 58 1e e8 c1 d2 a1 5c....[.`V.X.....\ e5 4f bb fd 1d a9 8c 94 b4 ae 08 11 dc 13 59 d3.O............Y. 7f f6 3e 87 31 b9 95 74 10 da 3b a4 5b b5 19 82.>.1..t..;.[... 7c 39 d7 0d 7c 22 ac 1c 2a 84 e9 0a 88 6d fa b1|9..|"..*....m.. e2 d8 e8 21 96 e1 2e 68 9a bf 44 45 3e 3c 8e 99...!...h..DE><.. 90 de 37 38 57 0b 92 15 bc de ff f2 07 7e b5 40..78W........~.@ 8c 51 3a c3 02 48 f6 13 12 72 fb 42 78 e6 47 88.Q:..H...r.Bx.G. 54 c7 b0 f0 93 9e fb 04 b7 b8 b8 90 de db ed 32T..............2 e1 fb 54 a6 ff ff ff ff..T..... And one more example: Code: a7 69 65 dd 55 e4 e5 4e b2 ba ec da 84 ac bc 99.ie.U..N........ 59 90 02 40 f0 00 00 f8 d8 00 00 02 b0 cd 1b fcY..@............ 31 7d aa 49 93 6a a4 60 0d 9d d0 83 1c 00 02 001}.I.j.`........ 5a 1e f8 69 ba 00 00 19 01 00 00 00 b6 00 00 00Z..i............ 00 00 02 00 48 50 51 4f 45 4d 53 4c 49 43 2d 4d....HPQOEMSLIC-M 50 43 57 49 4e 44 4f 57 53 20 00 00 00 00 00 00PCWINDOWS ...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 a8..............0. 7e 10 1b 0f 13 dd 2e 2d 36 c2 ab 54 a7 8c 3a a0~......-6..T..:. 2f c6 5b b3 b3 dd 93 ee 8e 39 a9 92 d0 5a 20 e1/.[......9...Z . 2d f5 a2 1c 7a 3e 54 85 99 72 56 5f ec 6b 07 17-...z>T..rV_.k.. 63 82 3e 79 02 50 40 c9 f1 d3 c5 58 39 a8 18 f1c.>y.P@....X9... 56 91 ea 9c 54 1a e0 ce c9 16 f0 5d d1 90 b1 b0V...T......].... 9e 81 e6 ba 62 f1 3b 96 b0 7d d7 47 10 78 03 c9....b.;..}.G.x.. 28 52 e7 2d 4a f7 70 bb 53 1f be cd 4f 77 d1 2f(R.-J.p.S...Ow./ a8 3d 5c 26 af 80 42 25 ef 7a b2 67 ba 1c 00 00.=\&..B%.z.g.... This one is padded with 00 00 (rather than F's). Note that a large amount of the two headers is identical.
Yeah, already noticed that the header is 38h bytes in size. I also noticed that there is nothing updated, except the marker and pubkey data as I've rebuilt the mod pressing save bios as.... So I have to assume there are no (module) checksum bytes corrected....means no checksum present. The bios I've modified contains two different pubkey and two different marker data (SLICs). One of it was inactive..that's strange...
Yeah good point I guess there is no checksum! It would be useful to find where the size of the module is stored in the header so an app can be made to automate the process. Which BIOS is this Yen?
It won't affect your existing vista install i just flashed my dell inspiron 530 to SLIC 2.1 vista is still activated
The last 182 bytes of SLIC table make marker and previous 156 bytes make pubkey, pretty easy to do in Winhex > copy block in new file.