I am currently working on a project to hide data inside an mp3 file...What I did was, I replaced the last BYTE of every mp3 frame with the bytes from message file(the file to be hidden)... It works fine... I could hide the file in it and also successfully extract it... But some noise are present in the resulting mp3 file, due to addition of external data which is, definitely, not desired... Please help me in where to store the data in mp3 so as to reduce the noise...
PS: There is already a tool to use mp3 for hiding data -Mp3Stego. But it takes uncompressed wav file as input. But I need to have mp3 as input.
Such kind of tools do not replace whole byte. They are replace only last BIT. Try to replace only a BIT instead of BYTE. This will reduce the noise, but also reduce size of an information which you can put in file.
Related
For example, I recorded a video using my camera and saved it as my_vacation.mp4 which size is 50MB. I opened the video file and an encrypted file called secret_message.dat using Visual Studio, by using File.ReadAllBytes() in C#, concatenated both arrays of bytes, and then saved it as my_vacation_2.mp4.
The program I created for testing purpose is able to save the byte index where the hidden file begin and I want to use it as key to extract that hidden file later.
Now I can play that video file normally, without any error. Total file size is 65MB. Suppose no one could access the original file, of course no one would know that the last 15MB part of that video file is actually another file, right?
What might be the flaw of this technique? Is this also a valid steganography technique?
Is this a valid steganography technique?
Yes, it is. The definition of steganography is hiding information in another medium without someone suspecting its presence or existence. Just because it may be a bad approach doesn't change its intentions at all. If anything, a multitude of papers on steganography mention this technique in their introduction section as an example of how steganography can be applied.
What might be the flaw of this technique?
There are mainly 2 flaws: it is trivial to detect and is absolutely fragile to modification attacks.
Many formats encode their data either by a header which says in advance how many bytes to read before the end of file, or by putting an end-of-file marker, which means to keep on reading data until the marker is encountered. By attaching your data after that, you ensure they won't be read by the appropriate format decoder. This can fool your 11-year old cousin who knows nothing about that sort of stuff, but anyone mildly experienced can load the file and count how many bytes were read. If there are unaccounted bytes in the physical file, that will instantly raise red flags.
Even worse, it's trivial to fully extract your secret. You may argue it's encrypted, but remember, the aim of steganography is to not raise any suspicion. Most steganalysis approaches put a statistical number to it, e.g., 60% there is a message hidden in X medium. A few others can go a bit further and guess the approximate length of the embedded secret. In comparison, you're already caught red-handed.
Talking about length, a file of X bitrate/compression and Y duration approximately results to a file of size Z. Even an unsavvy one will know what's up when the size is 30% larger than expected.
Now, imagine your file is communicated through an insecure channel where a warden inspects its contents and if he suspects foul play, he can modify the file so that the recipient doesn't get the message. In this case, it's as simple as loading the file and resaving it. In fact, your method is so fragile it can be destroyed by even the most unintentional of attacks. By just uploading your track to a site for playback, it can unwittingly reencode it for higher compression, just because it makes sense.
Suppose no one could access the original file, of course no one would know that the last 15MB part of that video file is actually another file, right?
No. Your secret file is encrypted, so that probably rules out any headers showing up in hex editor, but there is a problem - MP4 container format and its structure is well known.
You can extract all video/audio tracks and what you are left with is some metadata and your secret message, so it will be obvious that it's not supposed to be there.
It is a valid technique, just not a very effective one.
I am currently trying to play a encrypted .mp3 file. The way I am currently using is:
loading the encrypted file -> decrypting it -> save it to ISO -> play it with the backgroundaudioplayer.
But this can take up to 10-15 seconds to start one .mp3 file. Is there any other way to do this faster ?
For example is there a way to play from a stream and somehow decrypt it while playing ?
And is there actually the need for encrypting the files on the IsolatedStorage ? Since nobody should be able to touch them anyways ?!
Ok well since its been so long I would recommend "Buffering" its really easy, have your decrypt stream give you a decent sized buffer from the first 20 or so seconds of the file, that should take a few seconds max much faster than waiting for the whole file, then just simply feed the backgroundplayer using the decrypted buffer whilst the rest is still decrypting.
Okay so I have an application which uploads a text file to a web server and all works fine.
However, a line magically appears on the text file when it is downloaded
example:
textfile contains = Hello World
downloaded textfile contains = //notice the blank line here
Hello World
Normally this wouldnt be a problem as I would just create a temp file and delete the line.
However, as the text file contains encrypted data and if I create a new temp file to delete the line it completely messes with the encrypted text and creates
"Bad Data" and "length of data to decrypt is invalid" errors.
Im almost 100% sure its not my encryption algorithm as the text files are output before they are uploaded and it works fine on the non uploaded text files.
If you guys could help me that would be awesome. Any work around will do (no matter how horrible / nasty it is).
Does the server and client run the same family operating system? I'm thinking that this may be due to newline sequence differences, and uploading and downloading in different modes (text/binary).
If the data is encrypted or cryptographically signed, you want to do everything you can to make sure the transfers are done in binary mode.
What does the download code look like?
Making a wild guess: you are Response.Write()ing the text, without a Response.Clear() to clear any "aspx text". Plus you need that code to end on a Response.End() to prevent further additions to the text.
It looks like your encryption algorithm is appending your text with null terminated string.
Try loading the text file on you webserver in a byte array and see if last byte is '\0'.
There are two reasons something like this can happen.
You are making some changes on upload(like parsing the text and some amount of data manipulation,where you introduce this line)
You are readingthe file and manipulating it before you download it...
Check both the code and post some samples if you are actually manipulating it. I have uploaded files using c# and it works fine.
You should check Hanselman's blog for a simple upload application...It is straight forward.
I have a large raw data file (up to 1GB) which contains raw samples from a USB data logger.
I need to store extra information relating to the file (sample rate, description, trigger point, last seek position etc) and was looking into adding this as a some sort of header.
The header file should ideally be human readable and flexible so I've so far ruled out some sort of binary serialization into a header.
I also want to avoid two separate files as they could end up separated when copied or backed up. I remembered somebody telling me that newer *.*x Microsoft Office documents are actually a number of files in a zip. Is there a simple way to achieve this? Could I still keep the quick seek times to the raw file?
Update
I started using the binary serializer and found it to be a pain. I ended up using the xml serializer as I'm more comfortable using it.
I reserve some space at the start of the files for the xml. Simple
When you say you want to make the header human readable, this suggests opening the file in a text editor. Do you really want to do this considering the file size and (I'm assuming), the remainder of the file being non-human readable binary data? If it is, just write the text header data to the start of the binary file - it will be visible when the file is opened but, of course, the remainder of the file will look like garbage.
You could create an uncompressed ZIP archive, which may allow you to seek directly to the binary data. See this for information on creating a ZIP archive: http://weblogs.asp.net/jgalloway/archive/2007/10/25/creating-zip-archives-in-net-without-an-external-library-like-sharpziplib.aspx
I'm trying to open a file to bytes, convert it to a string, modify some data (think Steganography) and convert the file back to bytes and save it as a jpeg. So far, everything I've tried has corrupted the file in converting it to a string. I've tried converting it to a 64-bit string, but of course that's a bit hard to modify the data in :P
Any suggestions on how I can do this properly, without corrupting my file?
I don't have this in C# but in PHP, but you can take a look and adaptate to C#.
http://www.havenard.110mb.com/fotomagica/
This is my site where there's a tool to modify the EXIF data of a JPEG and build "magic pictures" which display something in the thumbnail which is not the real picture.
It opens the JPEG, slice its sectors, and build it back ignoring irrelevant sectors and placing my custom made EXIF header.
And this is the source of the PHP classes:
http://www.havenard.110mb.com/fotomagica/class.JpegMapper.php.txt (ExifMapper is incomplete)
http://www.havenard.110mb.com/fotomagica/class.DataMapper.php.txt
You can study it and rebuild in C#, it is really simple to slice a JPEG as you will see.
Usage of this PHP class (only JpegMapper):
$jpg = new JpegMapper('picture.jpg');
$jpg->save_filtered('filtere picture.jpg'); // save removing irrelevant sectors
It is great to get any JPEG even smaller (sometimes a lot smaller).