@lordkag, thank you once again for your reports, much appreciated. RAW files are parsed as BIOS space (i.e. like any input file), and the FV gets detected, but it's size is clearly wrong and can't fit in this RAW section. Yes, UEFITool can be more descriptive there, no one just asked for it, because such files are rerely moddable. Will do something about it later. This file is used by some old ASUS BIOSes as NVRAM defaults backup, and no code really checks the size of NVRAM volume there, so it can be incorrect without any impact. Padding is shown because the volume inside begins after some other bytes. It's nothing to worry about until you aren't trying to modify this file using UEFITool, but it's again a rare case. It's OK to have anything inside RAW file, because of it's raw nature. It's fully OK to have such things. The strategy right now is to obtain the lowest of this 2 possible values and use this obtained value as real volume size. Sometimes it's the wrong way, but mostly OK. NVRAM and other non-FFS volumes are very often having such problems, but the message is not shown properly now, which is a bug and will be corrected in one of next versions. *DONE* Yep, crashes the 0.19.0 after opening the file. I don't want to implement any support for such kind of files because they aren't UEFI images at all, nor can they be flashed into SPI chip, and if I will support this type of file, I will have to support all other types like Dell HDR and EXE, HP installers, etc. The utility is meant to open actual SPI chip dumps, not some vendor-generated crap, so my answer here is no. If anyone will develop and maintain patches for foreign files support - I'll be glad to include it. Yep, it's malformed and incompatible with any EFI specifications. Just a Lenovo bug. Version sections is only for information, so no need to do anything. Can't reproduce both on files with LZMA GUIDed section inside and without it on both ASUS and GB X99 BIOSes. Please provide more info on this. ASUS can not into specification once again. This file has Freeform type instead of RAW, and Freeform means there are well-formed sections inside. If not - it's a bug of ASUS guys, not mine. Both of them are non-FFS volumes, nothing to do there. Unknown volume subtype means not "GUID is unknown to developer" but "parsing method is unknown to him". On cosmetics: 1. Will think about making some tree items look different, it won't be hard, but it's a new thing I never thought about. Will look at it later. 2. Sizes will be shown as "Header size: %1, Body size: %2" if the item has both of them to make things less confusing. 3. Hex numbers will be printed uppercase. *DONE* 4. Empty(0x00) and Empty(0xFF) will be returned. *DONE* 5. Spaces will be no problem for hex pattern search. *DONE*
Well, I got off easy this time, so I might drop some other reports. Jokes aside, it is kind of awkward to see so little reports for UEFITool. On the other hand, even I, while having some interest in this area, have read so little about EFI, that there is no surprise in the lack of good reports - you can't really report problems about something you don't know how it should work. While I understand your explanation and agree about the size error, it is a little weird to have the raw section parsed, have error messages displayed about the parsing, but not the actual content displayed - like the FV inside. Especially that file where the padding gets displayed but not the FV. Is it your option to not display the content of that raw section, to prevent any tampering? You are right, I forgot about other vendors "solution" to pack the BIOS. In this case, Toshiba goes even further, because they are misleading with that extension. At least they should have packed it as .exe and leave the clean BIOS inside the package. Take that Asus Deluxe X99 BIOS posted. I meant that when trying to extract a ffs file (like CapsuleX64 for instance), all other sections are 4 bytes aligned, but Version section remains unaligned. Is it supposed to be left untouched? I tried inserting such file (without LZMA compression) in an Aptio 4 Bios and extracting it using MMTool. It was extracted aligned at every section. Thank you for the cosmetic patches. Now lets wait for another user to ask for them to be reversed. Or maybe I have just awaken the appetite for bells and whistles, be prepared for someone to ask you for themes and font support. On a serious note, some of the visual patches are actually helpful, like the one where you know exactly your position in tree.
The whole thing about parsed-but-not-showed contents pisses me off too, but the main reason for this is that all reconstruct* routines are using tree items and only them for reconstructing BIOS image, that is why I'll better not add something malformed into the tree. I will try to implement more convenient way to parse RAW file, so if there are something wrong, no subitems will be shown. Good thing is: if you don't touch it - it won't be modified at all. I think you have some wrong assumptions about section alignment, and MMTool proves them to be correct because of a bug in it. Specs says that all sections must be aligned to 4 bytes boundary, with 0 byte beginning right after FFS file header. Alignment bytes must be 0x00 according to the spec (MMTool uses 0xFD, AFAIR, but it's not the bug I'm talking about). There are also alignment requirements for FFS files, they must be aligned to 8 bytes boundary by default, and default alignment byte for FFS files depends on volume's erase polarity (i.e. 0xFF in like 99,99% cases and 0x00 otherwise). MMTool includes FFS alignment bytes as part of an extracted file for some reason, so all MMTool-extracted files have 8xSomething in size, with 0 to 7 empty bytes at the end. UEFITool does the extraction according to FFS file header, and if it's size is not 8xSomething, no additional bytes will be included. That CapsuleX64.ffs is 0x2F6E bytes long, with a UI section of 0x0E bytes, and UEFITool extracts it exactly like this. MMTool includes 2 additional empty bytes of FFS alignment, which have nothing to do with a file itself and are part of firmware volume. N-bytes alignment is not "make the size of this chunk NxSomething", but "start this chunk at NxSomething offset". More to say, if a section is really misaligned, parser code can't find it, because section header is too generic to be found by pattern matching. About positions in tree: right now I'm just using scrollTo(item), so I have no control over it. Please explain further (some drawing will be nice, because if it comes to UI stuff, I'm becoming pretty dumb), how it should work and why. Once again, much appreciated. I do know there aren't many users of this tool, so any report is useful, and detailed reports are very useful. Keep up the good work.
It seems I trusted too much in MMTool. It had crossed my mind right after I posted the last message that the alignment happens before the section, not in its size. Anyway, I have tested further and it seems MMTool is cheating, just like I do in Extractor, and adds the alignment after the section, so the last section has 4 * n bytes. And thank for clearing 0x00 vs 0xFD thing, which I thought about asking. Here is the first case: View attachment 32070 Notice that the focus is in Messages tab, I have double-clicked one of the messages and it has scrolled in the tree to that section. It is helpful to have the parent GUID in bold, to know where you are standing. If somehow every GUID in that area is expanded from previous searches, it will get very confusing and you need to always visually check the parent. Here is case two as of now: View attachment 32071 Let's say I have clicked a few messages, than I want to click a previous message, in reverse order. This takes me to that section, but the parent GUID is hidden. For me, it should be something like this: View attachment 32072 Third case, open to discussion: Let's say the focus is in the tree/structure, something like in the image above. The item selected in messages tab is barely visible. Maybe add a bold tag for the double-clicked message, like this? View attachment 32073 It goes without mentioning that this has low priority and shouldn't be done before other work, but it is something for usability.
Marking items in QTreeView and QListView bold or italic or different color is no problem at all, but right now it will break the abstractions I have, because the most straightforward way is to add "marked" property to the tree item itself, and then manage it according to selections, but the problem is that this "mark" is in fact not a property of the item (which is a part of Model side), but of the selection (which is a part of View side), so making it work will glue Model and View together for good, which breaks the MVC abstraction completely. What I can do right now to ease the pain is to change default scrollTo() behavior so the selected element will be placed right at the center of the viewport, so it became much easier to track it without marking anything. I've just pushed the change into the master repo, but it's too small change for a new release, I think. Let me know if you need a binary for testing or just build it yourself.
Will try not to be spoiled. UEFITool has no FIT support right now, but I will add it ASAP because of images like this. Any modification of that volume will brick the machine right now. This is, however, a big mistake of Asrock BIOS team, because Intel clearly says that FIT must be either in non-UEFI data regions (aka Paddings) or inside a RAW file in non-PEI volume (FIT can be changed after microcode update, that is why is must be outside any data regions protected by hardware-based validation technologies). Thank you for report, will try to include preliminary FIT support in the next version.
The reason is libpng, that is not present on your system, but it's very strange because I'm using static Qt build without png support. It appers, that OSX 10.10 is a bad system to use as a development platform, so I will switch back to 10.8, where all things were working properly. Thank you for reports and sorry for inconvenience.
GeryMix, why do you need a patch on this board? Is 0xE2 MSR locked there? I haven't found any sings of it, PowerMgmtDxe driver has no locking code. Some vendors are shipping already unlocked images. so no patches are needed. I think this is one of them.
Relesed UEFITool 0.19.4, UEFIPatch 0.2.4 and UEFIExtract 0.3.3. Changes: - new icon for UEFITool, big thanks Alexander Zhidkov - solved a rare crash during EFI1.1/Tiano decompression