search

LongSoft / UEFITool

UEFI firmware image viewer and editor
BSD 2-Clause "Simplified" License
4.33k stars 626 forks source link

Fix required for modifying Apple EFI dumps #29

Closed gdbinit closed 9 years ago

gdbinit commented 9 years ago

Modifying Apple's EFI dumps will brick the target Macs. The crc32 and crc16 are all ok and the modification (replacement or reinjection is also ok).

I found out that the issue is related to the last 4 bytes of the ZeroVector. As you know the first 4 of the last 8 bytes are the crc32 value of the firmware volume contents. The question is what are the last 4 bytes, since they appear to be meaningful. They are the number of bytes occupied by all the files in each firmware volume. So they are the difference between the FVLength reported by the EFI volume header and the free space (beware of padding?). So if the volume is modified and the free space changes, those bytes at the ZeroVector must be updated with the new value, and then the header crc16 fixed for this.

This way the firmware can be reflashed without bricking the machine. The value is not used on the boot volume (still too early for those kind of checks?) but definitely on PEI/DXE phases. I didn't reverse where it is implemented since I noticed its meaning before diving into reversing it.

Thanks for the awesome work with UEFITool :-)

fG!

NikolajSchlej commented 9 years ago

Thank you very much, I've also wondered what purpose has that value, but had no real hardware to test on. Recalculation will be implemented ASAP for both current and new_engine versions.

NikolajSchlej commented 9 years ago

I hope it's solved in 0.20.6, but I don't know for sure because I still don't have any Apple hardware to test on.

NikolajSchlej commented 9 years ago

@gdbinit, is this solved enough to be closed?

gdbinit commented 9 years ago

It is indeed solved. Sorry for late confirmation :-)