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.