PE Dump / PEDUMP / PE Viewer utility

[440bx]

Thank you! Will test that when I'm back home.

You're welcome.  Hopefully, it will be useful to you.

By the way: in case you're interested and bored here is an archive containing Alpha, MIPS and PowerPC binaries.

Thank you. If I ever get involved with one of those architectures, those files will come in handy. 

[440bx]

Don't download this version, download the UPDATE (November 2022) below which corrects a few bugs and adds capabilities not present in the version attached to this post.



UPDATE (May 2020)

Attached to this post is version 1.10 of PeBytesF, a PEDUMP/PE Viewer type of utility.

Version 1.10 (the version attached to this post) adds handling the undocumented UWOP_EPILOG unwind code found in the exceptions directory.

It also allows for a rare case created by Borland compilers (and possibly others), where a directory of size zero (0) actually exists, i.e, is present, in a section of the PE file. 

this version does not dump ARM32 and/or ARM64 PE files, it only processes PE files for the Intel/AMD architectures.  The version that handles ARM32 & ARM64 PE files is attached to the post https://forum.lazarus.freepascal.org/index.php/topic,46617.msg354933.html#msg354933

NOTE:

The ARM32 and ARM64 version recognize the presence of an exceptions directory but, unlike v1.00 and v1.10 (both for Intel/AMD), they only display directory information, not any details about the entries contained in it.  For this reason, the handling of UWOP_EPILOG does not apply to them, since the directory is not dumped/output.

[440bx]

UPDATE (July 2022)

NOTE: download the November 2022 update (v1.30) below instead of this one.

Attached to this post is version 1.20 of PeBytesF, a PEDUMP/PE Viewer type of utility.

This version corrects a few bugs and adds a few capabilities.


corrected bugs

1. sometimes the program would encounter an invalid value and internally report that it encountered an error which caused the program to terminate early but, no indication that an error was encountered was reported.  IOW, the program reported that it had terminated normally instead of abnormally.

2. the program failed to account for the fact that some LOAD CONFIG tables _may_ include an additional byte of flags. This caused the program to encounter invalid Rvas because it included the flags byte as part of the rva.  This caused the program to end prematurely (but no indication that a problem was found was reported upon termination - see above bug) the output of multiple tables were affected by this bug.

3. the routine used to output the value of function pointers found in the LOAD CONFIG directory failed to account for the program's bitness.  It always considered the pointer to be a 64bit pointer which caused an obviously incorrect 64bit pointer to be output for a 32bit PE file.

4. the program failed to account for the fact that section numbers in the COFF symbol table are 1 based. This caused an invalid pointer to the used as a section name when the COFF section was 0 (IMAGE_SYM_UNDEFINED.) The program's output routines detected the bad pointer and caused a blank line to be output.


enhancements

1. added the necessary functions to output tables that were added after Win7 in the LOAD CONFIG directory.

2. added code to detect _some_ errors in a PE file (malformed PE files) and emit a warning when they are found. 

3. changed the formatting of some of the tables (strictly aesthetics)

4. the program has been tested with 32bit and 64bit PE files from Win XP, Win 7 SP1, Win 10 21H2 and the initial release of Win 11.


limitations

Version 2 Image dynamic relocations that may be found in the LOAD_CONFIG_DIRECTORY are not output because no AMD32/64 PE file that uses version 2 could be found.  if the program encounters a file that uses the version 2 format, it emits a warning and skips the table.


other

Most programs are dumped in fractions of a second, however, some programs, notably 64bit programs can take as long as a little over a minute to dump.  This is because, some 64bit programs include hundreds of thousands of entries in the exceptions directory _and_ some of the tables in the LOAD_CONFIG directory can also be very large (several tens of thousands of entries.)  Formatting and outputting all those entries takes time.

Other programs that take more than just a few seconds to dump are those that include a large number of DWARF symbols, e.g, Lazarus.exe and gdb.exe among large programs with a large number of debugging symbols.



this version does not dump ARM32 and/or ARM64 PE files, it only processes PE files for the Intel/AMD architectures.  The version that handles ARM32 & ARM64 PE files is attached to the post https://forum.lazarus.freepascal.org/index.php/topic,46617.msg354933.html#msg354933

Please note that the bugs in the ARM32/64 version have NOT been corrected.  This is because, I don't have an extensive test suite for ARM CPUs to ensure the corrections work properly on that platform.

[440bx]

UPDATE (November 2022)

Attached to this post is version 1.30 of PeBytesF, a PEDUMP/PE Viewer type of utility.

This version corrects a few bugs and adds a few capabilities.


corrected bugs

1. the formula used to calculate the number of filler bytes between the IMAGE HEADER and the first section made a number of assumptions that are not always true, this occasionally resulted in an incorrect number of filler bytes being calculated and dumped.

2. the program failed to account for the fact that the sequence of the fields "Process Heap Flags" and "Process Affinity Mask" in the LOAD_CONFIG structure is different depending on the bitness of the module.  The program always used the 64bit sequence causing the values and field offsets of those two fields to be incorrect for 32bit modules.

3. if the resource type id did not identify a known type, then the resource type name was shown as empty in square brackets ([]). Since the name in that case is an empty string, the square brackets are superfluous and no longer appear. (cosmetic bug)

4. on rare occasions, in the "EXPORTS DIRECTORY ASSEMBLED" (EDA), the last angle bracket was not properly aligned with the previous line's last angle bracket. (cosmetic bug)

5. some PE files, mostly and possibly exclusively APISCHEMA files, declare a relocations block with zero relocations which caused a relocations header to be output without any relocations showing underneath it.  Now, in that case, the relocations header is no longer output.  (cosmetic and misleading bug)


enhancements

1. an EXPORT ALIASES LIST (EAL) now appears immediately after the EDA showing how many exports are aliased and the names by which each is aliased.

2. if the PE file has null exports (export entries that contain a null/0 rva) then a line under the EDA header shows the NET number of exports vs the declared number of exports.

3. if the IAT is bound (is a list of addresses instead of rvas to hint-names), the target import name is now shown between brackets after the import address.

4. added a record counter field to some tables that can occasionally have a fairly large number of elements.

5. the record counters now always appear after the file offset (instead of after the field width.)

6. added a list of informational messages that highlight some "features" present in the PE file.  They are:
    a.  there is at least one (1) invalid rva in the module
    b.  some resources may be embedded executables
    c.  exports data
    d.  one or more exported functions are forwarded to other dlls
    e.  some exported functions are aliased
    f.  module re-uses/multiplexes some areas for different purposes
    g.  contains null exports (exports whose rva is zero)
    h.  imports functions by ordinal
    i.  exports some functions by ordinal only
    j.  module has malformed bound imports
    k.  module has at least one malformed debug descriptor
    l.  module has one or more zero-sized directories
    m. module has one or more writable code sections

    Note that most messages are about "characteristics" found in the PE file, not about problems in the PE structure.

    Each message is prefixed by the word "INFORMATION" to denote that it is just that and not part of the PE file and they always appear at the END of the output.

7. the virtual address (VA), file offset (FO) and section name are now shown for every relocation.

8. a number of spacing changes that are functionally insignificant but (hopefully) make the output easier to read.


limitations

  same as previous version


other

  same as previous version

[AlexTP]

>of PeBytesF, a PEDUMP/PE Viewer type of utility.

Web search cannot find the homepage of PeBytesF. Is it real app?

[KodeZwerg]

It surprises me that so few people are interested in understanding the internal format of their programs.

I am really a fan of PE file format, just by now I see this thread.
I had no time yet to read all and compare to my product what is based on windows sdk headers etc... it also dig deep into.
Feel free to checkout https://github.com/KodeZwerg/Advanced-Properties, just dont look at GUI, that project was never meant to be released to public 
(Build with Delphi, usage of 32 and 64 bit sdk header definitions for read-in basics)
Usage is myapp.exe "c:\path\and\filename.exe" or over menu inside app.

[440bx]

>of PeBytesF, a PEDUMP/PE Viewer type of utility.

Web search cannot find the homepage of PeBytesF. Is it real app?

There is no homepage for PeBytesF.  This is its "homepage".

Feel free to checkout https://github.com/KodeZwerg/Advanced-Properties, just Usage is myapp.exe "c:\path\and\filename.exe" or over menu inside app.

I just tried it.  Used "AdvProp.exe AdvProp.exe" and got a message box stating that there was an error due to a "missing privilege".  Did I miss something ?


The reason I wrote this utility is because, with the exception of CFF Explorer, no PE dump/view utilities out there provide enough information about the PE file to enable a user to edit it using a hex editor.  PeBytesF is the only PE viewer that tells the user, for every byte it shows, its virtual address (if loaded at its preferred load address), its file offset and the size of the field (1, 2, 4, 8, n bytes) thereby allowing its user to locate the field in a hex editor and modify it.

It's also the only PE dump/view that shows the PE data in both, "raw" and "cooked" forms.  Not even CFF Explorer does that.

ETA:

Also, considering how complete it is, at about 260 kilobytes it is one of the smallest and also one of the fastest.  Not to mention that it provides very readable output, something that cannot be said about all PE dump/view utilities.

[KodeZwerg]

Feel free to checkout https://github.com/KodeZwerg/Advanced-Properties, just Usage is myapp.exe "c:\path\and\filename.exe" or over menu inside app.

I just tried it.  Used "AdvProp.exe AdvProp.exe" and got a message box stating that there was an error due to a "missing privilege".  Did I miss something ?

Not really, a working OS is all that this app needs to work.
Calling it like you did or calling without any parameter would end in the same, app would use itself as a test subject :-)

[440bx]

Not really, a working OS is all that this app needs to work.
Calling it like you did or calling without any parameter would end in the same, app would use itself as a test subject :-)

I don't get what you showed.  Attached is what I get:

[KodeZwerg]

Not really, a working OS is all that this app needs to work.
Calling it like you did or calling without any parameter would end in the same, app would use itself as a test subject :-)

I don't get what you showed.  Attached is what I get:

Excuse me for bringing up my app into this thread.
May I ask what OS you running? (I think Windows 8.1 is the lowest supported when I quick check references)
Yes my app tries to set for itself OS privileges to access deeper insights but ofc not everywhere in my app so I simplified by running that code right at startup but could improve
Sorry for that behavior, just tested on my own windows 10 system to run smooth and fast :-)

[440bx]

Excuse me for bringing up my app into this thread.

That's fine.

May I ask what OS you running? (I think Windows 8.1 is the lowest supported when I quick check references)

Windows 7 64bit SP1 (as stated in the signature)  Your "Help" box states that your program works with Windows Vista and above (it doesn't look like that's the case.)

Yes my app tries to set for itself OS privileges to access deeper insights but ofc not everywhere in my app so I simplified by running that code right at startup but could improve

No special privileges of any kind are necessary to analyze a PE file.  Access to it is, of course, required.

Sorry for that behavior, just tested on my own windows 10 system to run smooth and fast :-)

Your program doesn't start from a network drive.  That should not be a problem (at least not for a general utility.)  After some trial and error I managed to make it work on Windows 10 21H2.

I suggest you re-test on Windows 7, 8, 8.1 and various versions of Windows 10 because it looks like your program depends on features found in newer versions of Windows (which is not justified to just get information about a PE file.)