I am trying to find a good enough way to store a security key in a software so even a user wouldn't be able to find it unless they spend a week or more of their time. There were a few attempts using obfuscators and such, but in the end they just make it a day max to find it. Using ILspy you can create a VS project from the exe which makes it easy. To pass the obfuscator that fooled ILspy I used de4dot. I have searched a bit and there are some suggestions to use Windows DAPI but this is only good if you can use a password, which it is not possible since the user again must not know the key. The usage of a server is not feasible as part of the project.
Any suggestions? I feel that this is not an easy task from C#, where in C++ the native code would be quite harder to read once decompiled but the desire is to stay in C#.
Another thought was to embed somehow the libraries in the executable. A flaw in the previous attempts is that a DLL was used to call AES function. The decompiled code needed to specify the DLLImport functions with their name. So it was an easy starting point to see which function uses them which of course will have the keys passed to it even if all the rest of the functions had their methods and variable names changed. So a more specific question: is there a way to embed a DLL or library so it is part of the code?
Following the above thought, an idea was to somehow extend the AES DLL so it can have the keys embedded as well. Then the C# code would call the alternative function without passing the keys. So someone would be required to decompile that DLL. I am not so much an expert on decompiling native code to reverse engineer it so maybe a feedback would be useful before attempting this.
