I have made a project in C# (Windows Form App), and there are some constant variables in the code that hold important info, such as DB passwords and more. Basically my question is, when I "publish" my project and give the installation folder for somebody to install the app on his computer, is there anyway that he can read my source code?
-
yes. in short: the only way to protect data is to encrypt it. but the only way to _use_ it is to decrypt it. and if the computer can read something, so can the user. and hint: ***don't*** hardcode credentials. use config files. – Franz Gleichmann Jan 02 '21 at 12:31
-
3Well not the source code itself but with a decompiler like dotPeek (https://www.jetbrains.com/decompiler/) it's possible to get a very close version of your source code. passwords etc would be visible. – gsharp Jan 02 '21 at 12:38
-
Newer Visual Studio uses [Ilspy](https://github.com/icsharpcode/ILSpy), similar results (_Visual Studio 2019 ships with decompilation support for F12. To enable, go to Tools / Options / Text Editor / C# / Advanced and check "Enable navigation to decompiled source"_) – xanatos Jan 02 '21 at 12:54
-
Yes. For any application written in .NET (c#, VB.NET), anyone who has access to the DLL's can decompile them using dotPeek or JustDecompile. The names of local variables will be different, but the names of fields, methods, classes will be decompiled as in the original source code. – Pieterjan Jan 02 '21 at 13:04
-
According to [this link](https://learn.microsoft.com/en-us/previous-versions/aa730869(v=vs.80)?redirectedfrom=MSDN#introduction) ClickOnce Settings is the recommended way to store connectionstrings. But I can't tell for sure if the user is unable to access those... – Pieterjan Jan 02 '21 at 13:08
4 Answers
Yes, that's the case with all kind of code not just .net but managed code in general is much easier to disassemble. Tool like "w32dasm" (native code) and "Reflector" (.Net code) can be used to revert binaries to source code. To get matters worse using an extension to Reflector called Reflexil you can actually edit the source code and repack the binary!
Without disassembling the app tools like ResourcesExtract or .NET Resourcer can be used to extract all kinds of resources from a Windows binary file.
To protect your .net source code (to some extent!) use an obfuscator (like Red Gate SmartAssembly).
To protect your passwords (in Windows 7/10 only?) you can store them in Windows Credential Manager: How to store and retrieve credentials on Windows using C#
Or use the good old DPAPI: https://learn.microsoft.com/en-us/previous-versions/ms995355(v=msdn.10)?redirectedfrom=MSDN#windataprotection-dpapi_topic04
https://www.meziantou.net/how-to-store-a-password-on-windows.htm
Even if stored/retrieved securely, passwords can be stolen when kept unencrypted in memory, maybe SecureString class can help but it all depends: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

- 279
- 1
- 3
- 13
There are many de-compilers available to reveal the source code like
Jetbrains decompiler - https://www.jetbrains.com/decompiler/
ILSpy - https://github.com/icsharpcode/ILSpy
Many software provide activation key separately when the user buys it instead of embedding them in the application.
If the data is confidential or sensitive, it is better not to ship the application with them. Validate the user and then download the required data to complete the installation

- 435
- 2
- 8
Source code ? No not really. But if the passwords etc are held as plain strings then they can definitely be extracted.
The easiest thing to do is to store an encrypted version of the data you don't want to be visible.

- 28,809
- 4
- 51
- 69
-
If the data is in the binary, it can be obfuscated, but still can be unencrypted. The solution to this problem is not in to "where to store" but into "what to store" – Carlos Garcia Jan 02 '21 at 14:16
sure it can be read by reflection. you may use an obfuscator to avoid reflecting your code. try to search free or paid .net obfuscators.
or add a layer (a WebAPI or WebService) to communicate with the database and consume it with your windows application. so your passwords and other information will not be readable by clients. the client application will only know your service's address

- 850
- 6
- 6
-
that's wrong. with reflection you might find out the methods etc, but not insights on how the method is implemented. – gsharp Jan 02 '21 at 12:41
-
wrong? just try any reflector application to get method implementation. or take a glance at System.Reflection.MethodBody namespace. from msdn: "When overridden in a derived class, gets a MethodBody object that provides access to the MSIL stream, local variables, and exceptions for the current method." – mehmetx Jan 02 '21 at 12:56
-
this is at least misleading. If you add a backend service, then you need the secret to communicate with the backend. You need to change to token based user authentication, and then add a backend to follow best-practices. But adding an API is not the solution to the problem – Carlos Garcia Jan 02 '21 at 13:20
-
not misleading, maybe missing. token-based authentication can also be considered in the API according to the need – mehmetx Jan 02 '21 at 14:15
-
Sorry, I still hold the misleading because, in my opinion, the solution to this problem is not in "where to store" but in "what to store". You can make an API with a generic Key and then you are in the same issue. You need user-based authentication, and send the user/pass to some kind of server (whatever the server is) – Carlos Garcia Jan 02 '21 at 14:17
-
ok, you have solved the authentication issue, and then how will you communicate with the database? you may think it like a mobile app, it is just a consumer and does not need to know the database information, API is enough to get/send data (with any authentication) – mehmetx Jan 02 '21 at 15:00
-
@MehmetY. "there are some constant variables in the code that hold important info, such as DB passwords and more" makes me believe that he has a win app that uses adminuser to talk to a DB. I think his/her problem is not if there is an api or where to store the secret, but how should the app talk to a DBs or any other resources. To do that you need to authenticate the user first and then use a volatile token to talk to whatever (db in 2 layers, api in 3 layer, gateway in microservices, etc) - he should not store passwords in the app no matter what kind of app it is – Carlos Garcia Jan 02 '21 at 19:53