[UEFITool] UEFI firmware image viewer and editor

During the debugging of strange behavior of using UEFITool with Gigabyte BIOSes, I have found either a bug or a special non-standard region map configuration in all recent Gigabyte BIOS images.
If you don't familiar with structure of Intel descriptor region, here is an annotated HxD-screenshot of affected part:
View attachment 25376
Black - empty vector
Grey - flash descriptor signature
Red - upper bytes of BIOS region base
Orange - upper bytes of BIOS region limit
Yellow - upper bytes of ME region base
Green - upper bytes of ME region limit
Blue - upper bytes of GbE region base
Dark-blue - upper bytes of GbE region limit
So, this region map says to us (and to chipset logic too, if flashed to SPI chip as is) that:
1. GbE region starts at offset 0x1000 and ends at 0x3000 (0x02 + 1) * 0x1000, which is correct.
2. ME region starts at offset 0x3000 and ends at 0x200000 (0x1FF + 1)* 0x1000, which is correct.
3. BIOS region starts at offset 0x0000 and ends at 0x800000 (0x7FF + 1)* 0x1000, which is obviously incorrect!
BIOS regions should start at any offset between 0x200000 (end of ME region) and 0x250000 (begin of first firmware volume in image file) and end at the end of image file at offset 0x800000.
So, the right values for BIOS base and BIOS limit should be 0x0200 and 0x07FF respectively. This setup will have no unallocated space in SPI chip and no intersections between flash regions.
The current setup is dangerous by security means (Descriptor, GbE and ME regions are accessible, because they are parts of BIOS region now), it breaks Intel specifications, breaks normal use of FITC utility and simply damn wrong!
That's why some GB files are having debug-message about intersections in version 0.7.0. I have sent report to Stasio using TweakTown Forum PM, and hope it will be corrected soon.

 

I must admit that I was a bit wrong with calculations (my memory needs external storage ), and correct formula to calculate region offset is (base * 0x1000), and regions size (limit + 1 - base) *0x1000, but it doesn't make that bug any better.
If you have BIOS region base as 0x0000 and limit as 0x07FF, it makes BIOS region last from 0x00000000 to 0x00800000, which is the whole 8 Mb chip. On 16Mb Z87 BIOSes it's the same.
So, in simple words, the bug is: BIOS region has size of whole chip.

 

osmoTR, I don't have 64bit Qt on my Linux VM to test 64bit builds, but I think I can do something about it later. 64bit build is not a priority for me now, I will work on it once other important things be implemented. Actually, only basetypes.h must be altered for 64bit builds, I hope.
Why don't I release Linux version? I don't sure it will work on any particular Linux with such variety of environments there. Compile-it-yourself is also a sort of release.

 

You need to login to view this posts content.

 

Still crashes.
Will do something about that right now, I was ready for it.

 

You need to login to view this posts content.

 

XpamAmAdEuS, you are trying to add file in compressed volume inside another volume, which has enough size to fit almost anything. MMTool and PhoenixTool can't grow such volumes, but UEFITool can do it since version 0.7.0, AFAIR.
Do not bother repacking your CoreDxe module, just add your files to volume as is and see if UEFITool can create output file.
Insert compressed will be implemented a bit later.
Edit: have tried that and there will be no place in root volume, if all Ozmosis files are inserted without compressing CORE_DXE first. Will implement "Insert compressed" and "Compress" operations for files ASAP.

 

FredWst, my Maverick insalled in VM becomes unusable after some update (finder keeps crashing after trying to open any folder, safari crashes on every page, etc.), that is why I stopped building OSX versions now. Will try to fix my OSX during this weekend.
Have you done macdeployqt after compilation? If not, the app will require Qt Framework installed.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Edit: link added to first post, thank you.

 

XpamAmAdEuS, I tried tinkering with that BIOS you wrote about, and it has too little space to fit all that Ozmosis related modules, no mater how many files you compress in it. The whole DXE volume is located inside LZMA-compressed section, as you can see yourself buy opening that BIOS file with UEFITool. That is why compressing files in that volume makes not more, but even less free space after recompression.
The only way to do modification there is to shrink boot volume (last one, 0x100000 in size) to 0x80000 manually, move previous volume for 0x20000 below and grow main volume for that free 0x20000. No tools can do in now, AFAIK, so you have to use hex editor and be extremely careful to not mess things up.

 

krack38, don't know what to think. Have you tried using PhoenixTool on that modified file? UEFITool can't make any changes to root volumes, except recalculation of header checksum, that could be done wrong. Will try and report.