Hiding a data file from users

Stephen Hewitt

Another alternative would by to put the data in the .EXE as a resource. Steve

Maxwell Chen

Stephen Hewitt wrote:

Another alternative would by to put the data in the .EXE as a resource.

If the data is increasing, the EXE increases the size then? (I guess YES.) 2) Personally I think that if the data size is relative too large (for ex: 800 MB), it would be not suitable to merge in EXE.

Maxwell Chen

Hamid Taebi

I think yes increasing and I suggest use from one algorithm coding

Maxwell Chen

My point is: Let's say the EXE is now 800 MB as we use a smart algorithm to manage the resource in EXE. But launching the program might take maybe 5 seconds because we used to have the anti-virus installed. And there is the On-Access scan.

Maxwell Chen

Hamid Taebi

but why should exe file 800 MB? you can break this exe file to a little files ( I suggest dll) I think that its not idea exe 800 MB, right?

Maxwell Chen

You did not follow our discussion. Stephen suggested to put the original poster's data in the resource portion inside the EXE. Let's say, the real executable code of the EXE is just 2M in size (which should be average); user keeps adding data (thus into the EXE) (for example: all those TEL numbers from a phone book). It results in a 800 MB sized EXE file. :-D

Maxwell Chen

Hamid Taebi

yes I see suggestion Stephen and I agree with you that we have increasing oh yes you said if we enter data to resource we have a big file :-D

Maxwell Chen

Stephen Hewitt wrote:

Another alternative would by to put the data in the .EXE as a resource.

Another issue is: We have to export the data (separate the data from EXE) before we upgrade / replace the EXE.

Maxwell Chen

led mike

chasetoys wrote:

someway of locking the file from the user?

Sure there are potentially many ways to do that. While I would not advocate using any of them I can discuss it. One technique would be to use a Database type design for your application. You would build a Windows Service to do all the file IO and use IPC to communicate between the application and the Service. This way the Service is always running and has the file opened without sharing so no other process can access it. Of course the user can always stop the service and then access the file. The user does control the computer and if they know how the can access the file regardless of what you might do. About all you can do is make it harder for them. Of course doing that makes it harder to develop the application since more work must go into it. More analysis, design, testing, maintenance, support etc. You might want to reconsider and stick with hidden folder and file attributes.

"What classes are you using ? You shouldn't call stuff if you have no idea what it does" Christian Graus in the C# forum led mike

Phil C

After reading all this, I think you should: A) Just make the File Read-Only after your program closes it. This will keep a casual user from accidently damaging editing it. If they actually reset the read-only flag and then edit it, then they are determined and sophisticated enough that they can damage anything if they want to. B) Make a backup copy of the file when you close your program. Put it in the Windows/System folder or somewhere similar. Yes, this will take up an additional 800 MB of extra data, but if you're worried about data integrity and safety there really is no substitute for making a backup and HD space is cheap. When your program starts back up, check the data file against the copy, if you see any differences then you know someones been messing with it and can take action. I never cared much for trying to use Hidden files. I tried it a couple times in the past, and inevitably got a tech support call later and when I needed them to go look for, find and tell me something about that hidden file I had a heck of a time explaining to them how to "unhide" that file. (imagine a 5 second question over the phone "You're out of disk space? What's the size of the MYDATA.DAT file?" becoming a 30 minute long lesson in Windows File attributes and how to change them) Good luck, don't forget...KISS.

chasetoys

Great advice Phil thanks! A couple of clairifications: 1) Would you advocate combining methods both A & B? 2) Would you just replace the tampered file with the one you have in the Windows directory? 3) Does Windows allow you to use the WriteFile API to write in the Windows directory? I tried to do that once but couldn't... i.e. where would you put the bacakup file, and are you sure Windows lets you do that? 4) Is there a simple API to encrypt/decrypt an ASCII text file? Or is KISS more important here? Thanks!

Maxwell Chen

chasetoys wrote:

Would you advocate combining methods both A & B?

It's by design. Feel free to use what you prefer.

chasetoys wrote:

Would you just replace the tampered file with the one you have in the Windows directory?

Please elaborate more detail. Not really understand what you mean.

chasetoys wrote:

Does Windows allow you to use the WriteFile API to write in the Windows directory? I tried to do that once but couldn't... i.e. where would you put the bacakup file, and are you sure Windows lets you do that?

A) It may be the privilege issue. The program is run as the role of "User" instead of "Administrator". B) Or maybe you did something wrong. Show us your code snipet about creating / writing files.

chasetoys wrote:

Is there a simple API to encrypt/decrypt an ASCII text file?

Yes, there are some algorithms for this job, for example: DES, 3DES, AES, RSA, BlowFish, SawFish, etc. You can find those source code of the algorithms by Googling.

Maxwell Chen

Phil C

1)From what you described as your requirements I'd do A and B, yes. 2)That depends on what you anticipate the reason for the tempering. I'd probably start out with a messagebox to the user if you detect something wrong. something like: The database appears to have been changed or corrupted since the program was last run. Rebuilding Database, MB_OKCANCEL This way, the user at least has an option and has been warned that he may have completely screwed things up when he fooled around with your file. As I said, if he's sophisticated and determined enough to set the read-only attribute to false, then edit the file and finally to ignore the warning message you gave him, there isn't much you can do to stop him and there may be a legitimate reason for him to do it so you can only do so much. 3) Yeah, you're right, I think there is some permission thing that XP has. OK fine, don't put it in Windows\System, but I think there's another separate "Application Data" folder somewhere that's been designated for this type of use. You should be able to find a place, just putting the copy in a completely different folder goes a long way to making thngs more secure both from a tampering issue and crash-proofing. 4) I think someone else already answered this, yes there are ways. Personally I wouldn't bother. You mentioned that your data file can get fairly large. Whatever you do to encrypt/decrypt it will cause things to slow down, introduce bugs and will probably have a lot of other drawbacks too. ie. what if YOU want to edit the file to check for bugs, problems during development? If the thing is unreadable you are only making things harder on yourself. On the other hand, if you really really don't want anyone to see what's inside (prevent unwanted reverse engineering for example) then maybe it's worth all the extra time and trouble. This one is really something only you can answer. Good luck :)

cmk

You could also use a different stream in the file to write the additional information. To use streams you can either use NtQueryInformationFile (in ntdll.dll), or the Backup*() functions. e.g. http://www.sysinternals.com/utilities/streams.html[^] http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/backup/backup/backup_functions.asp[^] http://www.codeproject.com/csharp/CsADSDetectorArticle.asp[^] ...cmk Save the whales - collect the whole set