Old 11th February 2003, 14:43   #1
Idimmu
Junior Member
 
Join Date: Feb 2003
Posts: 1
Send a message via ICQ to Idimmu
Exclamation Decompile NSIS

How exactly I can decompile NSIS-compiled exe. Please some theory or concrete examples.
Idimmu is offline   Reply With Quote
Old 11th February 2003, 14:45   #2
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
Please see these search results:
http://forums.winamp.com/search.php?...by=&sortorder=
They should answer your question.

NSIS FAQ | NSIS Home Page | Donate $
"I hear and I forget. I see and I remember. I do and I understand." -- Confucius
kichik is offline   Reply With Quote
Old 11th February 2003, 18:22   #3
Joel
Debian user
(Forum King)
 
Joel's Avatar
 
Join Date: Jan 2003
Location: Arch land
Posts: 4,917
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: !"#$%&/()@


* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with MATE.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with MATE.
Joel is offline   Reply With Quote
Old 11th February 2003, 18:59   #4
pjw62
Senior Member
 
Join Date: Aug 2001
Posts: 108
sir, where there is a will there is a way
pjw62 is offline   Reply With Quote
Old 11th February 2003, 19:11   #5
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
dark_boy, that's not true. NSIS doesn't create machine code. And reversing the process can give pretty good results.

NSIS FAQ | NSIS Home Page | Donate $
"I hear and I forget. I see and I remember. I do and I understand." -- Confucius
kichik is offline   Reply With Quote
Old 11th February 2003, 19:46   #6
Joel
Debian user
(Forum King)
 
Joel's Avatar
 
Join Date: Jan 2003
Location: Arch land
Posts: 4,917
Then is possible, , how? With a HEX Editor?


* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with MATE.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with MATE.
Joel is offline   Reply With Quote
Old 11th February 2003, 19:59   #7
liquidmotion
Smokes Two Joints
Beta Team
 
liquidmotion's Avatar
 
Join Date: Feb 2001
Location: SFBA
Posts: 3,680
Send a message via ICQ to liquidmotion
i know there is a file extractor around somewhere...anyone got a link?

For a good time: shup | stashbox | my homepage
liquidmotion is offline   Reply With Quote
Old 12th February 2003, 09:44   #8
virtlink
Major Dude
 
virtlink's Avatar
 
Join Date: Sep 2002
Location: At [4C69:6E6B]
Posts: 561
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).

"I'll quote you when you say something memorable."
- Claudia Pelsmaeker
virtlink is offline   Reply With Quote
Old 12th February 2003, 13:20   #9
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
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.

NSIS FAQ | NSIS Home Page | Donate $
"I hear and I forget. I see and I remember. I do and I understand." -- Confucius
kichik is offline   Reply With Quote
Old 12th February 2003, 14:09   #10
virtlink
Major Dude
 
virtlink's Avatar
 
Join Date: Sep 2002
Location: At [4C69:6E6B]
Posts: 561
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.

"I'll quote you when you say something memorable."
- Claudia Pelsmaeker
virtlink is offline   Reply With Quote
Old 12th February 2003, 16:16   #11
Sunjammer
Major Dude
 
Join Date: Jun 2002
Location: Swindon, UK
Posts: 559
That would only work for official versions, a modified source version would not be decompilable still.
Sunjammer is offline   Reply With Quote
Old 12th February 2003, 18:37   #12
Joel
Debian user
(Forum King)
 
Joel's Avatar
 
Join Date: Jan 2003
Location: Arch land
Posts: 4,917
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....


* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with MATE.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with MATE.
Joel is offline   Reply With Quote
Old 12th February 2003, 19:26   #13
Sunjammer
Major Dude
 
Join Date: Jun 2002
Location: Swindon, UK
Posts: 559
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.
Sunjammer is offline   Reply With Quote
Old 12th February 2003, 20:48   #14
Joel
Debian user
(Forum King)
 
Joel's Avatar
 
Join Date: Jan 2003
Location: Arch land
Posts: 4,917
Talking Virgin at that too :)

mmm, ok... need to read more books about decompilation.
But to avoid these:
Quote:
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.


* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with MATE.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with MATE.
Joel is offline   Reply With Quote
Old 12th February 2003, 21:06   #15
Sunjammer
Major Dude
 
Join Date: Jun 2002
Location: Swindon, UK
Posts: 559
Quote:
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.
Sunjammer is offline   Reply With Quote
Old 14th February 2003, 11:28   #16
virtlink
Major Dude
 
virtlink's Avatar
 
Join Date: Sep 2002
Location: At [4C69:6E6B]
Posts: 561
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.

"I'll quote you when you say something memorable."
- Claudia Pelsmaeker
virtlink is offline   Reply With Quote
Old 14th February 2003, 11:35   #17
Sunjammer
Major Dude
 
Join Date: Jun 2002
Location: Swindon, UK
Posts: 559
Quote:
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).
Sunjammer is offline   Reply With Quote
Old 14th February 2003, 11:40   #18
virtlink
Major Dude
 
virtlink's Avatar
 
Join Date: Sep 2002
Location: At [4C69:6E6B]
Posts: 561
Didn't think of that.

"I'll quote you when you say something memorable."
- Claudia Pelsmaeker
virtlink is offline   Reply With Quote
Old 28th March 2003, 02:42   #19
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 28th March 2003, 10:24   #20
virtlink
Major Dude
 
virtlink's Avatar
 
Join Date: Sep 2002
Location: At [4C69:6E6B]
Posts: 561
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?

"I'll quote you when you say something memorable."
- Claudia Pelsmaeker
virtlink is offline   Reply With Quote
Old 28th March 2003, 18:51   #21
RDaneel
Member
 
Join Date: Nov 2001
Location: Seattle, Washington
Posts: 78
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 is offline   Reply With Quote
Old 28th March 2003, 19:07   #22
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 28th March 2003, 19:51   #23
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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...
sh0e is offline   Reply With Quote
Old 28th March 2003, 20:10   #24
RDaneel
Member
 
Join Date: Nov 2001
Location: Seattle, Washington
Posts: 78
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.
RDaneel is offline   Reply With Quote
Old 28th March 2003, 20:30   #25
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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

Quote:
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..
sh0e is offline   Reply With Quote
Old 28th March 2003, 20:51   #26
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 28th March 2003, 20:52   #27
RDaneel
Member
 
Join Date: Nov 2001
Location: Seattle, Washington
Posts: 78
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.
RDaneel is offline   Reply With Quote
Old 28th March 2003, 21:05   #28
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
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.
Joost Verburg is offline   Reply With Quote
Old 28th March 2003, 21:08   #29
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 28th March 2003, 21:21   #30
RDaneel
Member
 
Join Date: Nov 2001
Location: Seattle, Washington
Posts: 78
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!
RDaneel is offline   Reply With Quote
Old 28th March 2003, 21:26   #31
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
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?
Joost Verburg is offline   Reply With Quote
Old 28th March 2003, 21:27   #32
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
oh.. hm..
sfx is supposed to be an acronym for self-extracting executable
maybe ihave it wrong.. but ive always used it
sh0e is offline   Reply With Quote
Old 28th March 2003, 21:33   #33
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 29th March 2003, 16:01   #34
Ippi
Junior Member
 
Join Date: Mar 2003
Location: Ukraine
Posts: 45
FYI, the Kaspersky Antivirus (I use version 4.0.9) treats NSIS-generated installers as archives and checks all files inside without any difficulties.
Ippi is offline   Reply With Quote
Old 29th March 2003, 16:35   #35
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 29th March 2003, 17:08   #36
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
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.
Joost Verburg is offline   Reply With Quote
Old 29th March 2003, 17:53   #37
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
aha i see.. yes i fully agree with that joost
sh0e is offline   Reply With Quote
Old 29th March 2003, 18:11   #38
Ippi
Junior Member
 
Join Date: Mar 2003
Location: Ukraine
Posts: 45
I think the opposite option - blocking decompilation at all - will be also useful...
Ippi is offline   Reply With Quote
Old 29th March 2003, 19:16   #39
sh0e
Junior Member
 
Join Date: Mar 2003
Posts: 17
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
sh0e is offline   Reply With Quote
Old 29th March 2003, 19:28   #40
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
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.
Joost Verburg is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Developer Center > NSIS Discussion

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump