* workflows/release: Add PyPI release config
* util/release: Don't push to PyPI manually
The CI will handle this for us from now on.
* VERSION: 1.1.0.rc.1
* workflows/release: Try on this branch
* workflows/release: Syntax
* workflows/release: Disable on this branch
* VERSION: 1.1.0.rc.2
* 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
* Dockerfile, cmake: Simplify build
Always use clang in the Dockerfile, and don't overspecify
the build type.
Additionally, drop -Weverything when building in Debug mode --
it has competing flags internally and isn't intended for actual
builds.
* Dockerfile: Set CC and CXX
Ensures that we build with clang(++).
* python/setup: Blacken
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.
