Slashdot Mirror
Hydan: Steganography in Executables
An anonymous reader says "Ever wanted to hide a message into an executable? Now you can with Hydan. Presented recently by Rakan El-Khalil at Defcon and Blackhat, this tool lets you embed data into an application without changing its functionality or filesize! Check it out. Use includes steganography as well as embedding a program's signature into itself to verify it's not been tampered with."
if you blurt something like that out in the blurb maybe it would be nice to mention how the hell it happens. especially when the site gets slashed so fast.
executable packing or actually increasing the filesize? either one has to happen.
world was created 5 seconds before this post as it is.
especially if the OS goes off and double checks the executable is legit before executing it...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
If you embed a signiature of the file into the file, this by definition changes the file's signiature. At best you can append the signiature. However if the file can be modified, so can it's signiature.
If these folks have figured out a way of circumventing this innate paradox, I'm impressed and am dying to hear more about the technology/mathematics behind it! Can you say Nobel Prize nomination?
At least not without a top down Orwellian soceity where all hardware and software is controlled.
Free Mac Mini Yeah, it's
If I transmit files out to my friends that include encrypted data using steganography, then the extra data should be indistinguishable, effectively hiding within the noise of random crap on the web/usenet/email. Thus, without the key, an intercepted message is difficult to detect, and even if detected, I have sufficient plausible deniability to say "nothing there".
In order to detect an message encrypted and included inside another file, you either need to know its there and be looking for it, compare it to an existing file which should be identical, or statistically detect some aspect of the file. If you know it should be there, you just need to grab any file that looks like the file you're seeking, grab the relevant bits, and attempt decryption. If you have a file that should be identical, (say, an image that looks the same that was posted to usenet a couple days earlier), you can take the bits that are different and try and make some sense of them. If you are just doing statistical analysis, you might be able to find files which have a set of bits whose randomness is just shy of where it should be, and maybe those bits mean something.
In short, unencrypted steganography isn't particularly useful, but encrypted, you can really hide things.
OK, you place the hash in the executable; the file is changed. Now the hash should be different...
Problem.
If you mod this up, your slashdot background will turn into a beautiful sunset!
Since the diffrence can be detected with CRC or MD5, wouldn't that defeat the main purpose?
The main purpose is to send secret data, hidden in something that doesn't seem to contain such data.
If there's no "original" file to compare with, it'd be hard to detect the presence of the extra data. One could write a small application which seems innocent, but which only real purpose is to be used as a container for covert messages.
If the program has been tampered with, the most obvious thing to tamper with would be the validation mechanism.
I'm going to stick with a separate md5sum, thanks.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
This guy wrote his assembler to generate unusual form of MOV instructions at least 10 years ago. In this way, he can find out if a program is generated using an unregistered version of A86.
Any CPU that has an instruction to exchange two registers will have some redundancy, but for X86 even basic mov (as well as add, sub, cmp and so on) specifies both two operands and a flag that specifies which one is source and which one is destination. The significance is that both operands can be registers, but only one can be a memory reference.
A much more impressive use would be a program that reads its own code as data to save the last few bytes, especially if it has a real purpose, like fitting a game into a fixed-size ROM.
I think the main purpose is to be able to encrypt things in places people normally don't look. Breaking encryption on a wireless access point broadcasting over the air is one thing. Finding the only executable file on a laptop that includes an encrypted piece of information you need when you don't even know that it is encrypted in an executable file is another thing.
Coupled with messages in images, this will make it quite easy to move data around without anyone else knowing. There are too many places it could be. To look in all of them is impractical. They will only look in the obvious places, unless they have cause to look elsewhere.
Learn to love Alaska
This is a fascinating approach. One thing I didn't see mentioned at all in the documents is the possible change in performance characteristics by changing instructions which have the same effect but which have different pipeline, execution unit, or cache properties.
Modern optimizing compilers spend an awful lot of effort generating efficient combinations of instructions which try to make the most out of CPUs having complicated rules. For example, add eax,eax and shl eax,1 might both produce the same desired effect but yield significantly different runtimes depending on the presence / absence of barrel shifters or the ability of particular instructions to pair in a given CPU.
Naturally the above would only matter if the modified code is in an inner loop, but it could happen.