Hi CodeRush, finaly i understand howto put ozmosis stuffs using your uefi tool, but, it seems i dont have enough space, your tools say me root volume cant be grown
I had a strange behavior, i dont know why i cant insert ozmosis stuffs into bios even i have enough space, this is my method. download quo bios, extract coredxe with mmtool, open with mmtool my bios z87nwifi.f5 ( last version from gigabyte ) delete original coredxe save bios. Open bios with uefi tool and add coredxe form ozmosis bios, ok, save rom, reopen, try to insert ozmosis only and uefi tool say me cant grown bios volume, but if make a report with mmtool i have enough space. +-----------------------------------------------------------------------------+ | Firmware Volume : 02 Location : 00000000 Length : EB6000 | +---+---------------+------------------------------------+--------+------+----+ |NO | FileName | GUID |Location| Size |Type| +---+---------------+------------------------------------+--------+------+----+ +---+---------------+------------------------------------+--------+------+----+ | Bytes Free : 17C1C6 (1520 KB) Bytes Used : D39E3A (13543 KB) | +-----------------------------------------------------------------------------+ As you can see, i have enough space
Thanks CodeRush, using previus version i gain enough space to put ozmosis stuffs in. One question, using your tools i can see many guid without no name, it seems to be not needed, can be safely deleted? or, can be possibile know theyr scope or functions? Many thanks
No, they are needed and BIOS will not work after that deletion. To know their functions, you either need to have BIOS sources, or just reverse-engineer that files, which is hard, but possible. There are some leaked AMI sources in Internet, you can google it and study for more info about modules and GUIDs.
Hi, i dont know if it happens to others, but it seems that search function doesent works for me in the last version When i try to do a search, nothing happen even if looking for an existing guid
It's because x86 has little-endian byte order and GUID that begins with AABBCCDD is actually storred as 0xDD 0xCC 0xBB 0xAA in image file. If you wish to search for hex pattern and find GUID - reverse first 4 bytes of it and search for them.
Thanks for the guide, but I think the extraction must be done as separate piece of software. That BIOS file is not "encapsulated" (I prefer to leave this term to CAP-files with flash image inside), but packaged into InsydeFlash installer. Will write an unpacker when I have some free time.
Made a bit of research based on your guide, the structure is rather simple: Code: typedef struct _IFLASH_BIOSIMG_HEADER { UINT8 Signature[16]; //$_IFLASH_BIOSIMG UINT32 FullSize; UINT32 UsedSize; } IFLASH_BIOSIMG_HEADER; In your case, FullSize == UsedSize == 0x400000. --- UPD: attached executable, C source and CMake makefile. Usage: extractor INFILE OUTFILE INFILE must be InsydeFlash executable, OUTFILE will be created (or rewritten, if already exists). View attachment 27434
Wow supersonic time ! I would ask if It will work on .exe file too as IFLASH_BIOSIMG is decompressed and decrypted form ? I have found that not Always It start at the same offset address and len can be variable ( It depends on FW and Eeprom) going from 4.096 kb Acer to 4.096 (Lenovo) 6.144 kb (Dell) to 8.192 (Acer) etc. I can do a list to do a schematic list for size len offset address start and end ? Let me know ! regards Ok I tried on .exe file and error as Signature is outside the boundaries, indeed on bios normal works well ! I tried on all files I got and It works very well, nice job !!! regards
There is no need to have lengths\offsets\etc. database, because image length is stored right after "$_IFLASH_BIOSIMG" signature, which can easily be found. I have used the archive you linked in PhoenixTool topic for testing.
CodeRush, never mind. I debugged your code and you have all appropriate checks in place. It is this Asus BIOS only which have special construct in one of it's files. So everything is perfect.
0.17.6 is out. Changes: - corrected a possible crash on some rare files compressed with EFI11 algorithm (thanks Serg008 for report). - corrected extended volume header handling