BTW some hackers do come to codeguru.com, what if they come to know your super idea ? :pQuote:
Originally Posted by DeepT
Printable View
BTW some hackers do come to codeguru.com, what if they come to know your super idea ? :pQuote:
Originally Posted by DeepT
If you're referring specifically to a Windows program, the answer is probably "No". However, Windows isn't the only OS. Indeed, it isn't strictly necessary for a computer to even run a host OS. Many devices use "embedded systems" where an application gets run directly from an EPROM.Quote:
Originally Posted by DeepT
However, even this isn't foolproof. There's nothing to stop a determined hacker from removing the EPROM and analysing its contents.
The bottom line is that nothing is 100% safe. Once you release your code - no matter what form you release it in - you run the risk of someone analyising it or copying it. The only method of protection that's 100% safe is never to release the code!!
Am I missing something? How can you can decrypt the exe without the user peeking into your decryption key?
edit
No, you have to write a driver to do that job.Quote:
Originally Posted by DeppT
Why user comes into picture ? the program internaly decrypts the resource contents into memory.Quote:
Originally Posted by kumaresh_ana
Yes I get it. What I cannot get is : The loader as the OP says needs to know the key; a simple disassmebly of this app could reveal the key to the user. Then the user can decrypt it himself and all your work of loading app without writing to disk is defeated.Quote:
Originally Posted by Krishnaa
edit
what do i mean by the user is hacker.
The first step I would do is to run your app under system debugger like SoftICE, and make a whole process snapshot in its running state. :DQuote:
Originally Posted by DeepT
All decyphered modules running from anywhere (file or memory) will be unveiled in running state. Oops...
To avoid this various other issues you can strip the crucial data off your exe and encrypt only that data file.Quote:
Originally Posted by DeepT
AFAIK, no crypto principle is available to do the service you are asking for (this suggests me that we are missusing the crpto). Crypto always assumes that "a secret key is always secret". If you can peek into the system memory then the very assumption goes wrong.
Yes, I know nothing is "full proof". I am not trying to get a "full proof" system.
I just do not want the program to be a cakewalk to crack. An encrypted EXE will make it a lot more difficult, and yes, the casual hacker is of bigger concern then mr. super hacker. Someone will crack it, I just do not want it to be too easy for them.
Right now, a big area of deployment are campus networks. Campus networks, by their nature, have a lot of curious comp-sci majors who like to take a stab at cracking our product. It is very uncommon for someone to actually examine our exe very closely, but once in a long while someone will and ask a question about something they shouldn't (meaning they were nosing around in our EXE).
An extra layer of encryption on the exe itself, would reduce even this snooping.
Even then, I am quite aware that someone, somewhere will still get by any encryption I do.
Ok, a slightly different angle of attack. If I can not encrypt and load an exe into memory, is it possible for a single exe to be partially encrypted, maybe like having a header that can decrypt the rest of the exe and then jump to a new section of code that was previously decrypted?
True, but you can always hide a key in a forest of keys. Again, not full proof, but certainly beyond the "worth the effort" threshold of most would-be hackers.Quote:
Originally Posted by kumaresh_ana
Yes, it is always possible. Exe packers always do that. the unpacking code will be available as a section and all others (packed) will be different sections. On runtime the unpacker section will unpack the remaining sections readying for the execution.Quote:
Originally Posted by DeepT
Ok, great. How do I do that?Quote:
Originally Posted by kumaresh_ana
Sorry I cannot help you in this. I just know it can be done.
1. During build time encrypt the portion and build it into the exe? :confused:
2. Decrypt the portion and write it in the memory? :confused:
You will need to understand the PE format first, there is a section inside executable where the code (assembly) is stored, packers generaly take that and encrypt it, add new code which gets executed when the exe is run, and then this part decrypts the original code and places it in it's original position. Packers also use some *algorithms* to optimize and alter the code in a way to make it harder to analyse.Quote:
Originally Posted by DeepT
Not build time, after the build, you should have a separate program to alter the binary, otherwise you are giving away your logic to others. :)Quote:
Originally Posted by kumaresh_ana
Yes, thats what I meant. but slipped about. :D