This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Managing some files outside MSI package
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Aug 24, 2014
09:58 AM
Managing some files outside MSI package
Hi everybody, I’m a newbie at installshield so I hope my question is relevant to this forum.
I’ve got basic MSI installation made by install shield, which installing our company’s product.
Today, the installation is packing within the MSI file all the relevant files needed for successful installation, (e.g. our executable, some scripts, and some data files – mostly text ones).
The problem is that ‘Data’ file is changing rapidly, meaning it can be changed every few hours, while all other files remains the same (changes only once a week or so),
Since all files are packed inside the MSI file, there is a need to rebuild MSI each time the data changes.
We wish to separate this operation, so ‘Data’ files can be changed without issuing new MSI each time.
The problem is that we don’t want to just put the accessible ‘Data’ text file in the same folder as the MSI executable to prevent from users to change it.
What are my options to pack and/or encrypt all those ‘Data’ files ?, that it can be changed quickly, but will not be accessible to anyone, but the MSI installation will be able to extract and read them ?
Maybe some Binary conversion ? Of cause that zipping and similar archiving is not good (most of advanced users can overcome password protected archiving very easy).
Thanks in advance, Gil.
I’ve got basic MSI installation made by install shield, which installing our company’s product.
Today, the installation is packing within the MSI file all the relevant files needed for successful installation, (e.g. our executable, some scripts, and some data files – mostly text ones).
The problem is that ‘Data’ file is changing rapidly, meaning it can be changed every few hours, while all other files remains the same (changes only once a week or so),
Since all files are packed inside the MSI file, there is a need to rebuild MSI each time the data changes.
We wish to separate this operation, so ‘Data’ files can be changed without issuing new MSI each time.
The problem is that we don’t want to just put the accessible ‘Data’ text file in the same folder as the MSI executable to prevent from users to change it.
What are my options to pack and/or encrypt all those ‘Data’ files ?, that it can be changed quickly, but will not be accessible to anyone, but the MSI installation will be able to extract and read them ?
Maybe some Binary conversion ? Of cause that zipping and similar archiving is not good (most of advanced users can overcome password protected archiving very easy).
Thanks in advance, Gil.
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Aug 25, 2014
03:02 PM
Hi Gil,
It sounds like you have a MSI installer that has two major features: Application, Data. The data exists as text files that you do not want the end user to modify.
You do not say what type of media you will be using to deliver the package. However, a Setup.exe package or a DVD package can include files that are on the 'Media'. During install you can simply move the files from the 'Support' directory, or in the case of DVD media, from the DVD media to the target directory. Handling the data files in this manner will allow you to simply update the data files with some other mechanism. Note that I believe a hot-fix/ small update would do the same, but you are compiling some type of MSI process.
As far as I know, MSI is not a good medium for encrypting or decrypting files. If your company requires files that cannot be modified by an end user then they need to look at the configuration of their data files. They should be binary .dat files rather than plain text .txt files. I would guess this should occur on the development side. Security should be something that is planned as a core element of the application, not something that is injected inside of an installer.
Now as for security, someone can always find a way to determine where your text files are installed, simply by logging the install and reading the MSI log file. Source paths and target paths are reported in the log file. You could mask this with a custom action that moves the files for you, but you would have to find a way to inject the target path without the logger knowing that you passed a parameter to the custom action.
It sounds like you have a MSI installer that has two major features: Application, Data. The data exists as text files that you do not want the end user to modify.
You do not say what type of media you will be using to deliver the package. However, a Setup.exe package or a DVD package can include files that are on the 'Media'. During install you can simply move the files from the 'Support' directory, or in the case of DVD media, from the DVD media to the target directory. Handling the data files in this manner will allow you to simply update the data files with some other mechanism. Note that I believe a hot-fix/ small update would do the same, but you are compiling some type of MSI process.
As far as I know, MSI is not a good medium for encrypting or decrypting files. If your company requires files that cannot be modified by an end user then they need to look at the configuration of their data files. They should be binary .dat files rather than plain text .txt files. I would guess this should occur on the development side. Security should be something that is planned as a core element of the application, not something that is injected inside of an installer.
Now as for security, someone can always find a way to determine where your text files are installed, simply by logging the install and reading the MSI log file. Source paths and target paths are reported in the log file. You could mask this with a custom action that moves the files for you, but you would have to find a way to inject the target path without the logger knowing that you passed a parameter to the custom action.
