Ring3 Circus
December 5th, 2007, 16:45
When I mention my reverse-engineering feats or failures to technically-minded friends, I tend to get one of a few responses. Not uncommon is ‘I wouldn’t know where to start.’ Well, I know it’s just a figure of speech, but I always start in the same place: PEiD ("http://peid.tk/").
http://www.ring3circus.com/peid.png
Many programs are built with third-party post-applied protection schemes, or are compressed with a packer to reduce the file size. The basic workings are the same - you run what you think is the program, but unknowingly execute the unpacker’s code, which decompresses or decrypts the original exe in memory and executes that once it’s done. The fact that most people are completely unaware of this process goes to show that these protectors and packers do at least half of their job well. While some protection schemes are better than others, any such packer will have the effect of turning a trivial hack, crack or patching job into a relative pain in the neck.
Rather distinctly, the odd occasion comes up where you’d like to know which compiler and/or linker was used to produce a binary, as the different options have their own quirks and particulars. Differentiating your Borland C++ Builder 5 from your Microsoft Visual C++ 6 can save you a little time and effort, if you need to fiddle with the ins and outs of stack-frame prologues or function indirection tables, for example.
Any tool that modifies a PE (exe or DLL) has to conform to strict standards, so as to keep the program functional, but will also have the effect of leaving behind a mark. These tell-tale marks are aptly known as PE fingerprints, and PEiD is designed to sniff out these fingerprints and give you the lowdown. So if I decide that I want to tweak the interface of my PostScript viewer, or to investigate how my anti-spyware tool enumerates processes, I only need to drag-drop the respective exe files into PEiD and I immediately know that GhostScript 4.7’s gsview32.exe was built in Microsoft Visual C++ 7.0 and that AdAware SE Personal 6.20 is compressed using ASPack 2.12. This tells me that the former will be very easy to analyse, whereas the latter will put up something of a fight, and that I’d perhaps be better off spending my time on Google.
So PEiD is something of an unsung hero, in that it only ever runs for five seconds at a time, perhaps once a week (at least on my computer), but yet when used properly it can have a profound effect on the development of any RCE project. And it is for this reason that I hereby sing its heroism for all to hear.
http://www.ring3circus.com/rce/rce-essentials-peid/
http://www.ring3circus.com/peid.png
Many programs are built with third-party post-applied protection schemes, or are compressed with a packer to reduce the file size. The basic workings are the same - you run what you think is the program, but unknowingly execute the unpacker’s code, which decompresses or decrypts the original exe in memory and executes that once it’s done. The fact that most people are completely unaware of this process goes to show that these protectors and packers do at least half of their job well. While some protection schemes are better than others, any such packer will have the effect of turning a trivial hack, crack or patching job into a relative pain in the neck.
Rather distinctly, the odd occasion comes up where you’d like to know which compiler and/or linker was used to produce a binary, as the different options have their own quirks and particulars. Differentiating your Borland C++ Builder 5 from your Microsoft Visual C++ 6 can save you a little time and effort, if you need to fiddle with the ins and outs of stack-frame prologues or function indirection tables, for example.
Any tool that modifies a PE (exe or DLL) has to conform to strict standards, so as to keep the program functional, but will also have the effect of leaving behind a mark. These tell-tale marks are aptly known as PE fingerprints, and PEiD is designed to sniff out these fingerprints and give you the lowdown. So if I decide that I want to tweak the interface of my PostScript viewer, or to investigate how my anti-spyware tool enumerates processes, I only need to drag-drop the respective exe files into PEiD and I immediately know that GhostScript 4.7’s gsview32.exe was built in Microsoft Visual C++ 7.0 and that AdAware SE Personal 6.20 is compressed using ASPack 2.12. This tells me that the former will be very easy to analyse, whereas the latter will put up something of a fight, and that I’d perhaps be better off spending my time on Google.
So PEiD is something of an unsung hero, in that it only ever runs for five seconds at a time, perhaps once a week (at least on my computer), but yet when used properly it can have a profound effect on the development of any RCE project. And it is for this reason that I hereby sing its heroism for all to hear.
http://www.ring3circus.com/rce/rce-essentials-peid/