Decompile NSIS
How exactly I can decompile NSIS-compiled exe. Please some theory or concrete examples.
Archive: Decompile NSIS
Decompile NSIS
How exactly I can decompile NSIS-compiled exe. Please some theory or concrete examples.
Please see these search results:
http://forums.winamp.com/search.php?...by=&sortorder=
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, :D, 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 actualLet's make a cool installer in the first time.... ;)
form depends on which version of makensis was
used to create the exe
need to read more books about decompilationIt'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 :D
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
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,
http://www.pkware.com/products/enter...s/appnote.html
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! :)
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 :D
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.
Archive: Decompile NSIS
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 VerburgNot every installer always installs all files it contains.
File encryption for an installer that installs files is useles.
virtlinkWhile 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.
So what use is it to encrypt files which are decrypted and installed without any key or question?
Originally posted by IppiI don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. :weird:
Not every installer always installs all files it contains.
Also originally posted by IppiIn 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.
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 virtlinkAs 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?
I don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. :weird:
Originally posted by virtlinkFor 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.
I don't see why an installer would contain files that aren't installed. There aren't any advantages except a size increase. :weird:
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.
Originally posted by RDaneelSo there is still no need for encryption. These files will be installed depending on the OS and user selection.
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? :D
Etc.
Originally posted by Joost VerburgWell you can use 7Zip to extract an NSIS installer.... Also I found that Avast also scans for viruses inside the isntallers which is nice...
Getting the script from a compiled installer is almost impossible.
7-Zip can extract the files within a NSIS installer package, aside from BZIP2 compression