I have a customer using Host Intrusion Protection and has set every User's temp folder not to allow execution (C:\users\\AppData\Local\Temp). NSIS extracts all plugin dlls and its own dlls into a folder below %TEMP%. The problem is nothing is allow to execute from temp so the entire install fails. What I need to know is how to tell NSIS to use a different folder. The only work around I can find is to edit the TEMP and TMP values under the registry key HCU\Environment from "%USERPROFILE%\AppData\Local\Temp" to something like C:\NSISTEMP. However even though this works changing the registry and then putting it back is not really an option. I also cannot just redirect InitPluginDir as that only effects plug-ins and not the rest of what NSIS extracts (icons xml files etc...). Any ideas?s
You can set %TMP% in a terminal/console window before running the installer, there is no need to edit the registry.
In NSIS v3+ you can use UnsafeStrCpy:
Function .onInit
UnsafeStrCpy $Temp "c:\foo\bar"
CreateDirectory "$Temp"
FunctionEnd
The real problem is the security "solution", why would preventing execution from %Temp% but not from other directories really provide any protection after the bad guys find out about this restriction?
If the installer is started with the special _?=$InstDir parameter then it is not copied to %Temp%.
Try this (look for more info in documentation) maybe it is safer than overriding $Temp folder and so on.
Related
I have seen this was asked in the bask back in 2008 and can't find anything newer on the subject so I am bring it up again.
Is there a way to prevent a user from extracting the files from the installer and reading the nsi file.
I read something the opcode needs to be changed in the exe of nsis. Has NSIS come up with a plugin or something so users do not have to modify the exe?
If there an easy way or is it still messing with the exe. and if so can you point me in the right direction on how to do this or if someone has already posted a version
Thank!
NSIS is open source so it is not unsurprising that people are able to write decompilers.
There is no easy way to prevent it and the recommended method is still the same; change the order of the opcodes in \Source\exehead\fileform.h and compile NSIS.
To prevent most people from getting access to your files you can use one of the zip/7z/rar plug-ins from the NSIS Wiki that accepts a password and include a password protected archive in your installer. Keep in mind that a sophisticated user can run the installer in a debugger and find your password when you call the plug-in to extract the files.
I want to report to a Web Service whether the installation completed successfully or not. The identifiers that need to be passed to the service are stored in an uncompressed text file along with the other (compressed) files. Everything works on a successful installation, but when the user cancels the installation, no files are extracted (as expected) and I am unable to find a way to extract a specific file from the archive.
I have considered some other options (writing a custom plugin, parsing through the installer executable file), but I hope there is a cleaner solution.
You can extract files at any point in the installer, in your case probably in .onInstFailed or .onUserAbort:
Function .onInstFailed
InitPluginsDir
SetOutPath $pluginsdir
File something.ext
; Do something with "$pluginsdir\something.ext"
; Note: $pluginsdir is automatically deleted when installer quits...
FunctionEnd
I have an installer working with NSIS that I'm updating at the moment. At several points, the installer needs to configure packages by replacing paths or values inside configuration files. Those configuration files have placeholders in them that are replaced by whichever deployment tool I'm using (NSIS for this specific case).
Scripts are mostly PHP scripts written to do some simple tasks that would have been excruciatingly complex in NSIS. For some reason though I keep going back to making my PHP scripts replace the placeholders by themselves instead of doing it in the NSIS script, which just isn't right.
My code looks like:
nsExec::ExecToStack '"$INSTDIR\Php\php.exe" "$INSTDIR\Apache\tools\findport.php"'
pop $1 ; return code
pop $2 ; port number
!insertmacro _ReplaceInFile "Apache\conf\httpd.conf" "APACHE_PORT" "$2"
The _ReplaceInFile macro comes from http://nsis.sourceforge.net/ReplaceInFile and works just fine if I use $INSTDIR instead of $2 in the above example. Showing $2 in a MessageBox shows the port number just fine.
I guess I'm doing something wrong but I can't figure out what it is, and debugging is a pain with NSIS.
Thanks,
I guess the lesson is to always verify paths before blaming the utility functions (Using Process Monitor is a good idea so you can tell if file-system redirection is getting in the way)
I would also like to add that using $instdir to hold anything other than a path is not a good idea since it will strip away invalid path characters behind your back. Use a normal register or a custom variable...
Could any one clarify me that, when uninstalling I need to delete everything form the Installation folder except the License file. How can I do it with NSIS scripting?
Thanks
Regards,
RoboAlex.
Instead of opening the file, as in Anders' third point, I'd do it this way:
Rename $INSTDIR\license.txt $PLUGINSDIR\license.txt
RMDir /R $INSTDIR # Remembering, of course, that you should do this with care
CreateDirectory $INSTDIR
Rename $PLUGINSDIR\license.txt $INSTDIR\license.txt
Depending on when it gets to the file it can't delete, RMDir /R may leave most of it behind, as I believe it will stop when it can't delete something; this way will get rid of it all properly. This will also lose the directory stats, but that's probably not important.
I'd recommend one of Anders' first two solutions over this, though. They're more precise.
Off the top of my head, there are 3 ways to do this:
Use Delete on one file at the time on a list generated at compile time with !system etc
Use FindFirst/FindNext/FindClose at runtime and Delete everything except the license based on filename
A bit of a hack, but you should be able to open the license file for write/append, then Delete/RMDir will not be able to delete the file since it has a open handle.
I wanted to write an NSIS script, let's call it for now setup.nsi, and check
if several required dll files already exists in $SYSDIR
Let me emphasize on the word "several"
What I understand from nsis IfFileExists documentation is that if I type in:
IfFileExists $SYSDIR\blabla.dll +2 +1
then it checks if blabla.dll is in $SYSDIR .. but what if I want to know if *.dll from where setup.nsi copies the file (i.e. the *.dll's that I am interested in installing in.. and they are a lot of them.. so I can't just go around checking for all the names) exists in $SYSDIR
During uninstallation I want to then be able to delete them from $SYSDIR (using some uninstall.log to see if I really copied them in $SYSDIR.. and again the wildcard question).
Please be patient with me as I am really new to NSIS scripts.
Is it REALLY necessary to write and delete in $SYSDIR ? Unless yours is a system file, there's no reason for it to be in $__SYS__DIR. If you need to use a specific version of a library, consider DLL redirection (put your DLL in your app dir and use the .local feature) - see the MSDN article on DLL redirection and Side-by-side assemblies.
Plus, you are one typo away from wrecking the user's computer ("Deleted: C:\Windows\System32\user32.dll").
As Piskvor mentions, I don't think you should be worrying about deleting system DLLs in the uninstaller. In case you want to overwrite system DLLs with an updated version, you may want to look at the SetOverwrite command. It lets you overwrite files if what you've got is newer.
Windows XP (SP2?) and up has file protection for system32, so you can't overwrite system critical files in there.
Do try to stay away from that.
Also, to check for your file specifically, see if there's a plugin for NSIS that can calculate checksums and compare that on uninstall. That's probably the safest, IF you really need to do it.
I'd suggest install files somewhere else and add that to PATH.