Forensics on PDAs, notes from the field

[Thomas Shaddack]

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...