Expose PeFile data, section_table and data_directory

[roblabla]

Having those exposed allows the user to explore the full internals of a PeFile, while simultaneously using the higher-level convenience functions exposed by the Object trait.

All the types (the SectionTable and pe ImageDataDirectory) are already public, so the increase in API surface is fairly minimal.

I'm personally using this to parse the Import table myself, in order to better handle certain edge scenarios (such as being able to tell the difference between a missing import directory from an empty directory).

[philipc]

Thanks!

I'm personally using this to parse the Import table myself, in order to better handle certain edge scenarios (such as being able to tell the difference between a missing import directory from an empty directory).

Is this something that would be useful to add to the Object trait in some form too, or are you doing things that only make sense for PE?

[roblabla]

So, I'm currently using object for malware analysis. Right now I'm mostly using it to calculate the Import Hash (imphash) of a malware, which allows fingerprinting a malware based on the system function it uses. It's used by handful of libraries, like pefile in python or LIEF in C++.

To do so, I wrote a small extension to object that iterates on the Imports. There are a couple upsides compared to objects' imports function:

• It properly handles ordinals. Windows has two ways of handling function imports/exports, it can either import by name, or by ordinal, which is just a number. See this msdn article. Object currently ignores ordinals.
• It avoids allocations, which makes it a tad easier to prove the function to be correct (no OOM case to take care of).

I'll make a PR later today with the import iterator, as that's definitely something that'd be nice to have in object.

For the imphash, I can also upstream it if it's something you'd be interested in with object, but it's fairly PE-specific.

[philipc]

imphash sounds a bit too specific to malware analysis, and would require a md5 dependency.

The import iterator would be great. If I remember correctly, the only reason it doesn't currently iterate is because of all the extra boilerplate to do that (I was lazy).