Users are inherently DANGEROUS !

[Dan Bookwalter]

Without getting into too much detail .... i have a application that uses definition files , cal files and run files , these files are for the most part human readable , one of them i resorted to XML in the hopes of keeping the user from messing around with it... short of hiding or encrypting these files does anyone have a good way to keep the users from f***ing up my programs ?? sorry about the language but this is really starting to piss me off !!! there is no need to open these files outside of my application but they keep messing with them...

the quote below is being highly re-inforced over here lately!!!!!!

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.(Rich Cook)"

Dan

[crelf]

Without getting into too much detail .... i have a application that uses definition files , cal files and run files , these files are for the most part human readable , one of them i resorted to XML in the hopes of keeping the user from messing around with it... short of hiding or encrypting these files does anyone have a good way to keep the users from f***ing up my programs ??

Hey Dan - my first response is "go binary!", but if you must stay ASCII, add a line to the end of the file that does some sort of checksum (I'm sure plenty of other LAVAites will suggest checksum algorithms) - then when your SW changes the file it can update the checksum, and whenever you read it you check the checksum and if it doesn't add up then display a "naughty naughty!" message to the user - something about the file being corrupt. You can go even further (depnding on the user smarts) and encrypt the checksum (I could go on and on and on)...

[robijn]

i resorted to XML in the hopes of keeping the user from messing around with it...

You could XOR with some wel chosen value. You could use ROT13, base64 encode....

Indeed some users always find a way to mess up a good system. Their computer license should be revoked.

Joris

[Dan Bookwalter]

Hey Dan - my first response is "go binary!", but if you must stay ASCII, add a line to the end of the file that does some sort of checksum (I'm sure plenty of other LAVAites will suggest checksum algorithms) - then when your SW changes the file it can update the checksum, and whenever you read it you check the checksum and if it doesn't add up then display a "naughty naughty!" message to the user - something about the file being corrupt. You can go even further (depnding on the user smarts) and encrypt the checksum (I could go on and on and on)...

well binary was my first thought and i think more than likely that is the route i will go , you would think that they would learn after a couple of times , but , they dont... i would rather keep them readable so i can debug them if needed , but , it is causing so many problems i need to do something..

thanks

Dan

[Michael Aivaliotis]

well binary was my first thought and i think more than likely that is the route i will go , you would think that they would learn after a couple of times , but , they dont... i would rather keep them readable so i can debug them if needed , but , it is causing so many problems i need to do something..

thanks

Dan

Yes, it's always a trade-off. You need to view the file easily, but that means others can as well. One workaround is to come up with an encoding scheme that takes the text file and scrambles it just like robijn mentions. Then you should create a decoding tool\VI that you can run independantly of your main app. You can call it Dan Bookwalter's super duper general all-in-one decoder encoder tool. You can use this tool every time you need to view\edit\change these "special" files.

I would suggest sticking with text instead of binary. The nice thing about text is it can be parsed and data can be extracted in a variety of smart ways. It also allows abstraction of the data file from the code that actually generates the data.This is why XML is powerfull. Don't use XML just for obfuscation or security. Use an encoding algorithm for that.

[Chris Davis]

well binary was my first thought and i think more than likely that is the route i will go , you would think that they would learn after a couple of times , but , they dont... i would rather keep them readable so i can debug them if needed , but , it is causing so many problems i need to do something..

thanks

Dan

The casual user might be detered by changing the extension from an easily open file type. You mention that one is an XML file, but you could always rename it something like .mysettings or even hide them using the operating system's hiding capabilities ( assuming that the user hasn't turned that option off! )

Chris

[Gary Rubin]

The casual user might be detered by changing the extension from an easily open file type. You mention that one is an XML file, but you could always rename it something like .mysettings or even hide them using the operating system's hiding capabilities ( assuming that the user hasn't turned that option off! )

In addition to using a different extension, you could also try starting the filename with a ~, the way MS-Office names files that are in use. It obviously won't prevent anyone from being able to modify things, but maybe they've already been trained by MS to keep their hands off things that look like system files.

edit: Or make the files read-only, and change that programmatically when you have to modify them within your code? I've never tried this, but I assume it could be done.

Gary

[LAVA 1.0 Content]

short of hiding or encrypting these files does anyone have a good way to keep the users from f***ing up my programs ??

It seems to me that some sort of "encryption" will be necessary.

I haven't used the technique, but there was a section (6.3) in "A Software Engineering Approach to LabVIEW" that discussed this EXACT problem, and presented a solution. You can download the examples from the book HERE. You would be interested in the CONFIG INI code.

The idea is to replace the Config Data Read & Write vis in the Open Config Data and Close Config Data vis with the encrypted versions (downloaded from above).

Maybe you could leave the NI libs alone and create a private version of the Open Config Data and Close Config Data vis. You could use case statements that key off of the Application:Kind property to select between using the unencrypted NI Open and Close INI vis during development and the encrypted when called from the runtime engine...

[Aristos Queue]

If the code that uses this text file is written in LV, then how about putting the text file into a string constant on a VI and password protect the block diagram. Instead of using a text file, call LV to get the text. If you need editing capacity, then this isn't as helpful.

You could hide your entire block of text by writing it into the LabVIEW .ini file.

I'm trying to think of some clever way of using LV to solve this issue... not much I can suggest if you're not in a development environment. We leave out all of our "save" capacities in runtime engine.

[crelf]

If the code that uses this text file is written in LV, then how about putting the text file into a string constant on a VI and password protect the block diagram. Instead of using a text file, call LV to get the text. If you need editing capacity, then this isn't as helpful.

...unless you script it Either way, I think a binary datalog file would be easier to impliment.

[Aristos Queue]

...unless you script it Either way, I think a binary datalog file would be easier to impliment.

Scripting only works in a dev environment, not the runtime engine.

[i2dx]

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.(Rich Cook)"

whow

maybe you want to obfuscate your data with a simple XOR encryption?

this will prevent allmost all users from playing arount with the file, ony the nerds, will take a deeper look

cheers,

CB

Download File:post-885-1160778175.vi

[Jacemdom]

Without getting into too much detail .... i have a application that uses definition files , cal files and run files , these files are for the most part human readable , one of them i resorted to XML in the hopes of keeping the user from messing around with it... short of hiding or encrypting these files does anyone have a good way to keep the users from f***ing up my programs ?? sorry about the language but this is really starting to piss me off !!! there is no need to open these files outside of my application but they keep messing with them...

the quote below is being highly re-inforced over here lately!!!!!!

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.(Rich Cook)"

Dan

If you are under a windows network, I think it would be possible to put your files in a folder that you have access and that they don't. You could probably make your app run under this user also with a "run as.." thing. I don't know why it could not work in other networks also (Novell, Linux...).

[rkanders]

I would go with MD5 hash and have the application use default values when file is corrupted.

I usually setup my INI file routines to have some means to validate and check for missing keys or at least sections and replace missing/corrupt items with default values stored in separate INI cluster. I use modded OpenG INI routines.

Reinis

[crelf]

Scripting only works in a dev environment, not the runtime engine.

Really? I can't create, edit and save an external VI from a process in an exe?

[Yair]

Really? I can't create, edit and save an external VI from a process in an exe?

There are various kinds of options which are not supported in the RTE (methods and properties have a table in their help page which also says whether they're available in the RTE). At the very least, the RTE can not recompile a VI and can not call the Save Instrument method. Supporting those would make the RTE bigger and would make LV "less necessary". Since there is no need for them in the RTE, it probably can't access all the diagram properties, etc., but I didn't check that.

One option which would have been cool if the RTE could save VIs is using VI tags to save the configuration data (you can basically save a series of named variants inside a VI by using the tag methods. See Dataact's site for an example). Unfortunately, that can not be done in the RTE.

[crelf]

At the very least, the RTE can not recompile a VI and can not call the Save Instrument method. Supporting those would make the RTE bigger and would make LV "less necessary". Since there is no need for them in the RTE, it probably can't access all the diagram properties, etc., but I didn't check that.

There you go - you learn something new every day I had dreams of creating my own "thingy-builder"-style interface where my app (running as an exe) could be used to define a process, and then I could dynamically build the VIs required to do it - just like the old Vision Builder did... (or still does?)

[Aristos Queue]

Really? I can't create, edit and save an external VI from a process in an exe?

That's correct. In fact, you can't create, edit, or save in an exe (ah, boolean logic jokes...)

[crelf]

That's correct. In fact, you can't create, edit, or save in an exe (ah, boolean logic jokes...)

*sigh* I think it's time you got a hobby Stephen!

So how does Vision Builder do it?

[Chris Davis]

*sigh* I think it's time you got a hobby Stephen!

So how does Vision Builder do it?

I think aspect of Vision Builder you are thinking about is its LabView code generation. I think this is doesn't work if one doesn't have LabView installed alongside Vision Builder. I haven't used Vision Builder in a long time, so I'm not an expert on it.

[crelf]

I think aspect of Vision Builder you are thinking about is its LabView code generation. I think this is doesn't work if one doesn't have LabView installed alongside Vision Builder.

Ah - I see. So I can script up a VI from a built exe, but I've got to do it through the LabVIEW developement environment. That's cool - for the "builder"-style applications I'm thinking of, I don't think I'd ever want to create a VI for someone unless they had LabVIEW installed anyway

[Mads]

I normally use readable files for configurations and the philosophy is that if a user wants to screw up the system he will be able to anyway (if he is not able to read the content of a file he can still change or delete it so encryption is not much help), the only important thing is to prevent him from doing so by accident. If he does delete or edit a file intentionally then that's his fault, not the software (you have to draw a line of responsibility somewhere).

You can off course reduce the risk by making the files less accessible and/or make the content look less tempting to edit (adding warnings within the files is an option). If possible the software should also be able to detect and filter out invalid configurations. I store most configurations in the Applications Data folders. The only time I use encryption is when I store information that needs to be secret (like passwords, proprietary parameters etc.).

Mads

Without getting into too much detail .... i have a application that uses definition files , cal files and run files , these files are for the most part human readable , one of them i resorted to XML in the hopes of keeping the user from messing around with it... short of hiding or encrypting these files does anyone have a good way to keep the users from f***ing up my programs ?? sorry about the language but this is really starting to piss me off !!! there is no need to open these files outside of my application but they keep messing with them...

the quote below is being highly re-inforced over here lately!!!!!!

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.(Rich Cook)"

Dan

[Dan Bookwalter]

I normally use readable files for configurations and the philosophy is that if a user wants to screw up the system he will be able to anyway (if he is not able to read the content of a file he can still change or delete it so encryption is not much help), the only important thing is to prevent him from doing so by accident. If he does delete or edit a file intentionally then that's his fault, not the software (you have to draw a line of responsibility somewhere).

You can off course reduce the risk by making the files less accessible and/or make the content look less tempting to edit (adding warnings within the files is an option). If possible the software should also be able to detect and filter out invalid configurations. I store most configurations in the Applications Data folders. The only time I use encryption is when I store information that needs to be secret (like passwords, proprietary parameters etc.).

Mads

ARRRRRRGHHHHHHHHHHHHHH.....

i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... rather than go through all the hassles of changing everything over to hidden and encrypted files i have decided to play games with the techs and put the burden back on them... i am simply going to add a checksum to the end of each file and check it when the file is loaded , if they dont match they will gete a message that the file has been changed and is now corrupt and a new file must be created etc... that way THEY have to go through tthe hoops and not me....

Dan

[Grampa_of_Oliva_n_Eden]

"Nothing is fool-proof for a clever fool."

How about using the system registry to save the INI data AND Checksum the section?

Ben

[i2dx]

How about using the system registry to save the INI data AND Checksum the section?

on the one hand, this a good idea, on the other hand, it is not, because, you add some extra difficulties to your development:

during development, it's easier to open an *.ini file with the notepad and edit some entries, than open regedit and edit data stored in the registry.

if your software is in production, it is easier to request someone, "plz send me the *ini-file, I need to see your settings" than to request an export from the registry.

maybe a combination of *.ini file and registry would be a good solution: when closing the programm, make a MD5 hash and store that hash in the registry. Then you can detect any changes and display a "corrupt file" message !?

cheers,

CB