Post a link and I will look. Dynamic won't work with new ASUS. Most of the image is digitally signed. Normally a new module mod will work but sometimes you have to direct the tool to put them in (normally) the second firmware volume. DMI has to be done with an image of YOUR dumped BIOS not a downloaded one. A
To reflect the amount of changes under the hood. Although outwardly not much has changed there were 3 code paths for dealing with module manipulation (one to replace/delete, one to insert and one to resize) and all 3 were actually out of sync. Now there is just one. There were 3 code paths for scanning/dumping modules, now just 1! A
Don't use the RW report - rarely needed for EFI Also adding a SLP string will change modules that are digitally signed. I think you can flash EFIs that fail digital signature thru the USB flashback system on some ASUS boards as this doesn't check signatures It isn't really a bug - when a RW report is loaded the tool will look again and try and select a better method to mod - and dynamic is always (up until EFI anyway) considered least invasive. RW reports are really only relevant for some Phoenix and Dell mods. Tito/Serg008/Others - can anyone think of any EFI situations where you have to have a RW report - because I can't - but you guys know my tool better than I do!! If we can't think of any then I will disable RW report for EFI. Thanks, A
Thanks! That fixed it. I'm not a stupid person but when it comes to BIOS modification I'm very a much a "Get the tool and follow the instructions" sort of guy with only a basic understanding of what all the bits do. If the field was available I assumed I had to put something in there. With something like this I always RTFM before I start but looking at it again you do mention that RW files are required for "ANY Phoenix or Insyde mod and SOME Dell" so obviously I need to RTFM better! In the past I have only used the AMI tool (without problems). Is it the case that the SLP should always be left blank for a Phoenix BIOS or should it be left blank just for the 'New Module' method? Thanks to andyp and Serg008 for your help (and the tool!)
For newer Asus EFIs, its better to leave the SLP tab to avoid the security verification. Besides, its basically useless to install XP on these newer mobos (& thus SLP string is useless).
There is better solution for capsule header removal, because the header structure is known: Code: // UEFI 2.0 capsule header typedef struct { EFI_GUID CapsuleGuid; UINT32 HeaderSize; UINT32 Flags; UINT32 CapsuleImageSize; } EFI_CAPSULE_HEADER; // AMI Aptio extended capsule header typedef struct { EFI_CAPSULE_HEADER CapsuleHeader; UINT16 RomImageOffset;// offset in bytes from the beginning of the capsule header to the start of capsule volume UINT16 RomLayoutOffset;// offset to the table of the module descriptors in the capsule's volume that is included in the signature calculation FW_CERTIFICATE FWCert; //ROM_AREA RomAreaMap[1]; } APTIO_CAPSULE_HEADER; Header removal must be an option, I think, because it's required for any board if modified BIOS will be flashed by hardware SPI-programmer, but not required for anything, except Asrock, if it will be flashed by normal flashing tools.
Thanks. I think you know this stuff better than I do! Do you have any experience with crypto functions - I would like to emulate the digital signing check of ASUS EFIs (as done in UEFICAPSULE.EXE) but I don't know exactly how to do it. A
Is it possible to integrate the idea of using the signing key to sign Aptio EFIs with modded modules (no SLIC)??
I don't think so. I don't think its an RSA private key. But I know very little about crypto so could be wrong A