I'd like to hide some data somewhere on the hard disk on a WinXP PC system I'll be providing to the user. This data will be used by a PB program but for security I'd like to hide & encrypt the data file so it can't be found, modified or deleted/replaced by the user (at least make it hard to do so). Most of the encryption/hiding utilities require a password to be entered to setup a virtual (encrypted) drive. I don't want to have the user enter anything (possibly revealing a clue about the setup). I've considered EFS (Encrypting File System) but I've noticed while the file is encrypted, it is not hidden (file can be replaced), so I don't want to use it.
I was thinking of setting up a hidden partition or invisible file, but I think in doing so, it makes the data file inaccessible to PB for opening/read/write. Does anyone have any suggestion for hiding PB-accessible files on a hard disk?
Thanks.
hiding a data file - how?
sorry, whatever you are coding on...
PS: If you and your program are serious, you dont need to hide any stuff ^^
a programm doing this, is a program i would NEVER use nor install on my nor any others PC! So if you want to hide your data, you can just crypt it on your own way. no need to hide any files! Hears a bit like once again someone is trying to code any spy/trojaner/virusware!? :roll:"I'd like to hide & encrypt the data file so it can't be found, modified or deleted/replaced by the user (at least make it hard to do so)."
PS: If you and your program are serious, you dont need to hide any stuff ^^
va!n aka Thorsten
Intel i7-980X Extreme Edition, 12 GB DDR3, Radeon 5870 2GB, Windows7 x64,
Intel i7-980X Extreme Edition, 12 GB DDR3, Radeon 5870 2GB, Windows7 x64,
I agree - actually I don't mind the file being out in the open (i.e. just encrypted). There's nothing malicious planned here, I want to hide it because I don't want it to be deleted by the user. So if there's a good way to make a hard-disk file non-modifiable (except for my program), I'd be pleased to hear it.
-
netmaestro
- PureBasic Bullfrog
- Posts: 8452
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
I'll be generating some rolling game data - if it gets deleted, it's a problem - so an encrypted string on a disk is no good - but the registry idea is good, but maybe not secure. [edit: on second thought, people fiddle or replace their registry - so data could be wiped inadvertently if someone restored their registry].
If it is a multi-player game then a central server should hold all the key data, and have some methods of checking against the client copy. If there is some problem (data corrupted, player maybe cheated) then the server just restores the real data. Repeated problems, kick the player! 
OTOH, if it is not a multi-player online game, ignore this completely.
OTOH, if it is not a multi-player online game, ignore this completely.
Dare2 cut down to size
-
utopiomania
- Addict
- Posts: 1655
- Joined: Tue May 10, 2005 10:00 pm
- Location: Norway
You could hide yor file as an alternate data stream and it may be possible to tack it onto the exe itself.
http://www.heysoft.de/nt/ntfs-ads.htm
http://www.heysoft.de/nt/ntfs-ads.htm
i know the idea with the streaming but i absolutly dont like this way for any program! If you are coding on a game and dont want that the user delete the files... do you really think someon who is playing your game will try to delete your files while playing... i really dislike the idea to hide datas from the user for a game or any app. :roll:
va!n aka Thorsten
Intel i7-980X Extreme Edition, 12 GB DDR3, Radeon 5870 2GB, Windows7 x64,
Intel i7-980X Extreme Edition, 12 GB DDR3, Radeon 5870 2GB, Windows7 x64,
Let's air this topic a bit. First, any file can be marked as Archived, Read Only, System, Hidden, or even as a Directory (although the last would disrupt your drive directory structure). From DOS, you can use ATTRIB to check or change the way a file is marked. From Windows, you can also change the way it is marked via its Properties.
So what does marking a file actually do? Nothing to the file, but the system software respects the markings and will ignore files marked as Hidden. Likewise, it will give you an error if you try to write to a Read Only file, and it will warn you if you try to modify or delete files flagged as Read Only or System. The weakest flag is the one for Archive, which is most commonly used to indicate that a backup program has copied this file into an archive.
Under NTFS, you also have ownership flags, similar to the concept used with Unix and Linux. Again, these flags are intended for the system to use in limiting certain types of access, presumably to make it more secure or more robust against accidental acts. But these flag states are not absolutes, they only work when the programs, applications, and users use system resources to manage those files in accordance to their purpose.
Back when most programs came on floppy disks, there was an effort by some software suppliers to create true hidden files on floppies. To do this, they adopted nonstandard methods of formatting portions of the floppy, or creating artificial defects in the way the data was stored, or even in creating floppies that were physically altered in a way to mark them as original, not copies of the program disks. Some venders even tried to find ways to use the same techniques on hard drives after they became widely available, in the hopes of preventing people from making unauthorized copies of their programs. These schemes backfired, because they caused people to quit buying any software protected by such means, and because
the errors introduced on the hard drives made them more unreliable or caused problems with drive maintenance and archival programs.
It seems that in every generation of new programmers, there is always someone that wants to know how to protect and preserve his creation so that nobody else can borrow, steal, copy, or alter it in any way. The fact
is, for most people interested in programming, few will ever achieve the
skill level or make the commitment to write a fully functional, commercially viable program. Of those that do, even fewer will find a way to market it or make any real financial gain with it, because programming and marketing involve different capabilities. So just based on percentages, there is small likelihood that anyone here is going to really need to worry about encryption or hidden files.
But if it is still your concern, there are of course many ways to make the contents of a file unreadable. There are two very simple methods that can be employed with little difficulty. The most common is the XOR function,
which requires a mask. If you look at a byte of code, and employ a mask
byte of all 1s (FF in Hex), then evey 1 bit becomes a zero, and every zero
bit becomes a 1, so something like the letter "A" (a 41 code in Hex) becomes a ">" symbol (a 3E code in Hex). Apply the same mask again,
and you get back an "A" character. The XOR function is unique in that using the same mask each time means that every other time it is restored to what it was, and the times between it is unreadable. Now knowing how a mask of FF works means that simple XOR operations look too basic,
but by changing the mask between bytes in a controlled way, you use a different bit mask on each byte, and the results look unpredictable. But
by being able to reproduce the pattern of mask changes, you are able to restore the original sequence. This makes the XOR operator unique and
almost indespensable for cypher operations.
The other simple technique is to use the rotate shift operator, where all you are doing is rotating bits within each bytem word, or long. by a certain
number of places. Like the XOR function, no information is lost, because
each bit is retained, but now in a different location. Again, the results
are that you cannot read the resulting content. Unlike the XOR function,
you now need a complementary method of restoring the contents to the original form. If you used left shifts initially, you have to use right shifts to restore, and by the same number of places. If you overlapped the
pattern of cryption, say shifting words but incrementing by bytes, so that almost every byte has been shifted more than once (and contains bits from adjacent bytes), you also have to perform the restore in the opposite
direction, meaning if the cryption was from the beginning of the file, the restore has to be from the end of the file.
Shifts and XORs are especially useful in encryption because information is not lost - it is selectively altered, or it is repositioned. You can use a combination of XOR and shifts to achieve an unbreakable combination,
because two things need to be known before the puzzle can be unravelled - they have to know the exact mask used for XOR operations on bytes,
and they have to know exactly the sequence your program uses to perform the encryption and decryption processes.
By combinding XOR with shifts, you can also make it so that you only need a small mask in order to successfully hide a huge file. The problem with any encryption program is to avoid pattern recognition. Say you took a file of 8k with nothing but spaces in it. A space has only one bit set in it,
a 20 Hex (or 32 decimal) code. What are the changes that you can write
a coding method in which you can avoid any recognize repeat of a pattern
within that length? If a pattern emerges, it gives the cryptographer an important clue as to the length or size of the mask, and it allows him to work on consecutive sections of the file cut to the same size, to detect any improved readability as he strives to uncover the secret of the mask.
To prevent this from happening, I worked out a way to use the short mask
to generate a really long mask, using other operations aside from just the
XOR and shifts. Many of these operations do not retain the original bits,
but that is not important, because I just need to go through the same process each time I want to encrypt or decrypt a file. Then I use the XOR
and shift sequences in a secret manner to change the contents of the file.
If you can make an encryption process this good, what is the point of
using a public/private key system? Simple. The use of a public and
private key method means you can securely share your file with certain
other people. But if the contents are being preserved just for your own
use, you do not need to concern yourself with public and private key
encryption methods. My limiting myself to essentially integer and string
operators, I can create a very short and fast method for protecting any
data I want, and I alone know what it is or how to retrieve it.
So what does marking a file actually do? Nothing to the file, but the system software respects the markings and will ignore files marked as Hidden. Likewise, it will give you an error if you try to write to a Read Only file, and it will warn you if you try to modify or delete files flagged as Read Only or System. The weakest flag is the one for Archive, which is most commonly used to indicate that a backup program has copied this file into an archive.
Under NTFS, you also have ownership flags, similar to the concept used with Unix and Linux. Again, these flags are intended for the system to use in limiting certain types of access, presumably to make it more secure or more robust against accidental acts. But these flag states are not absolutes, they only work when the programs, applications, and users use system resources to manage those files in accordance to their purpose.
Back when most programs came on floppy disks, there was an effort by some software suppliers to create true hidden files on floppies. To do this, they adopted nonstandard methods of formatting portions of the floppy, or creating artificial defects in the way the data was stored, or even in creating floppies that were physically altered in a way to mark them as original, not copies of the program disks. Some venders even tried to find ways to use the same techniques on hard drives after they became widely available, in the hopes of preventing people from making unauthorized copies of their programs. These schemes backfired, because they caused people to quit buying any software protected by such means, and because
the errors introduced on the hard drives made them more unreliable or caused problems with drive maintenance and archival programs.
It seems that in every generation of new programmers, there is always someone that wants to know how to protect and preserve his creation so that nobody else can borrow, steal, copy, or alter it in any way. The fact
is, for most people interested in programming, few will ever achieve the
skill level or make the commitment to write a fully functional, commercially viable program. Of those that do, even fewer will find a way to market it or make any real financial gain with it, because programming and marketing involve different capabilities. So just based on percentages, there is small likelihood that anyone here is going to really need to worry about encryption or hidden files.
But if it is still your concern, there are of course many ways to make the contents of a file unreadable. There are two very simple methods that can be employed with little difficulty. The most common is the XOR function,
which requires a mask. If you look at a byte of code, and employ a mask
byte of all 1s (FF in Hex), then evey 1 bit becomes a zero, and every zero
bit becomes a 1, so something like the letter "A" (a 41 code in Hex) becomes a ">" symbol (a 3E code in Hex). Apply the same mask again,
and you get back an "A" character. The XOR function is unique in that using the same mask each time means that every other time it is restored to what it was, and the times between it is unreadable. Now knowing how a mask of FF works means that simple XOR operations look too basic,
but by changing the mask between bytes in a controlled way, you use a different bit mask on each byte, and the results look unpredictable. But
by being able to reproduce the pattern of mask changes, you are able to restore the original sequence. This makes the XOR operator unique and
almost indespensable for cypher operations.
The other simple technique is to use the rotate shift operator, where all you are doing is rotating bits within each bytem word, or long. by a certain
number of places. Like the XOR function, no information is lost, because
each bit is retained, but now in a different location. Again, the results
are that you cannot read the resulting content. Unlike the XOR function,
you now need a complementary method of restoring the contents to the original form. If you used left shifts initially, you have to use right shifts to restore, and by the same number of places. If you overlapped the
pattern of cryption, say shifting words but incrementing by bytes, so that almost every byte has been shifted more than once (and contains bits from adjacent bytes), you also have to perform the restore in the opposite
direction, meaning if the cryption was from the beginning of the file, the restore has to be from the end of the file.
Shifts and XORs are especially useful in encryption because information is not lost - it is selectively altered, or it is repositioned. You can use a combination of XOR and shifts to achieve an unbreakable combination,
because two things need to be known before the puzzle can be unravelled - they have to know the exact mask used for XOR operations on bytes,
and they have to know exactly the sequence your program uses to perform the encryption and decryption processes.
By combinding XOR with shifts, you can also make it so that you only need a small mask in order to successfully hide a huge file. The problem with any encryption program is to avoid pattern recognition. Say you took a file of 8k with nothing but spaces in it. A space has only one bit set in it,
a 20 Hex (or 32 decimal) code. What are the changes that you can write
a coding method in which you can avoid any recognize repeat of a pattern
within that length? If a pattern emerges, it gives the cryptographer an important clue as to the length or size of the mask, and it allows him to work on consecutive sections of the file cut to the same size, to detect any improved readability as he strives to uncover the secret of the mask.
To prevent this from happening, I worked out a way to use the short mask
to generate a really long mask, using other operations aside from just the
XOR and shifts. Many of these operations do not retain the original bits,
but that is not important, because I just need to go through the same process each time I want to encrypt or decrypt a file. Then I use the XOR
and shift sequences in a secret manner to change the contents of the file.
If you can make an encryption process this good, what is the point of
using a public/private key system? Simple. The use of a public and
private key method means you can securely share your file with certain
other people. But if the contents are being preserved just for your own
use, you do not need to concern yourself with public and private key
encryption methods. My limiting myself to essentially integer and string
operators, I can create a very short and fast method for protecting any
data I want, and I alone know what it is or how to retrieve it.
has-been wanna-be (You may not agree with what I say, but it will make you think).
va!n, please get over it - you've already voiced your concern, and I've addressed it, and you're saying it again. There are silly users out there, and I'm trying to address the issue the most elegant way possible, without malice.i really dislike the idea to hide datas from the user for a game or any app
Last edited by mskuma on Tue Jun 06, 2006 11:43 pm, edited 1 time in total.
Well since I told it to don't hide them anymore it doesn't otherwise it would^^ since I'm using Linux now it's even simpler since I only have to use ls -a instead of normal ls for hidden files...
Visit www.sceneproject.org