NSIS unpacker?

[vserd]

Signature used in NSIS.DLL for detect type archive
EF BE AD DE 4E 75 6C 6C 73 6F 66 74 49 6E 73 74

Code: Select all

ID=EF BE AD DE 4E 75 6C 6C 73 6F 66 74 49 6E 73 74 
IDPOS=4
SkipSfxHeader=1

[icfu]

My new findings, two entries are needed, one with SkipSfxHeader=1 and one without:

Code: Select all

[NSIS_SkipSfxHeader]
Archiver=<path>\7z.exe
Extension=exe
SkipSfxHeader=1
BatchUnpack=1
ID=4E 75 6C 6C 73 6F 66 74 49 6E 73 74
IDPOS=8
Start="^-------------------"
End="^-------------------"
Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp  n*256"
SkipLIST=1
List=%P l %AAQ
Extract=%P e -y %AAQ @%LQ
ExtractWithPath=%P x -y %AAQ @%LQ

[NSIS]
Archiver=<path>\7z.exe
Extension=exe
;SkipSfxHeader=1
BatchUnpack=1
ID=4E 75 6C 6C 73 6F 66 74 49 6E 73 74
IDPOS=21000, 21512, 23560, 25096, 26632, 32264, 34824, 38408, 45576, 47112, 47624, 50696
Start="^-------------------"
End="^-------------------"
Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp  n*256"
SkipLIST=1
List=%P l %AAQ
Extract=%P e -y %AAQ @%LQ
ExtractWithPath=%P x -y %AAQ @%LQ

If an archive doesn't open, add the offset to IDPOS in [NSIS] section. If an archive opens but shows "exe not supported" nothing can be done I think besides waiting for new 7zip version.

Icfu

[XPEHOPE3KA]

If an archive doesn't open, add the offset to IDPOS in [NSIS] section. If an archive opens but shows "exe not supported" nothing can be done I think besides waiting for new 7zip version.

that usually means that the file is suitable for ietotal. So we better should wait for new addons with good filtering (by id & idpos) of calls to ietotal.
See here for better understanding.

[icfu]

that usually means that the file is suitable for ietotal.

IETOTAL is extremely buggy and corrupts data when extracting, often file size correct but binary mismatches.

So, thanks, but no more IETOTAL for me.

Icfu

[XPEHOPE3KA]

Never seen it. IETotal used to unpack wrong files instead of what I choose, but then I unpack another file and get the needed
At least, IETotal can show you the filenames.

[icfu]

You don't see it usually, you have to do a binary file compare. Install an application, then extract archive with IETotal and compare the files.

The newst IETotal is the worst of all, that's why I have reuploaded a less buggier version in my file archive some time ago.

Icfu

[TychoBarfy]

Code: Select all

;Removed 33288, 34824, 36872, 37384, 40968, 47112, 48648, 50696, 57864, 58888, 333800
;Added 33800, 35848, 44040, 53256, 62984, 65032, 54792
;Added again 25096, 34312, 35336, 36360, 47624, 49160
IDPOS=21000, 25096, 21512, 23560, 26632, 32264, 32776, 33800, 34312, 35336, 35848, 36360, 38408, 39432, 41480, 43016, 44040, 44552, 45576, 46088, 46600, 47624, 48136, 49160, 49672, 50184, 51208, 52744, 53256, 54792, 56840, 58376, 59400, 59912, 60936, 62984, 64008, 65032, 135688, 136712, 141320, 147976

Tose in the lines "Removed" and "Added again" are candidates who somtimes
work if the IDPOS is removed and somtimes work if it is added, grmmflll*?

Sometimes if an exe seems to be not supported it is possibly UPX packed.

Had completely overseen the post and the dicussion above

More testing......

[icfu]

I can at least enter all ~100 NSIS archives I temporarily have here.

UPX doesn't have anything to do with unsupported archives as far I can tell. From the about 25 archives in which I get the unsupported message with 7-Zip, only 5 are UPX-packed and after uncompressing they are still unsupported.

Icfu

[TychoBarfy]

I unpacked about 20 or more UPX packed NSIS installers and everyone
was supported after unpacking.

Try ffdshow installers and installers from slysoft, only for example.

I tried your code posted above icfu and it shows me more unsupported
results than my actual IDPOS chain. Even every third file is unsupported
with it.

In the meantime I tested more than 150 exes.

[TychoBarfy]

Code: Select all

;Removed 33288, 34824, 36872, 37384, 40968, 47112, 50696, 57864, 58888, 333800
;Added 33800, 35848, 44040, 53256, 62984, 65032, 54792
;Added again 25096, 34312, 35336, 36360, 47624, 48648, 49160
;48648 if removed TC crashes if ctrl+pgdown on 7z440.exe
IDPOS=21000, 25096, 21512, 23560, 26632, 32264, 32776, 33800, 34312, 35336, 35848, 36360, 38408, 39432, 41480, 43016, 44040, 44552, 45576, 46088, 46600, 47624, 48136, 48648, 49160, 49672, 50184, 51208, 52744, 53256, 54792, 56840, 58376, 59400, 59912, 60936, 62984, 64008, 65032, 135688, 136712, 141320, 147976

[TychoBarfy]

This works with 99 of 110 files. Which is a rate of 90%.
While 6 of the not working are from Slysoft and the other 5 are from
2004 and older (2002).
So if I test more files the rate grows more and more.

Code: Select all

[7Z_NSIS]
Description="7-Zip 3.40 Beta NSIS"
Archiver=%TCMDPATH%\packer\7-zip\7z.exe
Extension=exe_NSIS,exe
ID=33 D2 8B, 55 8B EC 83, 55 8B EC
IDPOS=1024
BatchUnpack=1
Start="^-------------------"
End="^-------------------"
Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp n*256"
SkipLIST=1
List=%P l %AQA
Extract=%P e -y %AQA @%LQ
ExtractWithPath=%P x -y %AQA @%LQ

[icfu]

If you want to IDENTIFY an archive as NSIS you have to use a SPECIFIC string. Your ID string will simply match all Exes...

I think the 90% success rate comes from the IDPOS=8 and SkipSFXHeader=1 scheme I mentioned above.

All IDPOS values for the ID "NullsoftInst" I have found can be calculated using this formula in hex format:
O=8+512*n (O=Offset)

The lowest value for n I have found was 41. So, a string to catch all Exes probably looks like that:
IDPOS=21000, 21512, 22024, 22536, 23048, 23560, etc...

Icfu

[XPEHOPE3KA]

2all
Well, vserd hasn't told you here, but he told it in another place, that what he wrote here has been taken from the nsis.dll source code. So...

[icfu]

The string vserd has mentioned is:
4 bytes plus NullsoftInst

The point is that it is easier to search for "NullsoftInst" than to search for "ï¾­ÞNullsoftInst", you see?

Icfu

[XPEHOPE3KA]

Do you know what search algorithm multiarc uses? There are some search algorithms working better if received a longer string-to-find