digitalmars.D.learn - How to prevent sensitive information is displayed when the extension
- FrankLike (13/13) Jan 06 2015 How to prevent sensitive information is displayed when the
- Adam D. Ruppe (8/10) Jan 06 2015 If the data is in the program, it is visible to anyone you give
- Rene Zwanenburg (9/19) Jan 06 2015 This. It's why games and other licensed applications still get
- FrankLike (2/23) Jan 06 2015 Thank you ,it's a good idea.
- =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d-learn (9/27) Jan 06 2015 XaB
- FrankLike (3/11) Jan 06 2015 Yes,if I can't get some tools from dmd or ldc,then I should look
- Laeeth Isharc (4/10) Jan 07 2015 And I guess as an alternative to the utility you linked to, you
- =?UTF-8?B?TWFydGluIERyYcWhYXI=?= via Digitalmars-d-learn (7/17) Jan 07 2015 I don't think you would really need any compile time capabilities. You
- FrankLike (2/13) Jan 07 2015 Thank you,but it's not easy to do,can you show me some detail?
- Tobias Pankrath (2/18) Jan 07 2015 http://dpaste.dzfl.pl/3bbdecfefa5c
- John Colvin (6/25) Jan 07 2015 I'm not sure about some of that. Bad casts w.r.t. immutability
- Tobias Pankrath (2/8) Jan 07 2015 I would keep the encryption inside a template to prevent users
- John Colvin (3/13) Jan 07 2015 Why would that be a problem?
- Tobias Pankrath (6/20) Jan 07 2015 Because the plain text will be in the object file.
- FrankLike (1/10) Jan 07 2015 Yes.
- John Colvin (9/30) Jan 07 2015 Ah yes.
- FrankLike (1/3) Jan 07 2015 Thanks.
- FrankLike (1/2) Jan 07 2015 Thanks.
- Baz (15/22) Jan 07 2015 Notepad to display the infos ? are you serious ? Have you ever
- FrankLike (2/12) Jan 07 2015 Good job.
- H. S. Teoh via Digitalmars-d-learn (24/39) Jan 07 2015 Note that these encryption/decryption schemes can only serve as
- Baz (12/68) Jan 07 2015 You're right, it works against "static analysis" (disassembly)
- H. S. Teoh via Digitalmars-d-learn (14/29) Jan 07 2015 [...]
- Danny (23/31) Jan 08 2015 Hi,
- FrankLike (4/35) Jan 08 2015 'Trusted_Connection=Yes' is for local DB(127.0.0.1) ,but for
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 ?
Driver={SQL Server Native Client
10.0};Server=127.0.0.1;Database=test;Trusted_Connection=Yes \
€`B SELECT top 10 * FROM testtable 鑐B atest.d aB
testcolumnname aB std.stdio.File err.text GaB w
XaB error :
haB <
Thank you.
Jan 06 2015
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 the data is in the program, it is visible to anyone you give the program to. Alternatives would be asking the user for sensitive info separately from the exe like a config file that they must fill in or a password they must type when it starts up. Or just don't distribute the program to anyone who isn't authorized to use it.
Jan 06 2015
On Tuesday, 6 January 2015 at 17:32:29 UTC, Adam D. Ruppe wrote:On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote:This. It's why games and other licensed applications still get cracked, despite the industry spending millions (billions?) on researching means to prevent it.How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?If the data is in the program, it is visible to anyone you give the program to.Alternatives would be asking the user for sensitive info separately from the exe like a config file that they must fill in or a password they must type when it starts up. Or just don't distribute the program to anyone who isn't authorized to use it.Or don't let your application contact the DB directly. Build a web service or whatever fancy name those things have these days, and let the web service connect to the DB. Your application then connects to the service using a method of authorization if your choosing.
Jan 06 2015
"FrankLike" <1150015857 qq.com> On Tuesday, 6 January 2015 at 17:45:19 UTC, Rene Zwanenburg wrote:On Tuesday, 6 January 2015 at 17:32:29 UTC, Adam D. Ruppe wrote:Thank you ,it's a good idea.On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote:This. It's why games and other licensed applications still get cracked, despite the industry spending millions (billions?) on researching means to prevent it.How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?If the data is in the program, it is visible to anyone you give the program to.Alternatives would be asking the user for sensitive info separately from the exe like a config file that they must fill in or a password they must type when it starts up. Or just don't distribute the program to anyone who isn't authorized to use it.Or don't let your application contact the DB directly. Build a web service or whatever fancy name those things have these days, and let the web service connect to the DB. Your application then connects to the service using a method of authorization if your choosing.
Jan 06 2015
Dne 6.1.2015 v 18:15 FrankLike via Digitalmars-d-learn napsal(a):How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows? =20 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 ? =20 =20 Driver=3D{SQL Server Native Client 10.0};Server=3D127.0.0.1;Database=3Dtest;Trusted_Connection=3DYes \ ==E2=82=AC`BSELECT top 10 * FROM testtable =1E =E9=91=90B atest.d =07 =10aB testcolumnname =0E aB std.stdio.File err.text =08 GaB w =01=XaBerror : =08 haB =10 < =20 =20 Thank you.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. http://upx.sourceforge.net/ Martin
Jan 06 2015
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. http://upx.sourceforge.net/ MartinYes,if I can't get some tools from dmd or ldc,then I should look for some kind of code obfuscation. Thank you for your good idea.
Jan 06 2015
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.
Jan 07 2015
Dne 7.1.2015 v 12:00 Laeeth Isharc via Digitalmars-d-learn napsal(a):=20I don't think you would really need any compile time capabilities. You could just xor your strings and xor them again before using them to make it reasonably unreadable. But the thing is that doing these changes inside the code adds unnecessary complexity and is a potential source of bugs. Using an exe packer has the advantage of being practically a one-click solution.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.=20 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.
Jan 07 2015
On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote:Thank you,but it's not easy to do,can you show me some detail?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.
Jan 07 2015
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:http://dpaste.dzfl.pl/3bbdecfefa5cThank you,but it's not easy to do,can you show me some detail?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.
Jan 07 2015
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:I'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote:http://dpaste.dzfl.pl/3bbdecfefa5cThank you,but it's not easy to do,can you show me some detail?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.
Jan 07 2015
I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.http://dpaste.dzfl.pl/3bbdecfefa5cI'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1
Jan 07 2015
On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote:Why would that be a problem?I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.http://dpaste.dzfl.pl/3bbdecfefa5cI'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1
Jan 07 2015
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: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.Why would that be a problem?I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.http://dpaste.dzfl.pl/3bbdecfefa5cI'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1
Jan 07 2015
Yes.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?
Jan 07 2015
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: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);On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote: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.Why would that be a problem?I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE.http://dpaste.dzfl.pl/3bbdecfefa5cI'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1
Jan 07 2015
How about: http://dpaste.dzfl.pl/706ab2db9ce1Thanks.
Jan 07 2015
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
Jan 07 2015
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.dGood job. Thank you.
Jan 07 2015
On Wed, Jan 07, 2015 at 05:16:13PM +0000, FrankLike 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. 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.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.dGood job. Thank you.
Jan 07 2015
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: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.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). TTo 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.dGood job. Thank you.
Jan 07 2015
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...
Jan 07 2015
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?
Jan 08 2015
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:'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.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?
Jan 08 2015