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

stenography

[JohnFluxx]

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

But detection should be easy...

[rediguana]

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!

Virus

[bottlerocket]

So when can we expect our first virus using this code?

Re:Redundancy?

[Ninja Programmer]

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.

Re:stenography

[sql*kitten]

Hiding a secret message within a larger one in such a way that others can not discern the presence or contents of the hidden message. For example, a message might be hidden within an image by changing the least significant bits to be the message bits

OK, but geeks forget that possible/impossible isn't a binary state, like 1 and 0. It's a about likelihood. Is there a 1% chance that this file contains a hidden message? Or is it more like 90%?

One the police have "reasonable grounds", they can step up to the next level. You can deny it 'til you're blue in the face, but if they get a professor to testify that it's highly probable that there is a message there, and they have evidence that you have corresponded with other suspects ("exactly why did you send Mohammed bin Mohammed a picture of your kitten a day before al-Queda hijacked that airliner?") and suddenly your steganographic sK1Lz aren't worth so much.

Re:You might have gotten hoaxed.

[Ninja Programmer]

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

Re:You might have gotten hoaxed.

[grahamlee]

I don't know about you, but where I come from all bytes are pretty much 8 bits in size.

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.

Man, I need to get me some of them new magic size-changing bytes! Down with the tyranny of 8-bit bytes!

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.

Re:You might have gotten hoaxed.

[Omnifarious]

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.

Re:You might have gotten hoaxed.

[chrisseaton]

Why is C the authority on what a byte it? Bytes were around a long time before C.

Re:stenography

[p3d0]

And I suppose you made the leap from "can not" to "impossible"?

The problem is if you have two copies

[Midnight Thunder]

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.

Re:stenography

[Bunji X]

"exactly why did you send Mohammed bin Mohammed a picture of your kitten a day before al-Queda hijacked that airliner?"

None of your freaking business. Mohammed bin Mohammed is an old friend of mine, he wanted to see a picture of my new kitten.

Freedom of expression, freedom of speech. No?

Maybe a professor's testamony of "high probability" is enough to get you in deep shit over there, fortunately we still have something that reminds of citizen rights, this side of the pond.

Re:stenography

[pestihl]

thats funny considering all those people being held without a lawyer and without a court date and without representation from their country in guantonamo bay... I don't think in light of any "Homeland Security act" you will be allowed to have "free" speech.. in fact it seems quite the other way.

more like.. You know who Mohammed bin Mohammed is.. you goto jail do not pass go do not have any rights do not even get to try to explain yourself infront of a judge.