Slashdot Mirror
Program Hides Secret Messages in Executables
DmuZ writes "My friend Rakan has created a new steganographic tool named Hydan which can embed messages into an executable without altering its size. He recently presented this tool to the public for the first time at codecon. This new technique was intriguing enough to get coverage on SecurityFocus.com. The code is available here."
> El-Khalil concedes that the method is imperfect -- an application that's been impressed with a secret message has considerably more "negative subtractions" than an unadulterated program, making it easy to pick out through a statistical analysis.
Note that as far as I remember, stenography by definition is supposed to make it imposible to prove that there is data hidden there - one step further than normal encryption. It's not so much as about hiding the data as being able to deny its existance.
One reason for this is if you have encrypted data on your disk, then courts can demand the password for it. Stenography allows you to insist there is no hidden data.
if you are using a relatively common binary. Then you just have to compare the MD5 checksums against a known-good (known-bad in MSFT's case ;P ) to identify a binary that could possibly contain encrypted data. Would it then be too much harder to go back through and disassemble the two and pick out the differences and hence identify the bits?
Novel idea though!
So when can we expect our first virus using this code?
where the comment ends and sig begins
In your examples, if there is are jump target in there somewhere they won't work. Remember that these are binary recompiler tools -- the source is not necessarily available, and it might not be decompilable to find all jump targets.
The second example has the additional problem of having a different side-effect on AX and possibly stack faulting.
I spoke too soon! Actually now that I've read the article myself and dug deeper in the story I realize there is a bigger issue here. The technique used in "Hydan" actually is broken! The ADD and SUB instruction will set the carry flag in opposite directions meaning simple code sequences like:
...
...
...
A -= 3;
if (A 0)
Which might be encoded as:
SUB EAX, 3
JC
will cease to function correctly!! The technique I cite (which has been proven and used in the a86 assembler) *DOES* work, since you don't change any of the instruction semantics, but just the instruction encodings.
So in fact, this *IS* yet another bogus story posted by timothy
You work with pretty old computers like the IA32 then, and ancient character sets to boot :-P
Where I come from (which is C), the byte is defined as the smallest addressable unit of store (memory, IOW) that can hold one character from the execution character set (i.e. the number of bits in a char). If I'm using ASCII, then the character set is seven bits wide and the smallest addressable unit of store on an i686 is 8 bits, so the byte would be 8 bits. If I'm using EBCDIC on a computer that can address eight-bit-wide units of store, then the byte is still 8 bits.
But now consider a computer that can address eight-bit-wide areas of store, but my OS uses 16-bit Unicode. The byte is now 16 bits, as that's the smallest chunk of memory that can hold a single char. Or a computer that deals in 32-bit-wide chunks only, but I'm (for some Godforsaken reason) using Baudot coding as my execution character set. Now my character set only takes up five bits, but as the minimum addressable unit of store is 32 bits wide, the byte has to be 32 bits.
A common misconception is to think that the byte and the octet are interchangable concepts. They aren't. The octet is eight bits, the byte is defined as above (see the ISO C99 standard, for example). It's probable that every system you've used has an 8-bit byte; but don't start thinking that's a universal concept.
There are cases in which the way the carry flag is set doesn't actually matter. In fact, I suspect that in most cases it doesn't actually matter. But, you're right, unless Hydan carefully analyzes the code to make sure it doesn't matter, it's broken.
Need a Python, C++, Unix, Linux develop
Why is C the authority on what a byte it? Bytes were around a long time before C.
This like any solution is not fool proof. The catch is if you have managed to get hold of both the orginal and the modified copy. A quick MD5 check will reveal that both are different and could lead someone to suspect that something has been done. Now which one is the modified version? You could do this using a statistical method, by finding out which occurrence appears more often on the net. So to achieve the trick correctly you need to make the modification to an executable that does not exist on the net.
Another method to detecting an executable that contains hidden data is to work out whether the executable uses the most unusual method of implementing its assembly.
Of course just like in the film 'A Beutiful Mind', you could just end up seeing encrypted data left right and center, whether or not it is really there.
Jumpstart the tartan drive.