My problem is, that I cannot simply add all files to the installer file, because it will exceed the 2GB limit. I also cannot leave my large files in a flat structure on the dvd and just copy them using the CopyFiles command, because the total size of the directory structure will exceed 4.7GB. Note that running an admin install versus using a zip tool to extract the files is very different! The latter will not adjust the media layout of the media table so that the package is set to use external source files - which is the correct way.
Contents. History NSIS was created to distribute Winamp. It is based on a previous Nullsoft product, PiMP (plugin Mini Packager), and is also known as SuperPiMP. After 2.0a0, the project was moved to where developers outside Nullsoft started working on it on a regular basis. NSIS 2.0 was released approximately two years later. NSIS version 1 is in many ways similar to the classic, but it supports more compression formats.
NSIS version 2 features a new streamlined and supports compression, multiple languages, and an easy-to-use plugin system. In January 2006 NSIS was SourceForge's project of the month. Script examples Hello world! !include 'MUI.nsh '!insertmacro MUILANGUAGE 'English ' Name 'Hello world! ' # Name of the installer. OutFile 'HelloWorld.exe ' # Name of the installer's file. Function.onInit # Function that will be executed on installer's start up.
MessageBox MBOK MBICONINFORMATION 'Hello world! ' # Show a message that says 'Hello world!' Quit # Close the installer because this is a simple 'Hello world!' FunctionEnd Section # Useless section because this is a simple 'Hello world!' SectionEnd Simple installer. !include 'MUI.nsh '!define MUIABORTWARNING # This will warn the user if they exit from the installer.!insertmacro MUIPAGEWELCOME # Welcome to the installer page.!insertmacro MUIPAGEDIRECTORY # In which folder install page.!insertmacro MUIPAGEINSTFILES # Installing page.!insertmacro MUIPAGEFINISH # Finished installation page.!insertmacro MUILANGUAGE 'English ' Name 'MyApp ' # Name of the installer (usually the name of the application to install).
OutFile 'MyAppInstaller.exe ' # Name of the installer's file. InstallDir ' $PROGRAMFILES MyApp ' # Default installing folder ($PROGRAMFILES is Program Files folder). ShowInstDetails show # This will always show the installation details. Section 'MyApp ' # In this section add your files or your folders. # Add your files with 'File (Name of the file)', example: 'File '$DESKTOP MyApp.exe' ($DESKTOP is Desktop folder); or add your folders always with 'File (Name of the folder).' , always add your folders with an asterisk, example: 'File /r $DESKTOP MyApp.'
(this will add its files and (with /r its subfolders)). SectionEnd Concepts. # Example script Name 'Example1 ' OutFile 'jubaowu.exe ' InstallDir ' $PROGRAMFILES Example1 ' Page Directory Page InstFiles Section SetOutPath $INSTDIR File. Makensis.exe SectionEnd Modern user interface Version 2.0 introduced a new optional streamlined graphical user interface called Modern UI (MUI). The MUI has a wizard-like interface. It supports a welcome page, finish page, language selection dialog, description area for components, and greater customization options than the old user interface.
# Modern UI example script!include MUI.nsh Name 'Example 2 ' OutFile 'Example2.exe '!insertmacro MUIPAGEWELCOME!insertmacro MUIPAGELICENSE 'license.rtf '!insertmacro MUIPAGEDIRECTORY!insertmacro MUIPAGECOMPONENTS!insertmacro MUIPAGEINSTFILES!insertmacro MUIPAGEFINISH!insertmacro MUILANGUAGE 'English '!insertmacro MUILANGUAGE 'German '!insertmacro MUILANGUAGE 'French ' Section 'Extract makensis ' SetOutPath $INSTDIR File. Makensis.exe SectionEnd Since NSIS version 2.30 (Released on 25 August 2007) there is new version (beta) of this UI accessible: Modern UI 2 (MUI2) which is an enhancement to Modern UI. Unlike the old MUI this version is based on nsDialogs instead of old-fashioned InstallOptions.ini files. From version 2.34 (Released on 24 December 2007) this MUI2 is ready for mass consumption and it is included in all NSIS packages. Also all examples had been switched to it. Modern UI 2 documentation.
Graphical interfaces NSIS projects can be configured by simply editing text files (with.nsi extension). However, several third parties provide editing software:. EclipseNSIS is a module for the platform. It allows NSIS scripts to be edited, compiled and validated. HM NIS Edit (freeware) editor with support of custom or plug-ins. Venis (freeware) editor.
Visual & Installer is an add-in which integrates NSIS with IDE and allows to create and build NSIS projects right within it. Installer interfaces Several projects that extend or replace the Modern UI have started in the past few years. Interfaces such as the ExperienceUI and UltraModernUI completely change the style of the installer by skinning it to look like the interface.
Other interfaces like installSpiderUI aim for a more minimalistic approach on the visual side of things while maintaining the same level of functionality as the ASD. Plugins NSIS can be extended with that can communicate with the installer.
Plugins can be written in any unmanaged programming language capable of building a (such as C, C or Delphi), and they can be used to perform installation tasks or extend the installer interface. A plugin can be called with a single line of NSIS code. Several plugins come with the NSIS package that permit the installer to display a splash screen, display a custom page, display an image on the background, download files from a website, perform mathematical operations, patch files and more. Other plugins are available online, including ZipDLL, and a plugin.
Features NSIS supports the following features:., and compression. Script-based. Multilingual. support. Script Generated installer The generated installer is a, with the installation files archived within the installer, a 34 KB overhead for the NSIS installer, and the installation script compiled into executable code. As the installation script is compiled, the script cannot be obtained from the delivered executable without reverse-engineering the binary.
The archive may be unpacked using either, the plugin 'InstallExplorer', or the predecessor by the same name for the. The archive contains several folders:. $PLUGINSDIR: installation routine plugins. $INSTDIR: files used during the installation. $OUTDIR: files to be installed. The generated installer includes command line arguments in order to give users more control:.
/NCRC disables the CRC check, unless the script forces it. /S runs the installer/uninstaller silently. /D sets the default installation directory.
It must be the last parameter and must not contain any quotes. Only absolute paths are supported.
Unicode support Versions of NSIS before 3.0 did not support Unicode, but only a means to convert some files to different encodings via a plugin. However, a variant of NSIS that has full Unicode support is available. Notable projects using this variant are:. for Windows. (, ). With the release of version 3.0 of NSIS, Unicode support can be implemented using the compiler directive 'Unicode true'.
This gives full Unicode support with no further code changes, but the installer will not run under Windows 95/98/Me. As of 2016 before the 3.0 release NSIS was available in the format for Unicode 2.46.5 Rev 3 and ANSI 2.51. See also.
Sunjammer 12th February 2003 20:26 UTC darkboy 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. Virtlink 14th February 2003 12:28 UTC 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. Sh0e 28th March 2003 03:42 UTC 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. RDaneel 28th March 2003 19:51 UTC 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.:). Sh0e 28th March 2003 20:07 UTC 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. 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 28th March 2003 20:51 UTC 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.;). RDaneel 28th March 2003 21:10 UTC 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.
Sh0e 28th March 2003 21:30 UTC 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.
Sh0e 28th March 2003 21:51 UTC 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.
RDaneel 28th March 2003 21:52 UTC 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. Sh0e 28th March 2003 22:08 UTC 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 28th March 2003 22:33 UTC 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 29th March 2003 17:35 UTC 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 29th March 2003 20:16 UTC 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. Ippi 29th March 2003 22:40 UTC 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 30th March 2003 13:57 UTC 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. Joost Verburg 30th March 2003 17:07 UTC A compiled installer has three parts: 1. 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'). Sh0e 30th March 2003 17:36 UTC 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. Sh0e 30th March 2003 17:52 UTC 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. Ippi 30th March 2003 18:54 UTC 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. Virtlink 30th March 2003 19:10 UTC 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.:weird: 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. RDaneel 30th March 2003 19:35 UTC 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.:weird: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.
Ippi 30th March 2003 19:45 UTC 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.:weird: 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). Joost Verburg 31st March 2003 14:23 UTC Originally posted by RDaneel 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.So there is still no need for encryption. These files will be installed depending on the OS and user selection. Mesurf 6th October 2008 00:22 UTC Originally posted by Joost Verburg Getting the script from a compiled installer is almost impossible.Well you can use 7Zip to extract an NSIS installer. Also I found that Avast also scans for viruses inside the isntallers which is nice.
I was gonna make an installer to hack concurrent connections to winxp sp3 for my mce box, then i found that somebody else already made an installer for that, but i wanted to make sure it was virus free any who. It is an can be found here if anybody cares about concurrent terminal sessions in XP (like it was in the early builds prior to GM.) Peace.