Protecting an executable that spawns itself

[cloudmember]

Hi Enigma Team,

While trying to protect an app written for node-webkit (a shell based on Chromium & Node.js
for developing desktop apps in HTML5) I found out that Enigma isn't exposing its API to
new child processes spawned from the same protected executable image:

app.exe:
--> CreateProcess("app.exe" with some modified environment)
--> CreateProcess("app.exe" with some modified environment)
...

This basically means that node-webkit apps cannot be protected by Enigma because
there is no way to interact with the protection system. The user code is always
running in a child process.

Is this behavior by design of Enigma or can I expect a fix for this issue in the near future?

Thank you in advance

EDIT: I'm using the Virtual Box feature with all 3 options enabled. VM and plugins are disabled.

[Alec]

Hi.
Does it work the way it should while not being protected ?
How do you access Enigma API from node.js ?

[cloudmember]

Alec, the protection/boxing is working perfectly. I had to check the "[x] Share virtual system to child processes"
option though. Standalone (w/out Enigma) the app is working as expected. The calls to enigma_ide.dll
fail softly as described below.

enigma_ide.dll is invoked via "node-ffi" which in turn is using "libffi" (foreign function interface).
DLLs are loaded with LoadLibraryEx and functions with GetProcAddress.

It's a slightly cumbersome process (build-wise), but I ruled out any errors in this area by creating a wrapper
DLL that instruments and logs calls to enigma_ide.dll. The wrapper is calling enigma_ide.dll via
import tables.

And indeed, the calls reach enigma_ide.dll, but EP_CheckupIsProtected is returning FALSE
and EP_RegHardwareID NULL.

[cloudmember]

I've managed to put a tiny standalone test case together. Albeit tiny, the download would be quite large (17MB)
due to the dependencies.

Please let me know if you need it and how to send you the download link.

[Enigma]

Hi cloudmember,

The logic you are trying to implement Enigma API calls is quite correct.

The feature you are asking for is really not implemented in Enigma Protector.

But to clarify, why you can't just protect the executable you are running as a child process? What is the problem to do that?

And yes, the link to the whole project would be helpful. Please send it as support@enigmaprotector.com

[cloudmember]

But to clarify, why you can't just protect the executable you are running as a child process? What is the problem to do that?

Because there is only one executable file involved. There *might* be ways
to handle this by providing several *.exe with different file names side-by-side,
but Chromium is a huge project and I'm pretty glad not being forced to compile it myself.

I've sent you the link via e-mail.

Best regards

[Enigma]

Hi,

We are currently investigating the sample you sent - thanks for that!

Btw, there is some another way that you may successfully use. Create a simple C++/Delphi dll that will export some functions, and calls Enigma API functions. Protect this dll and call it's functions from your JS code.
Put this dll into Virtual Box feature when you will protect an exe file.

Such scheme should be working well for you.

PS: our email had been blocked by your server, please keep it in mind, because you may not get any reply from us by email.

[cloudmember]

Thank you, this worked for me!

I could swear that I have tested this already, but I believe I've chosen the "Advanced input"
feature instead of protecting the wrapper DLL with a separate Enigma project.

Best regards

[cloudmember]

I'm experiencing another related issue for which I'm not able to find a secure solution:

The app I'm protecting is using ShellExecuteEx (mainly on PDFs). Since I have to
enable the "share virtual system to child processes", those PDFs will be opened
in processes that have access to the virtual box. Their "open" standard dialogs
are able to see/access files from the virtual box.

Right now I'm coping those PDFs upon invocation into the TEMP folder in the
hope that users won't see where these files are coming from, but this is just
obscurity vs. security

Also, we're unable to QA all those PDF readers to see if they work inside the
WinAPI redirection/emulation. We can't control which reader is the default
on user's machine; we can't install a reader we know it will work inside the
virtual box.

To cut a long story short, I'm looking for a mechanism to temporarily disable
the virtual box for child processes via the Enigma API.

Alternatively, an option "share virtual system to child processes created
from the main executable image (argv[0]) only" will do as well , but I
believe no one beside me and Enigma Team would understand what this
option means

Best Regards

[Enigma]

Hi,

I may imagine few cases how to help you there:
1. Develop a simple application with using PDF ActiveX, which will output a content of pdf file into your own control. So you will not need to use ShellExecute and "share virtual system to child processes", because everything will be handling inside one process only.
2. Try to put the file to the non existing drive. For example, imagine, how many your users may have drive X: ? Put the file to x:\myfile.pdf, this path will be invisible in Explorer, but PDF reader should open it well.

Hope this helps!