You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug pesec does not recognize a PE-compliant file on s390x. Fails with:
ERROR [-18]: not a PE file
To Reproduce
Please provide us with:
pev version: 0.82
OS version: Debian sid
The file(s) you've analysed with pev: /usr/share/win32/gzip.exe as installed by the gzip-win32 package on Debian sid
The command you've used with the files, with all the flags: pesec /usr/share/win32/gzip.exe
Expected behavior
I expected pesec would read the PE file and report about its security properties.
Screenshots
N/A.
Additional context
The failure is likely due to libpe not taking endianness into account when loading the file into memory, being tested mostly on little-endian architectures (as amd64 and arm64). Those problems arise on s390x, as it is a big-endian architecture.
The text was updated successfully, but these errors were encountered:
I have to look into this. I will probably have to setup some virtual machine to look into what is actually breaking here but it is probably magic bytes/string comparisons.
So I did look into this and the general gist is that we currently just load all headers straight into memory.
This is quick and easy and work perfect on every little endian machine. On any other machine however this causes chaos obviously. I am planning on writing a new loading routine that loads the data machine sensitive that can be enabled via compiler arguments as the majority of users use little endian. This requires data to be processed context sensitively tho so it will be a bit of work. I started on an idea and confirmed that what I plan to do is working.
Describe the bug
pesec
does not recognize a PE-compliant file on s390x. Fails with:To Reproduce
Please provide us with:
/usr/share/win32/gzip.exe
as installed by thegzip-win32
package on Debian sidpesec /usr/share/win32/gzip.exe
Expected behavior
I expected
pesec
would read the PE file and report about its security properties.Screenshots
N/A.
Additional context
The failure is likely due to
libpe
not taking endianness into account when loading the file into memory, being tested mostly on little-endian architectures (as amd64 and arm64). Those problems arise on s390x, as it is a big-endian architecture.The text was updated successfully, but these errors were encountered: