How to secure that users does not modify files during installation?

Question

2.00/5 (1 vote)

See more:

Hi
I'm writing an installation in InstallShield and during the installation some SQL script files (*.sql) and an exe file are unpacked to a temporary location on the users harddisk. The exe file has to read these SQL script files to setup a database during the installation. I want to make sure that the user cannot grap these temporary SQL script files and modify them before the exe file uses these SQL script files. I could encrypt these SQL script files before InstallShield packs them, then let the exe file read the encrypted files and decrypt them in memory and then use the SQL script content, but what is best practice in this case?

Posted 29-Jan-16 1:17am

Henrik R L

Add a Solution

Comments

Jochen Arndt 29-Jan-16 8:12am

Why do you care about a user modifying a temporary file that exists only for a short time during installation?

Everyone who is able to do that (find the file, analyse it, modify it) should know that he is probably tampering the installation.

Henrik R L 29-Jan-16 8:24am

Because our software is validated and if the customer modify a file during installation then our softwares functionality is different from the validated version. Then the problem comes back to us. Trust and validation is everything in our business.

The customer could take a copy of the temporary *.sql and exe files and will then have the time to change the *.sql files and rerun the exe file.

Jochen Arndt 29-Jan-16 8:39am

A customer can do many things, even modifying your application executable after installation. If he does such things, your software is no longer validated and the customer knows that. How many customers do you expect to do that and complain afterwards that something is not working as intended?

However, you can make it more difficult: Move the code of the exe file to your application (optional using a library), provide a command line option to read the SQL file, and execute that as final installation step. The application can then ignore the option once the installation has been finished.

Henrik R L 1-Feb-16 2:48am

Hi
I will put the *.sql files inside a resource and compile it into the DLL.

And Yes, a customer has already changed the SQL files and run the exe. Our update tool for moving an old database backup to a new version of our software was not updating correctly. Therefore the customer ask there IT-support to find a solution so they should not run our normal software installation on the top of the backup updating tool. That way they think they could save some time and automate the upgrade/installation process. They made errors in the *.sql and our software did not work as described in the validation protocol.

Sergey Alexandrovich Kryukov 29-Jan-16 11:00am

What you describe is something opposite to trust. You don't trust the user won't refrain from modification of the files. It's funny that you even assume that customers can do that. Did you already have problems with that?

Moreover, shouldn't you always take care that nothing is changed when the product is already installed? :-)

—SA

Henrik R L 1-Feb-16 2:59am

Please see my answer to Jochen Arndt.

Richard Deeming 29-Jan-16 11:35am

What's to stop the user from modifying the database after your setup has completed, if they're that desperate to break your application?

Henrik R L 1-Feb-16 2:58am

Hi Richard

As described in my answer to Jochen Arndt our customers do things like changing something they should not. Now I will compile the *.sql files into the DLL and read it from a resource. Our software can be installed with our standard database that is protected with our secret password so the customers cannot change anything after the installation. But they tried to modify the *.sql files to automate the upgrade/installation process because we had an error in our update tool. The customer could also choose to install our database in there own SQL Server and then they can always change things but then it is not our responsibility if our software does not behave as described in the validation protocol.

2 solutions

Solution 2

As well as embedding them as resources you could get a hash value from the script somehow and your EXE will know what the hash value of the files should be and your installer with hash the files on disk and make sure the hash value is correct.

Posted 29-Jan-16 2:38am

F-ES Sitecore

Comments

Henrik R L 1-Feb-16 3:05am

I will just compile it into the DLL and read it from the resources. But I will keep the idea with hash value (checksum) in mind.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2016-01-29T02:31:00

Solution 1

You could put the SQL scripts in string resources in your .EXE. They then cannot be modified.

Posted 29-Jan-16 2:31am

Dave Kreskowiak

Comments

Sergey Alexandrovich Kryukov 29-Jan-16 11:03am

5ed, but the whole inquirer's idea looks weird; see the comments to the question.
—SA

Henrik R L 1-Feb-16 3:01am

Yes thanks Dave Kreskowiak. That will be our solution. I will put the *.sql files in the resources and compile it into the DLL.