How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?

[Baz via Digitalmars-d-learn]

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.