My program - Embed files within a BMP image!

[dag10]

I was bored a few days ago, so I created this pointless little bundle of joy in C++.

Have you ever wanted to have a permanent backup of file(s) existing on the internet for free? How about send secret (if encrypted) messages to others through a seemingly normal looking forum avatar?

Neither have I!

However, I created two command-line exe programs to do just that! The first one asks you for a filename. Once you type it in (ex. files.7z), it created a BMP image in the same directory (ex. files.bmp). It looks like repedetive colorful static if not compressed/encrypted. If it is compressed/encrypted however (I suggest 7zip), it looks like random colorful TV static. Odd, but not that suspicious of a forum avatar.

The extraction program asks you for a bmp filename, and then it extracts the original data and places the embedded file(s) in the same directory.

Here's how the data embedding works. Basically, is uses 24-bit bitmap. Which means each pixel has three bytes. I simple take the first three bytes of the data to embed, and make those the RGB values for the first pixel. Then the next three bytes go into the second pixel, and so on.

You can try out the program if you'd like. I don't care. If you want the source code, just ask. They are virus free I assure you.

Here is the link to the EXTRACTION program: [url]http://www.mediafire.com/?yalnm5tytw2[/url]

Now, I will give you an example of what one of these images looks like (It's a 7zipped folder containing 2 files):
[URL="http://minipenguin.com/avatar.bmp"][IMG]http://minipenguin.com/avatar.bmp[/IMG][/URL]

Click the image to save it.
Simply place it in the same directory as the extracting program and run it.

Do you want the EMBEDDING program to create your own embedding images? Hint: It's in the image above, as well as a text file. You'll need 7zip to extract the .7z file embedded in the image above.

What do you think? (Besides its pointlessness)

[killowatt]

Uncover government secrets and take over the world with a puppy dog nazi flag :patriot:

[dag10]

[QUOTE=Killowatt;20337305]Uncover government secrets and take over the world with a puppy dog nazi flag :patriot:[/QUOTE]

...

Wait, what?!

[efeX]

[QUOTE=dag10;20337488]...

Wait, what?![/QUOTE]

lmao

[editline]10:46PM[/editline]

how do i know you didnt pack a virus in that exe!!!

[KingTarkata]

And it'll be almost believable with natural .bmp file sizes!

Great program, but I don't think I have any use for it at the moment.

[dag10]

[QUOTE=tarkata14;20337540]And it'll be almost believable with natural .bmp file sizes!

Great program, but I don't think I have any use for it at the moment.[/QUOTE]

Because the data is stored in the RGB values for each pixel, the filesize will be the same if I embed an exe in it, or a text document containing the text "Hello World!".

In fact this is bad because if the target filesize is too large to be fully embedded within the bmp, it will be truncated without warning. This will lead to a cut-off/invalid file once extracted.

[KingTarkata]

Interesting, may I see the source code? I'm just learning C++, but I love examples.

[dag10]

[QUOTE=tarkata14;20337685]Interesting, may I see the source code? I'm just learning C++, but I love examples.[/QUOTE]

I programmed this out of boredom with no useful purpose in mind, so it is sloppy and un-commented.

Code to the file EMBEDDER:

// Copyright Drew Gottlieb 2010
// Use if you want I don't care.
// Just don't take credit for this exact code.

#include <iostream>
#include <fstream>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

using namespace std;

int main() {
	srand(time(0));

	char FileName[64];
	memset(FileName,0x00,64);
	cout << "Name of file: ";
	cin >> FileName;

	char OldFileName[64];
	memcpy(OldFileName,FileName,64);

	char FileBuffer[30000-68];
    ifstream myFileI(FileName, ios::in | ios::binary);
    myFileI.read(FileBuffer, 30000-68);
	int FileSize = 30000-68;
    if (!myFileI) {
		FileSize = myFileI.gcount();
		myFileI.clear();
	}

	char FILEHEADER[14] = {(char)0x42, (char)0x4D, (char)0x66, (char)0x75, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x36, (char)0x00, (char)0x00, (char)0x00};
	char INFOHEADER[40] = {(char)0x28, (char)0x00, (char)0x00, (char)0x00, (char)0x64, (char)0x00, (char)0x00, (char)0x00, (char)0x64, (char)0x00, (char)0x00, (char)0x00, (char)0x01, (char)0x00, (char)0x18, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x30, (char)0x75, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00, (char)0x00};

	int DotIndex = 0;
	for(int i=0; i<64; i++) {
		if(FileName[i] == '.') {
			DotIndex = i;
			break;
		}
	}
	FileName[DotIndex+1] = 'b';
	FileName[DotIndex+2] = 'm';
	FileName[DotIndex+3] = 'p';
	FileName[DotIndex+4] = 0x00;
	for(int i=DotIndex+5; i<64; i++) {
		FileName[i] = rand() % 255;
	}
    ofstream myFile(FileName, ios::out | ios::binary);
    myFile.write(FILEHEADER, 14);
	myFile.write(INFOHEADER, 40);

	myFile.write(OldFileName, 64);
	myFile.write((char*)&FileSize, 4);

	myFile.write(FileBuffer,FileSize);

	int Loops = (30000-68)/FileSize;

	int a = 0;
	for(int i=0; i<Loops; i++) {
		for(int j=0; j<FileSize; j++) {
			a++;
			if(a > (30000-68)-FileSize) {
				break;
			}
			char RandColor = char(rand() % 20 - 10 + FileBuffer[rand() % FileSize]);
			myFile.write((char*)&RandColor,1);
		}
	}

	return 0;
}

Code to the EXTRACTOR:

// Copyright Drew Gottlieb 2010
// Use if you want I don't care.
// Just don't take credit for this exact code.

#include <iostream>
#include <fstream>

using namespace std;

int main() {
	char FileName[64];
	memset(FileName,0x00,64);
	cout << "Name of file: ";
	cin >> FileName;

    ifstream myFileI(FileName, ios::in | ios::binary);

	int FileSize = 0;
	myFileI.seekg(54);
	myFileI.read(FileName,64);
	myFileI.read((char*)&FileSize,4);
	char FileBuffer[30000-68];
	myFileI.read(FileBuffer, FileSize);

    ofstream myFile(FileName, ios::out | ios::binary);

	myFile.write(FileBuffer,FileSize);

	return 0;
}

[i300]

Tight.

Here is everything:
[url=http://img85.imageshack.us/img85/5048/bmpstuff.png][img]http://img85.imageshack.us/img85/5048/bmpstuff.png[/img][/url]

[KingTarkata]

[QUOTE=i300;20338400]Tight.

Here is everything:
[URL="http://img85.imageshack.us/img85/5048/bmpstuff.png"][IMG]http://img85.imageshack.us/img85/5048/bmpstuff.png[/IMG][/URL][/QUOTE]
Uh, that's a .png file...

[a2h]

[QUOTE=tarkata14;20338456]Uh, that's a .png file...[/QUOTE]

Convert it to a bmp then :downs:

[jA_cOp]

[QUOTE=dag10;20337743]I programmed this out of boredom with no useful purpose in mind, so it is sloppy and un-commented.

Code to the file EMBEDDER:

-snip-[/QUOTE]

You should really be using std::string in C++, that way you don't need make size estimates all over the place.

[dag10]

[QUOTE=jA_cOp;20338564]You should really be using std::string in C++, that way you don't need make size estimates all over the place.[/QUOTE]

That uses more resources. Char is pretty much native to the processor however.

And I didn't want to do that for simplicity. I just wanted to have the first 64 bytes of the color data fo be the name, the next 4 to be the size of embedded file (an int), then the fil, then random colors that look similar to the file to fill up the picture.

[voodooattack]

[IMG]http://i46.tinypic.com/voleki.jpg[/IMG]

[jA_cOp]

[QUOTE=dag10;20338645]That uses more resources. Char is pretty much native to the processor however.[/QUOTE]

How about a path that is just 5 characters long? In this case, your 64-byte buffer is a big waste of resources.

How about a path that is 150 characters long? In this case, there is an error in your program that goes unhandled, effectively a bug.

If you're worried about the difference in CPU time between reading into an std::string and a 64 character buffer, you should just be coding in assembly language, because your platform must have an amazingly slow processor.

edit:

You're not even using cin.get or cin.getline. As it is now, a path longer than 64 results in a plain buffer overflow.

edit2:

And you're allocating almost 30kb on the stack...

I don't think you know the first thing about optimization. You should not compromise everything else for what [I]might[/I] end up as a uselessly tiny optimization.

[GreyIOutcast]

[url]http://www.squidi.net/three/entry.php?id=12[/url]

Tell me, where did you get your inspiration from, hmm?

[efeX]

[QUOTE=jA_cOp;20338823]How about a path that is just 5 characters long? In this case, your 64-byte buffer is a big waste of resources.

How about a path that is 150 characters long? In this case, there is an error in your program that goes unhandled, effectively a bug.

If you're worried about the difference in CPU time between reading into an std::string and a 64 character buffer, you should just be coding in assembly language, because your platform must have an amazingly slow processor.

edit:

You're not even using cin.get or cin.getline. As it is now, a path longer than 64 results in a plain buffer overflow.

edit2:

And you're allocating almost 30kb on the stack...

I don't think you know the first thing about optimization. You should not compromise everything else for what [I]might[/I] end up as a uselessly tiny optimization.[/QUOTE]

Thank you. The "STL uses too much resources" tards are getting old.

[a2h]

[QUOTE=GreyIOutcast;20338988][url]http://www.squidi.net/three/entry.php?id=12[/url]

Tell me, where did you get your inspiration from, hmm?[/QUOTE]

Oh my god converting binary data to RGB values is a very unique idea anyone who copies it must be shot and hanged

Oh hey what's this quote doing on that site
[quote]I believe that embedding data within pictures is already done.[/quote]

:downs:

[GreyIOutcast]

[QUOTE=a2h;20339159]Oh my god converting binary data to RGB values is a very unique idea anyone who copies it must be shot and hanged

Oh hey what's this quote doing on that site

:downs:[/QUOTE]

My, my. Nearly cut me with those sharp words.

I've seen this around other places as well (especially on here), don't be so quick to bring about a fight where none is needed. It's a terrible trait to have.

[editline]12:26AM[/editline]

Interesting enough program, though.

[a2h]

[QUOTE=GreyIOutcast;20339282]My, my. Nearly cut me with those sharp words.

I've seen this around other places as well (especially on here), don't be so quick to bring about a fight where none is needed. It's a terrible trait to have.

[editline]12:26AM[/editline]

Interesting enough program, though.[/QUOTE]

Eh, you took those words a bit too strongly.

In any case, I'm not trying to pick a fight.

[editline]07:34PM[/editline]

I do apologise for that post coming through to you like that, though

[butre]

What license are you releasing it under?

[GreyIOutcast]

[QUOTE=a2h;20339371]Eh, you took those words a bit too strongly.

In any case, I'm not trying to pick a fight.[/QUOTE]

Ah, pardon me then. Feel free to give me something to pack things inside, I suppose. I've been known by my friends to be rather agitatable.

Once again on-topic (a bit): Here is something I actually got from a friend of mine. Flips bytecode to corrupt files and make them unreadable/unusable.

[url]http://www.mediafire.com/download.php?nj2zhml1ufn[/url]

I don't have the code anymore, though.

[dag10]

Guys, you're taking this program too seriously.
I already knew there were 100s of programs that embedded files in images, most if them I invisibly with no limit.

And you're right: the STD::string thing was bullshit. I simply wanted to make the program as simple as possible, Which meant a static string size for the name. I was bored remember? I just coded whatever took less typing. And I inclded no error handling whatsoever.

So you're all missing the point.
I just wanted to share this. It's been done before 1000x better. Windows can even do this nativly with a png.

[QUOTE=GreyIOutcast;20339465]Ah, pardon me then. Feel free to give me something to pack things inside, I suppose. I've been known by my friends to be rather agitatable.

Once again on-topic (a bit): Here is something I actually got from a friend of mine. Flips bytecode to corrupt files and make them unreadable/unusable.

[url]http://www.mediafire.com/download.php?nj2zhml1ufn[/url]

I don't have the code anymore, though.[/QUOTE]

Do you mean the endian?

[jA_cOp]

[QUOTE=dag10;20344288]I just coded whatever took less typing.[/QUOTE]

Using std::string, you'd not only need less typing (less decisions and logic, even), but you wouldn't have to include a lot of the error handling anyway :v:

[ZeekyHBomb]

Well, if this was all for the fun and whatnot, why would you publicly release it?
Take the criticism or don't release your stuff.

[dag10]

I am taking the criticism. I was just saying that so that thy criisize the right thing (the code, not me being a horrible programmer). I'm a great programmer btw. If you guys need to see that, I can reprogram it properly.

[editline]05:06PM[/editline]

[QUOTE=GreyIOutcast;20338988][url]http://www.squidi.net/three/entry.php?id=12[/url]

Tell me, where did you get your inspiration from, hmm?[/QUOTE]

Oh and no, I thought of it entirely myself.
That page represents what I was thinking at the time too.

As I saaid before, I was sure this exact thig had already been done, and there it is.

[yngndrw]

We did something like this in University, however instead we generated a set of random unique number pairs (Pixel coordinates, one pair per bit that we wanted to encode.) and changed the leased significant bit of the pixel which that pair is referencing, in sequence. What you end up with is a system to encode small amounts of data within an existing image, without affecting how the existing image looks.

[url]http://en.wikipedia.org/wiki/Steganography[/url]

[ThePuska]

Or if you don't want to be too fancy you can just append the data to the file. PNGs, for example, have the "IEND" string, after which all data will be ignored by image viewers and browsers, but it'll still carry over whenever the file is sent.

[editline]07:50PM[/editline]

In fact the string marking the end of image may be longer than IEND but the point remains that there is such a delimiter. My avatar now contains two paragraphs of lorem ipsum.

[dag10]

[QUOTE=ThePuska;20345075]Or if you don't want to be too fancy you can just append the data to the file. PNGs, for example, have the "IEND" string, after which all data will be ignored by image viewers and browsers, but it'll still carry over whenever the file is sent.

[editline]07:50PM[/editline]

In fact the string marking the end of image may be longer than IEND but the point remains that there is such a delimiter. My avatar now contains two paragraphs of lorem ipsum.[/QUOTE]

I know about IEND. I've used that method a year ago. It bloats up the filesize though.

And I see your avatar: [IMG]http://minipenguin.com/loremispum.png[/IMG]
And that screenshot is a PNG btw. (Hint Hint)

[editline]07:33PM[/editline]

[QUOTE=yngndrw;20344713]We did something like this in University, however instead we generated a set of random unique number pairs (Pixel coordinates, one pair per bit that we wanted to encode.) and changed the leased significant bit of the pixel which that pair is referencing, in sequence. What you end up with is a system to encode small amounts of data within an existing image, without affecting how the existing image looks.

[url]http://en.wikipedia.org/wiki/Steganography[/url][/QUOTE]

And I know about steganography. I've used a program (stego-something) to do that. It does not append the data, but somehow encodes it in the color data while keeping the original image. I don't know how it's done though, but I'd love to do it myself. I don't understand exactly what you're explaining.

[efeX]

[QUOTE=dag10;20344482]I am taking the criticism. I was just saying that so that thy criisize the right thing (the code, not me being a horrible programmer). [b]I'm a great programmer btw. If you guys need to see that, I can reprogram it properly.[/b]

[editline]05:06PM[/editline]

Oh and no, I thought of it entirely myself.
That page represents what I was thinking at the time too.

As I saaid before, I was sure this exact thig had already been done, and there it is.[/QUOTE]

k do it.