From: astral on

I am just curious about double file encryption method. For example, we have
encrypted a PE executable with some algorithm, say AES-256, then have this
encrypted file repeatedly, using the same algorithm, for more protection. At
runtime, encrypted executable are rapidly decompressed in memory. How safe
is repeated encrypting for PE-executable data integrity? Sometimes, double
encrypted executable may not always work, or works incorrectly. What are the
factors that it depends on?



From: Dave -Turner on
It doesnt matter whether the program is encrypted with a single XOR or
AES... encrypted or compressed or both ... encrypted once, or a thousand
times ... when the program is running it has already been decrypted (or in
the case of packers such as UPX, decompressed - no difference really), and
can then be dumped from memory and the executable patched to simply jump to
the decrypted/decompressed code.

A similar analogy is with multimedia protection ... companies can do all
they like to try to prevent their audio/video from being recorded, but at
the end of the day if the audio/video is playing (as it has to) then it can
be recorded.

One strategy you can use is to re-encrypt code after it has been used, but
this slows down the speed/efficiency of your program, and only slows - but
never fully prevents - the cracker gaining access to the decrypted code.



From: astral on
well. As I know from many sources, sometimes, when pack and encrypt some
application twice, it may not work at all, or works incorrectly(some
functions not working). Especially when application is complex enough and
contains DLL libraries. When application based just on pure Windows API,
encryption usually is without problem..

thanks.
-----------

"Dave -Turner" <admin(a)127.0.0.1> wrote in message
news:AeudnV5Bb_MbeYvRnZ2dnUVZ8s6dnZ2d(a)westnet.com.au...
> It doesnt matter whether the program is encrypted with a single XOR or
> AES... encrypted or compressed or both ... encrypted once, or a thousand
> times ... when the program is running it has already been decrypted (or in
> the case of packers such as UPX, decompressed - no difference really), and
> can then be dumped from memory and the executable patched to simply jump
to
> the decrypted/decompressed code.
>
> A similar analogy is with multimedia protection ... companies can do all
> they like to try to prevent their audio/video from being recorded, but at
> the end of the day if the audio/video is playing (as it has to) then it
can
> be recorded.
>
> One strategy you can use is to re-encrypt code after it has been used, but
> this slows down the speed/efficiency of your program, and only slows - but
> never fully prevents - the cracker gaining access to the decrypted code.
>
>
>