!packhdr and VMProtect packer

underline
24th June 2010 18:35 UTC

!packhdr and VMProtect packer
Hello,

I try to pack the header of my NSIS script using !packhdr command and VMProtect protector (vmpsoft.com). The issue is that VMProtect is unable to replace the file to be protected with the protected file. If the file to be protected is "exeheader.tmp" then the protected file will be "exeheader.vmp.tmp".

__________________________________________
Command line version for VMProtect looks like:
(VMProtect_Con.exe is the command version file)

VMProtect_Con File Output file -ProjectFile -ScriptFile

File - the name of the executable file that should be protected (*.exe, *.dll, etc.) or the project file name (*.vmp). If a project file is specified as the source file, the name of the executable file will be taken from the project file.

Output file - the name and path to the protected file that should be created after the source file is processed. If the parameter is not specified, its value is taken from the project file.

Porject file - the name and path to the project file created in the ‘Expert’ mode mode. If the parameter is not specified, the folder with the executable file will be searched for in the project file (*.vmp).

Script file - the name of the file containing the script that will be used to process the protected file. If the parameter is not specified, the folder with the executable file will be searched for the script file (*.vms).
__________________________________________

Now if I try this:

!packhdr "$%TEMP%\exehead.tmp" '"${NSISDIR}\Packhdr\VMProtect_Con.exe" "$%TEMP%\exehead.tmp" "$%TEMP%\exehead.tmp" -exehead.tmp.vmp -exehead.tmp.vms "$%TEMP%\exehead.tmp"'

the installer header is not packed, but if I try this:

!packhdr "$%TEMP%\exehead.tmp" '"${NSISDIR}\Packhdr\VMProtect_Con.exe" "$%TEMP%\exehead.tmp" "$%TEMP%\exehead.tmp" -exehead.tmp.vmp -exehead.tmp.vms "$%TEMP%\exehead.vmp.tmp"'

and I check the TEMP folder then there I see that the installer header file "exehead.tmp" were corectly packed as "exehead.vmp.tmp" but ofcorse not applied to the installer exe.

Maybe the solution is to create a batch file or is there any way to use an packer that is unable to replace the file to be packed with the packed file as UPX do it?

Please let me have your suggestion or solution!

Thanks!!!

Afrow UK
24th June 2010 20:00 UTC

Just use a batch file.

Stu

underline
24th June 2010 20:10 UTC

Thanks Afrow!

I did it and works and this also thanks to one of your old posts:

http://nsis.sourceforge.net/Using_!packhdr

Now I can see that even packed, I can still extract using an universal unpacker the script file (script.bin) with every installer command information. This universal unpacker can't extract VMProtect exe packed file but seems the NSIS exe header is not the area with install information and install settings which is exactly what I want to protect using this packer.

Any suggestion to protect my NSIS installer on same way to avoid unpacking of the file with the NSIS information and settings?

Thanks!

Afrow UK
24th June 2010 20:14 UTC

This was asked a while back and you'd need to change the values of some constants in the source code and recompile NSIS (I forget which constants - probably in the lzma headers).

Stu

underline
24th June 2010 20:28 UTC

I will be very interested to find out this post but don't know how to locate it. Any suggestion?

I don't use LZMA, I use /SOLID BZIP2 as can't be extracted with 7zip

Afrow UK
24th June 2010 20:33 UTC

Wait a minute, it IS the header that contains the script code. Are you sure VMProtect is working?

Stu

underline
24th June 2010 20:44 UTC

I am sure that VMProtect is working because after protection the installer.exe size was increased with ~ 200k and also when I open installer.exe with an Hex Editor (HexWorkshop), I can see the VMProtect signature (VMP0 and VMP1) at the beginning of the installer.exe

Afrow UK
24th June 2010 20:46 UTC

Then perhaps it's not protecting well enough? The script code is definitely in the installer header.

Stu

underline
24th June 2010 20:48 UTC

Hmm, I will try to switch some protection settings and see if the result is the same and also I will try AsProtect as an alternative and see if the same result then I will let you know.

underline
24th June 2010 21:15 UTC

Done it with AsProtect and I have the same result!

My batch file is together with the packer inside \NSIS\Packhdr and looks as below:

cd /d %~dp0

Move %1 exehead.tmp

ASProtect -process ASProtect1.aspr2

Move exehead.asp.tmp %1

del exehead.tmp

and inside nsisconf.nsh I have added next line:

!packhdr $%TEMP%\exehead.tmp `"${NSISDIR}\Packhdr\asp.bat" "$%TEMP%\exehead.tmp"`

and I can still extract the script file with main script commands and that is exactly what I want to avoid.

underline
24th June 2010 21:57 UTC

After some tests I see that the exehead.tmp file which NSIS installer use it to pack is only 60k on size (not packed) but the script.bin file extracted with the Universal UnPacker is 120k on size so I think that the exe header is packed but not the very important NSIS information because if I look inside script.bin I can see the paths where NSIS extract the files, http links from where NSIS download updates, passwords for 7zip protected files and more... and those informations should be protected with the packer but don't know how to do it as seems that !packhdr don't do its job as expected...

Afrow UK
25th June 2010 10:53 UTC

There is no problems with !packhdr. UPX and Resource Hacker work just fine with it. What exactly are you using to read the script after packing?

Stu

underline
25th June 2010 11:05 UTC

Resource Hacker is used only to remove first installer icon. This works.
UPX is very common packer and can be easy unprotected.

I sent you a private message with the name and link for the unpacker.

Afrow UK
25th June 2010 11:54 UTC

Looking at the Universal Extractor forums the developer has asked for ASProtect samples so it looks like he could have cracked it?

Stu

underline
25th June 2010 12:06 UTC

AsProtect is an old protector but can't be cracked by this UnivExtractor! It is very hard to crack AsProtect and can be done only manually and not on all situations (depending on protection settings).

As a proof, If I pack any exe file even the NSIS installer exe with AsProtect and then I try to unpack it using the unprotector then the unpacking Failed so is not able to unpack any AsProtected file.

If I try the same with the NSIS installer with exe header packed using !packhdr then the extraction is completed.

This should be the proof that something is wrong with the !packhdr or maybe don't pack the full exe header and important information/settings are left not packed. This can explain why exehead.tmp is only 60k and when script.bin is extracted with UnivUnpacker that file is 120k. So the difference of 60k should be what !packhdr left behind unprotected?

underline
25th June 2010 14:29 UTC

I think that NSIS keep the installer instructions not protected and protect only exe header which don't have inside any installer instructions. If this is the situation then I will create an Function to obfuscate the installer instructions based to an unique hardcoded key so if the script.bin is extracted the installer instructions inside will be obfuscated and everything is protected without using a packer. I think that this is the real working solution and after some tests I see that this works.

Afrow UK
25th June 2010 17:07 UTC

That's interesting. I guess I just assumed the script code was included in the overhead but perhaps not then. Best ask kichik about it.

For obfuscation would you mind telling us your solution? I think a lot of people have asked for the same thing in the past.

Stu

underline
25th June 2010 18:45 UTC

I will try to understand where is the issue with !packhdr and how NSIS can be modified in order to fix that so I hope kichik will see this post and will come with an suggestion if any.

About obfuscation I will consider your suggestion when I will finish the function.

Animaether
25th June 2010 19:09 UTC

Isn't obfuscation semi-moot? The extracted script file (I extract files with a total commander plug-in, but the script.bin is the same as with Universal Extractor; probably uses the same binary underneath the hood) contains a ton of binary data and, lastly, a bunch of strings. E.g.


\NSISArray.dll LoggerCreated ExistsI LoggerExisted Push ý‚€\ #32770 ý€ 1016 0x1004 ýš€\System.dll 1024 Alloc *(i, i, i, i, i, i, i, i, i) i (0, 0, 0, 0, 0, r3, 1024) .r1 Call User32::SendMessageA(i, i, i, i) i (ý€€, 0x102D, ý‚€, r1) *ýƒ€(&t1024 .r4) -8 ... 100% 15 Create folder:  D: ý†€
 -> Created Directory: ý†€
 Output folder:  d: ý†€
 -> Created Directory (implicit):

Which is all very fascinating, but in no way that -I- or a layman is going to be figure out just what it all means.

Even if you grab up the old 7zip that decompiles it into a script file, you get things a la:
( I can't even find the above strings in the result, so this is another section )


StrCpy $0 "614.4" -2
FileWrite 54 6055 0
Pop $0
CopyFiles 74 6098 1556
Execute 6141 1 1
Call 491
Pop $[56]
Push $0
StrCpy $0 "617.4" -2
FileWrite 54 6179 0
SerCtlColors 74 0 0

Which goes on and on and on... I guess I could encrypt the strings and use some IntOp bits and pieces to decrypt them at run-time if I really felt like even the above information is too revealing
But obfuscating the source script code (e.g. through defines) would only really have any use if I were sharing the script file (perhaps a header) that I want people to be able to !include... yet not be able to read easily. Otherwise, somebody's just going to go through the trouble of disassembling the binary and try to turn it into some form of script such as the above ( with 'SerCtrlColors' and more ).

And if somebody is -that- interested in trying to figure out what your scripting does, then no obfuscation is going to help anyway. I daresay that somebody who wants to go through that trouble will probably happily look up asprotect removal instructions and put those to work, too.

Finally.. if what you are trying to protect is not so much the installer, but the program you are installing, then the installer is the wrong place for any protection whatsoever.
clean VM + a successful install = everything a person needs to copy your software, presuming it is generic for all people installing it.

underline
25th June 2010 19:16 UTC

What I need to protect is not the files inside the NSIS installer, is the installer binary where install instructions can be easy readed and on some cases we don't like end user to see that our installer use x resources and install on y folder and use z password or any http link used for updates. Obfuscation make those information invisible in the installer binary and without a proper key used for obfscation there is no chance to restore those information and this without use any packer as I just see the exe header packing is not a solution. I will just obfuscate NSIS installer instructions visible inside the binary file and this is enough as the files inside are already protected before add them to the installer.

Animaether
25th June 2010 19:42 UTC

That's my point, though... anybody with a mere modicum of interest in finding out what your installer does may fire up e.g. filemon to see what files you're working with, regmon to check for any registry key values you might be setting, tcpmon to monitor network connections, some other tool to see exactly what is inside the TCP packets, etc.

I'm not saying it's -entirely- pointless - just saying: is it worth the effort?
If for you the answer is 'yes', then you should certainly proceed :)

underline
25th June 2010 19:47 UTC

you're right but the main intention is to obfuscate password used to encrypt some files inside the script and some of the tools you talk about can be detected and rejected with an incompatibility mode function...

underline
25th June 2010 20:24 UTC

Originally posted by Animaether
That's my point, though... anybody with a mere modicum of interest in finding out what your installer does may fire up e.g. filemon to see what files you're working with, regmon to check for any registry key values you might be setting, tcpmon to monitor network connections, some other tool to see exactly what is inside the TCP packets, etc.

I'm not saying it's -entirely- pointless - just saying: is it worth the effort?
If for you the answer is 'yes', then you should certainly proceed :)

With other words:

filemon - can see the files but if are packed/protected user can't analyze them
regmon - can see registry but don't help very much if the detected files are packed
tcpmon - upload/download files are also packed/crypted or password protected

If together with all those methods the exe header is obfuscated then is very hard for the end user to understand and analyze the script. Please correct me if I am wrong.

Animaether
25th June 2010 21:07 UTC

My notes with regard to filemon, regmon, tcpmon were with how your installer operates and its end-result (installed files / an application) and how obfuscating your installer itself is moot if the end-result is what you're trying to protect.

As an example.. let's say I have a very simple script and a file that it installs, file_A.txt, that contains some information.. say "Hello World".

You know that users can extract the files with utilities out there, so you encrypt the file (becomes "Hsa0hUq-skq") using a key that you do -not- store anywhere in the installer (so you don't have to worry about obfuscating/etc. either), and store its original CRC/MD5/whathaveyou.

Now your installer asks the user for the installation key. The user enters the key, the installer decrypts the file, and checks its CRC to make sure the user entered the correct key before continuing with further decryption of other files. Note that any hacker can then try whatever other key they like and force the installer to believe the CRC is correct to let the installer continue, but all of the decrypted files are going to be corrupt as the key was incorrect (result "iaQ-1jUbq9z") unless they happen to guess right.

Now here is the problem in the above: at the end of the installation, if the correct key was entered, file_A.txt is going to have "Hello World" just fine.

filemon.exe is going to see the file_A.txt write-out, and if I'm interested in your files, I'll just grab it from there. Now presume I'm somebody with ill will, and the key you gave me is going on some popular forum the same night.

So what did the encryption in the installer accomplish in this case? Not a whole lot.

So you'd have to combine that with machine-specific details to combine the key the user should enter with those details in order to get the correct key. Of course that means you now need remote authorization (i.e. connect to the internet).
But even that is moot because instead of handing out the key.. why would an ill-willed person not just take file_A.txt, with the correctly decrypted "Hello World", and upload that to such a forum?

That's what I meant by the installer not being the correct place for protection of a product you're installing; by its very nature, an installer is ill-suited for it.

If you're trying to protect the installer itself, that's another matter entirely, where obfuscation and encryption of the strings can go a long way to at least stop some random joe from grabbing UE or the old 7zip and having a peek at the installer's code (which, again, comes out pretty ugly as it is).. but it won't do a whole lot for that which it installs.

underline
25th June 2010 21:22 UTC

Very interesting point of view and complete description! Thanks!

I will take it into consideration.