Thanks a lot, I'll try it. I hope you'll stay here at MDL if I have further questions. I'm not familiar with IDA, but I'll give it a try at weekend. I'm not familiar with any disassembler....I've tried to figure out how to locate the bytes at another bios using hexeditor only. I don't even use AMI bios, a friend does, Asus P6T deluxe, the next I want to try....... I'm doing a lot of hex-editing so my eyes are noticing quickly some similarities at code...... But a method that will show me clearly what's going on (disassembly) is what I need to try. Don't like the feeling that it was probably luck only to have found the right bytes....... Finally I want to figure out how to give general patch instructions for the new generation........(I already found a way, but need to have a look at more 1b modules......at rampage it looks OK as you've said.......) Thanks again......
Thanks to you Yen. I love this forum and have learned a lot from it. I am not good at assembly but I am willing to help. I believe there is another way to active slic without patching the BIOS code: Search hex value: 0F00 0000 6201 0000 00 in the 1B module Change it to: 0F00 0000 6201 0000 03 xor 0xFF to the public key and maker block of your slic. (starting offset 0x24) copy it to the slic in the 1b module. I haven't tested it. Flashing BIOS is always a dangerous thing to try. but if this works, it is sure a clean way to active slic in the bios.
I'm feeling like a noob You mean starting offset 0X24 is where public key starts, till end XOR all bytes with FFh? A sort of re-encryption? like Asus pubkey and marker: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000020 FF FF FF FF 63 FF FF FF F9 FD FF FF ÿÿÿÿcÿÿÿùýÿÿ 00000030 FF DB FF FF AD AC BE CE FF FB FF FF FE FF FE FF ÿÛÿÿ*¬¾Îÿûÿÿþÿþÿ 00000040 90 6D 62 23 4C 86 11 D8 D9 F7 07 23 A4 27 A0 B4 mb#L†.ØÙ÷.#¤'*´ 00000050 DE CB 54 9F 13 6F 38 3D 2A 9F 2A 0A 26 7D 06 D1 ÞËTŸ.o8=*Ÿ*.&}.Ñ 00000060 41 17 BC C7 2A 3D A4 61 DA 47 6C 32 EA 47 E4 3C A.¼Ç*=¤aÚGl2êGä< 00000070 CF 82 52 AA 96 86 42 E5 81 BB 37 43 A6 A5 E8 41 Ï‚Rª–†Bå»7C¦¥èA 00000080 7E 52 10 11 69 DE C8 33 75 BD 9D 39 EB FA F6 DE ~R..iÞÈ3u½9ëúöÞ 00000090 96 85 1E 73 B5 31 29 37 E7 87 87 79 D4 CF 9C 59 –….sµ1)7燇yÔÏœY 000000A0 1A 9B 48 2D EB A1 D4 BB 41 CC ED 94 94 5C 42 61 .›H-ë¡Ô»AÌí””\Ba 000000B0 7A 44 41 93 1E 4E CC 3D 25 6E 7F 0C BB 4B 35 60 zDA“.NÌ=%n.»K5` 000000C0 FE FF FF FF 49 FF FF FF FF FF FD FF A0 BE AC AA þÿÿÿIÿÿÿÿÿýÿ*¾¬ª 000000D0 AC A0 B1 90 8B 9A 9D 90 90 94 A8 B6 B1 BB B0 A8 ¬*±‹š”¨¶±»°¨ 000000E0 AC DF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ¬ßÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 000000F0 FF FF FF FF FF FF DB 4F 76 30 4E 0C E2 47 85 7F ÿÿÿÿÿÿÛOv0N.âG… 00000100 CA 34 32 B5 37 D0 7B 31 66 5F B0 C7 89 4F FB 06 Ê42µ7Ð{1f_°Ç‰Oû. 00000110 90 FA CC 38 13 57 A7 59 28 48 C0 A4 7D 4E 11 D4 úÌ8.W§Y(HÀ¤}N.Ô 00000120 58 7E AD 0C BA EC 31 11 2A A8 C8 01 8A A0 A3 9D X~*.ºì1.*¨È.Š*£ 00000130 3B AC 25 79 0E CB 05 12 6E 79 8C 61 2D 9A 02 75 ;¬%y.Ë..nyŒa-š.u 00000140 C2 79 6B D0 D5 9A E7 A3 26 1A 83 EA E1 0D F7 3A ÂykÐÕšç£&.ƒêá.÷: 00000150 7A 3B 70 F4 05 5A 3C 56 4F 0E 4D 18 95 B9 04 E7 z;pô.Z<VO.M.•¹.ç 00000160 FE A2 B3 C9 CC 21 04 18 E2 17 EA 3D 7A 60 75 56 þ¢³ÉÌ!..â.ê=z`uV 00000170 CD 97 E0 4B 43 57 Í—àKCW Then insert the xor'ed public key and marker? is that right? That sounds great! What about the SLIC header at 1b module: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00065180 53 4C SL 00065190 49 43 76 01 00 00 01 00 41 5F 4D 5F 49 5F 4F 45 ICv.....A_M_I_OE 000651A0 4D 53 4C 49 43 20 26 08 00 11 4D 53 46 54 97 00 MSLIC &...MSFT—. 000651B0 00 00 .. No XOR? Do you have the chance to test this way at p5q? That would be very cool. Nice way....and even only one byte to change additionally..... Btw: I've managed to disassemble the part. WoW, IDA is a huge tool Still have to play with it......
Hi, Yen, In the function sub_9C66: ..... _4000:9C70 push cs _4000:9C71 call near ptr sub_9CF6 ; xor the PUBKEY+MAKER block with 0xFF _4000:9C74 jnb short loc_9C8A ; jump if there is an error ..... So if we want to leave the BIOS program code untouched, we need xor the pubkey and maker block with 0xff before we add it to the 1B module: Steps: 1) take a SLIC 2) seek to offset 0x24 3) loop till the end of file: xor byte with 0xff 4) copy the encrypted SLIC to the 1B module In the sub_9CF6, the xor is after the header, so we can leave the SLIC header unchanged.
Hi I am very interested in looking at this as well so I hope you don't mind a question. I am trying to load the 1b module in IDA (it was a long time ago I last did ASM programming - and it looks far more complicated than CodeView!). When it asks for a segment and offset I worked from the fact that the AMIBIOS string is offset FF400h and worked back the first byte will be ef867 so put that as an offset. The code after 'system version' is then at 109c3c - however the call/jmp offsets are still all wrong. Help! Code: seg000:00109C3C pushaw seg000:00109C3E push ds seg000:00109C3F push 0B01FF000h seg000:00109C44 add [edx-17F15F20h], esp seg000:00109C4A imul eax, [ecx], 3ABB1472h seg000:00109C50 pushf seg000:00109C51 mov al, cs:[edi] seg000:00109C54 cmp al, 0 seg000:00109C56 jz short loc_109C5E seg000:00109C58 push cs seg000:00109C59 call near ptr 4829DF2h seg000:00109C5E seg000:00109C5E loc_109C5E: ; CODE XREF: seg000:00109C56j seg000:00109C5E push cs seg000:00109C5F call near ptr 662F9E7Eh seg000:00109C64 popa seg000:00109C65 retf
Yes, so I've got it right. What exactly is this for?: Change it to: 0F00 0000 6201 0000 03 This sequence is found once at offset A878, far (before) away of 'System Version' routine (1A3C3). How did you find the relation to it? Do you still have access to a second p5q board to test your idea? This would be a very clever method, if it works.
Hi, Yen, In my previous posting: I didn't see any configlock. But there is a little piece of code in f000:72bd which pull values at f000:e1a0 (0f00 0000 6201 0000 00) and set al to 0: E1A000F0 => 0F00 0000 6201 0000 00 ds = 0xf000 si = 0xA0E1 bx = [si+2] = 0 cx = [si+4] = 0x162 dx = [si+4]-0x10 = 0x152 al = [si+8] = 0 si = [si+6] = 0 later on the function branched based on the al value. What happens next is the part I am not so sure of. But since the edi was pointing to the PUBKEY+MAKER block, I guess one of the branch will change the data preventing it being copied to high memory. ==================== This value is in 0xf000 segment; it is not in 0x4000 segment ==================== There are many interesting functions in the first 0x0 - 0x520 block of the 0x4000 segment. Here are some I figured out: _4000:0402 func_vector <8Dh, 0, 0B270h, 4000h> ; Process and Add RSDT, XSDT, etc _4000:0408 func_vector <0FFh, 0FFh, 0A032h, 5936h> ; Add HPET table _4000:040E func_vector <0FFh, 0FFh, 9560h, 4000h> ; Add OSFR table _4000:0414 func_vector <0FFh, 0FFh, 9C3Ch, 4000h> ; Process SLIC (step 1) _4000:041A func_vector <0FFh, 0FFh, 0E584h, 4000h> ; Add TCPA table if exist _4000:0420 func_vector <0FFh, 0FFh, 500Bh, 4000h> _4000:0426 func_vector <8Ch, 0, 479Ch, 4000h> _4000:042C func_vector <8Ch, 40h, 6926h, 4000h> _4000:0432 func_vector <8Ch, 41h, 6ADFh, 4000h> _4000:0438 func_vector <8Ch, 42h, 6E5Fh, 4000h> _4000:043E func_vector <8Ch, 50h, 0AB14h, 4000h> _4000:0444 func_vector <8Eh, 0, 486Ah, 4000h> _4000:044A func_vector <8Fh, 0, 3D92h, 4000h> _4000:0450 func_vector <90h, 0, 0E31Ah, 4000h> _4000:0456 func_vector <0FFh, 0FFh, 0B4C8h, 4000h> _4000:045C func_vector <0FFh, 0FFh, 0E881h, 4000h> _4000:0462 func_vector <0A1h, 0, 4877h, 4000h> _4000:0468 func_vector <0FFh, 0FFh, 0DD63h, 4000h> _4000:046E func_vector <0FFh, 0FFh, 8403h, 4000h> _4000:0474 func_vector <0FFh, 0FFh, 9C66h, 4000h> ; Process SLIC (step 2) and Add SLIC table
I prefer not letting IDA to create segments if you open the 1B module in its original form. Here is how I did it: 1) open 1b in IDA 2) search for string "_32_" 3) create a segment from "_32_" with a size of 0x10000. call it _F000 segment 4) create another segment right after it call it _4000 segment and disassemble the code from there
If anyone has got an Asus board with AMI bios and is able to recover the bios in case of a bad flash, please reply. There are 2 new ways to enable dynamic SLIC hnfz Your first approach is IMO easy to realise as well. 1. Search for byte sequence 73 1A 0E E8 Now NOP the coloured bytes: 73 1A 0E E8 XX 00 73 14 0E. the XX byte is variable. 2. Search for byte sequence 83 C7 24 B0 00 BB 0F 00 after the system configuration string, next bytes are 9A XX XX 00 F0 BE NOP them as well, have to do more tests to see if it's explicit.
another breaktrough! you guys are great!!! though I barely understand what you are discussing (dissassembly/lock config OMG!) I am always reading it again and again. You guys deserved a break.....and i am sure everybody here wants to thank you all. yen....bios killer....no doubt about it hnfz...bios twister..IMO and i am sure no contest andyp..bios mechanic. IMO and i am sure no contest. ill test this method when i have oppurtunity. one question...are you guys from mars?.....
Hi, Yen, No need to flash twice. without changing the dword value after the $BCS string, EZflash gives an error msg: "boot block in file is not valid". afudos gives the same error message. How do we flash then? Not EZflash, Not afudos, what else can we use besides an EEPROM programmer? hint, hint..
Yes, you're right. But this seems to be a special issue at p5q. I did a lot of ASUS AMI mods by changing the 1b module. To update to current version and to flash the mod after using Afudos always worked. (Last one I've tried was P6T Deluxe, SSv3). We've never had to change that DWORD so far doing a SSv3....... I'll add the info, thanks. andyp How did you flash the M2F 1802 mod? Have you changed that DWORD as well?
as Yen said, this method is primarily for educational purposes. It is far from perfect yet. Here are two issues need to be working on: 1) find out how EZflash verifies BIOS. It reports "boot block in file is not valid" to all AMI BIOS modification methods available so far. If we cannot pass this verification, there is no way to flash modified BIOS using EZflash or afudos 2) In this method, I "nop"ed out a function call to "0F000h:72BDh": This is a P5Q 1611 BIOS: ******** _4000:9DB5 loc_19DB5: ; CODE XREF: sub_19C3C+Dp _4000:9DB5 ; sub_19C66+5p _4000:9DB5 push es _4000:9DB6 push ds _4000:9DB7 push 2CCFh _4000:9DBA pop es _4000:9DBB xor edi, edi _4000:9DBE mov di, 0C25h _4000:9DC1 add di, 24h ; '$' ; SLIC offset 0x24 _4000:9DC4 mov al, 0 _4000:9DC6 mov bx, 0Fh _4000:9DC9 call far ptr 0F000h:72BDh ; This need to be "nop"ed out. otherwise destroy SLIC ******** If someone can figure what happened in "0F000h:72BD" function call, it will be much better than patching the code. Disassembly skills are welcome~
Used MMTool to integrate the 1B made by my prog - I think as the 1B with its own checksum adds up to dword 0 the $BCS$ dword does not need to change. I am playing with checksums for the SSV2 method... I will let you know what I find. I actually flashed with EZflash. I was at 1802 (SSV2) already so no bootblock flash. Andy
Hi, Yen, you are right. I just noticed this error messages on P5Q series. Someone reported P5K had the same problem. I haven't seen it in P5B or earlier boards.