Yes One extra 'SLIC' string gets replaced with 'OEMX'. I am looking at why the tool doesn't do this. Andy
The phoenixtool191b5 produces an out of bounds error with the ASRock Fatal1ty 990FX Professional version 1.20 and 1.10 EFI files in the Windows 7 x64 OS and Windows XP VM guest environment. The error does not occur with phoenixtool191b4 using the same EFI files in the same OS and VM guest environment. The phoenixtool191b4 program can run completely, with No SLIC option enabled, to produce new versions of the 1.20 and 1.10 EFI files. I've attached a screenshot of the phoenixtool191b5 produced error and phoenixtool191b4 version 1.20 EFI SLIC Log. Update 00: The phoenixtool191b5 does not produce this error with the ASUS SABERTOOTH 990FX version 0402 EFI file in the Windows 7 x64 OS and Windows XP VM guest environment. The program can run completely, with No SLIC option enabled, to produce a new version 0402 EFI file. Update 01: The phoenixtool191b5 does not produce this error with the ASRock 890FX Deluxe5 version 1.20 EFI file in the Windows 7 x64 OS and Windows XP VM guest environment. The phoenixtool191b5 program can run completely, with No SLIC option enabled, to produce a new 1.20 EFI file. However, the phoenixtool191b5 reproduces the same error using the version 1.40 and 1.50 EFI files of the ASRock 890FX Deluxe5. Update 02: The phoenixtool191b5 does not produce this error with the ASUS Crosshair V Formula version 0506 and 0404 EFI files in the Windows 7 x64 OS and Windows XP VM guest environment. The program can run completely, with No SLIC option enabled, to produce new versions of 0506 and 0404 EFI files. Update 03: The phoenixtool191b5 reproduces this error with the ASRock 990FX Extreme4 version 1.00, 1.10, and 1.20 EFI files in the Windows 7 x64 OS and Windows XP VM guest environment. Update 04: The phoenixtool191b5 does not produce this error with the ASRock 890GX Extreme4 R2.0 version 1.10 and 1.20 EFI files in the Windows 7 x64 OS and Windows XP VM guest environment. The program can run completely, with No SLIC option enabled, to produce new versions of 1.10 and 1.20 EFI files. However, the phoenixtool191b5 reproduces the same error using version 1.40 EFI of the ASRock 890GX Extreme4 R2.0.
OK folks... some progess looking into the mechanism of the NVRAM mod. I have found this code in the A7C6.... module Code: .text:000000000040D42C push rbx .text:000000000040D42E push rbp .text:000000000040D42F push rsi .text:000000000040D430 push rdi .text:000000000040D431 mov r11, rsp .text:000000000040D434 sub rsp, 28h .text:000000000040D438 mov eax, 100h .text:000000000040D43D xor edi, edi .text:000000000040D43F lea rcx, [r11+28h] .text:000000000040D443 mov [r11+38h], rax .text:000000000040D447 mov [r11+30h], rax .text:000000000040D44B mov eax, cs:dword_4101FC .text:000000000040D451 mov [rcx], eax .text:000000000040D453 mov al, cs:byte_410200 .text:000000000040D459 mov dl, dil ; DIL (lower 8 bits of RDI) is 0 .text:000000000040D45C mov [rcx+4], al .text:000000000040D45F mov r8b, [r11+28h] .text:000000000040D463 lea esi, [rdi+1] ; ESI=1 .text:000000000040D466 cmp r8b, dil .text:000000000040D469 jz short loc_40D47D .text:000000000040D46B lea rcx, [r11+28h] .text:000000000040D46F .text:000000000040D46F loc_40D46F: ; CODE XREF: sub_40D42C+4Fj .text:000000000040D46F add rcx, rsi ; INC RCX .text:000000000040D472 add dl, r8b .text:000000000040D475 mov r8b, [rcx] .text:000000000040D478 cmp r8b, dil .text:000000000040D47B jnz short loc_40D46F ; INC RCX .text:000000000040D47D .text:000000000040D47D loc_40D47D: ; CODE XREF: sub_40D42C+3Dj .text:000000000040D47D mov rcx, cs:qword_4B5490 .text:000000000040D484 cmp [rcx+0D2h], dl ; Board specific flag .text:000000000040D48A jnz loc_40D616 ; Exit with RAX=1 .text:000000000040D490 cmp byte ptr [rcx+0D4h], 0FFh I can't figure out what is at r11+28 other than its on the stack and probably from a previous subroutine. But it seems to calculate a value that is compared against A01D2h in the NVRAM I wonder if an easier answer would by to NOP the jump at 404D48A. Anyone with an ASUS K43/53 board that is happy to experiment?? Andy
@andyP This question may have been posed to you before, you've thought of it yourself, or it's not reasonable/possible to accomplish. Have you considered, planning, or are currently creating separate tools for Phoenix, InsydeH20, and EFI firmwares? I would believe the code is more organized, easier to maintain, among many other benefits to your work with these firmwares.
Actually the tool was written the other way round... there are lots of shared routines - Insyde is effectively EFI anyway it turns out. At one point I thought of combining AMI and Award into this one as well - it's actually easier to maintain one tool. But given they are effectively dead now they wont be getting any further development so will be left as is. What may happen over the next year is Dell and Phoenix get stripped out, and an legacy version of the tool is left for those - I don't think i've touched them in ages and ages. And the tool then only moves forward with EFI. Andy
Thanks for information. I didn't think about them sharing subroutines and I was aware that newer InsydeH20 were EFI or hybrid EFI firmwares. That is surprising it would be easier to maintain one tool, as opposed to, a tool per each genus of firmware. I would have thought that the shared subroutines would not change that often but the functions for reading the structure's headers/DXEs/PEs, compressing, and decompressing, changed more often. Anyways, you're doing great work and I've learned quite a bit more in the past year from MDL, RHCF, and Darmawan Salihun's (Pinczakko) blogs, posts, and books. BTW, you might be interested in some of the tutorials by this blogger. However, it may not be of any help if you're already familiar with it. hxxp://pete.akeo.ie/
Well, what will happen with the tools also depends on windows 8 OA3.0. Your tools have started with the intention to add a SLIC and / or an SLP string. This was the one and only motivation for me to learn about BIOS / EFI at all. Recently I do not much biosmodding (busy with Android), but I am still interested in how your tools are developing. I am very happy that you are still around here at MDL and that you are updating your tool(s). Since official EFI tools seem not to leak (AMI BCP for EFI has been leaked though) your tool is the only one and the first that is able to decompose EFI and rebuilds it after modifications. You can be very proud of it. It is used by many people who want to mod their EFI (not implicit to SLIC it) If OA3.0 shouldn’t be implemented at BIOS / EFI anymore your tools still can be used for any module modifications. To ‘SLIC’ a EFI / BIOS would be just an additional option then. It seems there are more and more EFIs now replacing the BIOS. Only Award seem to stay at BIOS or at least at an hybrid. Looking forward to w8 and OA3.0....at the latest then I’ll start again. Keep it up!
Tested phoenixtool191b6 with the ASRock Fatal1ty 990FX Professional EFI version 1.20 file, with No SLIC option enabled, and it produced the same output as phoenixtool191b4. Thanks for the update.
If the module you are trying to add is already compressed tick compressed. If it is not leave it unticked and the tool will compress automatically. So when adding slpsupport.mod manually, compressed should be ticked, as it is already compressed. What exactly are u trying to do that gets the module count mismatch (ie which efi, adding/replacing which module, compressed ticked/unticked) nvram method - it will automatically determine if the efi is x43SJ, x53SJ, x43E, x53E and use the appropriate 1d2h byte EDIT: Although it appears I broke this in b6. b7 soon. Good spot Andy