NISIS installers compress data using bizp2, lzma or zlib -- I don't know if there are others algorithms--.

At some point in the installation process one of those algorithms has to be applied to certain buffer of data. Of course, that data was readed from the disk --contained into the installer--.

How can I debug a NISIS installer in order to know where the installer files are? What I have to look for?

Note: I can work with OllyDbg or IDAPro.

4 Answers 4


Generally speaking, you can either detect when the data is read from the file (by monitoring functions as ReadFile), or when it's being decompressed (by monitoring the decompression function once you find it). In some cases the program may read the compressed data directly and pass it to the decompression function, but in others it could read some chunk of file together with the header/metadata, parse that header, and then pass only the trailing compressed data to the decompressor. There is no single "right way" to figure out where exactly the compressed data is in the file.

That said, NSIS is open-source and you can just look at the source code to see how it works. There are also ready-made tools to extract files from NSIS installers.

  • 1
    I look for the ReadFile API call and in fact, I was able to find the routine that search the offset for the start of compressed data. Commented Oct 15, 2014 at 15:42

Quick google yields Extract / decompile NSIS

As a more general answer to finding embedded resources, try ExeInfo and its "Rip" feature which scans exe for various file type headers (PE, JPG, AVI....) and then allows to rip the found resources out.


For NSIS installers, you can simply use 7-zip or UniExtract - http://legroom.net/software/uniextract to extract all the files in the NSIS installer


Well, without reject Igor Skochinsky's answer I want to post this more landed in the fact of how to find where compressed data is.

Peter Kankowski wrote:

NSIS authors found a fast solution using marker. It's so simple that you will say: "Why didn't I think about it?!"

Just remember that data in an exe file is aligned by 512 or 4096 bytes. So you don't need to scan the whole exe for a marker, you just need to read 512-byte chunks and look for marker at their start. In pseudocode:

BYTE buff[512];
while(not end of file) {
   ReadFile( 512 bytes into buff)
   if(*(long*)buff == marker) {
       // Marker found!
   // else read another 512-byte chunk in the loop

I believe it's the simplest method; it's also faster than other methods with marker.

So as you can see NSIS installer have some sort of marker. So, just look for the ReadFile API call, follow the program flow until the loops start again an watch for the last jump before the loop repeat it has to have a comparision around.

And there you have the marker.

If you want read more you can visit this very useful article: Self-extracting executables, thanks to Peter for a good adn clean explanation.

  • Well, strictly speaking NSIS uses this approach to find the start of the installation data; and the actual compressed file data is somewhere in the middle of it.
    – Igor Skochinsky
    Commented Oct 17, 2014 at 18:55
  • However the article (or rather the comments) do mention one case I missed: when MapViewOfFile is used to map the whole file into memory, instead of reading it with ReadFile.
    – Igor Skochinsky
    Commented Oct 17, 2014 at 19:00
  • @IgorSkochinsky You are totally right, thats why I tried to apply the extracting algorithms to the data and all of them have failed, because the installation data is not the compressed data the last is some whare inside the former. I have to find the exact offset of the compressed file. Can you help? Commented Oct 20, 2014 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.