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

-- 
The best way to destroy a cause is to defend it poorly.

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.

On Wed, Jan 07, 2015 at 08:36:19PM +0000, Baz via Digitalmars-d-learn wrote:
> On Wednesday, 7 January 2015 at 17:57:18 UTC, H. S. Teoh via Digitalmars-d-learn wrote:
[...]
> >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.
[...]
> 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.

Right, like I said, it deters a casual user, but won't stop a determined attacker. Unfortunately, all it takes is for *one* determined attacker to publish his findings, and your secret data is no longer so secret.

There *are* ways to make things hard even for a determined attacker, though it comes at an increasingly higher cost that may not be worth the effort, depending on what your program is doing. If it's just an online game, it's probably not worth it. But if it's a banking app, you probably wanna think about it reeeally hard...


T

-- 
My program has no bugs! Only undocumented features...

Hi,

sigh, so I have to annoy you with the truth...

On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote:
> How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?

By not putting it in in the first place. Everything else is no good in the end. Encryption, xoring, everything is almost useless for that purpose.

> If you build a exe ,such as which can get Data from DataBase,when you modify the exe's  extension to 'txt',
> and you open it by notepad.exe (on windows),you will find the info,it's important for me,so how to stop  the info to display  ?

Do you mean find the password? (I don't see that field in your example)

Remove the password field and let the operating system care of auth forwarding to the database server. Then create all the users on your database and make sure to set their permissions right. That way, your computer and the database server will negotiate whether they let the user in and it's their problem. I always do it like that. Also, that way, you already have existing permission management tools (in the dbms).

If you don't want to grant them permission on the table, don't. Create a view with the harmless info and grant them permission to that. Likewise, if you want to completely abstract it away, create stored procedures in the database as the interface for your app and grant them only permission to execute them.

> Trusted_Connection=Yes    \

Well, now I don't see what the problem you are trying to solve is. You are doing as outlined above already.

So what is the problem you are trying to solve?

On Thursday, 8 January 2015 at 10:11:38 UTC, Danny wrote:
> Hi,
>
> sigh, so I have to annoy you with the truth...
>
> On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote:
>> How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
>
> By not putting it in in the first place. Everything else is no good in the end. Encryption, xoring, everything is almost useless for that purpose.
>
>> If you build a exe ,such as which can get Data from DataBase,when you modify the exe's  extension to 'txt',
>> and you open it by notepad.exe (on windows),you will find the info,it's important for me,so how to stop  the info to display
>>  ?
>
> Do you mean find the password? (I don't see that field in your example)
>
> Remove the password field and let the operating system care of auth forwarding to the database server. Then create all the users on your database and make sure to set their permissions right. That way, your computer and the database server will negotiate whether they let the user in and it's their problem. I always do it like that. Also, that way, you already have existing permission management tools (in the dbms).
>
> If you don't want to grant them permission on the table, don't. Create a view with the harmless info and grant them permission to that. Likewise, if you want to completely abstract it away, create stored procedures in the database as the interface for your app and grant them only permission to execute them.
>
>> Trusted_Connection=Yes    \
>
> Well, now I don't see what the problem you are trying to solve is. You are doing as outlined above already.
>
> So what is the problem you are trying to solve?

'Trusted_Connection=Yes' is for local DB(127.0.0.1) ,but for network ,must have the username and password.
I have known how to do,but thank you.