So, we have a SLIC but it is empty. So, can we find anywhere else that may alter the SLIC. Yes! We can see that offests to the ACPI tables are stored in dwords from F000:7974h - so the SLIC offset is at 7990h. Using this knowledge we find: Code: seg000:6523 push esi seg000:6525 mov eax, [esi+7990h] ; ? SLIC offset seg000:652D or eax, eax seg000:6530 jz short loc_6573 seg000:6532 mov edi, [esi+7974h] seg000:653A mov es:[edi+2Ch], eax seg000:6540 mov edi, [esi+7978h] seg000:6548 mov es:[edi+34h], eax seg000:654E mov edi, eax seg000:6551 add edi, 24h ; '$' seg000:6555 mov esi, 6E000h seg000:655B mov ecx, 9Ch ; '£' seg000:6561 rep movs byte ptr es:[edi], byte ptr [esi] seg000:6564 mov esi, 6F000h seg000:656A mov ecx, 0B6h ; 'Â' seg000:6570 rep movs byte ptr es:[edi], byte ptr [esi] We note that 24h is the size of the SLIC header (unmodified), 9Ch is the size of the pubkey and B6h is the size of the marker! Step 2: nop out the rep movs instructions: offsets 6560h and 656fh 00 f3 67 a4 66 00 90 90 90 66 End result - the slic table is now copied correctly. However the SLIC and OSFR tables still have an blank OEM/Table ID field (actually all the ACPI tables do). Look at the original code again. A subroutine at 6335h is called: Code: sub_6335 proc near ; CODE XREF: sub_6299+41p seg000:6335 pusha seg000:6336 push ds seg000:6337 push es seg000:6338 push offset unk_4000 seg000:633B pop es seg000:633C assume es:nothing seg000:633C mov di, si seg000:633E add di, 0Ah seg000:6341 push 6F00h seg000:6344 pop ds seg000:6345 assume ds:nothing seg000:6345 mov si, 0Ch seg000:6348 mov cx, 0Eh seg000:634B rep movsb seg000:634D pop es seg000:634E assume es:nothing seg000:634E pop ds seg000:634F assume ds:nothing seg000:634F popa seg000:6350 retn seg000:6350 sub_6335 endp Which copies 14 bytes (the size of the OEM and Table ID fields) from 6F00:Ch (where this info is found in the SLIC marker) to new ACPI table +10 bytes - the offset of these ID fields. Step 3: nop out the call offset 62D9h 03 e8 58 00 66 03 90 90 90 66 End result - IT WORKS! Summary and thougts in next post...
Summary Replace: EB 06 90 80 8E xx xx 01 BF with EB 06 90 90 90 90 90 90 BF EB 06 90 80 8E xx xx 02 07 with EB 06 90 90 90 90 90 90 07 66 B9 9C 00 00 00 F3 67 A4 with 66 B9 9C 00 00 00 90 90 90 66 B9 B6 00 00 00 F3 67 A4 with 66 B9 B6 00 00 00 90 90 90 75 03 E8 58 00 66 3D 4F 53 with 75 03 90 90 90 66 3D 4F 53 And ensure there is: 1) A full SLIC in the ACPI module 2) At least the RSDT, XSDT (if present), SLIC and OFSR table and OEM IDs match. What have we actually achieved? This is still being tested but - I think we have found the code that the pubkey/marker method takes adavantage of. It would seem that the pubkey get loaded/are expected at 6E000h and the marker into 6F000h. We have simply modded the code to take the SLIC from the ACPI table. Clearly if a pubkey/marker mod works that is far less invasive. However, if for some reason it was not, this would be an alternative method. It still involves modding the code in multiple places so is inherantly more risky than normal mods..... I have not yet looked at other ASUS Award BIOSes to see if it can be more generally applied. Work to be done - to see how the pubkey and marker end up at the addresses above and whether that can be manipulated to avoid code modding. Also, as a side effect, you get a valid OSFR table for free. I don't know much about this table - I understand it is needed for some cable cards to work in HD (along with an additional Vista PID for the media center). In theory it would be possible to add an OSFR table in the normal mods anyway.... Cheers, Andy PS And thanks to Zort for risking his board to test! (although it was his idea!)
Some findings from zort (thanks!) that confirm the code is the same code that normally dynamically loads the pubkey/marker. I guess the next steps is 1) to see if the process can be intercepted earlier and fool the BIOS into thinking there is a SLIC without having to do all the patches 2) to see if there are other ways to insert the pubkey/marker, other than flashing... Andy
No, not this time, but we should keep that method in our minds. But to remove a 'lock' of a already implemented routine is of course reasonable. Reasons: We have approved methods already. 'Super Static' addresses are even used at a few official OEM bioses. I was worried about that M$ will block super static addresses some day.
Great work Andyp and Yen I m very interested in a mod for my Asus m3n78 pro to achieve a populated SLIC 2.1 and OSFR table. Or a software emulation to get these two tables. I currently am running a OSFR emu on my windows 7 RC. I am willing to mod my bios in order to get this to work since I want to update anyway. In the mean time I will be researching these topics more.
Thank you so much zort, I will install the bios, then report the results sometime this week. I can't believe how quick your responses and work are. You guys have a great community and I will do as much as I can to contribute back to this wonderful community. Thanks again sir.
Well I installed it and it didn't work. Now it just boots to a black screen. Is there anyway to recover my motherboard or is it broken forever?
Is the award tool what is used to emulate the osfR table? If I can get this fixed, no free time for acouple of weeks, I would prefer a software emulation of both the slic 2.1 and the osfr table. That'd probably ne the easiest to troubleshoot. Or trying to mod the bios for just the slic 2.1 then emulate the osfr table like I have been doing, after I got everything installed. I don't know if the emu would break the activation or not.
Can you run the newest bios through the award tool for me since I don't have time to mess with it because my motherboard is down for now and I'm getting married Friday, if my soon to be wife found out a was fooling around with this stuff she d probably kick my ass! Thanks in advance.