Executing a Memory Mapped file

[EagleKeeper]

Scenario:
I have a paranoid client that wants to have a program that can only be run if a security dongle is in place.

Should the dongle be removed while program is running; the program must terminate.
The program itself is unable to be modified; dynamically created by a third party utility.


I can scramble the initial program so it can not be read unless the dongle is in place.


My thoughts are:
I need to create a file in memory - simple enough.
Unscramble the application - simple enough.
Launch the unscrambled application from memory. - Help here ( I think that it is possible).

Win32 API CreateProcess requires a path to the executable, not a handle to a file.

Option 1:
Figure out a way, using the APIs, to create/access a file in mamory that I can actually treat as a file with a path.

Option 2:
Get some utility out in the world that allows me to create a RAM drive dynamically.
Copy the file to it and using CreateProcess, launch it from the dynamic RAM drive.

I do not want to have to modify a user's system to create a "static" RAM drive or install additional S/W.

Option 3:
????

 

[DaveSimmons]

Since you need a path, the file must exist and a clever user could find / copy the unscrambled version whether it is in the temp folder, the program files folder, or a ramdisk.

I haven't messed with folder permissions beyond read-write, but under XP - NTFS can you dynamically create a subfolder of temp or the program files folder of the program where the folder is blocked from Windows Explorer and My Computer but not ShellExecute / CreateProcess?

 

[Markbnj]

Have you looked at Hasp, or any of the other third-party providers? Hasp has been doing dongle-based software protection since the eighties, so if it can be done I suspect they know how to do it.

 

[Mark R]

Couldn't you just install a service that monitors the dongle?

If the service receives notification that the dongle has been removed, it scans the process list for the application and sends a kill message.

Just thought, there may be permission issues with this - the service might not be able to interact with another user's process - but I suppose, it's worth a try.

 

[DaveSimmons]

Originally posted by: Mark R
Couldn't you just install a service that monitors the dongle?

If the service receives notification that the dongle has been removed, it scans the process list for the application and sends a kill message.

Just thought, there may be permission issues with this - the service might not be able to interact with another user's process - but I suppose, it's worth a try.

That's actually the easy part.

The tricky part is that the main app is not dongle-aware so it must be delivered scrambled / un-runnable, then unscrambled to run by the second dongle-checking app.

Once you create an unscrambled, runnable version of the main exe you must somehow keep the user from just copying that unprotected exe with Windows Explorer / My Computer.

 

[xtknight]

Maybe this will help:
http://www.relsoft.net/Articles/Process/ProcessAdvanced.html
http://www.relsoft.net/part1.html

Or use a simple rootkit like HackerDefender to hide the unprotected EXE?

 

[Mark R]

What about this:

Use a service running as a special user to decrypt the exe into a restricted folder. A folder to which the logged-on user has no access.

Use the service account to spawn the exe in its own user context.

 

[EagleKeeper]

Problem is that the client (at this point) does not want to impact the end user system by installing anything on it.

 

[notfred]

I don't think you can actually do this and make it secure without modifying the program itself to check and see if the dongle is attached.

Actually, I don't even see how the heck you're going to accomplish this:
"I can scramble the initial program so it can not be read unless the dongle is in place."

I guess you want to encrypt the app as it's stored on disk, and decrypt it through some 3rd party app to start it, correct? So, you give someone an encrypted file and the key to decode it. The key checks for the presence of a dongle and then decrypts the program.

It seems like it would really be easy for hacker to break your copy protection mechanism with a hex editor, or a decompiler. It seems like it would only take one line of assembly code to make your program ignore the dongle, and start the other app.