Hi.

I noticed the code fail to build on Hurd and kFreeBSD, and one of the hurdles is the way PATH_MAX is defined in the code.

POSIX specify to include <limits.h> to find PATH_MAX, and it seem to be no need for the complicated section in config.c to find it. I suggest to rewrite it like this:

diff --git a/src/config.c b/src/config.c
index 6021151..ec6713c 100644
--- a/src/config.c
+++ b/src/config.c
@@ -38,13 +38,9 @@
 #include "utils.h"
 #include <stdlib.h>
 #include <string.h>
-#if defined(__linux__)
-#include <linux/limits.h>
-#elif defined(__NetBSD__)
-#include <limits.h>
-#elif defined(__APPLE__)
+#if defined(__APPLE__)
 #include <sys/syslimits.h>
-#elif defined(__CYGWIN__)
+#else
 #include <limits.h>
 #endif
 

I do not know what kind of platform __APPLE__ refer to, but the other platforms mentioned (Linux, NetBSD, Cygwin) are POSIX compabile and can use limits.h. It also seem to be the only sensible fallback if no special casing is needed.

Topic:

cd lib/libpe && make all
make[1]: Entering directory '/home//build/pev/lib/libpe'
cc -shared -Wl,-soname,libpe.so.1  -o libpe.so /home//build/pev/lib/libpe/build/./error.o /home/jlay/build/pev/lib/libpe/build/./pe.o
make[1]: Leaving directory '/home//build/pev/lib/libpe'
cd src && make all
make[1]: Entering directory '/home//build/pev/src'
cc -c -o build/./pehash.o pehash.c -I/home//build/pev/lib/libpe -I"../include" -W -Wall -Wextra -std=c99 -pedantic -D_GNU_SOURCE -D_FORTIFY_SOURCE=1 -DSHAREDIR="\"/usr/local/share/pev"\"
pehash.c: In function ‘calc_hash’:
pehash.c:218:13: error: storage size of ‘md_ctx’ isn’t known
  EVP_MD_CTX md_ctx;
             ^~~~~~
pehash.c:224:2: warning: implicit declaration of function ‘EVP_MD_CTX_cleanup’ [-Wimplicit-function-declaration]
  EVP_MD_CTX_cleanup(&md_ctx);
  ^~~~~~~~~~~~~~~~~~
pehash.c:218:13: warning: unused variable ‘md_ctx’ [-Wunused-variable]
  EVP_MD_CTX md_ctx;
             ^~~~~~
make[1]: *** [build/./pehash.o] Error 1
Makefile:142: recipe for target 'build/./pehash.o' failed
make[1]: Leaving directory '/home//build/pev/src'
make: *** [all] Error 2
Makefile:9: recipe for target 'all' failed

Debian version is stretch/sid with gcc version

gcc (Debian 6.2.1-5) 6.2.1 20161124

Thank you.

The variable buff_index is incremented without checking the length of buff.

https://github.com/merces/pev/blob/master/src/pestr.c#L202

#define LINE_BUFFER 32768
...
    unsigned char buff[LINE_BUFFER];
...
        if (isprint(byte)) {
            ascii++;
            buff[buff_index++] = byte;
            pe_raw_offset++;
            continue;
        } else if (ascii == 1 && byte == '\0') {
            utf++;
            buff[buff_index++] = byte;

The following is a reproduction on Mac OS X Mavericks (10.9.1):

$ ./src/pestr --net samples/windows-live-messenger.exe 
o.AM
W.NP
regex compilation failed

Thank you @loganbr for the report.

I checked a just compiled x265 v1.7+298 EXE and DLL built with GCC 4.8.2 or 4.9.2 with different PE analyzers for whether they export functions.

In contrast to PE Scanner and Dependency Walker, which report all exported functions with unique names, the list of exported functions reported by readpe contains the same name for all exported functions.

Exported functions
0x2af000:                        x265_api_get_63
0x1c:                            x265_api_get_63
0x36cd36ad:                      x265_api_get_63
0x36e336d8:                      x265_api_get_63
0x36f936ee:                      x265_api_get_63
0x370f3704:                      x265_api_get_63
0x3f66:                          x265_api_get_63
0x2b0000:                        x265_api_get_63
0x1c:                            x265_api_get_63
0x310a30ff:                      x265_api_get_63
0x31203115:                      x265_api_get_63
0x3136312b:                      x265_api_get_63
0x314c3141:                      x265_api_get_63
0x31b3:                          x265_api_get_63
0x2b2000:                        x265_api_get_63
0x26c:                           x265_api_get_63
0x344733a6:                      x265_api_get_63
0x3454344e:                      x265_api_get_63
0x3462345b:                      x265_api_get_63
0x34703469:                      x265_api_get_63
0x347e3477:                      x265_api_get_63
0x348c3485:                      x265_api_get_63
0x349d3493:                      x265_api_get_63

A link to this x265 build will be published in the doom9 and videohelp forums if you need the binaries to check.

I'd love to get the OS X support into a real version; any chance of tagging a new version so we can package this in Homebrew?

Thanks!

Ref: Homebrew/legacy-homebrew#13263

plugins: could not open directory '����' -- No such file or directory

os: osx 10.9.3 mavericks

I have noticed that some checks for return codes are missing in your source files.

Would you like to add more error handling for return values from functions like the following?

• printf ⇒ to_text
• fseek ⇒ pe_get_resource_directory

When trying to print the output of PESCAN and PESEC does not genarate some valid XML tag some are like: <.text>, <DEP /NX> and < Stack Cookies (EXPERIMENTAL) >.

Running readpe with the same binary for the master & mmap versions gives different outputs.

./src/readpe -A samples/windows-live-messenger.exe

pev@master:

Size of .data section: 0x1100000
Size of .bss section: 0x1087a

pev@mmap:

Size of .data section: 0x61100000
Size of .bss section: 0x101a0

This is most definitely a bug. Or isn't it?

Hi,

I am a student currently working on my anti-malware project. I cam across this pev toolkit. I love this tool totally. I got the results of what I am looking for. But, I would like to integrate this toolkit with my project.

Is there any chance that I can integrate it. Please let me know ASAP! You can email me directly to my email id: [email protected]

Appreciated in advance..:)
Thanks!

@marcelomf is working on that.

Hello,
I just found your code and it's really great! Any chance you could release the libpe component under LGPL license? I would love to use it within the LibVMI project to replace our own home-baked version of parsing PEs.

Thanks,
Tamas

Currently peres.c provides information about Characteristics, Timestamp Major/Minor version we should also support language and sublanguage features.

Apparently peres assumes that memory from malloc() is zero-initialized.
It crashes on some files when this assumption is violated:

$ printf 'MZ%058d\200\0\0\0%064dPE\0\0%03d\0%016d\v\1%090d\20\0\0\0%016d\0%d\0\0%0160d\0%d\0\0%04d\0\f\0\0%02648d' > crash.exe
$ export MALLOC_PERTURB_=165
$ peres -i crash.exe 
Segmentation fault

Backtrace:

#0  freeNodes (currentNode=0x5a5a5a5a) at peres.c:271
#1  0x80001886 in discoveryNodesPeres (ctx=<optimized out>) at peres.c:731
#2  0x800022ae in main (argc=3, argv=0xbffff654) at peres.c:769

Tested with git master (e9f7c2d).

Found using American Fuzzy Lop.

• Update current documentation at http://pev.sourceforge.net/html-doc/
• Add compatibility option with pev v0.60 output in documentation.
• Move 'tutorial' to a different place, update it and translate it to PT-BR also.

A one-off compile and run is rather painful currently:
either you need to install, or you need to rename libpe.so to libpe.so.1 and set LD_LIBRARY_PATH.
For quick one-off usage a way to compile and use a static libpe would be much more convenient.

Hi, since you're linking to OpenSSL from a GPL-licensed program, you should add a licensing exception because the OpenSSL license and GPL license are incompatible (see https://people.gnome.org/~markmc/openssl-and-the-gpl.html for details). This assumes all the copyright holders are in agreement of course.

This is preventing Debian from packaging anything newer than version 0.50...

Thanks!

In documentation is referenced version 0.71, but in sourceforge and github find only version 0.70.

Links for reference
http://sourceforge.net/projects/pev/files/
http://pev.sourceforge.net/doc/manual/en_us/ch01s02.html
http://pev.sourceforge.net/doc/manual/en_us/

Likely GPLv2.

$ echo 'H4sIAAAAAAACA/ONMiAbBDAwMGCIuYLFMMS5mQzoBhiwuAsmBwCA6xwr8AAAAA==' | base64 -d | gzip -d > hashcrash.exe
$ pehash -a hashcrash.exe
file
    filepath:                        hashcrash.exe
    md5:                             3d378c038f5281ae0c3f0339ae7bdadf
    sha1:                            31b9e48301db117435c1622cdd7c3ef5ff9a8320
    sha256:                          02d7de7e610a5c8cf6b936d1085d6ba3840b796c7203d9c98ca432600a1649bf
    ssdeep:                          3:2VdVtlelIdV1:ye+/
headers
    header
        header_name:                     IMAGE_DOS_HEADER
        md5:                             da3e91f67626d80649b86c39e8812252
        sha1:                            9d5fcad36f61b006c3f4200324988d7a00d15370
        sha256:                          17327dcf970a729e204fbfe35b501d7042d72b239781d4a2f2384743403f5f8a
        ssdeep:                          3:2VdVtln:yn
    header
        header_name:                     IMAGE_COFF_HEADER
        md5:                             b71115576544b6dbaf1225e6fd916419
        sha1:                            71ffd44c14e5dbac7c17584a68908f6b07dc55ac
        sha256:                          32256f276794b7e1442be90f4ebe4af57e3f5e98157f7e0e279a340221dce0fa
        ssdeep:                          3:n:n
    header
        header_name:                     IMAGE_OPTIONAL_HEADER
        md5:                             e2769e60c82d1a787c7688cbf1ea108f
        sha1:                            3434532052d2f05b059c5745e22db3f44e4a470b
        sha256:                          d00f681801cd5ea674944bd60a139d1f7a3499c54e9e2bb40c95573fe42257f8
        ssdeep:                          3:IdVV:of
sections
    section
        section_name:                    000000000000000000000000
Segmentation fault

(Unhelpful) GDB backtrace:

#0  md5_block_asm_data_order () at md5-586.s:27
#1  0x08073ff8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Tested on i686, against git master (ccef80d).

Found using american fuzzy lop.

Hi. The pev source do not compile when using OpenSSL 1.1. This is the first build failure:

pehash.c: In function 'calc_hash':
pehash.c:218:13: error: storage size of 'md_ctx' isn't known
  EVP_MD_CTX md_ctx;
             ^~~~~~
pehash.c:224:2: warning: implicit declaration of function 'EVP_MD_CTX_cleanup' [-Wimplicit-function-declaration]
  EVP_MD_CTX_cleanup(&md_ctx);
  ^~~~~~~~~~~~~~~~~~
pehash.c:218:13: warning: unused variable 'md_ctx' [-Wunused-variable]
  EVP_MD_CTX md_ctx;
             ^~~~~~

Please port pev to the most resent OpenSSL version.

I've used the pev 0.40 tool to get file version information quite easily from a windows PE file with

$ pev -p jre-8u92-windows-i586.exe
8.0.920.14
$ pev -p jre-8u92-windows-x64.exe
8.0.920.14

With the most recent version of the toolkit, I can't figure out how simply get the File Version field from a PE file. The pev tool is gone, and there is nothing in the current documentation that says specifically how to do this.

in line 317 of readpe.c, a function pe_directory_name whose function definition is

const char *pe_directory_name(ImageDirectoryEntry entry);

is used. But in the line 317 when we have passed uint32_t values into pe_directory_name function, and the program ran happily.

Why did it work when we have passed uint32_t when ImageDirectoryEntry is actually expected.

1. Get the file resource_shuffled.exe from corkami, BinaryCorpus_v2.zip: https://code.google.com/p/corkami/downloads/detail?name=BinaryCorpus_v2.zip&can=2&q=
2. Execute:
   peres -i resource_shuffled.exe

The output is:
this file has no resources

The output should be something like:
address: 0x12f0, size: 0x229, language -> ID: 0, name -> ID: 101, type -> ID: RT_RCDATA
(extracted info with another tool)

Hello,

I just noticed that pescan prints out the section name as tag name in the XML.

$ pescan -fxml ~/idafree50.exe | grep '<\.'
<.idata>normal</.idata>
<.tls>suspicious name, zero length</.tls>
<.rdata>small length</.rdata>
<.reloc>zero length</.reloc>
<.rsrc>normal</.rsrc>

But, the XML standards states that the tag name cannot be started by dot character. [1]

[1] - http://www.w3.org/TR/REC-xml/#sec-starttags

• download: http://corkami.googlecode.com/svn/trunk/src/PE/bin/exports_order.exe
• execute: readpe exports_order.exe

readpe shows no exports for this file.

I expect to see this:

Ordinal      RVA         Name
0          0x00001020h    export
2          0x00001022h    zz
1          0x00001021h    export2

Note: The exports are not in alphabetical order.

pestr do not show all network-based strings of certain binaries. It can probably be an encoding problem.

print_basic_hash() declares the output buffer as:

char hash_value[EVP_MAX_MD_SIZE * 2 + 1];

With the current OpenSSL versions, EVP_MAX_MD_SIZE * 2 + 1 is 129.
However, fuzzy_hash_buf() requires an output buffer of size FUZZY_MAX_RESULT, which is 148.

pev.conf enhancements:

• Consider SHAREDIR when compiling the source file that contains pepack default database file path.
• Spaces in pev.conf entries should be ignored.

Hello,
Looking at the code of strisprint() function on pescan.c, I found a memcmp() usage that doesn't uses the trailing NULL byte in the comparison, which can lead to an unexpected behavior when checking against other strings started with ".tls". (e.g. .tlsfoobar)

pescan.c:244

    if (memcmp(string, ".tls", 4) == 0)
        return false;

If anyone add a custom ".tlsfoobar" section to the PE, it will be treated as the ".tls" section by pescan. I think maybe this is not the expected behavior. Or is it?

• download the file: http://corkami.googlecode.com/svn/trunk/src/PE/bin/imports_virtdesc.exe
• execute: readpe imports_virtdesc.exe

The output will show no imports.

The expected output is something like:

kernel32.dll
rva: 4224 (0x1080), name: ExitProcess, hint: 0
msvcrt.dll
rva: 4168 (0x1048), name: printf, hint: 0

Would be awesome if PEV tools were able to export to JSON format, since its a common format.
For example:

{
    "file entropy": "7.471861 (probably packed)",
    "fpu anti-disassembly": "no",
    "imagebase": "normal",
    "entrypoint": "fake",
    "DOS stub": "suspicious",
    "TLS directory": "found - 1 function(s)",
    "timestamp": "normal",
    "section count": "3",
    "sections": {
        "UPX0": "suspicious name, zero length, self-modifying",
        "UPX1": "suspicious name, self-modifying",
        ".rsrc": "normal"
    }
}

$ pescan nonexistent
ERROR [-15]: open() failed (°xˇ´ľuˇé�[ˇ�Woˇ)

Tested with git master (ccef80d).

Below are the steps taken and result:

1. Copied C:\Windows\system32\cmd.exe to C:\Windows\system32\malwaretest.exe
2. Ran pepack -d against cmd.exe in the path as dscribed above and it runs successfully detecting no packer.
3. Re-ran the same steps and syntax with malwaretest.exe and I get an error "ERROR [-14]: fdopen() failed (No such file or directory). The path and filename have been validated.

Note I am simply running this from windows command line (cmd.exe).

Please advise as to why I am seeing this issue.

Thank you.

1. Download: http://www.phreedom.org/research/tinype/tiny.168/tiny.exe
2. Execute: readpe tiny.exe

Output: After printing the optional header values, the parser breaks with the message
"unable to read the Directories entry from Optional header"
The section table is not shown, although it is there.

Note: the file is the 7th step of the tinype project. All of the files before work fine. It has low alignment, no msdos stub, a collapsed mz header, and no data directories. What causes readpe to ignore the section table is the empty data directory table.

And of course the plugin loader must know where the plugins are installed in order to load them correctly. As those plugins are not meant to be executed by the user directly, I believe we should install them to $(libexec)/pev, or ultimately to $(libdir)/pev.

Keeping in mind our Makefile conforms to the GNU Coding Standards, it allows all paths to be configured during compilation, thus we cannot simply hardcode a path for the plugins - our Makefile would have to pass this path via CPPFLAGS, I suppose.

pehash should calculate the hashes of all sections, headers and the whole file by default.

The support for TLS callbacks should be rewritten due to mmap changes.

I've tried pehash 0.60 on about 20,000 windows 32-bit executables, pehash gives me the hash of the entire file. I thought it would give me has hash of the PE headers instead.

Just tried to run readpe on idag.exe and a crash occurred:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000403589 in print_imports (ctx=0x7fffffffe360) at readpe.c:854
854         if (id->u1.OriginalFirstThunk == 0)
(gdb) p id
$1 = (IMAGE_IMPORT_DESCRIPTOR *) 0x488000
(gdb) p id->u1
Cannot access memory at address 0x488000
(gdb) p *ctx
$2 = {stream = 0x606010, path = 0x7ffff75a8000 "MZP", map_addr = 0x2a5e00, map_size = 140737346067968, map_end = 140737343291392, pe = {dos_hdr = 0x4550, 
    signature = 4149903876, coff_hdr = 0x7ffff75a8218, optional_hdr_ptr = 0x60010b, optional_hdr = {type = 0, length = 140737343291928, _32 = 0x0, 
      _64 = 0x8278000000100000}, num_directories = 32767, directories_ptr = 0x606040, directories = 0x8, num_sections = 33528, sections_ptr = 0x6060d0, 
    sections = 0x180c, entrypoint = 4194304, imagebase = 4209296}}
(gdb) p ofs
$3 = 1974784

When testing pesec on a random .exe file I had on my disk, I ran into a segfault. Here is the valgrind output from the crash.

==10656== Memcheck, a memory error detector
==10656== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10656== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==10656== Command: debian/pev/usr/bin/pesec /home/nobody/src/popcorn-desktop/Import/chromecast-win32/node.exe
==10656== 
ASLR:                            yes
DEP/NX:                          yes
SEH:                             yes
Stack cookies (EXPERIMENTAL):    yes
==10656== Invalid read of size 4
==10656==    at 0x403D43: output_open_scope (output.c:293)
==10656==    by 0x402112: parse_certificates (pesec.c:327)
==10656==    by 0x402112: main (pesec.c:476)
==10656==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==10656== 
==10656== 
==10656== Process terminating with default action of signal 11 (SIGSEGV)
==10656==  Access not within mapped region at address 0x8
==10656==    at 0x403D43: output_open_scope (output.c:293)
==10656==    by 0x402112: parse_certificates (pesec.c:327)
==10656==    by 0x402112: main (pesec.c:476)
==10656==  If you believe this happened as a result of a stack
==10656==  overflow in your program's main thread (unlikely but
==10656==  possible), you can try to increase the size of the
==10656==  main thread stack using the --main-stacksize= flag.
==10656==  The main thread stack size used in this run was 8388608.
==10656== 
==10656== HEAP SUMMARY:
==10656==     in use at exit: 9,066 bytes in 51 blocks
==10656==   total heap usage: 67 allocs, 16 frees, 47,047 bytes allocated
==10656== 
==10656== LEAK SUMMARY:
==10656==    definitely lost: 24 bytes in 1 blocks
==10656==    indirectly lost: 13 bytes in 1 blocks
==10656==      possibly lost: 0 bytes in 0 blocks
==10656==    still reachable: 9,029 bytes in 49 blocks
==10656==         suppressed: 0 bytes in 0 blocks
==10656== Rerun with --leak-check=full to see details of leaked memory
==10656== 
==10656== For counts of detected and suppressed errors, rerun with: -v
==10656== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

This is using version 0.80.

PESEC fails to export in XML the signers of certificate the output its incomplete like:
...
...
Valid
??

Hi! I'd like to be able to use peres or pev more generally to get version information out of EXEs and DLLs under UNIX environments, and pev looks almost ideal. However, the extracted resources don't appear to be valid files--and it's not clear that peres attempted to transform the compiled .RC at all.

As an example, extracting the PE32+ / x86-64 binary from SIV produces a lot of directory information, as expected, and a small resources/ tree with a number of .ICO and .CUR files. Various tools at my disposal, including ExifTool, ImageMagick, file(1), and so forth don't recognize any of these as valid cursor or icon bitmaps. file(1) identifies about half the .ICOs as dBase IV databases; dedicated image processing tools refuse to recognize the files at all.

The file I'm actually most interested in is resources/versions/1.rc, which I'm guessing is a compiled .RC generated from a resource script. (I'm not completely familiar with the process of compiling Windows executables.) There are some interesting strings in here--what I was looking for originally--and what I'm guessing might be some 8- and 16-bit bit fields indicating properties.

Catting the file gets me this:

�4VS_VERSION_INFO���?�StringFileInfo�000004B0>CompanyNameRay Hinchliffeh FileDescriptionSystem Information Viewer (x64),FileVersionV5.166
                                                                                                                                         InternalNameSIV64X.exel$LegalCopyrightCopyright� Ray Hinchliffe 2001-2017>
         OriginalFilenameSIV64X.exe(ProductNameSIV0ProductVersionV5.16:SIV AuthorRay HinchliffeHSIV [email protected] Imagehttp://rh-software.com/siv.gifr)SIV Updateshttp://rh-software.com/downloads/siv.zipP▒SIV Websitehttp://rh-software.com/DVarFileInfo$Translation�

...and strings -el gets me this:

VS_VERSION_INFO
StringFileInfo
000004B0
CompanyName
Ray Hinchliffe
FileDescription
System Information Viewer (x64)
FileVersion
V5.16
InternalName
SIV64X.exe
LegalCopyright
Copyright
 Ray Hinchliffe 2001-2017
OriginalFilename
SIV64X.exe
ProductName
ProductVersion
V5.16
SIV Author
Ray Hinchliffe
SIV Support
[email protected]
SIV Image
http://rh-software.com/siv.gif
SIV Updates
http://rh-software.com/downloads/siv.zip
SIV Website
http://rh-software.com/
VarFileInfo
Translation

This last output looks the most useful, but it's hard to be certain whether this is a simple key-value output in the format 'key\lvalue' with some missing fields at the beginning and end, or if some of the fields contain non-string data. At any rate, file(1) doesn't think that this is a text file of any kind at all until it's run through strings(1), so I assume it's not really a simple UCS-2 or UTF-16 text file.

Is peres normally supposed to translate this format? If not, would you mind adding this feature? It would be great to get the output formatted according to the -f flag, or, if that's not possible, perhaps a decompilation back to the original resource script format? I understand that it's generally a simple plaintext format. If it's not normally an ASCII or UTF-8 file, a final, optional step converting it to either ASCII or UTF-8 would be much appreciated.

Thanks!

• ChangeLog
• Full user manual
• README

Despite the (probably outdated) source installation guide, make zip fails, Makefile does not contain a target "zip".

Instead it contains a target "win"; but this fails too, at this file: /usr/bin/cyggcc_s-1.dll does not exist in current cygwin-win32 installations; instead, there is a cyggcc_s-seh-1.dll (which seems to serve now the same purpose).

I have come across a couple binaries that cause pehash and readpe to segfault. I uploaded an example of such a binary to malwr:

https://malwr.com/analysis/NmIwMDZkMTZlOTRkNDJkOTgzZDFhZTNhNTQ3ZWIxZjA/share/e09332fe54fc412ba2a995d3b9b9fd0d

(This is from the wild, so handle with care.)

On this sample, pehash gives me this output:

file
    filepath:                        bdb1ee7bdff9d6fff9f1bbc61c246e90206c37e28eae38bd391c6652e839aeeb.data
    md5:                             c122f3f4f4e08e854ab387900b80fb5c
    sha1:                            c4de77b015b9d515ba6024665ed2d5eb072f6b6f
    ssdeep:                          6144:oj98IJ+DlOxnmXmdcUHpiBENp1+xOKez6KO2m7wIVPitvezgxp:fIIDqm2dcIpiBENp8xpeeKOn8IV6Fqgf
headers
    header
        header_name:                     IMAGE_DOS_HEADER
        md5:                             391ea009064a4158eb6a7c8d6c49c886
        sha1:                            c3047ff45c7b4b6f290f157e200892f2c1177058
        ssdeep:                          3:WlWUqt/vll1:idqf
    header
        header_name:                     IMAGE_COFF_HEADER
        md5:                             7bbc50502f0564715b8b25afe445a1ec
        sha1:                            05199e13a4493b605fda16f63ef81ed616581b18
        ssdeep:                          3:VtlQQlH:+Qd
    header
        header_name:                     IMAGE_OPTIONAL_HEADER
        md5:                             7db26786973e4396ac69fb6c556c6e59
        sha1:                            b4f5a77022883e041cf3d39cb514d391c8348578
        ssdeep:                          3:x/rjJnPvX7MHvl5LuXNlk8s/J/llFllNllFllX:x2+08s/Jt
sections
    section
        section_name:                    .text
Segmentation fault (core dumped)

readpe gives me this:

...snip...
        Section
            Name:                            .reloc
            Virtual Address:                 0x12c000
            Physical Address:                0x1924
            Size:                            0x1a00 (6656 bytes)
            Pointer To Data:                 0x128a00
            Relocations:                     0
            Characteristics:                 0x42000040
            Characteristic Names
                                                 IMAGE_SCN_CNT_INITIALIZED_DATA
                                                 IMAGE_SCN_MEM_DISCARDABLE
                                                 IMAGE_SCN_MEM_READ
output: trying to close a document, but the current scope is of a different type.
Aborted (core dumped)