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 😛

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


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




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