I have found a pair of stupid bugs in 0.12, will release 0.13 soon to solve them. KaminoReal, mediafire works well for me and bunch of other people. What is your favorite host?
This volume is located inside volume image section, which is located inside LZMA-compressed section of a file in Volume 01. This structure is typical for almost all AMI Aptio UEFI BIOSes, only ASUS uses another, flat structure, AFAIR. There is nothing to fix: View attachment 26172 BTW, you can locate your "missing" files by searching it, using "Search->Text->NameOfYourFile" with Unicode box checked.
I have a report, that BIOSes for ASUS Z77 boards won't boot after modifying with UEFITool. Can someone with external programmer or additional SPI chip test that?
@CodeRush: Thx for the info. .... Is it possible with your tool to extract/replace/delete 'Option Roms'? Thx
0.14.1 is out, another bugfix release, once again upgrade is recommended. Changes are in the first post. Binary download host is changed to Sendspace. OSX binary will be uploaded tomorrow. @mictlan, there is no GUI for it, but you can use HexEditor to mod CSMCORE file and then replace it's body with UEFITool. I have no plans to integrate OROM editing, because they are in near dead state, and many people use "UEFI only" approach on their new boards.
I have finaly found the source of that bug with ASUS boards, that was reported 4 days ago: PEI modules in boot firmware volume must be executable in place, so UT must rebase all modules with modified offset, or modified BIOS will be bricked. I must study PE32+ and TE file formats to implement this, but MMTool has already a working solution, so testing can be performed without flashing. Will release this bugfix as soon as possible. If you don't want to modify PEI volume (where most files have 'PEI Module' type), you will not be affected by this bug.
0.15.0 is out. No visual changes, but now all PE and TE executables will automatically be rebased, so modification of Boot Firmware Volume can now be done correctly. This new feature isn't well tested for now on, so I personally don't recommend to touch BFV (volume with PEI core inside), unless you have programmer or backup chip. Windows binary is uploaded, OSX app bundle will be uploaded later.
This story about rebasing contents of boot volume will drive me to drink someday. Some BIOSes for Intel-based platforms have Application Processors Entry Point stored in Volume Top File (first byte of that address is located 32 bytes above end of BIOS dump), that normally points inside PEI Core, so if PEI Core was moved, this EP must also be patched for modified BIOS to work. MMTool does it, so must UT. But it's hard to distinguish which VTF must be patched, and which is not, so right now I'm trying to make an algorithm for that. New version of the tool will be ready soon, and hopefully, will produce less corrupt files. But right now, please don't touch volume(s) where PEI Core is located, unless you really know what you are doing.
0.16.0 is out. Changes: - image rebuild code is rewritten, it needs further testing, but it become more reliable and like 50% easier to understand - settings are stored in system-specific location instead of INI-file (Registry in Windows, .plist in OSX and so on) - volume subtype "Boot" added to indicate Boot Firmware Volumes. Any changes in that volume will cause rebase of all following PE32 and TE images. - "Rebase" action added to indicate that executable image will be rebased during image rebuild. This action can't be set from UI, use "Rebuild" instead, if needed. - if PEI Core module base address was changed, UEFITool attempts to patch Volume Top File to replace old PEI Core entry point address stored there to newly calculated one. Without this patch it would be impossible for SEC phase code to transfer control to PEI Core, that makes modified BIOS unbootable (hang up with 0x0B debug code). If that attempt was unsuccessful, the "VTF not patched" message will be shown. Please send me all BIOS images, that cause that message. Boot volumes modification really needs further testing. It works normally on my AMI Aptio-based BIOS from Zotac Z77-ITX, but Phoenix, Insyde and Apple UEFIs are still completely untested, so try that kind of modification on your own risk, and only if you have programmer or spare BIOS chip.
Quick bugfixes are quick. 0.16.1 is out, important bugfix release, please update ASAP. Reason: New rebuild code had a stupid bug in section rebuild phases, so some of files modified with "Replace body..." can become invalid. It's corrected now. Changes: - corrected bug described above. - opening Search dialog automatically sets focus to edit box. OSX binary will be uploaded a bit later.
Another important bugfix release, 0.16.3. Changes: - padding symbol is now always 0x00 for sections, as described in UEFI PI specs - eliminated some dead code - volume base address is now calculated properly for non-boot volumes - PEI files will be rebased in all affected volumes This version is tested on Zotac Z77-ITX'es AMI Aptio4 UEFI and produces bootable image after modification of every volume type. UPD: tested by LS_29 (aka Sonix, author of UEFI BIOS Updater) on ASUS Z87-Plus' AMI AptioV UEFI, BIOS works normally after near all kinds of mods.
0.16.5 is out Yet another bugfix release in 0.16.x branch, 0.16.5. New reconstruction code appears to be buggier then I planned. Changes: - solved a bug in file reconstruction, raw files with volumes inside can be reconstructed now - solved a bug in UEFI 2.0 capsule reconstruction, header can't be lost now Windows binary uploaded, OSX will be built tomorrow.
on -.165 build im trying to edit my lenovo s230u bios, ive found where the current pci ven ids are for my current wifi card, i extract that module to a .sct file and edit it with hex edit and try to replace it with the current one in that bios image, it does not save or rebuild the image, am i doing something wrong? i just want to get a new wifi card working on the bios, so far this is the closest ive come to identifying even what section of the code in the bios where my current wifi card info is. or is there another way please help.
0.17.0 is out. Changes are small but there are many of them: - solved a bud in working with tailed files (OMG, six times already) - new volume subtype - Unknown, files can't be inserted into them now - sections can be inserted into encapsulation sections now - regions (except Descriptor) can be replaced as is - region access table and BIOS access rights are show in Descriptor region info - Rebuild action removed form all item where it did nothing - font changed to Consolas 9pt - Windows compiler changed to MSVC2013, please check Windows XP compatibility Please test new version and report. Thank you in advance.
mukhya, can you upload your BIOS image and more info about the patch you are trying to apply? I will try to reproduce the failure you've encountered.
@CodeRush Can I replace the original DSDT with a longer one in AmiBoardInfo module with UEFITool? (Is UEFITool able to fix the offset?) I was able to replace it with my own DSDT only if the module's length is same as the original one with PhoenixTool. And btw, 0.17.0 does fix the parseSection errors. Many thanks! But there is still an error: View attachment 26677