In a previous post I took issue with Chad McMillan’s claim that they had a revolutionary technology of identifying packed executables (btw., if you are interested, you can read my thoughts on the idea of packing your executables). He replied to me and in the spirit of fairness I publish his reply (with his consent of course below):

Hi,

I just wanted to clarify a little further the podcast with Bret. I have posted a comment, but am always interested in ensuring people are well informed.

So, I have actually encountered PE’s that were packed with known packers and were altered (via entry points and some other methods) in which PEiD (even with hardcore scan turned on) could not determine what the packer or compiler was. Our tool, however was able to find it. This is primarily because we try to associate signatures with the unpacking routine as opposed to the entry point.

Obviously, packer identification is nothing new by any means. But, we have built a suite of elements into one tool, which, as far as I have found, no one has. It includes:

1 – Packer / compiler ID via entry point
2 – Packer ID via “roaming” signature
3 – The correlation of the previous 2 (thereby, if someone tries to muck with the EP, but cannot change the unpacking, we’ll find it and note that fact … PEiD will not)
4 – Digitally Signed executables (code signing with X509 Cert)
5 – PE “anomolies” (things most compilers will not do, but are usually a result of a packer)
6 – Generic Entropy section check (PEiD also has this feature … but it appears it may also be foolable, where as we have a method against that)

Does this clear things up? I certainly would agree that PEiD has a great tool. We are just trying to help improve on the idea and make it a little better. Ours will also be free to the public once it is released (it’s actually finished … the GUI is all that is left).

Let me know if you have any questions!

Chad

My comments would be: PEiD is capable of searching the whole file if hardcore mode is set and the signatures have the ep_only property set to false. I just verified this (as a sidenote: PEiD runs perfectly fine with Wine. W00t!) The fact that it failed to identify a given packer on some sample(s) proves only that you have better signatures for that given packer. Also the additional features are nice, but no way revolutionary (for example you can use Sigcheck to verify the digital signatures of the files). Again, I think that it’s great that people are working in this area and this tool has the potential of becoming very useful (if implemented in a way that is easily scriptable – ie. command line with no user interaction) and available under a permissive license, but it is evolutionary rather than revolutionary.