what i mean by ALT-255 is that you hold down the ALT key and type in 255 (the NULL char) on the NUMBERPAD (not the numbers ontop of our letters, but the thing to the far right).
this will let u view the folder through dos, but not able to view it through windows. Btw, you may substatue Floder for anything u like
after you encrypt it you could convert it to binary and it will appear to have very little info in it like a bas file from QBasic 4.5.
You can also have it stored in the system directory and change its attributes to hidden system and read-only which will hide it from dos and windows unless they change some system settings.
Also if you name it somthing that looks like a system file ,like syscfg32.sys, then it will make people think twice about opening it or editing it.
Just a thought perhaps it is possible to add data to the bottom of a picture, so that when opened it shows a picture, but underneath are the encrypted passwords. Anyone know if this is possible, or are there more effective ways than this?
It is not only possible, but i have done it. Each color in a 24-bit picture is made up of 3 entire bytes of data. If you replace the bottom bit of each byte with your own bit, you can effectively store a 100k in a 800k bitmap picture file. And all you did was reduce the color depth to 21 bits.
Basically, open a bitmap in binary format. Make sure it is a 24 or 32-bit bitmap, or this won't work. It can be done with 16-bit, but it is much harder to program for, because 5 bits of a byte go to one color, then the next 3 bits are the start ofthe next color, etc.
Ok here is basically what you do:
open your password file in binary.
open your picture file in binary.
open a new output file.
read the first 50 bytes from the bitmap and write them to the new bitmap.
enter this loop:
for cl = 1 to lof(passwordfile)
get a byte from your password file.
break the byte into 8 individual bits and store them in
an array named newlowbit. Preferred method is read them directly into a byte array.
the name of the byte array in my example is "char"
read 8 bytes from the new picture and store them in a array
replace the lowest bit of each byte with your 8 divided up bits of the password byte.
-like this:
for replaceloop = 1 to 8
. char(replaceloop) = char(replaceloop) AND 254 + newlowbit(replaceloop)
next replaceloop
then write the 8 bytes you just created to the output file.
Repeat until you are done.
When you get comfortable with the technique, you can add error code to check for end-of-file for the bitmap,
and add code that adds the size of the file you are putting in it.
Obviously, to read from the file, do just the opposite.
Read in 8 bytes at a time, save only the lowest bit, and write that to an output file.
but is there any way to store it so that it is its own file but not readable by the file structure? or even remove it from the file allocation table but not let the system write there but have your program read from the location on the disk? that would be a cool little sniplit of code to add to my library
Possible, yes, but I think scandisk will complain about lost clusters.
You mark the clusters as used, but don't associate a filename with them, you'll need a way to access the data though.
Hiding it in a 24 bit bmp file is quite cool, but a 24 bit bmp file stores 4 bytes for every pixel... like this:
HEADER 56? bytes
BGRrBGRrBGRr
Where BGR is Blue/Green/Red (in that order) and r is a reserved byte, not used at the moment. Perhaps for 32 bit color bmp's
In this way you can store the encrypted password file in your company's logo, noone will look for it there. You can also just compile the logo into a resource file and LoadRespource it, that way there won't even have to be a seperate file.
If the 24 bit picture has a free byte available, is it possible to use this, instead of replacing bits used by the picture?
In this case would I open the two files, read in the first 3 bytes of the Pic, then add a byte of my password file, then read in the next three bytes of the picture and so on?
Originally posted by JamesM If the 24 bit picture has a free byte available, is it possible to use this, instead of replacing bits used by the picture?
My point exactly. Yes it's possible. I'd go and search for a desription on the bmp fileformat. You still need some info from the header (width, height, color depth) to make it work...
In other images (<24bit) you could use the lowest bit in a color byte for the information, if you do it the right way, noone will be able to see it.
On the other hand, the gif fileformat allows for plain text to be stored inside the image file. With a standard viewer nobody can see that unless you want them to. You can encrypt the passwords and store them in a .gif file without hassle.
my testing says that that isn't so. You must be thinking of color values. When they are stored as a long data type, they have an extra bit, but when they are in a bitmap file, they don't.
Here, do a little math and see for yourself:
Setup.bmp that comes with win98/me:
load it into paintbrush and resave it as a 24-bit image.
it is now a 640x480x24 bit image and takes up 921,654 bytes on disk.
since 24-bit is 3 byte, we can figure out how many bytes the image should take up like this:
640x480x3 = 921,600. This leaves 54 bytes for the header. If they took up 4 bytes as you said, then the file would now be 1,228,800 + 54 byte header = a file size of 1,228,854. Obviously, you have mixed your data up.
I hope this correct information is a help to you.
Last edited by Lord Orwell; Mar 21st, 2001 at 04:12 AM.
Another thing, you can't store data in a bitmap less than 16 bit. The bytes in a bitmap of color depth less than that don't represent the actual color.
They are merely indexes to a color table that is stored in the front of the file. Thus the smaller bitmap files have larger headers, and the change of a single bit in a pixel can potentially turn white into red or whatever.
I think that someone ELSE needs to read about bitmap file headers.
And finally, if you mark a sector as bad in the fat, scandisk ignores it. You have to change the options of scanning to "full surface scan" for scandisk to notice that the sector isn't really bad.
You have 2 problems:
one: reading (and in fact finding) the correct fat32 into memory, changing the appropriate byte to fff7(bad), then writing the newly changed fat and the sector directly to disk. I have a program i wrote in dos that can do all of this to a floppy (i never bothered to finish the program to work with hard drives), but i have yet to discover a way to read/write sectors in vb. If you want to do this, you will have to program in C++ and include inline assembly (unless you are on winNT, which lets you open the drive as a file)
If you don't want to make any change in the appearance, you can use the extra byte in the color table (for each color) of a bitmap. Only bitmaps with a color depth less then 24 bits have a color table. So for a 256 color bitmap, you can use 256 bytes.
Bitmaps must be aligned on a long boundary.
If a bitmap has a width of 255 pixels, and uses 24 bits color depth, you would need 255 * 3 = 765 bytes for 1 scan line.
You must be able to devide this number by 4 (align on a long boundary; long = 4 bytes) so you have to add 3 bytes for each scan line.
This means (for a 24 bit bitmap with a width of 255 pixels) you can use 3 bytes for your own purpose. If the bitmap has a heigth of 300 pixels, you have 300 * 3 = 900 bytes for yourself.
I never used these extra bytes, but I think they don't show up in the bitmap.
Gerco, in 32-bit bitmaps, the alpha-blending byte is the 4th byte. 24 and lower don't have them.
This is the difference in 32 and 24 bit images. Alpha blending byte.
FranceC where did you come by this information? Tests prove you correct. I never tried file size checking with odd dimensioned bitmaps, so i never noticed this.
Further bitmap info i discovered:
bytes 19 and 20 represent the horizontal width in binary. To decode, multiply byte 20 by 256 and add to byte 19.
bytes 1 and 2 = "BM" so you can test to see if it is a bitmap file.
Bytes 23 and 24 work the same way for vertical dimensions. (actually 19-23 represent , etc. but who will ever see a bitmap that big?)
byte 29 is the bitdepth.(ascii 24)
The picture starts on byte position 55.
the left over space is stored as null characters.
The size you gave will put all 3 of them at the end of each line.
so you will have your header, 765 bytes of picture, 3 null bytes, 765 bytes of picture, 3 null bytes, etc. until end of file.
However, this is easily discovered. Create a picture of these dimensions and save in the windows directory.
then do this:
open a dos prompt and from there, type this (assumes pic is named newpic.bmp):
cd\windows
edit /768 newpic.bmp
This will open the picture in binary mode in the dos text editor, which was given this ability as of win 95. Note: the editor will run under dos 6.0, so you can transfer it.
See that blank stripe straight down the middle of the screen?
That is the left-over byte region.
If someone opened a file like this and you had stored your passwords as plaintext, they would be right there to see.
Sorry for such a simple question, but how do I create a picture that is 255 * 300 pixels at 24 bit colour. Can I do it with paintbrush or do I need a graphical package?
If I understand, a picture 255 * 300 pixels at 24 bit colour depth:
54 bytes header + 230,400 bytes picture = 320,454 bytes, where 900 bytes are available for data?
Going on from this to add data to the available space, you read in the first 819 bytes (to skip the header) then add 3 bytes, then read next 765 bytes, add 3 more, etc until you reach the end of the file?
Lord Orwell, where did you find out all that info on bitmaps?
Last edited by JamesM; Mar 22nd, 2001 at 01:18 AM.
You can do it in paint. Just go to Image->Attributes... (Win98) or one of the other menus on Win95, then type in the dimensions. Then go to save as and change the format to 24bit.
What do you mean by "find"?
i "Discovered" it, through experimentation. To find the bit width sizes, i simply took blank bitmaps and resized them and wrote down the values, etc. The same image in different bit formats changed the bitdepth bit.
More interesting bitmap facts: The image is stored in the file upside down.
The reason i wanted to know all this in the first place was i wrote a program (in dos) that scanned files for embedded bitmaps. It would take an area of the file and draw it on the screen as pixels in different widths starting at whatever value i chose. Then it would try the next wider horizontal width. I kept this up until i found an image. When i did this on a bitmap file that i knew the dimensions of, that is when i discovered that the image is stored upside down. And if you have a 16 color image, each byte represents two entire pixels. Quite hard to decode (and slow in vb)
[off topic]
hehe, Lord Orwell... I had something similar a while ago.
I had a game on the Amiga called R3, I thought I'd recreate the game on the PC.
The problem was that all graphics were stored in .iff files with the header&palette missing! It took me quite a while to read the images and add headers,palette and save them out as .bmp files. But it was great fun.
[/off topic]
You can also find all info on the bmp fileformat here.
Originally posted by JamesM Just a thought perhaps it is possible to add data to the bottom of a picture, so that when opened it shows a picture, but underneath are the encrypted passwords. Anyone know if this is possible, or are there more effective ways than this?
JamesM i threw together a program over the last couple of days that works real well.
Would you like it? i attached a copy of it. despite an advanced user interface, it weighs in at a svelt 36 kb.
requires vb 5 runtime files, which come with windows.
what i originally said was, i will send you the code to your email address if the program works like you want.
I worked a little hard on the source code to post it for everyone. If anyone else uses it, how about a little feedback on the interface?
The front end version might be a good stand alone product in the future (kinda like winzip is for pkzip), but what I would be interested in as a developer is the engine, which is the cool part of the app.
So from my perspective, a dll containing the engine would be cool instead of a front end app. I think you understand what I mean?
Anyway the source would be appreciated. I'll certainly be looking to turn it into a dll to use.
Hang on I'll test the new version you have posted.
You know on the above quote. that says to use ALT-255. I just tried it because it seems very cool. It creates it fine. I am able to see it in windows but wen i try to access it tells me The folder does not exist, but i can view it in dos. What's up with that?
did you get the message box with the number? That indicates the size of the file.
Even if you enter a different file name for the file, it is saved as the original name. All you can change is the path. Try manually entering the path to your desktop and extracting again. It is also possible that it isn't putting the file exactly where you think it did. Due to some small work i need to do on the code, it might have saved it in one higher directory. Until i fix this, put a \ on the end of any directories.
your picture didn't tell me anything, until i did this:
i tried to extract from it, and it extracted the last file i saved in mine. That is when i realized that i had left debugging code in the program. It was (as you recieved it) hardcoded to a path. It is now fixed. I am sorry about any problem. It is fixed now. Redownload from the last post. I changed the attachment to a (hopefully bugfree) new version. I also modified the error checking of the main text boxes. If you even begin to type a incorrect path, it knows it. Try it and see if you type c:\winb it will trigger on the b. I might actually prevent the typing in the future.
it should let you choose the drive the bitmap you are getting from is on.
Try manually typing in the drive letter in the text box. I'll put a drive selection box on the form for the next release. Thanks for the idea. Version 1.0 did use a password. I plan on putting that in the registered version.
Reply With Quote
like a bas file from QBasic 4.5
, can I hide from dos too?
, oh well thanks all the same.
