* Expose more export information
namely, ordinal and forwarded export
* ensure IterExpVA's behavior is not changed
* Added description in the header file
* Use 'offsetof' to resolve undefined behavior
../pe-parser-library/src/parse.cpp:1821:7: runtime error: member access
within null pointer of type 'typeof (curEnt)' (aka
'peparse::import_dir_entry')
* Fix bad rename
* pe-parser-library: Use WinAPI for UTF-16 to UTF-8
If ICU isn't available and we're on C++17 or later, use
the Windows API for Unicode conversion instead of codecvt.
* Pass resource by const pointer instead of value
Found/Suggested by LGTM:
This parameter of type resource is 128 bytes - consider passing a const
pointer/reference instead.
* Fix pepy
* resource by reference
* Change other iter* functions to be consistent pass by const reference
* nt-headers: Add IMAGE_DLLCHARACTERISTICS constants
Like the other Win32 constants, these are guarded by
_PEPARSE_WINDOWS_CONFLICTS.
* nt-headers: Add comment
Identified by #109: when parsing the PE sections, we incorrectly
trust that the offset range given to us by each section is valid.
We pass this range to splitBuffer expectly a valid bounded_buffer.
splitBuffer correctly determines that the range is invalid, and
returns a nullptr to indicate failure.
We fail to check for that nullptr in getSections, resulting in
an eventual segfault by null dereference when we attempt to
reference the invalid section.
This commit adds a check for that nullptr and causes getSections
to return false. This is then propagated as an invalid
section error.
Example:
```bash
/app/pe-parse # /usr/bin/dump-pe /tmp/test1.exe
Error: 3 (Invalid section)
Location: ParsePEFromFile:2380
```
Fixes#109.
* parse: Fix unsafe cast
* parse: Fix uninitialized warning
This is a false positive from cl.exe's /W4: We only
use this variable in a branch where it ends up initialized.
When read 2, 4, or 8 bytes from a bounded_buffer, we only
checked to see if the offset, not the whole span, was in bounds.
This results in an arbitrary memory read of up to 1, 3, or 7 bytes
when the offset is aligned with the very end of the buffer.
The following issues were found and corrected:
1. Auxiliary symbols were not being counted; this caused
the parser to loop above the actual number of symbols
2. When parsing auxiliary symbols, it is best to position
the offset manually at the start of the next data
structure (everything is padded to 18 bytes)
3. Some auxiliary symbol handlers were not correctly
updating the file offset
4. Print a warning when skipping auxiliary symbols
This closes#65
* CMake: Added install directives
* CMake: Added support for find_package(pe-parse)
* Fixed a compilation error on Linux
* CMake: Fix cmake module installation
* Added ArchLinux package
* Finished implementing the address converted example
* peaddrconv: Print the image base address.
* peaddrconv: Enable more warnings.
* Update travis to also build the examples
* Fix a compilation warning on Ubuntu 14.04
* Travis: Add macOS support.
* Better output for Travis, fix a compilation error on macOS.
* Travis: Do not build examples under macOS.
* Travis: Also compile the python module (pepy)
* Readme: Add a section to show how to use the library.
* Windows: Fix a compilation error, enable /analyze (see details).
The nt-headers.h include file is defining several constexpr values
using reserved (by windows.h) names.
These names (i.e.: IMAGE_FILE_MACHINE_UNKNOWN) are in fact macros
defined inside the Windows header files, and causes the preprocessor
to break definitions such as the following one:
constexpr std::uint16_t IMAGE_FILE_MACHINE_UNKNOWN = 0x0;
The fix (for now) consists in including the nt-headers.h file before
windows.h, but we should probably choose whether to use different
names or avoid defining those values (since they are inside the
system header anyway).
