Debug information is actually stored as an array of debug entries. Historically YARA has only parsed the first available PDB path from this array. However, different debug entries can have different details (including different PDB paths) so I'm choosing to add pe.debug_details array which exposes the type, timestamp and PDB path for each debug entry. I'm careful to maintain the current behavior of parsing the first available PDB path into pe.pdb_path so as to not break existing rules.
Fun fact for the above: I've found at least one MSFT binary that has different PDB paths (System.Data.Entity.ni.pdb
and System.Data.Entity.pdb) in its respective debug entries.
This PR also adds support for LOAD CONFIGURATION parsing. It currently only pulls out the timestamp from there, but can be extended to add more if considered useful. I thought about adding the SEHHandlerCount, and maybe some of the CFG stuff, but decided against it as I'm not sure how useful it will be. The timestamps stored in this area seem to be all over the place in my testing but it may be useful to compare with other timestamps.
I've added a test case for the PDB improvements but haven't found a legit, non-malicious, binary with a timestamp in the LOAD CONFIGURATION structure yet.
Debug information is actually stored as an array of debug entries. Historically YARA has only parsed the first available PDB path from this array. However, different debug entries can have different details (including different PDB paths) so I'm choosing to add
pe.debug_details
array which exposes the type, timestamp and PDB path for each debug entry. I'm careful to maintain the current behavior of parsing the first available PDB path intope.pdb_path
so as to not break existing rules.Fun fact for the above: I've found at least one MSFT binary that has different PDB paths (
System.Data.Entity.ni.pdb
andSystem.Data.Entity.pdb
) in its respective debug entries.This PR also adds support for LOAD CONFIGURATION parsing. It currently only pulls out the timestamp from there, but can be extended to add more if considered useful. I thought about adding the SEHHandlerCount, and maybe some of the CFG stuff, but decided against it as I'm not sure how useful it will be. The timestamps stored in this area seem to be all over the place in my testing but it may be useful to compare with other timestamps.
I've added a test case for the PDB improvements but haven't found a legit, non-malicious, binary with a timestamp in the LOAD CONFIGURATION structure yet.