He tried also through DOS using the leprg.exe is only one side of the indicator appears some mechanical characters.
Well done! You are several steps ahead of me..... so I have stopped and had a rest! I have written EFI parsing/dumping (ala XFV3) into the tool. I will study your work and incorporate it. Nice one Andy
I will be waiting for your tool, Andy. At the moment it takes 10% of time to find a solution and 90% to insert module into BIOS. You must pack file, change section and file sizes, recalculate checksums, make right aligning etc. It's very easy to make a mistake on some stage. And if BIOS don't work properly you can't understand whether it was a wrong solution of the problem or you did a mistake in checksum. Feel free to ask the questions if you need to clarify some things in my ASUS P5Q Deluxe patch.
I'm good at that mind numbing stuff! I am looking thru the 80E6 module....... to be honest I can see what you've done but not why...... I guess my questions would be: 1) I assume the first couple of changes are size - I need to remind myself about PE32 headers. 2) Why the changes around 270h and 290h?? 3) What are the changes around B120-70h (It appears to be some sort of table... doesn't really look like code)?? 4) How did you know where to put the SLIC, and how to pad it (with CCh before/after and with C7 xx xx every DWORD?? Andy
andyp These changes concern efi-executable PE-header. 1) This is "Size of Image" field changing. 2) Here I changed attributes of last PE-executable section ".reloc". I needed to add code therefore I expanded last section and changed its attributes to show efi-loader that this section contains executable code and loader must not remove section from memory after image loading. It's usual behavior for virus-like code which infects executable file. By the way, I am absolutely sure: if all BIOS vendors will make their products UEFI-based then viruses for BIOS will appear very soon . BIOS adds MCFG ACPI table here. It's a 64-bit code. Yes, UEFI BIOS'es are mostly 64-bit based. I changed here only three assembler jumps so that they lead to my code. On my Toshiba laptop SLIC table is placed in memory right after MCFG ACPI table. I decided to make in the same way. I inserted jump to my code after MCFG ACPI table adding. I placed SLIC adding code in the last section free space (do you remember I expanded last section?). 0xCC opcode (int 3 instruction) is a usual executable files' padding. 0xC7 encodes assembler instruction "move dword to memory". Here I move SLIC table bytes into memory buffer forming the complete ACPI SLIC table. Then I transmit a pointer to that buffer to EFI_ACPI_SUPPORT_PROTOCOL.SetAcpiTable() method.
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] seg000:000000000000D430 seg000:000000000000D430 loc_D430: ; CODE XREF: seg000:000000000000D0A2j seg000:000000000000D430 add rsp, 38h seg000:000000000000D434 pop rdi seg000:000000000000D435 pop rbx seg000:000000000000D436 retn Is this the EFI_ACPI_SUPPORT_PROTOCOL.SetAcpiTable() calling code?? Andy
seg000:000000000000D420 call qword ptr [rax+8] calls EFI_ACPI_SUPPORT_PROTOCOL.SetAcpiTable() seg000:000000000000D42D call qword ptr [rax+48h] frees allocated memory for SLIC table
I am new at this but very interested in learning. I flashed the asus patched rom successfully. I hope to figure out how to edit the slic 2.1 table from Asus notebook to my HP desktop. And maybe enter SLP 1.0 HP Pavillion strings to accomodate my XP Media OEM. Thanks for the interesting reading...I have a lot to learn. Bullet
I'm thinking about SSv2. To inject the SLIC (would it be written to EEPROM?). Therefore the question, middlenton. Do you think there is a way to extend the XSDT +8 bytes and set a static address call to EEPROM where the SLIC is located? Then also modify the OEMIds. I guess to disassemble the XSDT could shed some light. This could be an easier approach if possible at all.
At the moment I don't have enough information to answer your question. I think you'd better ask Andy, he is much more experienced than me in such SLIC injection methods.
I am sure you could do it SSV2..... put the SLIC somwhere in the padding at the end of a FV, but it looks like you would still need to modify code. At first glance (and I don't have it in front of me) all the tables are generated dynamically in code, so it would need to be modded to put the SLIC offset in the right place. Middleton's way is very elegant, and probably the best. From a tool point of view it just depends if the same code is present in all EFI BIOSes so it can recognise the opcodes and patch them. Challange 1 is writing the EFI manipulation code - I am 75% done here - it can insert/replace same sized modules, I am writing the code to deal with different sizes as we speak. Insyde will now use the EFI code path, and this shares a lot of code with the phoenix path (as they now dump modules to disk). It will be possible to do a middleton mod manually and have the tool reinsert the amended module. Challange 2 is writing code to insert the slic generation code. That comes next! Andy
UEFI bioses allow to inject a virus / trojan. I guess Intel has advanced integrity checks to avoid manipulations. Knowing Intel I guess it will be hard to circumvent that..... Edit: At recovery mode it updates the bios, right? Your PC boots and the SLIC is there. What happens when you reboot again? Does it flash the recovery bios(mod) again? Then when you remove the recovery bios, it searches endless? Have you tried to recover your bios twice? I guess the original bios is stored somewhere, probably on HDD (btw: is there a second EEPROM chip, like dual BIOS?)....and will be restored. What's strange to me is the fact that the recovery function updates the mod already! I don't know if the known integrity checks (checksums) are right, but I guess middleton did fantastic work and they are right already.
I would try to recover it twice. Hoping it keeps the last backup only...is there any option at the bios setup regarding recovery?
Some thoughts about Intel UEFI implementation. 1) Intel BIOS is not simply an image for flashing. It's an UEFI capsule (see Capsule.pdf). Flash utility assembles BIOS image from the capsule and then flashes image into flash chip. 2) Capsule has two copies of important files so you need to patch every file twice. 3) Intel uses additional protection for important firmware volume files. I found 2-byte field which gives additional checksum. 4) There are checksums of either whole BIOS image or important files somewhere in the BIOS. I think it is the reason why Intel desktop board DG41RQ can detect BIOS changing. But at the moment I have not found the place where Intel BIOS keeps these checksums.