I am facing the issue where I need to convert a video(in .mp4 for example) to .bin so it can be read by one of these infamous 3D Holographic Fan. At the moment I am doing it this way using C#.
private async Task<bool> convertToBin(string file)
{
byte[] bytes = System.IO.File.ReadAllBytes(file);
string path = Path.GetFullPath(file) + ".bin";
string str = System.Text.Encoding.UTF8.GetString(bytes);
System.IO.File.WriteAllText(path, str);
return true;
}
However, the produced .bin is recognized by the fan but when played the LEDs all turn white. Furthermore if I open a .bin generated with the fan's software the format seems completely different, as the first 8.000 lines of the correct .bin are just 0000 0000 0000 0000.
Any idea how to accomplish this?
This is a pretty broad question on file conversion since technically you can just change the extension on any file to .bin and it is a valid .bin file.
The reason being that the .bin extension has no specific standard, its just a collection of binary data - this means that different companies can (if they wish) implement their own standards within files that they work with.
In terms of holo fans, most manufacturers of them will often either have for free (or a small fee) a video conversion piece of software available that converts a file into a .bin that will work with the fan for you. (also many fans now can just work with .mp4 etc too, but im guessing yours cant)
If the first X amount of data in the correct file really is just a stream of 0's it seems as if there is some amount of "padding" at the beginning of the file though without really being able to see the file not 100% on that.
Either way, generic conversion to a .bin without knowing the specific format that the device / manufacturer is potentially enforcing is pretty hard - like trying to get the exact amount of water to fill a bucket, without ever seeing the bucket
Binary itself is meaningless, until such time as an executed algorithm defines what should be done with each bit, byte, word or block. Thus, just examining the binary and attempting to match it against known formats can lead to the wrong conclusion as to what it actually represents.
Quote from the Wiki page on Binary files :)
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 working on a system that saves temporary files in windows\temp. These files take on a .tmp file extension.
I am working on functionality that needs to read one of these files, identify whether it is an image or video file, and the filetype. Since the files are saved as .tmp, I can not use the file extension.
I've already written code that identifies whether the file is a valid image file, and it's filetype - This was actually quite easy, to my surprise!
My question is this: How can I identify whether an array of bytes is a valid video file, and if it is, how can I identify it's filetype?
As I understand, this is in general not an easy task as there are hundreds of formats. But I guess if you learn about binary signatures, or file signatures, you'll get a step forward with this question.
Here is an idea:
http://www.den4b.com/wiki/ReNamer:Binary_Signatures
And here more information:
http://en.wikipedia.org/wiki/List_of_file_signatures
Good luck :-)
In C#, I have a ZIP file that I want to corrupt by XORing or Nulling its bytes.
(by Nulling I mean make all the bytes in the file zeros)
XORing its bytes requires me to first, read the bytes to a byte array, XOR the bytes in the array with some value, then write the bytes back to the file.
Now, if I XOR/Null All (or half) of the file's bytes, it gets corrupted, but if Just
XOR/Null some of the bytes, say the first few bytes (or any few number of bytes in any position of the file) it doesn't get corrupted, and by that I mean that i can still access the file as if nothing really happend.
Same thing happened with mp3 files.
Why isn't the file getting corrupted ?
and is there a "FAST" way that i could corrupt a file with ?
the problem is that the zip file that I'm dealing with is big,
so XORing/Nulling even half of its bytes will take a couple of secs.
Thank You So Much In Advance .. :)
Just read all files completely and you probaly will get reading errors.
But of course, if you want to keep something 'secret', use encryption.
A zip contains a small header, a directory structure (a the end) and in between the individual files. See Wikipedia for details.
Corrupting the first bytes is sure to corrupt the file but it is also very easily repaired. The reader won't be able to find the directory block at the end.
Damaging the last block has the same effect: the reader will give up immediately but it is repairable.
Changing a byte in the middle will corrupt 1 file. The CRC will fail.
It depends on the file format you are trying to "corrupt". It also depends on what portion of the file you are trying to modify. Lastly, it depends how you are verifying if it is corrupted. Most file formats have some type of error detection.
The other thing working against you is that the zip file format uses a CRC algorithm for corruption. In addition, there are two copies of the directory structure, so you need to corrupt both.
I would suggest you corrupt the directory structure at the end and then modify some of the bytes in the front.
I could just lock the zip entries with a pass, but I don't want anybody to even open it up and see what's in it
That makes it sound as if you're looking for a method of secure deletion. If you simply didn't want someone to read the file, delete it. Otherwise, unless you do something extreme like go over it a dozen times with different values or apply some complex algorithm over it a hundred times, there are still going to be ways to read the data, even if the format is 'corrupt'.
On the other hand, breaking a file simply to stop someone else accessing it conventionally just seems overkill. If it's a zip, you can read it in (there are plenty of questions here for handling archive files), encrypt it with a password and then write it back out. If it's a different type of file, there are literally a million different questions and solutions for encrypting, hiding or otherwise preventing access to data. Breaking a file isn't something you should being going out of your way to do, unless this is to help test some sort of un-zip-corrputing-program or something similar, but your comments imply this is to prevent access. Perhaps a bit more background on why you want to do this could help us provide a better answer?
Hello I am trying to compress a file using GZipStream.
I have created my own extension, let's call it .myextension
I try to compress .myextension and keep its extension. I mean that I am trying to compress a .myextension to the same extension. Example: I have myfile.myextension and
I want to compress it to myfile.myextension. It works. I can compress my file really well.
The problem is that when I try to decompress it using GZipStream it says that the magic number is incorrect.
How can I fix that? When decompressing should I just change the extension to .gz? Should I convert it somehow? Please help me I have no idea how to continue.
This is a common question. I would like to provide you the similar threads with the solutions:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=427166&SiteID=1
A 'Magic Number' is usually a fixed value, and often appearing somewhat arbitrary, possibly indecipherable. For example, a line of code may have:
If X = 31 then
'Do Something
End If
In this case, 31 is a 'Magic Number': It has no obvious meaning (and as far as coding is concerned, a term of derision).
Files (of different types) often have the first few bytes set to certain values, for example, a file which has the first two bytes as then hexadecimal numbers 42 4D is a Bitmap file. These numbers are 'magic numbers' (In this case, 42 4D corresponds to the characters BM). Other files have similar 'magic numbers'.
http://forums.microsoft.com/msdn/showpost.aspx?postid=1154042&siteid=1
Of course, the minute someone (team) develops a no-fuss compression/decompression custom task which supports zip,bzip2, gzip, rar, cab, jar, data and iso files, I'll use that, until that time, I'll stick with the open-source command-line utilities.
Of course, you can code up a solution, but this one is such low hanging fruit. For handling zip files, there is no native .NET library (at least not yet). Now there is support is for handling the compressed streams INSIDE the zip file, but not navigating the archive itself.
Now, as I mentioned in a previously, there are plenty of open-source zip utils like those on Sourceforge. These work fine on Win2003 Server x64, I can attest to that.
However, if you're insistent on a .NET solution for zip decompression, use http://www.icsharpcode.net/OpenSource/SharpZipLib/, which is open source, and which has a clean and reliable 100% .NET implementation.
First off, from other users who have had various issues, GZipStream should not be used since it has bugs. It does not compress short strings correctly and it does not detect corrupted compressed data. It is a very poor implementation.
As for your problem, others using GZipStream see a four-byte prefix to the gzip data which is the number of uncompressed bytes. If that is written to the file, that would cause the problem you are seeing. The gzip file should start with the hex bytes 1f 8b.
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