make a crypter

[taos]

Hi!!
I'm making a simple packer but I need your help.

When I encrypt a file, the decrypter code is in the EXE but I'm coding a Dll that decrypt the EXE.

EXE program are encrypted with key A.
EXE OEP is changed to make a call to a function (B) in a dll pasing a parameter.
The parameters are all the encrypted bytes of the code section in a loop.
If you have registered the APP then the function B use this unlock code to return the right decrypted byte.

But can be possible?
How can I determine wich could be the unlock code in the PC to previously encrypt the app?
In EXECryptor if you don't have the right unlock code you can not unpack the EXE. how they do it?.
Ideas???
Regards

[Michel]

Hi Taos,
It's nice to see you so obstinate
You want to do a protector, not a packer.
It seems your idea looks like what Pc-Guard did. I sujest you to read their commercial docs in order to understand, as generic approach, the mechanism of generating and using keys to register a particular app on a particular pc.

[taos]

Originally Posted by Michel

Hi Taos,
It's nice to see you so obstinate
You want to do a protector, not a packer.
It seems your idea looks like what Pc-Guard did. I sujest you to read their commercial docs in order to understand, as generic approach, the mechanism of generating and using keys to register a particular app on a particular pc.

Thanks, I want to make a protector but I need powerfull crypter to avoid cracking the algorythm in minutes.
I've tested PC-Guard (last version) but I've unpacked PCGWIN32.EXE and all his schemes are on my IDA disassembler
In any crypters, if you don't have the key, you don't have the code, how it works?

Regards.

[Michel]

Pc-Guard is not a sample of very strong protector : there are tools to unpack automatically protected apps : even pcgwin32 wich is protected by itself is easilly decrypted, as you know
Nevertheless, if you trace manually the decrypt process you become aware of this generality : All is needed to decrypt must be in the distributed exe, exept one key wich may not be hardware nor username dependent. This key must be the same for all users and all machines.
Of course, the app vendor dont send this key (let name it "A"), but a combination of A, UserName, HW-id, etc

So, in two words, encrypt your app with key A. When some user want to register your app, he send to you his HW-id, name, mail or what you want.Then you return to him a key "B" (some complex combination of A , name, etc). In your app, there is a routine wich decode key B, (knowing his name, HW-id etc), and restore key A wich can decrypt your app.

On another pc, decoding key B will give a wrong key A.

Is that more clear for you ?

[taos]

Michel,thank you, I understand, it's very clear.
I'm thinking to use RSA private/public key or hashing keys.

Regards.

[dyn!o]

The problem is not about the encryption based on a public key algorithm.

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 (for instance: look at expensive 3D apps like GameSpace or Messiah) and that moment is critical for the protection. From all protectors ASProtect has the best (most secure) implementation of keys generation and validation, so what? It is and will be cracked by unpacking.

If you want to build a serious protection, not another ASProtect clone (let's be honest: nowadays protectors are clones of ASProtect), then you have to implement a fancy VM or/and own CPUs (a real challange ). Such a solution gives you a chance to stop the crackers for a long time and excludes from "the game" 99% of all crackers.

Regards.