Re: Against sofware piracy! EXECryptor 2.034 update

From: Michael Furman (MichaelFurman_at_Yahoo.com)
Date: 09/21/04 

Date: Mon, 20 Sep 2004 16:04:08 -0700

Corey Murtagh wrote:
> SoftComplete Development wrote:
>> mwojcik@newsguy.com (Michael Wojcik) wrote in message
>> news:<ci4m2o011of@news1.newsguy.com>...
>>
>>> In article <81f33a98.0409100623.25dad35@posting.google.com>,
>>> gswork@mailcity.com (gswork) writes:
>>>
>>>>> With EXECryptor the protected code block is disassembled into
>>>>> nondeterminate transformations, effectively scrambling the visible
>>>>> logical code structure.
>>>>
>>>> that's quite interesting, has anyone on comp.programming had a go
>>>> at something similar to this.
>>>
>>> It's an old idea. I believe AxCrypt[1] supports self-decrypting
>>> programs, for example, with the caveat that they run in a temporary
>>> directory after decryption. Of course, AxCrypt is free, and open
>>> source, unlike this EXECryptor.
>>
>> EXECryptor creates no self-decrypting program. EXECryptor doesn't
>> contain at all such function as code decryption. The code is ALWAYS
>> enrypted
>> (transformed) and it is executed in this state.
>
> It took me a few moments to figure out that the above is nonsensical.
> Of course the program is decrypted... it must be, or the CPU won't
> know what to do with it. Assuming there is no external program doing
> the decrypting, the program would therefore be self-decrypting.
>
> Unless of course the 'encrypted' code is simply another way of
> expressing the same algorithms and so on, in which case it's simply
> transformed and hardly encrypted.
>
> If you decrypt straight to memory then that's fine. There are plenty
> of tools that will let you browse foreign process memory. There are
> plenty of people who love to take an encrypted or compressed program
> and crack it in a number of ways. There's really no way to stop them
> since ultimately your program MUST pass through the processor in a
> usable form.
>
> Someone once said words to the effect: "Anything science can create,
> science can circumvent." For computer science this is fairly apt :)

I do not know about EXECryptor, but some time ago (~15 years) I made
a protection scheme that was not so easy to crack. It readed CPU ID
prom the computer and used it as key to decript the code in memory
before execution. To crack it more or less easily you need to kave the
original computer (that, BTW, occupied a large room) or, at least, steal
its CPU ID number.
And there was another encrypting layer above that, so you need some time
to crack it and find out what hardware ID you need.

                    Regards,
                                      Michael Furman

Relevant Pages

  • Re: Encryption/Decryption
    ... The same i want to do the same in reverse process for the decryption at ... > For encrypting / decrypting multiple files at once, ... >>>> stored in the key container. ...
    (microsoft.public.windowsce.app.development)
  • Re: Is it possible to encrypt without a key ?
    ... Even if your viewer application decrypts the data into memory (NOT ... Given that the decryption program, and any needed key, is contained ... hardware and operating systems. ...
    (sci.crypt)
  • Re: Copy protection for a .NET application
    ... > then encrypting the dll yourself and encrypting the key in the loader or ... I think under both (hardlock and self encrypted dll) you have ... > decryption and just use that to manually decrypt the dlls. ... Your really protecting from the crackers that live ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Copy protection for a .NET application
    ... > then encrypting the dll yourself and encrypting the key in the loader or ... I think under both (hardlock and self encrypted dll) you have ... > decryption and just use that to manually decrypt the dlls. ... Your really protecting from the crackers that live ...
    (microsoft.public.dotnet.framework)
  • Re: Copy protection for a .NET application
    ... > then encrypting the dll yourself and encrypting the key in the loader or ... I think under both (hardlock and self encrypted dll) you have ... > decryption and just use that to manually decrypt the dlls. ... Your really protecting from the crackers that live ...
    (microsoft.public.dotnet.general)