Topic: EXE File Steganography
by alcopaul (@thealcopaul in Twitter)
Data files like pdf, doc, jpeg, mp3, wmv and other files are an obvious curiosity for information hackers. Why? They contain data
and we have seen people love hiding data in data. The tendency for this is that people will naturally look for "data"
concealed in data sources.
One way to subvert this is to hide data in not so obvious places. Like in EXE files.
People will just think that "Hey, it's an exe file. If I click it, my computer may have a rootkit or virus."
So people are cautious to click exe files.
And that's the perfect place to hide data.
Any programming language can be used to do this. But, in standard compiled language like C, say if we program an exe file to hide
data within itself, it could be in spaces within the exe file or appending the data to the file. Moreover, the file could include
extra, if not, mega bytes of code that will handle the encryption of data, resulting to a very big file.
Good thing that the .NET Framework Languages exists, for this is the perfect platform for us to do our aim.
.NET has classes that contain assymetric and symmetric encryption routines. Symmetric encryption alone could be used but communicating
paragraphs worth of text and for safer key exchange, assymetric encryption is preferable, combined with symmetric encryption.
Assymetric encryption can just encrypt small amounts of data. So for our purpose, we will use both. Encrypt the large data with
a random generated key with symmetric encryption and encrypt the key with assymetric encryption.
Crafting our EXE file
For our exe file, It has to be a quine. Why? So it could compile itself, forming an exefile that looks like it's not tampered by
appending or space filling.
.NET framework has the ability to compile sources programmatically. And for the exe file to be recompiled, it has to reproduce
its own source code when it is run.
Thus it must be a quine.
What would our quine do?
Get the information on the console when say "/infohide" command-line is typed, generate a random key and use it to encrypt the message,
encrypt the key with a public key, attach the encrypted data and encrypted key to the source and recompile it to be an exe file.
/infohide "This is my message to Rudy." <public key here>
Then send the exe file to the recipient.
Then the recipient executes the exe file to read the message, with another command-line.
/readmsg <private key here>
say the "/readmsg" command-line just reads the data stored, decrypt the encrypted key with a private key and decrypt the message with
the decrypted key.
Those who will intercept the exe file would not notice the communication channel, and if attached to an email, would think that
the email came from a third party trying to infect the target with a virus. But i think that Gmail, Yahoo and the like banned
exe files in the attachments. Well, warez sites could be your communication platform now.
Thus another layer of security is made.