On Thu, 12 Aug 2004, Thomas Shaddack wrote:
The NIST CDROM also doesn't seem to include source code amongst its sigs, so if you compile yourself, you may avoid their easy glance.
A cool thing for this purpose could be a patch for gcc to produce unique code every time, perhaps using some of the polymorphic methods used by viruses.
Just adding a chunk of data to make the hash unique will work against the current generation of the described tools. But we should plan to the future, what moves the adversary can do to counter this step.
We can do some in-depth changes of the executable, using the "Steganography in executable files" approach described here (and on Slashdot) recently. See eg. here: http://www.informit.com/articles/article.asp?p=102181&seqNum=6 The difference is we don't want to store anything to the file itself but just to change its content without changing its function. We can use the Hydan approach, using random data as what to store inside. Adding a command dd if=/dev/urandom count=<length/bs> | $HYDAN_STEGO $exefile (where $HYDAN_STEGO is the steganography-adding program and $exefile is the product of the compilation by an unmodified compiler) into the makefile of the project could make the signatures unique for every compilation. Same applies to installation scripts. As we shouldn't trust our tools completely, a suite of suitable test vectors should be run afterwards. This can be used in combination with executable packers (eg. UPX), or some wrappers for "copy-protection", which wrap and optionally encrypt the executable and refuse to run it when eg. a dongle (which can contain the key) is not present in the computer. It doesn't work for copyprotection too well, but can slow down the adversary (or making some of their attack methods impossible or impractical to use) in other scenarios. If the usage scenario is plausible, the deployment of the protection technology may "make sense", so its presence won't have to necessarily raise suspicion. (We have to always keep in mind that the presence of any given technology can be a factor on its own.) The adversary then has to resort to heuristic analysis of the code segments, or hashing data segments, or maintaining sets of characteristics of the executables other than the hashes of the complete file (code/data segments size, addresses of jumps...), or relying on the strings in the file, or other options, all of them more difficult than hashing a file, and potentially requiring better-trained forensics people...