Protect from unpacker
I used NIS Edit to create the setup, how to protect my job?
Protect from unpacker
13 posts
You are using open source software, you pretty much need to change the order of the commands in the nsis source and recompile nsis.
short answer: you don't
The standard question we ask you, at this point, is this:
Are you trying to protect...
A. your installer
B. you installer code
C. the files inside your installer
D. the files being installed
For A: you can tag the installer with a customer ID.. it's easily removed, of course.. on-the-fly building of the installer would be more secure but depending on the installer size also a lot more CPU/RAM intensive.. not sure if you want to put that on a web server if that's your distribution form.
For B: although there's some old utilities that try to decompile the installer code, based on some test runs against both simple and complex installers, the result is pretty much unusable.
For C: 7zip and the like can always extract files from your installer as NSIS uses pretty standard compression routines. If you want to try to protect against that, you could try archiving them into a password-protected archive and un-archive them on installation (similarly, there are encryption/decryption plugins available which means the files are useless without decryption).
For D: even with the protection at point C, at some point the files will end up on the user's drive 'as is' in usable form. Using Process Monitor, anybody can see what registry and file i/o you perform, take the installed files + registry changes, and package that up.
So if you're trying to protect the files / application being installed.. then it's those files / that application that should have protection code added.. never the installer. Hence: you don't.
The standard question we ask you, at this point, is this:
Are you trying to protect...
A. your installer
B. you installer code
C. the files inside your installer
D. the files being installed
For A: you can tag the installer with a customer ID.. it's easily removed, of course.. on-the-fly building of the installer would be more secure but depending on the installer size also a lot more CPU/RAM intensive.. not sure if you want to put that on a web server if that's your distribution form.
For B: although there's some old utilities that try to decompile the installer code, based on some test runs against both simple and complex installers, the result is pretty much unusable.
For C: 7zip and the like can always extract files from your installer as NSIS uses pretty standard compression routines. If you want to try to protect against that, you could try archiving them into a password-protected archive and un-archive them on installation (similarly, there are encryption/decryption plugins available which means the files are useless without decryption).
For D: even with the protection at point C, at some point the files will end up on the user's drive 'as is' in usable form. Using Process Monitor, anybody can see what registry and file i/o you perform, take the installed files + registry changes, and package that up.
So if you're trying to protect the files / application being installed.. then it's those files / that application that should have protection code added.. never the installer. Hence: you don't.
my case is C, blowfish.ddl is good? or dcryptdll?
Using a plugin to extract password protected archives can be bypassed by using a custom plugin to get the password etc
IMHO you should focus on protecting your app and not the installer and just accept the fact that unbreakable DRM is impossible
IMHO you should focus on protecting your app and not the installer and just accept the fact that unbreakable DRM is impossible
there i find the plugin?
Where, I don't think there is a public one, but it would take 5 minutes to create a fake plugin that just dumps the parameters passed to it. You could probably even hex edit the dumpstate plugin's named export.
ok but if i use blowfish.dll or dcryptdll.dll?!?!?
Does not matter which plugin you use, the key has to be in plain text at some point
what other tools are their to extract files from installers and do they also just work when the installer is lzma compressed? 7zip does not extract when using bzip2.Originally Posted by Animaether View PostFor C: 7zip and the like can always extract files from your installer as NSIS uses pretty standard compression routines.
and winrar? which plugin should I use?
I hear the latest beta fixed that.Originally Posted by Yathosho View Post7zip does not extract when using bzip2.
Personally, I'm a big fan of Total Commander...Originally Posted by Yathosho View Postwhat other tools are their to extract files from installers and do they also just work when the installer is lzma compressed?
Homepage of Total Commander, a file manager replacement for
Windows 95/98/NT/2000/XP/Vista/7/8/8.1/10/11
...and it has a plugin available that lets me browse into installer packages (not just NSIS) through the same familiar TC interface...
Largest unofficial database of plugins and utilities for Total Commander file manager with user comments. Total Commander is a highly configurable file manager with great plugin support. InstallExplorer Total Commander
...and it works just fine with LZMA, yes. It has saved me a couple of times when installers did bad system checks (old applications determining I don't have enough memory due to a 16bit wrap-around, a Western Digital utility that failed to extract on Win7 because it looked for a non-existing file required for the installer.. but not for the utility itself, of course.. etc.) It doesn't work with BZIP2, but see MSG's reply.
But basically you shouldn't rely on the compressor for any form of protection... NSIS has source freely available and the compression/decompression routines are available to whoever really wants to open up your installer and extract the files.
But, as noted again and again.. you shouldn't rely on any security inside the installer itself -at all- if what you're protecting is the application/files it's installing 🙂