Quote:
|
Originally Posted by dyn!o
The problem is the moment when your code gets decrypted. No matter which AES you chose - there exists always possibility of unpacking the application. I mean crackers always have the possibility of obtaining at least one valid key
|
But imagine this:
My EXE is encrypted with key value 64 (it's a very simple example
).
I insert into the EXE the hash code of 64.
When user runs in his PC gets HW-ID value 4.
When he sends me value 4, I send him value 60.
Then EXE program adds HW-ID(4) + my unlock code (60). Hash of this sum is equal hash inserted in EXE.Unpack succesfull.
He sends the valid key to a cracker (60) and the cracker have another HW-ID (18). Hash not equal.Unpack not succesfull. If cracker changes JE/JNE or nop's jumps, EXE file is not valid.
Obviously the algorithm must be more complicated that 60+4
How then a cracker can unpack this EXE?
or do you mean that cracker buy a legal code and then unpack?
then I understand...Protect must be in another direction...
I'm with yours about VM or emulating CPU it's the future and with these systems can be more difficult to crack APPS.
Using server side app it's not indicated, not everyone have internet in his PC.
With this project I'm only "playing" in the other side of the board.
Anyone have info about VM or CPU?
Regards