On Wednesday, 7 January 2015 at 17:57:18 UTC, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Jan 07, 2015 at 05:16:13PM +0000, FrankLike via Digitalmars-d-learn wrote:

>To hide the infos you can also (I've seen people say that you >can use
>a packer) encrypt the strings and decode them at run-time (e.g
>base64, a simple XOR, etc) and use the import() idiom:
>https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable
>to import the compiled things.
>
>I've made a simple software in this spirit, even if it's not >made to >encrypt/hide (it's more globally a resource manager), it can >be used
>to hide the strings since it encodes in base 85 and base 64:
>https://github.com/BBasile/Resource.d

Good job.

Thank you.

Note that these encryption/decryption schemes can only serve as
deterrent to the casual user, they do not prevent a determined attacker from decrypting the sensitive data. As long as the data is decrypted on the user's machine, the user can read it. For example, an encrypted executable has to decrypt itself at some point, since otherwise it couldn't run on the user's machine in the first place. So, in theory, all the user has to do is to run it inside a VM or a debugger and stop it immediately after the point where it decrypts itself, and the code
will be in cleartext for all to read.  Similarly, if a piece of
sensitive data is decrypted by the program at some point during
execution, a user can just run it inside a debugger and break it
immediately past the point where the data is decrypted, and just read
off the cleartext.

Basically, the only way to be 100% safe with sensitive data that the user shouldn't read, is to never transmit said data to the user's machine in the first place. If the program needs to read something from a database, and the database has a password, don't store the password anywhere in any form on the user's computer (this includes inside the executable). Instead, use a database server that the program talks to; the server knows the DB password, the program doesn't (and shouldn't).


T

You're right, it works against "static analysis" (disassembly) but in a debugger, the attacker can track the content of the stack because before being used, the data **have** to be decripted somewhere, so before a CALL he detects the data put as parameter, then he tries to find where they are generated (e.g put a breakpoint on each dword xxxx... or by putting a breakpoint on memory access for a particular address). As said before by other people in this topic, you cant do anything againt someone who really wants to get the thing, but you can reduce the amount of people able to to do it.

Reply via email to