[C#] BitCrypt - Visually Encrypt Binary Data (Bitmap Structures)

[AceInfinity]

So finally this prolonged project is in it's first complete stage if I wish to continue development on this.

Name: BitCrypt
Description: Visually encrypt binary data from an input file over to a Bitmap format, and decrypt it at a later date.

Preview:

Example Encrypted Output BMP 24:

Video:

More Information Here: http://tech.reboot.pro/showthread.php?tid=3051

 

[tom982]

Nice app Ace! I've never seen anything like it before.

Is there any chance you could upload it here? I don't meet the required post count for downloading attachments there

 

[AceInfinity]

Yes, no problem, i'll upload it as an attachment in the first post right now. :) The app is complete for it's first stage. If I continue development on this app, then I need to work on better compression output. I'll compress before encoding into a BMP, then when I decrypt the BMP back to it's original binary stream, i'll have to decode it into it's compressed byte collection, then decompress and save the output which should be the original file again.

I post all updates on my own personal community out of habit, but if I continue development on this certain app, i'll be sure to post all updates here as well at Sysnative :)

There's only really 3 communities that I frequent, the first is obvious, the other 2 include Sysnative, and the MSDN forums.

 

[tom982]

Works a treat :) Thanks! That sounds like a lot of fuss for a little compression!

I know it takes a fair level of incompetence to do it, but I made your app crash by having the input and output location as the same file; just thought I'd let you know. It also crashed in another scenario, but I can't seem to reciprocate it. I'll post back if I find out what I did.

 

[AceInfinity]

Yeah, this was more of a hobby app, you know those little experimentals that kind of intrigue you to create them based upon a single idea. I was curious what others thought about it before I went crazy with all possible error handling and compression and all that.

I thought it was something cool and unique though, so I went with it :)

It took me a while to figure out how I could encode the data, but I got it.

That error of input and output file being the same is an easy fix though. On the button click event I'd just put:

if (textBox1.Text == textBox2.Text) return;

Or perhaps even provide a MessageBox for the error. Or if you really only wanted one file, and input and output were the same, i'd load the input file into memory to make sure no direct filehandle was created on the actual file in the filesystem, create my output file, and overwrite the actual file itself using the file data loaded into a MemoryStream.

 

[candyman]

Name: BitCrypt
Description: Visually encrypt binary data from an input file over to a Bitmap format, and decrypt it at a later date.

Many thanks for your work!
But I have a question about its feature.
When I encrypted image.jpeg(155,553 bytes) into 1.bmp(466,713 bytes) with BitCrypt.

Q1. Why it became 3 times bigger in size?

And I converted 1.bmp to 1.jp2 with IrfanView(ver. 4.33) with "Lossless compression" checked. The size was almost the same as 1.bmp (it doesn't matter).

And I converted 1.jp2 to 2.bmp(463,794 bytes) with IrfanView. (There's no option provided in this process)

Q2. 1.bmp got decreased in size by 2,919 bytes. What's wrong with the processes on the way from image.jpg to 2.bmp? As a result, BitCrypt decrypted the original image perfectly except the bottom blank lines which covers the dark area of the original image but the color is not the same as the original so that I can discriminate the blocked lines of black color on the resulted image. Here I attached the binary comparison table with TotalCommander:

​

​

Thank you in advance for your kind advice.

 

[AceInfinity]

This is because I wrote a lossless version of the BMP specification dynamically and into a grayscale format, meaning RGB has to be the same value for all 3 bytes, unless you change the BMP format, or go to a color output. It's not ideal as a way of data storage or compression for this reason, and was more just experimental. :)

I made other ramifications to this along the way in unreleased versions before I lost the project data from hard drive issues. This was pure binary writing for the BMP bits though, header to EOF... If you are interested, I could probably write a better version of this now anyways. The BMP that was being written by this program though was lossless (no compression), and therefore was really no protection to the data being written to the image, and the data was not by any means obfuscated/encrypted either.

If I can remember correctly this was just a plain old 24bit ARGB bitmap output. In hex view it should be obvious that it's by no means efficient though. You should see 4 consecutive bytes for each distinct byte in the file, which hints at the ARGB values for each pixel in reading order for the way the BMP is displayed (right to left).

Thanks for your interest btw, It's a very old project :)

 

[candyman]

This is because I wrote a lossless version of the BMP specification dynamically and into a grayscale format, meaning RGB has to be the same value for all 3 bytes, unless you change the BMP format, or go to a color output. It's not ideal as a way of data storage or compression for this reason, and was more just experimental. :)

Thank you for letting me understand why it becomes 3 times bigger in size. :)

I made other ramifications to this along the way in unreleased versions before I lost the project data from hard drive issues. This was pure binary writing for the BMP bits though, header to EOF... If you are interested, I could probably write a better version of this now anyways. The BMP that was being written by this program though was lossless (no compression), and therefore was really no protection to the data being written to the image, and the data was not by any means obfuscated/encrypted either.

No compression can be applied in this project, I think. The source binary should be compressed or encrypted before converting into the target BMP.

If it doesn't make you too much busy, please rewrite one. :)

If I can remember correctly this was just a plain old 24bit ARGB bitmap output. In hex view it should be obvious that it's by no means efficient though. You should see 4 consecutive bytes for each distinct byte in the file, which hints at the ARGB values for each pixel in reading order for the way the BMP is displayed (right to left).

Thanks for your interest btw, It's a very old project :)

If you rewrote, I wish you would convert each byte of the source binary into each 8bit part of R & G & B values one byte by one byte. This would make the file size almost the same.

FYI, image - How would I encode a binary file to JPG format - Stack Overflow http://stackoverflow.com/questions/3296045/how-would-i-encode-a-binary-file-to-jpg-format .

PS: May I have any advice how to convert BitCrypt's BMP format into the standard lossy JPG format without losing any quality and recover the JPG into new BMP which can be decrypted into the original source binary without losing any data? It's because some blog service providers allow JPG, PNG, GIF format images only to be uploaded.

Thank you again for your kind explanation!

 

[AceInfinity]

This is because I wrote a lossless version of the BMP specification dynamically and into a grayscale format, meaning RGB has to be the same value for all 3 bytes, unless you change the BMP format, or go to a color output. It's not ideal as a way of data storage or compression for this reason, and was more just experimental. :)

Thank you for letting me understand why it becomes 3 times bigger in size. :)

I made other ramifications to this along the way in unreleased versions before I lost the project data from hard drive issues. This was pure binary writing for the BMP bits though, header to EOF... If you are interested, I could probably write a better version of this now anyways. The BMP that was being written by this program though was lossless (no compression), and therefore was really no protection to the data being written to the image, and the data was not by any means obfuscated/encrypted either.

No compression can be applied in this project, I think. The source binary should be compressed or encrypted before converting into the target BMP.

If it doesn't make you too much busy, please rewrite one. :)

If I can remember correctly this was just a plain old 24bit ARGB bitmap output. In hex view it should be obvious that it's by no means efficient though. You should see 4 consecutive bytes for each distinct byte in the file, which hints at the ARGB values for each pixel in reading order for the way the BMP is displayed (right to left).

Thanks for your interest btw, It's a very old project :)

If you rewrote, I wish you would convert each byte of the source binary into each 8bit part of R & G & B values one byte by one byte. This would make the file size almost the same.

FYI, image - How would I encode a binary file to JPG format - Stack Overflow http://stackoverflow.com/questions/3296045/how-would-i-encode-a-binary-file-to-jpg-format .

PS: May I have any advice how to convert BitCrypt's BMP format into the standard lossy JPG format without losing any quality and recover the JPG into new BMP which can be decrypted into the original source binary without losing any data? It's because some blog service providers allow JPG, PNG, GIF format images only to be uploaded.

Thank you again for your kind explanation!

The BMP structure does have a compression byte, so compression can indeed be applied here. (In both ways if one wanted.) That value is currently set to 0 though when the BMP gets written.

If you rewrote, I wish you would convert each byte of the source binary into each 8bit part of R & G & B values one byte by one byte. This would make the file size almost the same.

As I mentioned, you would lose the grayscale by doing this, and initially I wanted a grayscale image kind of like the way those tags for blackberry look for instance.

PS: May I have any advice how to convert BitCrypt's BMP format into the standard lossy JPG format without losing any quality and recover the JPG into new BMP which can be decrypted into the original source binary without losing any data? It's because some blog service providers allow JPG, PNG, GIF format images only to be uploaded.

You would need to make sure that you are not keeping any metadata in the JPG when converting back and that you are converting to a full quality JPG. I don't have much knowledge about JPG, but you can use FFMpeg to try and convert. Then convert back and see if any data has changed. Do understand the complications of doing this because converting to a different file format may also mean re-arranging the original data. So converting back, would mean that you would have to convert to lossless both ways, otherwise data would be missing from the original after both conversions have taken place.

Look into the JPG file format. It shouldn't be very difficult. It's what I had to do with BMP.