Decompile NSIS

It's too much work for such a thing. You would need different structures for each compression method.

IMHO it's useles too...who would need it?

oh.. hm..
sfx is supposed to be an acronym for self-extracting executable
maybe ihave it wrong.. but ive always used it 😁

joost:
it is still possible to decompile it..
without anything done while making the package
at least im pretty sure of it..
since ive found information that may allow this

tho it will be difficult to make it generic
ive been able to successfully extract files
by constructing valid headers and putting it with
the compressed data ive been able to locate inside some sfx

ive found some new info that may allow it to be generic..
but it will take some more work.. but i think its possible

anyways what i am hoping is that someone can give some insight
so that i can maybe do this quicker.. as ive seen info
on people who seem to have made programs for past versions
that may speed things up for me as starting points

FYI, the Kaspersky Antivirus (I use version 4.0.9) treats NSIS-generated installers as archives and checks all files inside without any difficulties.

yes but its easier on the av scanners..
av scanners do not need the filenames or listings to scan the files..
all they need to do is search for patterns within the data blocks..
which use gzip or bzip2 compression.. so its a simple matter for them
ive been able to successfully attach reconstructed header/trailer to the data blocks in the files
and actually extract files using that..
i need to work on a way to easily locate this block..
and to parse the filenames and listings and paths
it appears that a data file containing strings representing the filenames and other stuff is also compressed in a data block
just need to find a way to easily parse this right now

I'm not saying that it's impossible to decompile NSIS installers. You can always get at least the compressed data from the file.

What I mean is that there are more important things to do than adding optional support for decompilation.

aha i see.. yes i fully agree with that joost

I think the opposite option - blocking decompilation at all - will be also useful...

basically what you are asking for is a method of encrypting the data
and actually i would disagree with that..
first of all it will add to bloat of the program and im not sure but from reading the history it appears adding this would contradict their direction
second of all there are plenty of other programs that are designed for this

and of course you will never be able to completely block it anyways theres always a way around it.. and its usually pretty trivial to circumvent
and adding the fact that this is open source..
all it would take is a couple of decent coders..
give or take a week at the most itll be cracked

Getting the script from a compiled installer is almost impossible. If you want to be even more sure, you can change the order of the instructions in fileform.h and recompile.

Encrypting the file data is useles, because the installer is being used to extract these files.

All data may be at least encrypted with a random key during compilation. Of course, this key will be stored somewhere in the installer, but retrieving of this key will be a bit tricky and probably will not be fully automatizeable. In this manner we can embarrass the coming of some kind of "universal NSIS decompiler".

I am not trying to say that the above feature is absolutely necessary. But if we discuss the NSIS decompiling, it is not out of place to consider another side of subject.

sh0e was able to extract some files from an installer, but it was very hard and is not yet easy. Extracting a script is impossible, since most of the script is compiled. All macro's and !ifdef's are lost. All installer attributes too.

Getting the original script from an installer is impossible. Even if the NSIS version was not recompiled and you could get the script data (which would require lots of work), you can't get the installer attributes, labels, macro's etc, so the script will be useles.

File encryption for an installer that installs files is useles.

joost i agree with everything you said in the last post..
but i couldnt find the comment related to extracting the script?
could you provide the quote so i can better understand the viewpoint thx

virtlink:
it isnt actually that difficult..
youd be suprised at how easy this really is

But Ippi, do you understand that even if there would be some kind of 'universal NSIS decompiler', it wouldn't make any difference. At first, I doubt that there will ever be one. Secondly: The script cannot be retrieved and the files are extracted anyway. So what use is it to encrypt files which are decrypted and installed without any key or question?

btw finding now that all sfx generated
have the same executable code in the beginning
which i would consider as a "base" or "skeleton"
and i have found a lot of strange garbage like stuff
(i havent truly analysed it fully)
within the compressed block that contains the file listings..
i have a biting suspicion that the "garbage" may be some kind of
compiled version of the script.. and may possibly be decompiled (?)


oh yes i forgot to mention this before.. the version IS detectable
within this compressed data block is a string containing version..
heres the snippet copy/paste from an example i am reversing from
>Nullsoft Install System v1.98

I don't think that that 'garbage', if it's a script, can be decompiled, due to what Joost and I have been saying.
But maybe KiCHiK, Subjammer and/or Joost can jump into this conversation and give us some more info about the structure of the compiled .exe-file.

decompiled into the original script? probably not
but perhaps that data can be translated
into some kind of pseudo code
kinda useless tho

You can never get the original script from the exe file. All defines, macro's, installers attributes are being processed by the compiler.

What I mean is that there is no need for encryption, because you can't get anything useful from the exe file.

We understand that Joost, but maybe you could tell us a bit more about the compiled .exe itself. Than sh0e can find out how to extract the files from a corrupted NSIS installer. What is the 'garbage' he's talking about?

A corrupted installer is called corrupted for a reason. Trying to extract files from such an installer is bad mojo.

A compiled installer has three parts:

1. NSIS VM
2. Script code
3. File data

Probably the 'garbage' is the script code.

The first two parts are very small. If the installer is corrupted, you can be quite sure that the compressed data is corrupted, so you won't be able to get the files back.

If certain files are not corrupted, you can always start NSIS with the /NCRC parameter so it will ignore the corruption (this is not possible if CRCCheck is set to 'force').

i dont see why this "bad mojo" should be reason
that development on such a decompiler should not be done
in any case my reasons are for platform issues
and lets say the executable is truncated or the headers
are corrupted.. or certain blocks of data are corrupted
some of the data within the executable would still be
salvagable..

yes i see that structure and it is apparent.. the script
code is also compressed it seems
for some reason the filenames are embedded with the script code

i have found something strange tho..
i have been unable to reproduce the structure that some
sfx generated by nsis seem to have..
and supposedly they are all using unmodified v1.98..
which is strange as all the sfx ive made come out the same..
for example one has a significantly smaller vm.. by about 10kb
and the data is of a different structure

correction.. i was downloading old versions..
which is why there was such a difference

it seems i have all the information i need
although a little bit more about the script code

anyways i will be creating a program
restricted to gzip deflate of unmodified nsis v1.98

probably not of use to anybody here..
but there is a project that is in need of this
and i will create what they need
no thx to those of you who made
scoffing type of comments or discounting
the merit in the creation of this

Joost Verburg
File encryption for an installer that installs files is useles.

Not every installer always installs all files it contains.

virtlink
So what use is it to encrypt files which are decrypted and installed without any key or question?

While protection is usually provided by program itself, sometimes this function assigned to distribution package. In this case any difficulties attending the unauthorized file extraction process may be considered as positive factor.

Originally posted by Ippi
Not every installer always installs all files it contains.

I don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. 🤪

Also originally posted by Ippi
While protection is usually provided by program itself, sometimes this function assigned to distribution package. In this case any difficulties attending the unauthorized file extraction process may be considered as positive factor.

In that unusual case, I would encrypt the files before compiling the installer. And I would include a small DLL/EXE that can decrypt the files with the right key.

Originally posted by virtlink
I don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. 🤪

As an example, a unified installer meant to work differently in different [detected at install-time] environments... maybe extracting and installing a .VXD file on Win 9x, but installing a service instead on NT4/2000/XP?

Or installing different language DLLs based on the install-time environment detected?

Or even optionally installing components based on user selection? 😁

Etc.

Originally posted by virtlink
I don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. 🤪

For example, the Windows Service Packs contain files for all possible configurations and all product subfamilies (server/workstation), but only the nesessary files are installed during the update. If you write a some kind of service pack for your product, which appears as "Standard" and "Pro" versions, you possible will not desire that files designated for the "Pro" version (which very likely is more expensive) can be easy mined by the "Standard" version owner.

Please understand: I'm not trying to say that program or data protection must be done in that way (quite the contrary, I never did the program protection in manner we discussed). But what to do if someone will like this way?

Actually, I know what to do 😉 Encrypt the files into SFX with password using something like WinZip or WinRar and then call it from the script (password can be stored in the script, calculated in some way or retrieved from the user).

such a feature would add too much overhead
and the encryption will most likely be
somewhat trivial to reverse
with the key contained in the executable
i seriously doubt such a feature will be considered

->already established
besides.. it is possible to do thru scripting
and adding a decrypter to execute within the executable

sh0e, you just said what I said too (not that I mind 😉). That's what I mean. Just include a decrypter, and encrypt the files at compile time, or before.