Securing an exe

I did something similar to this one time.  I made one program to "encrypt" the wrapped exe by switching some of the bytes to invalid bytes.  That way it wouldn't execute.  Then I changed the extension to .dat.  Then, I made the wrapper exe do the opposite of the encrypt exe.  It was pretty easy and worked.  I don't know how secure this is, but it is uncrackable to the avg windoze user I would say.

jk

I know, but when I want to execute the exe I need to extract the exe, then execute it, and when it's done, delete it.
The problem is when the original exe is running someone can just copy it and paste it somewhere else

yes, i forgot about that, but i of course enountered the same issue

what i did was extract the exe to the user's temp directory.  i named it some random characters like 1lKJGA.exe or whatever.

this is still crackable, when the user runs the file, he can look at running processes and see that there is the regular process, i.e. "Wrapper EXE Name" or whatever, but also another process with a weird name

a good user could track this down.  i decided to live with that potential security issue and use this technique anyways

sorry i forgot about that

jk

the only other option i can think of is to build the trialware abilities into the main exe, and not use the wrapper exe

however, i understand that you probably would have done that if you had the option

this is the only solution i came up with when i had a similar problem

Do you have any control over the source code of the main program?  A very small change in it would simplify this task and make it much harder to break to protection.

-- Dan

You can always set registry values during the install and have the .exe file check them.  If the values aren't set, or aren't set correctly, the .exe quits.

Write the "obvious" stuff in the registry,

HKEY_LOCAL_MACHINE\\SOFTWARE\\COMPANY_NAME\\PROGRAM_NAME

Then write an obscure variable in some other place like

HKEY_CURRENT_USER\\SOFTWARE\\COMPANY_NAME\\PROGRAM_NAME


Not foolproof, but it will slow most fools.

Then again, you can get REALLY creative in what you place in the registry, where, and how.  ;)

Kdo

I'd have to agree w/ Dan on that one.  If you can control the source of the main prog that is a much better option.

You can always set registry values during the install and have the .exe file check them.  If the values aren't set, or aren't set correctly, the .exe quits.

Write the "obvious" stuff in the registry,

HKEY_LOCAL_MACHINE\\SOFTWARE\\COMPANY_NAME\\PROGRAM_NAME

Then write an obscure variable in some other place like

HKEY_CURRENT_USER\\SOFTWARE\\COMPANY_NAME\\PROGRAM_NAME


Not foolproof, but it will slow most fools.

Then again, you can get REALLY creative in what you place in the registry, where, and how.  ;)

Kdo

I always wondered of the system would read an EXE from a NamedPipe.  If it would, then you could create one containing the in-memory image of your decompressed/decrypted EXE so that it would never be written to disk.  Just a thought (I don't have time to test this theory today).

-- Dan

I can't extract the exe to a temp directory, since most exe's rely on the path of the app for their external files.

I have no control over the source code

>>since most exe's rely on the path of the app for their external files.

That's going to be a problem regardless of the technique used, isn't it?  Certaintly any technique that excutes the exe directly from RAM would be a bit confused...  But if it has a problem when being loaded from a temp directory, it would also have a problem when being loaded from a non-temp directory.

I think you have just ruled out all possible solutions.  I therefore propose this as the answer (feel free to write it down and laminate it for your wallet):

It can't be done.

-- Dan

Nop, that isn't an answer, since

1. I still have the problem
2. Perhaps it's possible to disable read access or something? I just don't know how...

i can be done.

look at UPX
this program packs the executable and modify's the entry point to execute the upx code, and when this executable is execute this upx code unpacks the original executable and execute's it.

but i don't know how to do that :s

No comment has been added lately, so it's time to clean up this TA. I will
leave a recommendation in the Cleanup topic area that this question is:

Answered: Points to DanRollins: Grade A

Please leave any comments here within the next seven days.

Experts: Silence means you don't care. Grading recommendations are made in light
of the posted grading guidlines (https://www.experts-exchange.com/help.jsp#hi73).

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

-bcl (bcladd)
EE Cleanup Volunteer