ITK will refuse even if you do not change any byte. try to check. I do not believe that something in the computer can be safe
Code: seg000:000000000000D3F7 mov cs:qword_C760, 0 seg000:000000000000D402 lea rax, qword_C760 seg000:000000000000D409 mov [rsp+20h], rax seg000:000000000000D40E mov rax, [rsp+60h] seg000:000000000000D413 lea r9d, [rcx+0Eh] seg000:000000000000D417 mov r8b, 1 seg000:000000000000D41A mov rdx, rbx seg000:000000000000D41D mov rcx, rax seg000:000000000000D420 call qword ptr [rax+8] seg000:000000000000D423 mov rax, cs:qword_C650 seg000:000000000000D42A mov rcx, rbx seg000:000000000000D42D call qword ptr [rax+48h] Couple of questions. 1) Aren't the first two instructions the same as xor rax,rax?? 2) What is significance of [rcx+0Eh] - for the MCFG table it is [rcx+06h] (if I remember correctly lea r9d,[rcx+0Eh] is effectively the same as r9d=rcx+0Eh)?? Andy
The original Bios file opens fine when you load the corresponding *.ITK file. Anyway when you have a look at physical memory, you don't find the interesting code being decompressed. So to mod at physical memory isn't possible. ITK allows to mod boot screens and settings, all out of the signed areas. But some checks must be there, otherwise I wouldn't refuse to load the mod. I guess ITK checks for the signature the same way and recognises it being invalid. I don't know if it would be possible to figure what ITK makes to refuse to open it and then patch the bios in order it's validated after. Like mod opens in ITK = mod flashes well....
Yes, it's all hypothetical..I guess we are stuck now, at least I am....hope middleton and andy can go on. It's far beyond my understandings.
1) mov cs:qword_C760, 0 puts zero into memory location [ImageBase + C760]. For example, if ImageBase = 0x400000 then qword whose memory address is 0x40C760 will be set to zero. lea rax, qword_C760 loads in rax address of memory. If ImageBase = 0x400000 then rax will contain 0x40C760 after executing of this assembler instruction (LEA - Load Effective Address). 2) I've just checked my patch - for the MCFG table the code is also lea r9d,[rcx+0Eh] as for SLIC table. This assembler instruction is equal to the following: r9d = rcx + 0x0E. rcx in our case is equal to zero (see instruction xor ecx, ecx above in the code) so r9d = 0x0E. You can ask me: What does this 0x0E mean? Here is a quote from MSDN: "The primary thing to know about the x64 calling convention is its similarity to the x86 fastcall convention. Using the x64 convention, the first four integer arguments (from left to right) are passed in 64-bit registers designated for that purpose: RCX: 1st integer argument RDX: 2nd integer argument R8: 3rd integer argument R9: 4th integer argument Integer arguments beyond the first four are passed on the stack." Therefore in R9 we have the 4th parameter of EFI_ACPI_SUPPORT_PROTOCOL.SetAcpiTable() - it's EFI_ACPI_TABLE_VERSION. EFI_ACPI_TABLE_VERSION_1_0B = 0010b EFI_ACPI_TABLE_VERSION_2_0 = 0100b EFI_ACPI_TABLE_VERSION_3_0 = 1000b So we have SLIC table which is compatible with all ACPI versions as 0x0E = 1110b.
Hi 1) My bad. LEA always confused me (and I have not actually programmed in ASM for nearly 15 years now!). Why is mov cs:qword_C760, 0 performed. There does not seem to be an equivalent in the MCFG code. 2) My bad. You are quite right. Both are 0Eh. I don't know what I was thinking! Andy
Hi Having a free time today I tried to play with the recovery mode, with the last 2 mods, which already reported. All as usual: after first boot I have working slic and updated bios, and after switching off recovery mode - no slic and old bios. I we can not modify protected modules, can we replace for example boot logo with slic. Or may be something like ISA module?
Middleton, Please check your PM. I guess there is no point currently in implementing your Intel mod, as the result cannot be flashed I will have a look at your feature request next! Andy
andyp About RC5. 1) I padded 16 bytes before the new code only to separate my patch visually from the previous contents of the last section. 2) I advise you to patch the first jump like I did it. The matter is that the first jump executes if LocateProtocol(EFI_ACPI_SUPPORT_PROTOCOL) fails and in that case - if you don't patch the first jump - my code will call SetAcpiTable() method using null pointer. This will definitely force BIOS to hang or to get into recovery.
Thanks for this. I will look tonight. Off the top of my head - should the first jump then point to the add rsp,38h.... retn. Andy
Yes, the first jump should point to the add rsp,38h.... retn because if we don't get a pointer to EFI_ACPI_SUPPORT_PROTOCOL we'll be unable to call SetAcpiTable() method.
its efi bios yes, and rc5 can already open and mod it, however i wouldnt trust that mod atm, since andyp is still fixing bugs etc. So just wait a bit. Oh ye this vaio bios suppose to have slic 2.0 inside according to rc5, question is if it gets replaced properly. So here is another sample of efi bios to check.