processing for NSIS installers about assemblyline HOT 9 CLOSED

The nsidis project was used as a base into my fork of the nrs project. It is very incomplete but it is a good starting point to get the main elements decompiled. Any request for improvement on the current decompilation should open a new ticket with a specific element that is wanted, as there are probably hundreds and it would take too long to handle them all.

from assemblyline.

Those decompilers are very old and not really functional. Both python ones are based on python2 and the C++ one has some files for windows XP. I may be able to build it using Dotnet-Vcxproj but that's also relatively involved.
Do we know what we're supposed to extract, and how?
The example given was c2a13d7d4d2ca6bef8ebdb914943563a1b583d03cf093f03fc3ac5e9cb9e5485, which already extracts a few files.

from assemblyline.

7zip 15.05 extracts a sixth file [NSIS].nsi with a hash of 609dcf661ae9b3596074efe9e0a36aebed542fe7d1ad4446378d2b9fd4d6fcd4.

from assemblyline.

7zip doesn't want to handle NSIS: https://sourceforge.net/p/sevenzip/bugs/1544/

Another note from Igor:

nsis can use bzip2, but it's modified bzip2.
7-zip can't unpack that modified bzip2.

from assemblyline.

Does the NSIS.nsi file provide anything of interest?

Would want to evaluate if this is a feature that's super important for detection or not at all.

from assemblyline.

Here are my last notes:
Since the goal of the issue is to be able to extract the equivalent of [NSIS].nsi from the NSIS installers, I tried to find a bit more information on what it is.
This blog post has a bit of information about NSIS installers and talk about it in section 2 : https://malcat.fr/blog/reversing-a-nsis-dropper-using-quick-and-dirty-shellcode-emulation/
I believe section 2.2 identify that [NSIS].nsi file and call it the SETUP script.

This post is full of information related to the removal of the extraction of the SETUP script in 7z : https://sourceforge.net/p/sevenzip/discussion/45797/thread/5d10a376/#6e1d/3fa3/6840/fe9c
The linked post has a link to the source code of 7z 15.05, which was the latest version supporting the extraction.

Out of the original three tools that are linked in the Can_I_decompile_an_existing_installer page, I concentrated on both python libraries.

• nsidis (https://sourceforge.net/projects/nsidis/) has some interesting documentation, mostly in nsiDecomp.txt, but was created for python2 and has a few issues even when trying to convert the code to python3
• nrs (https://github.com/isra17/nrs) works on python3, but doesn't look to have anything related to extraction of the SETUP script.

The nsidis look to have the code needed to extract the SETUP script, so I am looking into extracting a few functions from nsidis and use nrs as the backend parser of the NSIS structure. The compression handling of nrs is much better, handling all three instead of only one, but the block IDs are hard-coded while nsidis had them determined dynamically. A lot of improvement can be taken from one library to the other.

As you said, generating the SETUP script just for the sake of having it is not useful. There are interesting actions that can be extracted from the script, like registry key manipulation and even the ExecShell keyword. I do not know how long it will take to extract, adapt and validate the important bits of nsidis, and if it is justified in term of time.

from assemblyline.

If we can compile 7z v15.05 for linux from source code, we could package it in this module, or make an independent module that would only run on that filetype.

from assemblyline.

Two options are available.
First option: Make a completely new, independent module into which we can install a very old version of 7z from 2015, if we can compile it to run on linux.
Second option: Reuse what was done in the nsidis project but adapt it to the newer nrs project. I started going that route and was able to port all the code over. What was covered in nsidis is now covered in my fork of the nrs project, more specifically, on the nsi-script branch. The previous PR made it available for the Extract module.

There is still a very large amount of work left, if we want to get to 7z's level. The 7z file that was extracting the nsi script is about 6000 lines long. It is handling special Park encoding, Unicode, and a lot of other edge cases. It may still be a very valid option to remove dependencies on nrs from Extract and go toward creating a new service based on the very old 7z version.

At the current moment, the nsi Extractor is part of the nrs library, but could very easily be in Extract itself, which may make it easier to raise heuristic on certain features/keys of the nsi script.
I believe that there is no official pattern that would make the resulting text file be identified as a NSIS script, but we could mimic 7z in always starting the file with a line starting with ; NSIS script. If we go the 7z module option (or mimic it), a new Identify line looking for that comment could be added the day we want a service to analyze the nsi scripts.
The person requesting the script didn't have any precise element that needed to be extracted from the script, so I believe we can use what was done, until more requirements comes up.

from assemblyline.

Was this fixed ?

from assemblyline.