NSIS decompiler

Question

Anyone familiar with NSIS decompiler (google wasn't :-) )

Thanks, E

Answer 1

How to access the NSIS Installer Script?

Okay that's the big topic for that post.

http://netcologne.dl.sourceforge.net/project/nsis/NSIS%202/2.09/nsis-2.09-src.tar.bz2

nsis-2.09-src\Source\exehead\fileform.c
nsis-2.09-src\Source\exehead\fileform.h

#define FH_SIG 0xDEADBEEF

// neato surprise signature that goes in firstheader. :)
#define FH_INT1 0x6C6C754E  // 'Null'
#define FH_INT2 0x74666F73  // 'soft'
#define FH_INT3 0x74736E49  // 'Inst'

typedef struct
{
  int flags; // FH_FLAGS_*
  int siginfo;  // FH_SIG

  int nsinst[3]; // FH_INT1,FH_INT2,FH_INT3

  // these point to the header+sections+entries+stringtable in the datablock
  int length_of_header;

  // this specifies the length of all the data (including the firstheader and CRC)
  int length_of_all_following_data;
} firstheader;

Data Sample:

$ ==>  00000000  ....
$+4    DEADBEEF  
$+8    6C6C754E  Null
$+C    74666F73  soft
$+10   74736E49  Inst 
$+14   000268E2            157 922  length_of_header (inside <<Compressed Data>>)
$+18   011947CB         18 433 995  length_of_all_following_data
       <<Compressed Data>>

$+011947CB CRC32

Getting <<Compressed Data>> Uncompressed

Well this data is written to %temp% however with ShareMode=None and Attributes = DELETE_ON_CLOSE so you can't access it.

Fix:
    Inside 'NSIS Setup.exe'
Replace 
    68 00 01 00 04 with
    68 00 00 00 00
    To avoid that this tempfile get's create with DELETE_ON_CLOSE

Background:

    00402E56  |.  68 00010004   PUSH    4000100                          ; |Attributes = TEMPORARY|DELETE_ON_CLOSE
                  ^^^^^^^^^^^-Patch Target
    00402E5B  |.  6A 02         PUSH    2                                ; |Mode = CREATE_ALWAYS
    00402E5D  |.  53            PUSH    EBX                              ; |pSecurity
    00402E5E  |.  53            PUSH    EBX                              ; |ShareMode
    00402E65  |.  68 000000C0   PUSH    C0000000                         ; |Access = GENERIC_READ|GENERIC_WRITE
    00402E6A  |.  50            PUSH    EAX                              ; |FileName
    00402E6B  |.  FF15 90704000 CALL    [<&KERNEL32.CreateFileA>]        ; \CreateFileA

Okay that big <> Uncompressed temporary file starts like this:

00000000   E2 68 02 00 A0 00 00 00  2C 01 00 00 08 00 00 00  2C   âh      ,       ,

E2 68 02 00 -> 000268E2 157 922 length_of_header (inside <>)

Just cut out this datablock and well have the NSIS script as uncompressed Raw

The rest of data are data files that 7z will extract for you.

Update: Get Universal Extractor

It uses

cmdTotal 1.02 (c) 2006/2007 KaKeeware, http://www.kakeeware.com

with plugin: InstExpl.wcx

to more or less successfully extract a Nullsoft Setup.exe. Be careful don't trust much on the extracted files - there are somethings corrupted. (Prefer 7zip for that.) However the main thing of that procedure is the script.bin That was on the 3-4 example I test in good shape. :)

Okay an update: Here's an really early version of my NullsoftDecompiler 1.2 alpha

At the moment it's still heavily under development however here's the first raw unfinished version of it.

UPDATE(About a year later): NullsoftDecompiler 3 Finally I added decompression support.

Answer 2

Google it again.

NSIS "Can I decompile an existing installer"

Short answer: no.

Long answer: it might be possible using 7Zip or other decompresser but there are no guarantees and would likely take a lot of work to reconstruct the original script.

Answer 3

I assume from your question that you want to reverse engineer a NSIS installer into a Windows Installer database. There are commerical programs called "Repackagers" that basically capture the state changes made by a given process or installer and transform them into an MSI project. Note that these programs only capture 1 instance of the business rules from the NSIS package. Sometimes it is needed to run the process more then once, anaylize the behavior differences and manually author them into your install.

I wrote a blog about this almost six years ago:

http://blog.deploymentengineering.com/2004/12/chriss-rant-about-repackaging.html