Printable View
I have a list of passwords. I don't want anyone to be able to add to this list or find it.
I can encrypt the file.
What other steps can I use to stop people from recognising it as a list of passwords?
There must be some cool ways of hiding files from systems?
to do this... go to Start-->Run-->Command.com
and type rename C:\folder C:\<ALT-255>Folder
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:D like a bas file from QBasic 4.5:D.
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.
Regards
E.P.
L0phtpDK,
That really works :), can I hide from dos too?
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:D
Regards
E.P.
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.
more info about image cryptography: www.blindside.co.uk
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?
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...Quote:
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?
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.
Gerco.
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.
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.
Gerco, could you post some code to show me how to accomplish this with a gif or even how to do it with a bmp?Quote:
On the other hand, the gif fileformat allows for plain text to be stored inside the image file.
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)
I'd love to but I don't have a clue. Gif Construction Set can do it, but I haven't a clue how.Quote:
Originally posted by JamesM
Gerco, could you post some code to show me how to accomplish this with a gif or even how to do it with a bmp?
You are right Lord Orwell... I was thinking about the palette!
The palette has an extra byte for each color value in it. It's stored in the BMP file in this form:
Gerco.Code:typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
in 32-bit pictures, the 4th bit is some sort of chroma bit. It may be for setting transparency or something. Quite confusing.
Wasn't there an Alpha-Blending byte somewhere as well? Or is that the fourth byte?
Gerco.
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?
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.
Gerco.
JamesM i threw together a program over the last couple of days that works real well.Quote:
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?
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.
Thanks Lord Orwell, I'll give it a try tonight :D.
Oh it is only an exe :(, oh well thanks all the same.
i have to know if you plan on distributing anything made with it though.
If so, i would expect some mention in the help.
Give me your email address and i'll send you something.
???
lost a post.
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?
(sigh) found a major bug (again). New version as of edit time attached :(
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.
Lord Orwell,
I can encode the bitmap, but can't extract it. The save path doesn't seem to be working :(.
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.
This is what I mean Lord Orwell. After selecting the bmp with message in it, I select extract to say c:\, then I get a message "path not found".
See attached.
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.
Cool app :D:D:D, can I have the source or are you going to release a dll for developers to use? My email is [email protected]
BTW, when restoring the file I can't browse between drives.
Also, suggestion (not vital) adding a password to only allow user with password to be able to extract the text file.
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.
I'll send you the code in a little while.
Why a drivelistbox?
The GetSaveFileName() API is almost perfect for the job.
Gerco.
the answer is simple.
I am only interested in the path and directory.
the GetSaveFileName api makes you enter a file name.
This is pointless since the filename is stored in the file, and you can't change it. i won't let you :)
So given this information, you can see that a dirlistbox and a drivelistbox is perfect.
By the way, i use that api call in the program also. All of the common dialogs are called with api.
Then use the SHBrowseForFolder API. That will show the standard "Browse for folder" dialog box, that's what you need :D
Gerco.
i don't have a prototype of example of it. Plus it wouldn't do me any good. I use the api for the common dialogs to remove need of an .ocx. The drive and dirlist controls don't require an .ocx.
Neither does the SHBrowseForFolder API:
Do note: it's not my code.
can someone post a the source code to place text into a bmp and read it later
there was some problem with your upload? the .bas was empty.
Anyway like i said, i only use api when i need to, or i get a speed increase. I like my code to keep a semblance of readability when possible. The dirlist box and drivelist boxes only added about 10k with support code and another form. I have more control with a custom setup like mine anyway. For example, the text box at the bottom in a future version will have active path checking and will actually PREVENT you from typing a letter that will lead to an illegal path.
The main text boxes already have a feature similar, but they don't actually prevent the typing, they just change the background to red.
Create your own UDT and encrypt the password and store as binary format will be safe :)
example:
Code:Private Type My_UDT
Username As String * 15
password As String * 15
End Type
Private up As My_UDT
Private Sub UpdateFile()
Open "C:\1.dat" For Binary As #1
'//Encrypt Data
Encrypt up.Password
Put#1, 1, up
Close #1
End Sub
Private Sub Encrypt(ByVal lpSource As String)
'//Add your encryption algorithm here
'//Or try out my encryption ActiveX DLL at my home page
End Sub
'Code improved by vBulletin Tool (Save as...)
if you wish to have a 128bit data encryption, take a look on the CryptoAPI :)
hmm strange... here it is again.
And you cannot select a not-existing folder with this either, just call the BrowseForFolder function. no manual API needed, it's in the function.
I agree that inline API is ugly, which is why I always encapsulate it into subs and functions, unless speed is critical, which it never is.
Gerco.
you can't with the directory box either. Look at my implementation. I have a manual entry box at the bottom. As you type the directory, it automatically sends the directory and drive boxes to that path, and it won't let you type a fake one. Obviously, you can use the dirbox instead of typing... That is why i did it that way. But i will check out the new upload and learn from it :)
Hmm that box has network support. Looks like i'll be changing my code :) It looks better also.
Thanks for the code.