On Wednesday, 7 January 2015 at 14:33:16 UTC, Tobias Pankrath wrote:
> On Wednesday, 7 January 2015 at 14:18:53 UTC, FrankLike wrote:
>> On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote:
>>>
>>>>
>>>> What you want is some kind of code obfuscation. The easiest thing for
>>>> you is to use exe compression. It is not going to stop a dedicated
>>>> attacker, but ordinary people will not be able to extract any
>>>> information from it.
>>>
>>> And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup.
>>
>> Thank you,but it's not easy to do,can you show me some detail?
>
> http://dpaste.dzfl.pl/3bbdecfefa5c

I'm not sure about some of that. Bad casts w.r.t. immutability etc.

How about:
http://dpaste.dzfl.pl/706ab2db9ce1

> http://dpaste.dzfl.pl/3bbdecfefa5c

Thanks.

>>
>> http://dpaste.dzfl.pl/3bbdecfefa5c
>
> I'm not sure about some of that. Bad casts w.r.t. immutability etc.
>
> How about:
> http://dpaste.dzfl.pl/706ab2db9ce1

I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.

> How about:
> http://dpaste.dzfl.pl/706ab2db9ce1

Thanks.

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?
>
> 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  ?

Notepad to display the infos ? are you serious ? Have you ever heard about IDA and more globally about the disassemblers ? In a disassembler you always have a "strings" display, in IDA you have the "Names"... which are basically like "strings" with infos about where they are used. It will blow your mind...

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

On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote:
>>>
>>> http://dpaste.dzfl.pl/3bbdecfefa5c
>>
>> I'm not sure about some of that. Bad casts w.r.t. immutability etc.
>>
>> How about:
>> http://dpaste.dzfl.pl/706ab2db9ce1
>
> I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.

Why would that be a problem?

On Wednesday, 7 January 2015 at 16:23:38 UTC, John Colvin wrote:
> On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote:
>>>>
>>>> http://dpaste.dzfl.pl/3bbdecfefa5c
>>>
>>> I'm not sure about some of that. Bad casts w.r.t. immutability etc.
>>>
>>> How about:
>>> http://dpaste.dzfl.pl/706ab2db9ce1
>>
>> I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.
>
> Why would that be a problem?

Because the plain text will be in the object file.

http://dpaste.dzfl.pl/95b17fff42c6

Take a look at the object file and you will find “Sailor Moon” in it - which is what we wanted to avoid in the first place. I'd prefer the API that prevents something like that.

>>> I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.
>>
>> Why would that be a problem?
>
> Because the plain text will be in the object file.
>
> http://dpaste.dzfl.pl/95b17fff42c6
>
> Take a look at the object file and you will find “Sailor Moon” in it - which is what we wanted to avoid in the first place. I'd prefer the API that prevents something like that.

Yes.

On Wednesday, 7 January 2015 at 16:45:11 UTC, Tobias Pankrath wrote:
> On Wednesday, 7 January 2015 at 16:23:38 UTC, John Colvin wrote:
>> On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote:
>>>>>
>>>>> http://dpaste.dzfl.pl/3bbdecfefa5c
>>>>
>>>> I'm not sure about some of that. Bad casts w.r.t. immutability etc.
>>>>
>>>> How about:
>>>> http://dpaste.dzfl.pl/706ab2db9ce1
>>>
>>> I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.
>>
>> Why would that be a problem?
>
> Because the plain text will be in the object file.
>
> http://dpaste.dzfl.pl/95b17fff42c6
>
> Take a look at the object file and you will find “Sailor Moon” in it - which is what we wanted to avoid in the first place. I'd prefer the API that prevents something like that.

Ah yes.

Nonetheless - if you possibly can - don't use casts to/from immutable, it's so easy to be in undefined-behaviour-land and not even notice. In this case it's a textbook use of pure to avoid it.

Also, I presume you are aware of the parametrised enum/alias syntax?

enum encrypt(string s) = foo(s);

> 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.