Discussion in 'MDL Projects and Applications' started by CodeRush, Oct 8, 2013.
You need to login to view this posts content.
You need to login to view this posts content.
New release with some new features but still no FIT support: UEFITool 0.19.6, UEFIExtract 0.3.5, UEFIPatch 0.2.5.
- added support for firmware volumes with CRC32 stored in ZeroVector (Apple UEFI feature)
- ZeroVector included to volume information
- added new volume types AppleCRC, AppleCRC Boot and AppleCRC Unknown
- added support for HP postcode sections
- size information split into header size and body size
- decimal sizes are added, shown in braces after hexadecimal sizes
- corrected small bug with Extract Body action being enabled for items with empty body
I have a silly question...
If I want to replace roms with MMTool and replace EFI modules with UEFITool for an UEFI Bios. Which one would you recommend me to do first,
replacing with MMTool or UEFITool?
Either way is fine.
It makes sense now. Since UEFITool now shows the ZeroVector, I analysed a few files. Many of them - independent of OEM, AMD/Intel, Aptio/Insyde - have this in the ZeroVector of the first boot volume.
But what about finding this in pad files or volume free space? Is it an error or a fail-safe mechanism? Could it be something like this: if the parsing failed and you reach this point (which normally wouldn't happen), then jump to recovery? Either way, it's still a lousy excuse to use them in such places.
@lordkag, thank you for the report, apreciated.
FFS_ATTRIB_TAIL_PRESENT should be set only in "old" pre-PI11 volumes (the ones that use EFI_FIRMWARE_FILE_SYSTEM_GUID ). FFS_ATTRIB_LARGE_FILE should be set only in FFSv3 volumes.
It's interesting that FFS_ATTRIB_LARGE_FILE was added, then removed, then added again.
Will be renamed in the next version, thanks.
Actually, there was no public FFSv1 volumes, as far as I know, and the file system format (except for tails) was common for both volume revisions, so I just name it FFSv2, but you are right after all - it's pretty much the same, but still different formats, so I will change FFSvX to RevX, it will show more information that way.
Both will be *.sct in the next version, thanks.
Already solved in my development branch, will be in the next version.
ZeroVector is reserved for CPU that use 00000000h as their start address (i.e. some types of ARMs), so you can add a trampoline there without messing up with volume header. On Intel-based machines it's considered "free space covered by volume header checksum", so vendors are free to use it as they want. The current spec says nothing about it's contents or anything, it's just not a part of FV volume parsing, that's all.
The "impossible" one. Actually, real FIT is very easy to be found (it's physical address is stored at FFFFFFC0h, i.e. 40h back from the end of the last VTF), as well as all other things linked by it, but the real problem is that all that linked things are now either fixed in position (and by fixed I mean really, relative to the last VTF, not the velume start or image start or anything like this, which is hard as sh*t to implement using current recursive reconstruct* routines), or their addresses must be stored and recalculated after modifications, so FIT can be regenerated (which is easier but raises some questions like "what if there is no place for FIT left" and so on). That is why I know about the problem for so long and yet did almost nothing with it - it's just that hard and required a complete redesing and rewrite of the whole image reconstruction part.
Will do something about it soon.
Literal constants in C are 32-bit by default (if no suffix is used), so 1, 0x01, 0x0001, 0x00000001 are the same.
It can be either Types (which is GCC-specific, AFAIR), or Types, or nothing. I've chose nothing because Intel defined it that way. Just Types will not work because of unknown size.
This thing is obscure and isn't used by anyone, so errors in such dark corners are not only tolerable, but expected. Guys who write the spec aren't gods or kings, they are just men, and they have their right to make an error or two. I doubt we can find the volume that uses this structure.
I haven't forgot them, I can't include them into the structure because they are GUID-specific, so the section with another GUID will have different structure. Thank you for pointing me to the correct definition, I will rename it properly and add required parsing in the next version.
Thank you for your reports once again, LK. We can make the utility better together.