Umm, kicking out LZMA compression from NSIS would destroy the best compression available to NSIS!! It makes more sense to get 7-zip to remove that feature!
7zip now allows to extract installers
61 posts
7zip is based on lzma 😛
@dopey - not exactly, but nearly 😉
@dopey - not exactly, but nearly 😉
Originally posted by Afrow UKThanks alot Afrow UK,
Please explain in what way it is ridiculous?
I have added an example (EncryptionUserPass.nsi) to the PassDialog plugin which uses an MD5 checksum for username and password validation instead of the usernames and passwords themselves.
I also included a script called EncryptWithMD5.nsi which once compiled allows you to enter a string and get its MD5 checksum. The MD5DLL plugin is also required (as well as installation of the latest PassDialog.dll plugin).
-Stu
I was like shocked when I tested it, 7zip can really exact the entire raw data username and password out of it. I will try your method, do I still use Lzma or stick to bzip2 ???
Nothing will get kicked out of nowhere. Being "uncrackable" is in no way a declared feature of NSIS. On the contrary, it's open-source. Everyone could easily "crack" it. Many anti-virus applications already open NSIS installers to check what's inside them. 7-zip is not the first to do it, it's just the first user-end utility to do this.
If you want to protect a password or a file in your installer, you shouldn't count on an open-sourced code that compresses it or encodes it. If you want to protect, you encrypt it, ask the user for a password which will be used to generate a key and use that key to decrypt the file.
Afrow UK, keeping an MD5 in the script is still not good enough because one can simply yank the MD5, put a breakpoint at the appropriate place and change the input to that MD5. To protect a password, you should take a known set of bytes, preferably random to prevent dictionary attacks, and encrypt it with the password. This way, one must enumerate all key options to successfully decrypt the content.
Note that this will not work for a simple page that blocks the user from continuing until the correct password is given. In this case, the password doesn't really matter and a simple code patch will do the trick. One could easily change the jump address of a failure check to a good jump address. Without the protected computing everyone has been talking about lately, you can't really protect a program. Everything can be cracked, you can only make it harder. How hard? Depends on how much you're willing to invest in it and what level of attacks you want to block.
You can, however, have the password decrypt a file crucial to the program, using the method mentioned above.
If you want to protect a password or a file in your installer, you shouldn't count on an open-sourced code that compresses it or encodes it. If you want to protect, you encrypt it, ask the user for a password which will be used to generate a key and use that key to decrypt the file.
Afrow UK, keeping an MD5 in the script is still not good enough because one can simply yank the MD5, put a breakpoint at the appropriate place and change the input to that MD5. To protect a password, you should take a known set of bytes, preferably random to prevent dictionary attacks, and encrypt it with the password. This way, one must enumerate all key options to successfully decrypt the content.
Note that this will not work for a simple page that blocks the user from continuing until the correct password is given. In this case, the password doesn't really matter and a simple code patch will do the trick. One could easily change the jump address of a failure check to a good jump address. Without the protected computing everyone has been talking about lately, you can't really protect a program. Everything can be cracked, you can only make it harder. How hard? Depends on how much you're willing to invest in it and what level of attacks you want to block.
You can, however, have the password decrypt a file crucial to the program, using the method mentioned above.
LZMA is fine. You will still be able to get the MD5 checksums out of it, but I'm taking a guess that it isn't possible to get the original string from an MD5 checksum.
-Stu
-Stu
Afrow UK, just for the sake of a complete discussion:
As I said, it's all just a matter of setting a threshold of time you're willing to invest in defending yourself.
mrogers writes "Researchers at Ruhr-Universität Bochum have found a way to produce MD5 collisions between human-meaningful documents. This could be used to obtain a digital signature on one document and then transfer it to another. The same technique is theoretically applicable to other hash fu...
Gravix writes with a shameless plug for his new site "Sporting over 12 million entries, project GDataOnline is one of the largest non-RainbowTable based MD5 crackers on the internet. The database spans over 7 languages, 35 topics, and contains common mutations to words that include numbers and capi...
Effugas writes "I've completed an applied security analysis (pdf) of MD5 given Xiaoyun Wang et al's collision attack (covered here and here). From an applied perspective, the attack itself is pretty limited -- essentially, we can create 'doppelganger' blocks (my term) anywhere inside a file that ma...
SiliconEntity writes "The crypto world was shaken to its roots last year with the announcement of a new algorithm to find collisions in the still widely-used MD5 hash algorithm. Despite considerable work and commentary since then, no source code for finding such collisions has been published. Until ...
As I said, it's all just a matter of setting a threshold of time you're willing to invest in defending yourself.
Thanks Kichik. Think I'll let other people take this a step futher if they need to 🙂
-Stu
-Stu
Originally posted by BrummelchenNot exactly, what?
@dopey - not exactly, but nearly 😉
i cannot tell you, just use your imagination ^^
I don't know what are you blabbering about.
do not use winrar outside...
I don't really see a problem. If you don't want someone decompiling your installer, pay some money for an installer suite like InstallShield or WISE installer. Or use MSI (not pefered).
both were hacked before NSIS LZMA <lol>
they use also a script which is clear readable with tools
they use also a script which is clear readable with tools
If you don't want someone decompiling your installer, pay some money for an installer suite like InstallShield or WISE installer.Why should I pay? NSIS is one of the best installer systems and is free.
There are several cracking tools to decompile InstallShield aviable too.
7Zip's method to unpack NSIS is user friendly, thats the different.
[NSIS].nsi script extracting will be disabled in next version of 7-zip.
Originally posted by lkjNonsense. It's already out in the wild.
[NSIS].nsi script extracting will be disabled in next version of 7-zip.
Besides, what good reason does this serve?
An installer is not an archive. Why do you think people take all the trouble to write an installer while they could simply pack things up as an SFX?
As some of the posts in this discussion clearly show, disassembling an installer serves nothing but the interests of outlaw types.
OTOH, I'm glad the sevenz author showed it's not hard to disassemble an NSIS installer, I used to think otherwise. Actually, I'd like to see how far he can go in this endeavor, maybe try all combinations in the enum, even employ heuristics to disassemble modified installers? (no wonder the guy's got too much time on his hands.)
He is the author of 7-zip 🙂
I don't think it's nessecary to remove this feature. The only reason could be that is it not useful for most 7-Zip users.
I don't think it's nessecary to remove this feature. The only reason could be that is it not useful for most 7-Zip users.
I don't think it's nessecary to remove this feature.At least, 7-Zip should not extract the [NSIS].nsi script, then all is fine. It's up to the author, if he wants to release his script, or not.
And if I got Igor right, this is exactly what he planned for the next release.
I see you all want to implement a well known concept of "security through obfuscation". In several posts in this thread I've seen suggestions in that direction (I don't have the time now to quote them, but that attitude can be easily spotted). I'm saying this as a totally uninvolved person and if you take a step back and have a look at this issue more 'neutrally' (in the sense that if it is was not your work that is affected), you too will see that obfuscation is extremely unfriendly to the end user. End users should have a chance to at least see what's going on BEFORE installing an unknown program. As for myself, I have often declined such installs that don't let me do anything, but insist on having their way. No, I have not done anything 'bad' with unpacked data, but trust is a two-way street.
And finally, if one relies on installer to protect his work, that says a lot about his/her programming skills.
Thank you for your attention.
And finally, if one relies on installer to protect his work, that says a lot about his/her programming skills.
Thank you for your attention.
7-Zip 4.41beta is out, it will no longer unpack the .nsi script.
nice to hear that it no longer generate nicerly done .nsi script but something important now 7zip is able to extract bzip2 right ?
I tested it but it was unable to extract the installer in bzip2. Is this counted safe to use
I tested it but it was unable to extract the installer in bzip2. Is this counted safe to use
You can not count on bzip2 to protect your data. It's just a matter of time until some user-end utility, 7-zip or else, would be able to extract files from that too. The source code for the modified bzip2 compression is freely available as part of the NSIS source code package.
If you want to implement security through obscurity, you do not use a popular open-sourced application to do so. NSIS is not meant to protect your data, it's meant to create installers. If you want to protect your data you should encrypt using the method I've described earlier. If you don't want to involve a password, use a closed-source obfuscater of your own as a plug-in.
If you want to implement security through obscurity, you do not use a popular open-sourced application to do so. NSIS is not meant to protect your data, it's meant to create installers. If you want to protect your data you should encrypt using the method I've described earlier. If you don't want to involve a password, use a closed-source obfuscater of your own as a plug-in.
It's a fucking installer, not PGP.
Protecting NSIS installers by removing features from 7-zip is like stopping people stealing from an unlocked house by cutting their legs off -- people who are genuinely out to do bad will just say "no" when you say "please can I cut your legs off?" (ie, they'll just use a different app, rather than the crippled 7-zip)
The *real* solution to protecting your data is to encrypt it (ie, put a lock on your door) -- anything else is just an annoyance to legit users, and practically nothing to someone who really wants to get in when they shouldn't.
Also, open / closed source and free / costly has nothing to do with it. In fact, open source encryption is considerably stronger than closed source obfuscation.
In addition, EULAs and such are pretty much worthless from a legal view, so the argument that the user absolutely must be forced to read it at all costs doesn't stand.
If you want *actual* security, not just a "please don't steal" sign, encrypt the installers with a proper encryption program, and give out decryption keys in the same way you were giving out installer passwords before.
The *real* solution to protecting your data is to encrypt it (ie, put a lock on your door) -- anything else is just an annoyance to legit users, and practically nothing to someone who really wants to get in when they shouldn't.
Also, open / closed source and free / costly has nothing to do with it. In fact, open source encryption is considerably stronger than closed source obfuscation.
In addition, EULAs and such are pretty much worthless from a legal view, so the argument that the user absolutely must be forced to read it at all costs doesn't stand.
If you want *actual* security, not just a "please don't steal" sign, encrypt the installers with a proper encryption program, and give out decryption keys in the same way you were giving out installer passwords before.
I can't believe this discussion has gotton so big (I can actually).
Just because there is now an app to extract installer files, dosen't mean that we should do something about it to stop it (unless it breaks the law). It appears that microsoft has not done anything to protect its Windows files from resource hacker, and I don't think nsis is going to introduce protection for extracting files from an installer (because it is open source).
I love nsis, and always will, desite the fact that files can be extracted from installers now.
Just because there is now an app to extract installer files, dosen't mean that we should do something about it to stop it (unless it breaks the law). It appears that microsoft has not done anything to protect its Windows files from resource hacker, and I don't think nsis is going to introduce protection for extracting files from an installer (because it is open source).
I love nsis, and always will, desite the fact that files can be extracted from installers now.
turn "crccheck off" and pack it! O_o
Why is this all about some password compromise buried into installer script?
Has anyone heard about this thing called software deployment? It's not a fancy name for just copying program files into users' PC, believe me.
Software distributing entites (be it an organization or an individual) heavily rely on the integrity of their installers to enforce a deployment policy.
Now that it's extremely simple and encouraging for the ordinary end-user to perform a stray installation, that policy (any policy, thereof) has become useless for those based on NSIS.
Has anyone heard about this thing called software deployment? It's not a fancy name for just copying program files into users' PC, believe me.
Software distributing entites (be it an organization or an individual) heavily rely on the integrity of their installers to enforce a deployment policy.
Now that it's extremely simple and encouraging for the ordinary end-user to perform a stray installation, that policy (any policy, thereof) has become useless for those based on NSIS.
Originally posted by guest dudeIf you want to prevent the unpacking of your installer you have some options:
Why is this all about some password compromise buried into installer script?
Has anyone heard about this thing called software deployment? It's not a fancy name for just copying program files into users' PC, believe me.
Software distributing entites (be it an organization or an individual) heavily rely on the integrity of their installers to enforce a deployment policy.
Now that it's extremely simple and encouraging for the ordinary end-user to perform a stray installation, that policy (any policy, thereof) has become useless for those based on NSIS.
1) Continue using poor security and hoping that nobody want to spend 5 minutes (without 7-zip!) to "crack" your installer. 👎
2) Add some actual protection: encryption, modification of the headers, etc. 🔒
3) Don't distribute your installer, so nobody can extract it! 😢
Hear Hear. The installer is unimportant. It mearly copies files onto the users machine. You are worried about the unpacking of files you are intending to unpack anyway.
If you are worried about the extraction of your nsis script, who cares? It's mearly a set of instructions on what you are doing to the persons machine. That too can be monitored with appropriate software.
Anyone care to bring in some appropriate use-cases that are broken by 7zip's implementation?
If you are worried about the extraction of your nsis script, who cares? It's mearly a set of instructions on what you are doing to the persons machine. That too can be monitored with appropriate software.
Anyone care to bring in some appropriate use-cases that are broken by 7zip's implementation?
It is very convenient to look inside installer just for readme.txt or for a list of changes, for example, or to see if documentation is included, or just unpack files without repeating install if they were damaged by accident. Many projects provide separate .zip and .exe distributions. This could be avoided.
In short - you are wrong, guys, to remove NSIS support from 7zip. One, who is especially greedy, should make use of crypting .exe with UPX or some other PE utilites.
In short - you are wrong, guys, to remove NSIS support from 7zip. One, who is especially greedy, should make use of crypting .exe with UPX or some other PE utilites.