longsoft / uefitool Goto Github PK
View Code? Open in Web Editor NEWUEFI firmware image viewer and editor
License: BSD 2-Clause "Simplified" License
UEFI firmware image viewer and editor
License: BSD 2-Clause "Simplified" License
Hi,
I noticed the too shy post and wanted to express this, so this issue is more of a question. Last time I tried to use UEFITool it was not obvious how to extract the video card blob. If you have not already, could a option be implemented that makes this task much more straight forward?
Thanks,
Edward.
You have deleted fitParser.h and fitParser.cpp in 59a6f2 commit.
But you did not edit UEFIDump/uefidump.h. UEFIDump/uefidump.h includes fitParser.h.
I tryed to comment this line, but it was unable to build. Please fix.
This tool and applications like it are, in my opinion, vital gateways to user-owned and hack-friendly firmware. It can do no one any good, however, if it is undocumented. I would like to assist in this effort if you'll allow it, but I'll first need to understand how it works.
A simple README with build instructions is the first step, I think. I will draw one up, and possibly a POSIX shell build script if you will guide me.
Seriously, thank you for putting in the effort to create this tool.
( An example of just how wordy I can get: http://www.coreboot.org/pipermail/coreboot/2013-October/076442.html )
Hi,
Is there a way to run this without the UI and just via command-line ? I want to embed this tool into a custom Linux distro that will have no X-server and no mouse inputs either.
It would be great if you could do this or at least inform me on how to go about it and I can give you a pull request for it.
Or can I just use the FFSEngine class to do all the work without the UEFITool class ?
--Thanks.
It would be nice if you could load a file with GUIDs and descriptions (or maybe this would be compiled in) and the UI would display the description along with the GUID.
Here's a script that will scrape GUIDs from .dec files, from e.g. TianoCore EDK2:
https://github.com/jethrogb/uefireverse/blob/master/guiddb/dec2c.rb
PE32 images, in uefi, can contain multiple sections. The sections of a PE32 image follow the EFI_IMAGE_SECTION_HEADER, and are contained immediately after the optional PE32 header.
UEFI drivers compiled with the "UEFI_HII_RESOURCE_SECTION = TRUE" will create a .rsrc section that containsii the Hii String, IFR packages, etc.
Being able to extract, and replace the .rsrc subsection would allow modification of setup string, etc.
You can't get away from me, human! One robot order coming up:
UPD: moved all TODOs to the top, new_engine only:
First of all this project is amazing!
Would it be possible to add a dependency graph option ?
I think on something to let easier to understand what modules are dependent to each other.
It's not possible to open multiple bios files at the same time, at least in the OS X version.
It would be great to have an option to open a new window for working on another bios file.
Usually this is very useful for comparing changes and so on.
fG!
I am trying to create PKGBUILD for Arch Linux, but I cannot do this, until I solve problem of compiling.
UefiTool itself is not a problem, compiling normally.
But UefiExtract fails to compile:
qmake-qt5 uefiextract.pro
make
g++ -Wl,-O1 -Wl,-O1,--sort-common,--as-needed,-z,relro -o UEFIExtract uefiextract_main.o ffsdumper.o types.o descriptor.o ffs.o ffsparser.o peimage.o treeitem.o treemodel.o utility.o LzmaDecompress.o LzmaDec.o EfiTianoDecompress.o moc_treemodel.o -lQt5Core -lpthread ffsparser.o: In function
FfsParser::parseNvarStore(QByteArray const&, QModelIndex const&)':
ffsparser.cpp:(.text+0xfd4a): undefined reference to nvarAttributesToQString(unsigned char)' ffsparser.o: In function
FfsParser::parseVssStoreBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1c559): undefined reference to efiTimeToQString(EFI_TIME_ const&)' ffsparser.o: In function
FfsParser::parseFlashMapBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1f133): undefined reference to flashMapGuidToQString(EFI_GUID_ const&)' collect2: error: ld returned 1 exit status Makefile:340: recipe for target 'UEFIExtract' failed make: *** [UEFIExtract] Error 1
Also for UefiFind
qmake-qt5 uefifind.pro
make
g++ -Wl,-O1 -Wl,-O1,--sort-common,--as-needed,-z,relro -o UEFIFind uefifind_main.o uefifind.o types.o descriptor.o ffs.o ffsparser.o peimage.o treeitem.o treemodel.o utility.o LzmaDecompress.o LzmaDec.o EfiTianoDecompress.o moc_treemodel.o -lQt5Core -lpthread ffsparser.o: In function
FfsParser::parseNvarStore(QByteArray const&, QModelIndex const&)':
ffsparser.cpp:(.text+0xfd4a): undefined reference to nvarAttributesToQString(unsigned char)' ffsparser.o: In function
FfsParser::parseVssStoreBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1c559): undefined reference to efiTimeToQString(EFI_TIME_ const&)' ffsparser.o: In function
FfsParser::parseFlashMapBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1f133): undefined reference to flashMapGuidToQString(EFI_GUID_ const&)' collect2: error: ld returned 1 exit status Makefile:340: recipe for target 'UEFIFind' failed make: *** [UEFIFind] Error 1
The corresponding line numberrs are:
Also, where did UefiPatch disappeared from new_engine branch?
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!
Most files have a BSD LICENSE header, but there is no explicit LICENSE.md file of the BSD license.
With qt ver.4.8.5 name conflict with `struct _XRegion* Region ' occurs.
I quick-fixed addind namespace: https://github.com/6vasia/UEFITool/commit/73bbcda5002cbe88c8e1c94de904ff684da2a736
The latest pecoff v8.3 specification from microsoft:
https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx
AARCH64 (ARM64) images are already running UEFI firmware
In the EDKII build tools, there are some references to PPC: (file BaseTools\Source\Python\CommonDataClass.py)
EBC | IA32 | X64 | IPF | ARM | PPC | AARCH64
It would be nice to be able to generate a report about the current BIOS and save the report to a text or comma separated value file. This would be useful when trying to compare two versions of a BIOS when trying to determine the individual FFS files, ME regions, etc, that have changed between the two versions.
It's an issue indeed, but no one can do something about it.
I've began UEFItool's development about 10 months ago, and there are still only very few issues reported.
Hey, users, am I achieved perfection with this peace of poor C/C++ mix or you are just too shy to report anything? 😄
Please go ahead, I know there are many flaws here, but I keep forgetting about them and issue tracker will help me remember.
I would like to point out that identifiers like "_FLASH_DESCRIPTOR_HEADER
" and "__UEFITOOL_H__
" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?
To remind myself about small things that keep being forgotten I'm opening this issue. It will not be closed until all this small problems are resolved:
Hi,
I've noticed that the info.txt files that get dumped to disk by UEFIExtract don't have a trailing new-line for the last line of the file. This creates all sorts of interesting issues for Linux tools and python which all expect POSIX compliance for all lines in a file.
I'd like to help you remedy this by sending a patch to new_engine. I'm opening this issue to discuss what your preferred option of fixing this is. From what I see there are three ways to fix this problems and I list them below. Obviously each option has its advantages and disadvantages. Options 3 seems the easiest and most future proof as it doesn't require you to change how you code but it feels like a hack :)
Anyway, please let me know which option you prefer (or if you have another option I didn't list) and I'll send a pull request to you!
Cheers,
Parth
Go through ffsengine.cp and make sure that every occurrence of info += tr
or info = tr
that appears just before a call to model->addItem
has a \n
as the final character of the text.
An example of doing this would include changing the current line 240 to have the extra \n
added:
QString info = tr("Full size: %1h (%2)\n")
This is tedious but the real downside is if you append new info later then you have to remember to make sure the \n
stays in the correct place.
Go through ffsengine.cp and add info += tr("\n")
just the line before every model->addItem
call.
An example would be adding a new line at line 243 that will state:
info += tr("\n")
This feels like repetitive coding.
Modify in only the one central place by changing the addItem function in treemodel.cpp so that the first code at line 275 reads:
info += tr("\n")
As you can see the shell gets wrapped wrongly:
pparth@doctor:~/bios.bin.dump/4 FFF12B8D-7696-4C8B-A985-2747075B4F50/2 Free space$ cat info.txt
Type: Free space
Subtype:
Offset: 5D1000h
Full size: 1F000h (126976)
Compressed: No
Fixed: Yes
Memory address: FFDD1000hpparth@doctor:~/bios.bin.dump/-2747075B4F50/2 Free space$
Looking at some Lenovo UEFI BIOS (downloaded from Lenovo's website) I get the following:
parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50
parseVolume: unknown file system 00504624-8A59-4EEB-BD0F-6B36E96128E0
Digging into these I have found credible references for both of these:
FFF12B8D-7696-4C8B-A985-2747075B4F50 is "EFI_SYSTEM_NV_DATA_FV_GUID" according to edk: https://github.com/tianocore/edk/blob/master/Foundation/Guid/SystemNvDataGuid/SystemNvDataGuid.h#L26
00504624-8A59-4EEB-BD0F-6B36E96128E0 is "ADDITIONAL_NV_STORE_GUID" according to chipsec: https://github.com/chipsec/chipsec/blob/master/source/tool/chipsec/hal/uefi_platform.py#L512
Both of these seem to be used for storing NV ram settings.
Please include these GUID translations in the next update =)
Plutomaniac sent me an image that showed some errors in Extractor. Upon inspection, I noticed it was because of a little bug in UEFITool engine. To test it, just take any Intel SPI image and add something after BIOS region with hex editing. This is what you will get:
I believe they are all due to the same error, the offset of the padding is wrong.
A readme and/or instructions on how to actually compile would be nice...
Take this Intel file.
Hi,
UEFIExtract will not use the GUID for firmware volumes for OS X EFI images. It instead uses "AppleCRC32 AppleFSO" text field that shows ip on UEFITool.
Instead of this code in FfsEngine::recursiveDump
QString childPath = QString("%1/%2 %3").arg(path).arg(i).arg(model->text(childIndex).isEmpty() ? model->name(childIndex) : model->text(childIndex));
it probably should be
QString childPath = QString("%1/%2 %3").arg(path).arg(i).arg(model->name(childIndex));
Personally I find it more useful to have the GUID as folder name instead of that text.
Best,
fG!
I seem to not be getting any interface referenced in the usage guide. A command prompt window comes up and disappears.
When trying to 'Insert after…' legacyvga to the end of my BIOS, I get a crash as below. I've emailed you the images separately.
Process: UEFITool [12490]
Path: /Network/*/UEFITool.app/Contents/MacOS/UEFITool
Identifier: com.CodeRush.UEFITool
Version: ???
Code Type: X86-64 (Native)
Parent Process: launchd [267]
Responsible: UEFITool [12490]
User ID: 1025
Date/Time: 2014-11-21 23:58:35.915 +0800
OS Version: Mac OS X 10.9.5 (13F34)
Report Version: 11
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000020314d9d7
VM Regions Near 0x20314d9d7:
CG shared images 00000001c871f000-00000001c8727000 [ 32K] r--/r-- SM=SHM
-->
MALLOC_NANO 0000600000000000-0000600000400000 [ 4096K] rw-/rwx SM=COW
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.CodeRush.UEFITool 0x00000001000379e6 Decode + 102
1 com.CodeRush.UEFITool 0x00000001000378d5 Decompress + 229
2 com.CodeRush.UEFITool 0x0000000100037a44 EfiDecompress + 20
3 com.CodeRush.UEFITool 0x0000000100021459 FfsEngine::decompress(QByteArray const&, unsigned char, QByteArray&, unsigned char_) + 233
4 com.CodeRush.UEFITool 0x00000001000224a8 FfsEngine::compress(QByteArray const&, unsigned char, QByteArray&) + 440
5 com.CodeRush.UEFITool 0x0000000100027101 FfsEngine::reconstructSection(QModelIndex const&, unsigned int, QByteArray&) + 881
6 com.CodeRush.UEFITool 0x00000001000268cc FfsEngine::reconstructFile(QModelIndex const&, unsigned char, unsigned char, unsigned int, QByteArray&) + 1180
7 com.CodeRush.UEFITool 0x0000000100025ad2 FfsEngine::reconstructVolume(QModelIndex const&, QByteArray&) + 2642
8 com.CodeRush.UEFITool 0x0000000100024f10 FfsEngine::reconstruct(QModelIndex const&, QByteArray&) + 480
9 com.CodeRush.UEFITool 0x00000001000245a7 FfsEngine::reconstructRegion(QModelIndex const&, QByteArray&) + 391
10 com.CodeRush.UEFITool 0x00000001000238da FfsEngine::reconstructIntelImage(QModelIndex const&, QByteArray&) + 714
11 com.CodeRush.UEFITool 0x0000000100024e71 FfsEngine::reconstruct(QModelIndex const&, QByteArray&) + 321
12 com.CodeRush.UEFITool 0x0000000100027bc2 FfsEngine::reconstructImageFile(QByteArray&) + 82
13 com.CodeRush.UEFITool 0x0000000100007fa7 UEFITool::saveImageFile() + 167
14 QtCore 0x0000000100d8cb6f QMetaObject::activate(QObject_, int, int, void**) + 1871
15 QtWidgets 0x00000001000a11d4 QAction::activate(QAction::ActionEvent) + 260
16 QtWidgets 0x00000001000a165f 0x10007c000 + 153183
17 QtCore 0x0000000100d8cb6f QMetaObject::activate(QObject*, int, int, void**) + 1871
18 libqcocoa.dylib 0x0000000104e9638f 0x104e73000 + 144271
19 com.apple.AppKit 0x00007fff8c5b2260 -[NSApplication sendAction:to:from:] + 327
20 com.apple.AppKit 0x00007fff8c5cd1c8 -[NSMenuItem corePerformAction] + 394
21 com.apple.AppKit 0x00007fff8c5ccf04 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 117
22 com.apple.AppKit 0x00007fff8c61c40d -[NSMenu internalPerformActionForItemAtIndex:] + 35
23 com.apple.AppKit 0x00007fff8c61c289 -[NSCarbonMenuImpl carbonCommandProcessEvent:handlerCallRef:] + 104
24 com.apple.AppKit 0x00007fff8c5c2ff6 NSSLMMenuEventHandler + 716
25 com.apple.HIToolbox 0x00007fff929d21d4 DispatchEventToHandlers(EventTargetRec, OpaqueEventRef, HandlerCallRec) + 892
26 com.apple.HIToolbox 0x00007fff929d1787 SendEventToEventTargetInternal(OpaqueEventRef_, OpaqueEventTargetRef_, HandlerCallRec_) + 385
27 com.apple.HIToolbox 0x00007fff929e5880 SendEventToEventTarget + 40
28 com.apple.HIToolbox 0x00007fff92a1b640 SendHICommandEvent(unsigned int, HICommand const_, unsigned int, unsigned int, unsigned char, void const_, OpaqueEventTargetRef_, OpaqueEventTargetRef_, OpaqueEventRef**) + 420
29 com.apple.HIToolbox 0x00007fff92a4e228 SendMenuCommandWithContextAndModifiers + 59
30 com.apple.HIToolbox 0x00007fff92a4e1d0 SendMenuItemSelectedEvent + 178
31 com.apple.HIToolbox 0x00007fff92a4e0af FinishMenuSelection(SelectionData_, MenuResult_, MenuResult_) + 94
32 com.apple.HIToolbox 0x00007fff92a56085 MenuSelectCore(MenuData_, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 718
33 com.apple.HIToolbox 0x00007fff92a55cb1 _HandleMenuSelection2 + 446
34 com.apple.AppKit 0x00007fff8c53562c _NSHandleCarbonMenuEvent + 284
35 com.apple.AppKit 0x00007fff8c39452e _DPSNextEvent + 2170
36 com.apple.AppKit 0x00007fff8c39389b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
37 com.apple.AppKit 0x00007fff8c38799c -[NSApplication run] + 553
38 libqcocoa.dylib 0x0000000104e925e4 0x104e73000 + 128484
39 QtCore 0x0000000100d559ad QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 381
40 QtCore 0x0000000100d58ee7 QCoreApplication::exec() + 359
41 com.CodeRush.UEFITool 0x000000010000338e main + 302
42 com.CodeRush.UEFITool 0x0000000100003254 start + 52
Hi,
I try to replace a modified PE32 image, but i only have Extract body option selectable. Replace body is gray in menu. I use 0.30.0_alpha21 of tool. The same on Mac and Windows...
Can help ?
Hi
I am trying to patch my Asus Rampage V Extreme 3301 bios
I am using Broadwell E patch.txt
Uefipatch outputs this:
parseImageFile: Aptio capsule signature may become invalid after image modifications parseSection: section with unknown type 52h parseFile: non-empty pad-file contents will be destroyed after volume modifications parseSection: section with unknown type 52h parseFile: non-empty pad-file contents will be destroyed after volume modifications patch: replaced 6 bytes at offset F69h 0FBA6C24400F -> 0FBA7424400F Image patched
Is It correct?
Hi attach original bios and patched one
Thank you
Asus RVE.zip
Hi,
I ran:
./UEFIPatch X99-E-ASUS-0601.CAP
And got this output:
parseImageFile: Aptio capsule signature may become invalid after image modifications
parseSection: section with unknown type 52h
parseFile: non-empty pad-file contents will be destroyed after volume modifications
parseSection: section with unknown type 52h
parseFile: non-empty pad-file contents will be destroyed after volume modifications
No patches can be applied to input file
Can this be fixed?
It would be nice to have a rudimentary Makefile.
What a better way to start the new year, than with a bug report? Get back to work, lazy human, bring me the ultimate tool for slashing UEFI!
I was just testing whether I could modify a BIOS binary with UEFITool and write it back to the machine with an SPI programmer. I just randomly picked a PEIM, PchSpiPeim out of this HP BIOS. I right clicked the PE32 within it and did "Extract Body" and saved out the PE32 file. Then I opened it in CFF explorer, went to the end of the .text section, and changed some padding 0s to 0x90s. Then I went back into the file, right clicked on the PE and said "replace body" and selected the modified PE with nops at the end. But when I do this, UEFITool starts displaying 2 PE sections under that GUID. I can see it's set to rebuild the file, but when I save it out and open it again, there are still two PE sections under the same PEIM file GUID. Am I doing something incorrect? Despite the extra file, the BIOS is still bootable. It's just that I don't know if I made a meaningful change if it would actually be using the proper file.
The HP BIOS I'm modding is available here:
https://drive.google.com/file/d/0B-fqKYB_fAF-aFQ0TW1BN2pweTA/view?usp=sharing
(While I'm submitting I should also say that when I try to replace a DXE file within the compressed volume, it seems to do the replacement correctly, but the resulting BIOS is un-bootable once written back to the HP. I just don't know how I could help debug this for you... But if you have any thoughts feel free to email me at my username at gmail and we can guess and test things.)
see: https://pmbs.links2linux.de/package/show/Extra/UEFITool
g++ -c -pipe -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o ffsengine.o ffsengine.cpp
ffsengine.cpp: In member function 'UINT8 FfsEngine::parseVolume(const QByteArray&, QModelIndex&, const QModelIndex&, UINT8)':
ffsengine.cpp:849:19: error: 'ParsingDataTypes' is not a class or namespace
pdata->Type = ParsingDataTypes::VolumeParsingData;
^
ffsengine.cpp:955:23: error: 'ParsingDataTypes' is not a class or namespace
pdata->Type = ParsingDataTypes::FileParsingData;
^
ffsengine.cpp: In member function 'UINT8 FfsEngine::reconstructVolume(const QModelIndex&, QByteArray&)':
ffsengine.cpp:3076:28: error: 'ParsingDataTypes' is not a class or namespace
if (pdata->Type == ParsingDataTypes::VolumeParsingData && pdata->Data.Volume.HasZeroVectorCRC) {
^
Makefile:351: recipe for target 'ffsengine.o' failed
Sometimes I just need to quickly check something in a file or an NVAR, and having to dump it to disk is a bit bothersome. Would be nice if a small window with hex dump was shown for it.
i have issu in bios lenovo t460 win i make chang in module laptop npt work
i have teste all version uefitool
i have ather lenovo t450 i can mak modification withwot problem uefitool work gret
i think problem in compression of module
thinks for your help
if you want bios dump for t460 i can send it and for t450 if you want compar bitwin
sory for my english
No more candies for you, mister!
The report itself is here, I'm opening the issue to remember fix all the stuff I've promised.
Master branch:
New_engine branch:
Hi!
I've just compiled UEFITool and tried to open Lenovo G505s bios file with no luck. An error message "parseBios: One of volumes inside overlaps the end of data" occurred.
What's the reason? Could you help me?
Link to BIOS file
Would you like to replace more defines for constant values by enumerations to stress their relationships?
I see you have closed my issues. They were so young and beautiful, will be endlessly missed. Now I'm going to open others, as a revenge. Take that, human!
Hi,
I really like how the UEFITool UI in new_engine displays the FIT table but this information seems to get lost when I run UEFIExtract on the same flash image. Can you please look at exposing this within the structure so it will get extracted out to disk with UEFIExtract?
I've attached a screenshot here. As you can see in this example, the FIT table physical address show that it's within the Padding area. When I extract this out, I just get body.bin and info.txt for the Padding area volume and the details of the FIT table aren't exported out in any manner.
Cheers,
Parth
I can just use Extract facility,any else si black and can't use. what the problem
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.