Archive: 7zip now allows to extract installers


7zip now allows to extract installers

Release Name: 4.40 beta

Notes:

--------------------------------------------------------------------------------
Changes:
- 7-Zip now can unpack some installers created by NSIS
- New localization: Kurdish
- Some bugs were fixed
Is there a way to protect the source from being extracted and so on because this is really no longer safe to use.

If this happens, Afrow UK passdialog.dll will not be useful anymore since it can be extracted instead entering username and password.

You can mix up the EW_* values in Source\exehead\fileform.h and recompile.


where is this fileform.h and how to edit it to EW_* can u show more examples.

thanks for replying The Head Developer Of NSIS


There is already a thread about the new 7-Zip feature:

Link ;)


Originally posted by rxs2k5
where is this fileform.h
Download the Source Code: NSIS Download Page . The fileform.h is located in nsis-2.16-src\Source\exehead\

Originally posted by kichik
You can mix up the EW_* values in Source\exehead\fileform.h and recompile.
Release notes for 2.16 has an item that says:
* Changing Source/exehead/fileform.h to alter the internal structure of installers is no longer enough....

There seems to be a contradiction here, could you please clarify the issue?

Installers must be possible to unpack, example i hate installers from people who bundle spyware, now i can unpack directly THATS ALL.


Agreed.


Originally posted by potska
Installers must be possible to unpack, example i hate installers from people who bundle spyware, now i can unpack directly THATS ALL.
well that's the good thing about the unpack.... but you will have to think if this happens, the author which wants to protect his/her installer or to hide their hard copy script from some other people from leeching making it as their work.

Plus bundle spywares, you would have been able to find those later, and mostly people do not really include spywares especially those who uses username and passwordto protect the installer for private usage. If username and password is required there's no way a installer will have spyware in it because its the original work.

I don't see in what way this is a threat to the PassDialog plugin. As far as I know, the unpacker only unpacks files and nothing more. How can anyone use it to access hard coded passwords in your installer? The username or passwords aren't stored in passdialog.dll... so what is the problem?

-Stu


Unpacking installers is useful only to those who want to steal other people work, in every possible way they can do it. That's it. Moreover, why they do not unpack InstallShield for example? Unpacking free and open source installers like NSIS, has the meaning of kicking out of the scene this software, it seems some are bothered, and they use others like the author of 7z to make the dirty work, in order to kick out nsis.


Originally posted by potska
Installers must be possible to unpack, example i hate installers from people who bundle spyware, now i can unpack directly THATS ALL.
What a crap!

If a software bundles spyware, then avoid it.
If you definitely need the software without spyware/adware, then buy it.
Other ways serve nothing but freeloaders.

What is different that i unpack or not, i do always this way thai i install program and copy program folder, uninstall and program is install free....


What is different that i unpack or not
You don't need to agree to the licence file when you use the program.

All installers should be unpackable. I don't want installers to ruin my windows.
Program must work clearly.


I never read licenses, i am country man and i dont care.


Originally posted by Koopatrooper
You don't need to agree to the licence file when you use the program.
Why the hell do I need those licences. I never read them.
I collect the licences and send them to Business Software Alliance, so they can carefully read licences, which is their main work. I'm glad to help!

Originally posted by venekirsa
Why the hell do I need those licences. I never read them.
E.g one part of the licence file say, that the author isn't liable for all damages, wich maybe appear after using the program. You have to agree otherwise the intaller will abort.

Other licence files maybe contain important infos related to the program.

I don't want installers to ruin my windows.
Yeah, but other people like installers, because an installer is much easier to handle for many users.

Btw, not all installers are bad. ;)

Your posting makes no sense for me, you don't like installers, because you fear, they could destroy your system. Why are you posting then in the Nullsoft Scriptable Installer System forum?

I have another opinion on damages.
First I take programs that look good, but if program is bad and does any damage, I will throw computer out of window.
Few month ago, some program screwd up my Windows and I threw my computer againt the wall. Wall got damaged :(
Or else, if some programs screws up something, I will mail-bomb it's author.

There is only one use for licences. I don't want hot cooking-pan to burn my table cover, so I put can put some licence papers under the cooking-pan.


My vote: no - this harms s/w developers
The problem here is that while the ability to (partially) decompile NSIS installers can prevent spyware installations and such, software developers are now at risk because their NSIS source code is partially available.

IMO: I say this feature gets booted from 7-zip. Why would anyone need to extract an NSIS installer? Yes, I understand that it can save you from spyware. But why download illicit software in the first place? Most spyware-infested programs (to name names, FlashGet or NetAnts, both of which I have used) aren't worth a dime, even without the ad banner or whatever. This only puts software developers at risk. For example I have a friend I'm working with who's writing an installer for a certain open source program (he prefers that I don't give the name). He's making it a webdownload so the installer EXE itself only maxes out at around 500kB. But he prefers to keep the URLs to his files secret, and yet I was able to decompile the installer using 7-zip and get the URLs.

One thing that I have noticed is that some strings, namely Registry entries, do not appear in the unpacked script files. Which means that the Registry key where my NSIS-based ClockLock trial system is still safe. But what if 7-zip learns to unpack the string table that has that key in it? people will start cracking my custom-built installers which will cost me a lot of money.

People, most of you are installer developers. For those of you who don't do open source development, you know that your code can be compromised by this new feature in 7-zip. And that's why I'm saying what I'm saying.

@Igor Pavlov: I am a long time user of 7-zip and I absolutely love it. Currently it's the only archive utility installed on any of my Windows machines, and I have never needed anything more. I've also used 7za in a package management system that I'm working on, and because of that the package files are very, VERY well compressed. Great job. But I feel that this ability can be harmful towards software developers and that things like licensing algorithms can be compromised by this. Therefore, I vote that you remove this feature from 7-zip.

-dandaman32


I think that there should be an obfusicator for the NSI script on NSIS now...


I think that there should be an obfusicator for the NSI script on NSIS now...
Originally posted by kichik
You can mix up the EW_* values in Source\exehead\fileform.h and recompile.
7-zip is an archiver, not an hacking tool like the installshield and inno unpackers, so it's very unlikely that it will be able to overcome a good protection.
Modify the fileform.h and the fileform.c should work because 7-zip refuses to open archives with incorrect/non-standard headers.
Anyway if 7-zip can unpack an installer, any competent hacker can do the same without installing 7-zip. Depend of the NSIS format to protect your installer without taking any other step is the same than use Aspack or Upack without any additional tools to protect the program files.

Edit: the last 3 paragraphs.

Instead of begging the author of 7z to remove such feature (which is too little too late anyway :P), the right answer to this could be incorporating his password protection (optional) to lzma compression of NSIS. Or no?


Originally posted by Afrow UK
I don't see in what way this is a threat to the PassDialog plugin. As far as I know, the unpacker only unpacks files and nothing more. How can anyone use it to access hard coded passwords in your installer? The username or passwords aren't stored in passdialog.dll... so what is the problem?

-Stu
Well when I tested one of the installer I made compressed with Lzma, using 7zip to extract,

the source files, the dlls , the images and the nsi file which contains all the information, the username and password is being reveal in that .nsi script. So its like he can read all the available username and password in the .nsi script.

I not too sure why is it 7zip is able to create a .nsi during extracting.

Hmm sorry didn't realise that 7-Zip decompiled the installer as well. That is very very bad. Indeed, we should ask for this feature to be removed from 7-Zip.

One solution rxs2k5, would be to store the MD5 checksum for your passwords and usernames, rather than the passwords and usernames themselves. To get the MD5 checksum of strings, use the MD5 plugin on the Wiki. You can create a dummy installer to convert the strings to MD5 checksums, which you can then put into your main installer. When the user enters the username or password, you need to call the MD5 plugin to convert them to their MD5 checksum equivalents before comparing.

I'll add an example to my PassDialog plugin which does this.

-Stu


pass/user with md5 is mandatory!
if bzip2 is still protected there is no other way.
in any other case encrypt all files in a container
and put the accesskey hidden somewhere into program.
my solution uses that method and the installer is
about 150kb smaller than lzma (incl extractor!, total~4mb)
sure my mind m8 weird :p


Originally posted by guest_dude
Release notes for 2.16 has an item that says:
* Changing Source/exehead/fileform.h to alter the internal structure of installers is no longer enough....

There seems to be a contradiction here, could you please clarify the issue?
EW_* are defined in an enum, they're not part of a struct. Only struct changes must be reflected in Source/fileform.cpp.

Originally posted by Afrow UK
Indeed, we should ask for this feature to be removed from 7-Zip.
This is ridiculous. :hang:


Anyways, if any of you want to password protect your installer for your little weird reasons, why not pack the compilled installer into a passworded (with encrypt filenames option) WinRAR SFX (with options to silently unpack to $Temp and run the installer.exe). Haven't heard of anyone cracking a decent Rar password. Not sure if 7zip supports password encryption on SFXs, maybe it could be done too.
While this opensource plugins to incorporate psw protection into NSIS is of amateur level (no offense) and could be defeated very easy, doesn't matter md5 or no md5, by anyone who has a debugger and knows how to use it, even if there wasn't that 7z unpack feature.

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).

http://nsis.sf.net/File:PassDialog.zip
http://nsis.sf.net/File:Md5dll.zip

-Stu


I guess the whole conversation offers to Mr Igor a very good free of charge publicity. Perhaps you know what has been said "you may say what you like about me as long as you spell my name right".
The fact is that until he gets cracked bzip2 as well, lzma is useless to everyone who wants to protect his work, therefore I think, kichik, perhaps you should think about kick out lzma from nsis.


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 is based on lzma :p

@dopey - not exactly, but nearly ;)


Originally posted by 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).

http://nsis.sf.net/File:PassDialog.zip
http://nsis.sf.net/File:Md5dll.zip

-Stu
Thanks alot Afrow UK,

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.


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


Afrow UK, just for the sake of a complete discussion:

http://it.slashdot.org/article.pl?si...49256&from=rss
http://it.slashdot.org/article.pl?sid=05/08/21/1946254
http://developers.slashdot.org/artic.../12/07/2019244
http://it.slashdot.org/article.pl?si...37232&from=rss

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


Originally posted by Brummelchen

@dopey - not exactly, but nearly ;)
Not exactly, what?

i cannot tell you, just use your imagination ^^


I don't know what are you blabbering about.


Archive: 7zip now allows to extract installers


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


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 lkj
[NSIS].nsi script extracting will be disabled in next version of 7-zip.
Nonsense. It's already out in the wild.

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.
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.


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


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.


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.


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.


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.


Originally posted by guest dude
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.
If you want to prevent the unpacking of your installer you have some options:

1) Continue using poor security and hoping that nobody want to spend 5 minutes (without 7-zip!) to "crack" your installer. :down:
2) Add some actual protection: encryption, modification of the headers, etc. :lock:

3) Don't distribute your installer, so nobody can extract it! :cry:

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?


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.


I'm sorry for the late post but I was very busy during the last weeks (only getting slightly better now...). As many before already stated, security by obscurity just doesn't work. I thought "cool idea" when I first read about the new feature in 7zip, simply because it already happened to me that I accidentally deleted install-related stuff accidentally. It would be a great help if I could recover those without writing my own unpacker. Unfortunately, I'll now have to do exactly that.
And for stuff like ClockLock: There are end-user friendly tools which enable everybody to kill such poor attempts within a mere 10 seconds. I won't name them, for obvious reasons.
Face it, fellows: Everything that runs on a machine, can be cracked. And NSIS isn't about security, it's an INSTALLER. If you feel you need to protect your incredible amount of intellectual property in your installer, either use encryption or keep it to yourself. Period.

@Anoter voice: Oh please, UPX is not a crypter. Unpacking UPX takes about 5 seconds. And even for the derivative crypting variants, fully automatic unpackers are available. Please do your homework before suggesting inappropriate tools for a job :)