* NULL is replaced by nullptr
* Added parameter std::nothrow to operator new so in case of
failure it returns nullptr instead of throwing exception
std::bad_alloc. This is important due to check that follows
the statement. Example:
parsed_pe *p = new(std::nothrow) parsed_pe();
if (p == nullptr) {
...
}
* Using range-based for loops.
* Removed redundant boolean literals.
Example: if (readWord(...) == false) => if (!readWord(...))
* Resolved implicit casts.
Example: if (!ch) => if (ch == 0u)
* Created functions getImports, getExports, getRelocations from
parts of ParsePEFromFile to make it smaller and more readable.
* Using reinterpret_cast instead of C-style cast to convert
between unrelated types.
* Added braces around statements to improve readability.
PE file can contain any number of base relocation blocks, where
each of the blocks can contain any number of Type/Offset entries
beside of PageRVA and BlockSize fields. Without this fix only
first base relocation block is parsed.
Also fixes the issue #32.
lookupVA is initialized to 0. Also, if it remains 0 after the two
ifs, then ParsePEFromFile() returns NULL, since the section
lookup at the virtual address 0 is invalid.
* Put all of peparse in the peparse namespace.
* Fixes dupicate symbol problems when using the library inside other applications, namely Python
* Closes#25
I've noticed this in one (otherwise valid) EFI image. What happens is
the section specifies an invalid PointerToRawData, which the bounded
buffer abstraction catches and returns NULL. However, the SizeOfRawData
is still in the structure (and probably invalid too).
I saw two ways to fix this. If sectionData ends up being NULL we can set
SizeOfRawData to 0, but that would be truncating what is otherwise
specified in the file.
The other option is to teach dump-prog and pepy about this and adjust
accordingly. This involves checking for a data being a NULL pointer in
dump-prog when printing sections. In pepy it required roughly the same
check.
I went with option 2.
This was causing a problem where resources with strings would accumulate
the strings of previous resources in the directory.
For example, here is the output of test.py on
3f0961b7942f12bc96848509c04da2b6:
Resources: (4)
[+] MD5: (191649) 33a6345b919c7c733da9d33ee4ac64eb
Type string: BINARY
Name string:
1.165.3106.0_TO_1.165.3138.0_MPASDLTA.VDM._P
Lang: 0x0
Codepage: 0x4e4
RVA: 0x51dc
Size: 0x2eca1
First 10 bytes: 0x4d50535091ec0200c263
[+] MD5: (293587) e4c9b9aa65e0b236cb180fa489502700
Type string: BINARY
Name string: 1.165.3106.0_TO_1.165.3138.0_MPASDLTA.VDM._P1.165.3106.0_TO_1.165.3138.0_MPAVDLTA.VDM._P
The second resource has the first resources name string in it.
