Forgot your password?
typodupeerror
Security

Hydan: Steganography in Executables 235

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."
This discussion has been archived. No new comments can be posted.

Hydan: Steganography in Executables

Comments Filter:
  • by gl4ss ( 559668 ) on Thursday August 12, 2004 @05:06PM (#9952719) Homepage Journal
    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.

  • by advocate_one ( 662832 ) on Thursday August 12, 2004 @05:08PM (#9952733)
    especially if the OS goes off and double checks the executable is legit before executing it...
  • by guanno ( 597251 ) on Thursday August 12, 2004 @05:09PM (#9952747)
    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?
  • by CarrionBird ( 589738 ) on Thursday August 12, 2004 @05:10PM (#9952753) Journal
    It's more proof that you can't stop people from having secret conversations.

    At least not without a top down Orwellian soceity where all hardware and software is controlled.

  • by Ioldanach ( 88584 ) on Thursday August 12, 2004 @05:14PM (#9952801)
    If steganography is now in the hands of joe user, how useful is it really? It's not exactly a secret anymore, is it? ;P

    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.

  • Hashing problem: (Score:2, Insightful)

    by Tribbin ( 565963 ) on Thursday August 12, 2004 @05:23PM (#9952907) Homepage
    OK, you place the hash in the executable; the file is changed. Now the hash should be different...

    Problem.
  • by sonicattack ( 554038 ) on Thursday August 12, 2004 @05:33PM (#9953010) Homepage
    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.
  • by shadow_slicer ( 607649 ) on Thursday August 12, 2004 @05:33PM (#9953015)
    How could that be useful for stenography?
    Don't most compilers just use pick one of the redundant instructions and use that throughout? If so you just have to look for an executable that alternates betweent redundant instructions, and then you know that data is in there. At that point you're no better off than if you used plain encryption (and encryption uses less bandwidth...).
  • by Derek Pomery ( 2028 ) on Thursday August 12, 2004 @05:40PM (#9953074)
    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.
  • by iamacat ( 583406 ) on Thursday August 12, 2004 @05:50PM (#9953168)
    This guy [eji.com] 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.
  • by AK Marc ( 707885 ) on Thursday August 12, 2004 @05:52PM (#9953209)
    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.
  • by segfault7375 ( 135849 ) on Thursday August 12, 2004 @06:15PM (#9953401)

    At least not without a top down Orwellian soceity where all hardware and software is controlled.

    Isn't this basically what DRM aims to do?
  • by BlueBiker ( 690984 ) on Thursday August 12, 2004 @06:18PM (#9953432)
    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.
  • by Unordained ( 262962 ) <unordained_slashdotNOSPAM@csmaster.org> on Thursday August 12, 2004 @06:57PM (#9953753)
    except the hash isn't part of the hash. if i wanted to modify it, knowing this method, all i have to do is modify the executable part, hash it again, and re-insert. at best, the checksum lets me know i got the copy intended by the sender, nothing more.

    even if the hash were part of the hash (come to think of it), having a method for generating such executables would still make tampering possible. at best, it'd make it a slow process (assuming it's not something you can generate in O(1) time.)
  • Re:DUPE (Score:2, Insightful)

    by Lshmael ( 603746 ) on Thursday August 12, 2004 @08:01PM (#9954202) Homepage
    RTFA...
    Update: I've finally updated the hydan code, after a long time off. The encoding rate has been improved to 1/110 (thanks to a tip from sandeep!), and the code is now much cleaner too. In the mean time, hydan has been presented at:


    CansecWest 04
    BlackHat Vegas 04
    DefCon 04
    Not a dupe exactly, but an update on an old post.

Last yeer I kudn't spel Engineer. Now I are won.

Working...