How to prevent files extraction from an Installer created with NSIS?

Originally Posted by Anders View Post

The difficult part would be patching the exehead when compiling, after all, if we embed the EW_ file as a resource it can just be extracted...

Embedding the EW_ file in makensis.exe or directly in generated installer?
I think if it is embedded in makensis then it will become invisible in generated .exes (but 7zip author still can download the makensis and look at it - this is why I prefer random values).

I started to play with makensis and disassembler and I got another idea:
Enums in C++ are translated as integers => every enum occurrence in source files is (during compilation) replaced by some int value.

What if I find that integer value (e.g. EW_EXTRACTFILE it is 20) and replace it with different?
In disasm that is only instruction like mov reg, 0x0000value.

So I could find e.g. EW_CHDETAILSVIEW and replace it with EW_EXTRACTFILE values.

This should, work, shouldn't it? Is single change enough?

No matter how you look at it you need to replace the values used in the generated installer, in both the exehead instruction decoder which is just a big switch statement and also in the instructions generated by makensis. The last part is easy of course, the tricky part is changing the exehead, you cannot just use a simple search and replace. MakeNSIS would have to know the offset of the switch statement inside the exehead stub and even then it is tricky. The C compiler is free to generate a jump table for the switch or just a bunch of "if" branches. When you also take into account that we have multiple exeheads (12 in NSIS v3, even more if you count the special builds and 64-bit) and these exeheads can be compiled with all the different compilers we support: VC6, VC2003...2015 + GCC on Windows and cross compiling on POSIX plus the unofficial support for Borland C++ etc. you can see that supporting this if it is not automated would be impossible.

I'll finish with a personal statement (which may not represent the views of the NSIS project nor its other contributors): I personally like the fact that 7zip is able to decompress our installers. Sometimes it is handy to just grab the single file you need instead of having a installer spew stuff all over the place without knowing if it will clean up everything again when you uninstall. It would be sad if we lost the freedom to open NSIS, Inno and MSI installers to inspect their contents...

This is a cool idea from a programmers perspective, but I share the view with Anders. I like being able to open up an nsis installer and extract a file or two that I need.

Adding some sort of randomizing algorithm would appeal to crack writers as it would hide all the code and files from the user. This kind of goes against the philosophy of open source software, where everyone should be able to view and use the software and its source code with a fair amount of freedom.

There is nothing stopping you from forking the codebase and writing in this functionality yourself.

Originally Posted by JasonFriday13 View Post

This is a cool idea from a programmers perspective, but I share the view with Anders. I like being able to open up an nsis installer and extract a file or two that I need.

Adding some sort of randomizing algorithm would appeal to crack writers as it would hide all the code and files from the user. This kind of goes against the philosophy of open source software, where everyone should be able to view and use the software and its source code with a fair amount of freedom.

There is nothing stopping you from forking the codebase and writing in this functionality yourself.

My first idea was to provide all users an option to make an NSIS installer safer.

OK, at the beginning it can be in standard order of EW_s and it can be randomized later when user chose to -let's have an option for this.

This was intended as new feature (discussion) for all users which could help many commercial projects to choose NSIS.

For me it suits recompiling NSIS with changing EW_ in the .h file.

Originally Posted by T.Slappy View Post

My first idea was to provide all users an option to make an NSIS installer safer.

OK, at the beginning it can be in standard order of EW_s and it can be randomized later when user chose to -let's have an option for this.

I think that making this option script configurable is a bad idea for end users, as Joe Bloggs can add security to their installer even though it's only 200kb in size. Then if they lose all their data and the installer is the only part left, they can't do anything with it because the codes aren't in the default order. For companies see below.

Originally Posted by T.Slappy View Post

This was intended as new feature (discussion) for all users which could help many commercial projects to choose NSIS.

For me it suits recompiling NSIS with changing EW_ in the .h file.

If a company really wants some security in their nsis installer, there is nothing stopping them from randomizing the values and compiling the source themselves. This lends itself well to automation, as the .h file can be automatically generated with random values, compiled, and then the resulting makensis.exe is used to build the installer.

For the standard user, I don't think security is a big enough problem. When you start getting into companies that use NSIS, it's not really a big deal to compile the source with a random set of values. I can change the values around in the .h file myself if I wanted to, but I don't see the need (I like to compile the 64 bit version as well during my coding experiments).