Decompile NSIS

How exactly I can decompile NSIS-compiled exe. Please some theory or concrete examples.

Please see these search results:

They should answer your question.

Is not posible because you convert(Compile) your Source Code (Nsis Script) to Object code (Win32 EXE)...
reverse the process will give you the Object code
in unicode text, you know: !"#$%&/()@

sir, where there is a will there is a way

dark_boy, that's not true. NSIS doesn't create machine code. And reversing the process can give pretty good results.

Then is possible, 😁, how? With a HEX Editor?

i know there is a file extractor around somewhere...anyone got a link?

Mostly, when you use an installer, all the files are extracted. I think that what Idimmu wants is to get the original script (or something alike).

dark_boy, all that needs to be done and to somehow find out the version of NSIS used to compile the installer, hope you're right and the developer didn't change the source of NSIS, read the headers, decompress data (assuming you know what compression type was used) and parse it. If the user didn't change the source, and you know the exact version the parsing will be very easy.

A suggestion: Add the version of NSIS that it was compiled with to the header, so decompilers/decompiling people know what version was used. You could make this optional, so that not all NSIS installers can be decompiled unless you know the version number.
That versionnumber could be a number, starting at 0, going up for each CVS released.

That would only work for official versions, a modified source version would not be decompilable still.

I watch the "source" in a HEX Editor and Resource Hacker...
Try to modify my IO page and when I try to recompile give errors
like:

Corrupted file.

Since there was used: CRCCheck, upx, etc...

It's very dificult(but not impossible) to reverse the project....
We most know the properties of the installer to know what we
can do...
must agree with Virtlink .... I think that he was looking for is
the script that genereted the installer....

dark_boy I think you've got the wrong idea about decompilation. You don't approach it with a hex editor. You'd try to write a program that would load the installer data in the same way that the header attached to the data by makensis would go about it. In that way you'd be able to determine the opcodes and parameters to each opcode that would be run, and be able to decompress the data files contained within the exe installer. The only difficulty arises when handling many possible forms of binary data because the actual form depends on which version of makensis was used to create the exe. If you don't know what version of makensis was used to create the installer then life becomes very difficult, and it becomes (practically) impossible if an altered makensis (it is opensource after all) was used to create the installer.

Virgin at that too 🙂

mmm, ok... need to read more books about decompilation.
But to avoid these:

many possible forms of binary data because the actual
form depends on which version of makensis was
used to create the exe

Let's make a cool installer in the first time.... 😉
These compilation make ma head dizzy 🧟
Thanks for the info.

need to read more books about decompilation

It's just the reverse process of compilation, and in our case that means what is done as an nsis installer runs... just doing that. The only reason it is hard is (a) it was never designed to be done by something other than the installer itself, and (b) decompilation code written at one time might not handle an installer created in the future... there's not much you can do about that.

Conclusion: Decompilation is hardly possible, if possible at all. But since the decompiling user only needs to extract the source code (after all, the files are extracted by the installer itself), I would include the source code and extract it automatically to the $TEMP directory. When you need it, you can get it there. And when you release your program with the installer, you just remove the few lines that include and extract the source code file.
Then you have never the trouble of losing the source, but having the installer that you want to decompile.
Might also be an option for a switch that you can use when you run MakeNSIS.exe, instead of coding it yourself.

You could even encrypt the sourcecode file with a password, to prevent others from taking the source, but no need to remove those lines when you release it.

But since the decompiling user only needs to extract the source code (after all, the files are extracted by the installer itself)

The first time I came across the topic of decompilation on this forum it was not with this in mind. Instead the user who raised the issue wanted to recovere the files inside the installer when the installer had become corrupted (failed download or whatever).

Didn't think of that.

Re: Decompile NSIS

so from reading these threads..
assuming you know that the original version 1.98 nsis was used and you have the original script.. you could possibly extract the files?
could somebody provide some information as to some point i can start at in doing something like this?
perhaps some information on how and where compressed files are generically stored.. or the listing of the files stored..

using a generic sfx that does nothing but extract its files.. and that uses gzip
i have been able to locate compressed version of the data within the executable.. (matching the gzip data) which is basically the compressed data without the header
the only thing i can think of right now is to find a way to locate the start and end.. which is actually not the hard part
and to somehow reconstruct a header..
or maybe just use zlib and feed it to a gunzip stream
im hoping tho that this is actually stored somewhere that can be excessible.. and thats generic
and there is not an easily spottable list of the filenames..

admittingly i am being a little lazy.. i have not actually traced/reversed the code in detail to find the possibilities of this
im hoping that there is some information for this 😁

KiCHiK, Joost, Sunjammer: Are the files written between the instructions that the installer has to execute, or are they written at the end of the .exe-file. If not, I suggest this mayor change so that from all the NSIS compiled exe-files the files can be extracted, whatever version you would have.
Can you tell me how this works?

Well, this does bring up something I have wondered about since I first came across NSIS - why aren't the ZIP-style header structures written out to the EXE?

Sure, this could be optional, and it only applies if you are using the ZIP family of compression algorithms, but the headers / data structures are specified such that they can occur "embedded" in some larger file... heck, I was doing this with my own installer that I used before I switched to NSIS - mostly because of MUI - thanks, Joost et al. 🙂

RDaneel:
im not sure what you are trying to say.. but nsis does not use the zip compression format
but rather either bzip2 or zlib(gzip deflate)


virtlink:
the compressed data is stored at the end of the file.. i have been able to successfully take out some of the compressed data
and by creating a valid gzip header and appending the snippet of compressed data..
i have been able to extract original compressed data..
unfortunately this requires a lot of user intervention/analysis
and i have not been able to find original filenames..
it appears the header data is stored elsewhere.. and most likely in a special way..

i am hoping that a equivalent to the compressed datas header can be found somewhere in the sfx..
i will do some reversin today and see if i can turn up anything

but it is imo that extraction is potentially possible

and ive seen some people bring up the point that it will not work with all versions.. or you cant detect version..
and also some talking about possible alteration of the original program
well first of all it can be up to the user to find out what version executable it is.. i dont think that should matter
if it is wanted support for different versions can be put in.. and then the user could chooses which version to try.. this can be made a trial and error thing
second of all.. any sfx method can be altered.. this decompiler will target a specific "pure" version.. there is nothing wrong with that
i dont see why this should discourage development on such an utility..
on a further note.. this utility would not even need to be targetted at normal users.. just devers.. who cares?
and even if the original source were changed.. changing the way the data is stored would require large structural changes in the nsis sfx generation..
the new sfx would in a sense not be nsis anyways.. and its not of any concern to this decompiler utility

btw i dont think that it is impossible to detect version..
as anti-virus scanners prove.. every executable has a "signature" that you can detect
to claim that detecting differences in version is impossible does not make sense..
there must be something from version to version that is similar or different

some information dug

anyways i forgot to mention what ive found out so far.. this information is specific to version 1.98
the data appears to always start at address 0x8e00(decimal 36352)
as everything above this point is the same consistently with all generated executables

so i know that the header information must be somewhere in here..
and i am convinced the header information is stored in a special nsis way.. as if you turn compression off you will find the file listing seperated from the file content data
it seems that each file content data has 4 bytes of data preceding it.. which tells the size and compression..
so if you have a file that uses gzip deflate and is 5 bytes long you will have these 4 bytes: 05 00 00 80
anyways size and decompressing is easy to do.. i cant quite find the file listing.. i suspect if you use compression it compresses the filenames as well..
if anyone has information and can save me some time...😉

I know that NSIS doesn't use "ZIP" per se, and you may elect to use bzip2 (I do)... that is why I deliberately used the phrase "ZIP family"... but where do you think "deflate" came from? 🙂

Anyway, I brought up the subject of these headers (actually, they are more "trailers", given that they typically come at the end of or late in the containing file) because some have expressed an interest in accessing the files contained in an NSIS-built installer, and this approach provides a fairly standard way of doing just that... for instance, installers built containing these headers are able to be "understood" by programs like WinZip - in particular, this is one of the ways that the WinZip context menu entry "Open with WinZip" becomes available.

ic what you are trying to say now..
what you describe are sfx installers that embed a "block" of data that is the direct compressed archive appended to the program
and works because most archivers search for the headers in a file

RDaneel: actually, they are more "trailers"

you are somewhat partially right.. part of the informational stuffs is put in "trailing" data.. but for most there is also a preceding header of information
for example gzip puts a crc32 value and uncompressed file size in the "trailer"
and the preceding headers contain the gzip identifier.. bytes compression method.. and some other information

in any case the aforementioned headers are not embedded directly with the original specifications in the nsis generated sfx..
and it seems to be deliberate..

anyways ive made more headway.. i believe i may have found gzip data representing the filenames..
following the identifying text NullInst..
the following seems to be placed depending on the letter immediately following the NullInst text.. (how far it is displaced)
there will be 4 bytes that represents the size and compression method of a block of compressed data.. i suspect the filenames or more information used by the sfx

and then immediately following the above mentioned block is the compressed file data which i already identified earlier

For anyone interested in how this really works,



talks about it from their perspective. Note that things are simpler if you are not dealing with (or generating, as I am suggesting here) their Zip64/Deflate64 extensions, and remembering that we are specifically talking about DEFLATE and Windows.

To reiterate: this should be quite do-able (depending on exactly how NSIS constructs the files portion of the installer), and would allow NSIS installers to be viewed as "archives" by virtually any of the many free and commercial archive-viewing programs out there. Whether this would be allowed or not could be then left up to the developer generating the NSIS installer, through a directive in the .NSI file or a command-line switch if that is preferred.

NSIS supports different compression methods. ZIP/BZIP2 headers won't be added because it will be a lot of work and it adds extra size (both the headers and the code to ignore all these things).

Not being able to decompile is also a good thing for many people.

what you are saying involves altering the structure nsis uses in generating the sfx
this involves changing the source and recreating the packages
this does not help in decompiling.. and is rather something that would be added as a feature to the nsis format

in any case.. what you are saying defeats the purpose of using nsis.. as it will alter the basic structure used by nsis
you are better off creating your own sfx format or using another sfx format.. and this would be really what you would be doing
if went by what you have said

analyse the way that the nsis sfx are built and you will see what i mean

a) like I said, "optional"

b) this was for the posters who wanted to get at the contents of an NSIS-generated installer

c) I personally am happy with the way things are 🙂

d) why do you keep talking about "sfx"? If you mean it as "generic self-extracting archive", that's cool... of course, if you mean it as a ".sfx" file, that is a specific format - not what NSIS uses - which does support the functionality I describe! 🙂