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).
