pe-sieve

pe-sieve copied to clipboard

Allow to exclude known hooks from the detection. Hooks should be defined in an external configuration file, easily readable and editable for humans.

Can pe-sieve calculate hashes (sha256, imphash) and signatures for each of the detected modules so we can filter on them rather than just the name?

@asekhar - unfortunately, calculating hashes and signatures makes sense only when we compare files, and not in case of modules in memory. Once the module is relocated, its imports filled etc the original hash will change. So, hashes of modules in memory will be changing and we cannot rely on them. Few examples:

• On each Windows restart the load bases of all DLLs is randomized: that makes a different relocation base, different addresses filled in import table, etc -> different hashes than in the previous sessions
• the same DLL loaded in different processes can have different hash due to different compatibility patches, shims, etc.
• in case of modules belonging to the .NET platform, the modules are always modified in memory - so their hashes are highly unreliable
• Some PE-sections are irreversibly changed during the run, i.e. the .data section can be filled with different data

The only thing that hashing of loaded modules can do, is, to compare if the hashes of modules in a particular process has changed across different runs of PE-sieve. I believe Process Dump does it, but I don't see much benefit from implementing it in PE-sieve, as PE-sieve uses different approaches.

Could you define a hash function for a native image in memory that only includes the headers and RX sections, treating any address specified by the relocation table as just 0?

Also - for DLL and static library versions, could this be exposed via an API so software using PE sieve can specify hooks without having to write information to a file