From: astral on 13 Jun 2010 16:57 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 14 Jun 2010 22:25 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 17 Jun 2010 18:42 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. > > >
|
Pages: 1 Prev: Hashing of short fixed length messages Next: Need some simple bijective mappings |