Menu
What is best practice for securing DLL's for projects you are working on? Certain DLL's I am interested in developing will have data access layer (DAL) and business logic layer (BLL) functionality. There may be several apps that can eventually hit these DLL's to perform business specific functions.
What is the best way to secure these DLL's so they can only be used by only creator's applications?
Security for both blocking unauthorized use of the DLL's and security against possible decompilation are both desirable.
715
In . NET core the problem is solved, You can combine all the dll to one exe. This way the user will not have access to dll file. Next they can de-compile exe, for this you can put some sort of security check or licence system (offline or online) to secure your exe.
The way to prevent your DLL from being reverse engineered is to never ever put it on any system. Print the code out, wipe the disk entirely and shred the printouts then burn them and scatter the ashes in different locations. Just by using a DLL you're preventing casual access.
As per my understanding, we can reverse engineer any compiled dll whose source language is a . net language like c#,vb.net. There are many tools availablein the market for obfuscation and prevent reverse engineering of the dll.
Compile the VB Project into the DLL and then import a reference to it. You can create a solution that contains VB projects and C# projects. you just can't have C# and VB.NET class files in the same project.
One option might be to mark all the exposed classes in your DLL as "internal" instead of "public", then use the "InternalsVisibleTo" attribute in your DLL to explicitly name the DLLs (and possibly exes) that are allowed to use your internal types. This may require all participants to be strongnamed, but that's a good thing to do anyway.
Ultimately, there is no absolute way to prevent a determined hacker from accessing your code when your code is executing on the hacker's machine. All code that can be executed by the machine can be disassembled and reassembled into something else with sufficiently advanced tools and experience.
The best way to approach code security is to ask the question "How difficult do we want to make it for someone to use this code without license or authorization, and how much time/money are we willing to spend to achieve that?" If you do nothing, it's very easy for someone to use your DLLs in some other project. If you do a few simple things, you can make it inconvenient for someone to use your DLLs elsewhere. If you invest months of effort, you might be able to make it very difficult for someone to misuse your code, but you can never make it impossible.
One technique that is as close to absolutely secure as I can imagine is: don't execute your code on the client's (or hacker's) machine at all. Run a web service instead, and keep your code on the server where a hacker can't casually fire up a debugger on your process or disassemble your code. Your code security is then defined by the physical security at the server location and network access security to the server's ports. These attack vectors are many orders of magnitude more difficult to circumvent than anything you can do to code that executes on the hacker's machine.
For some software companies, moving a portion of their applications from the client to the cloud isn't about getting better scalability or easier updates or lower costs, it's about code security and piracy prevention.
110
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
