Quite a few people have really taken interest in the dll's ivé sent them, and they're not the type that should be given away for free too often...
I was just wondering, if I were to sell my components, user controls etc, how would I go about protecting them, in terms of ownership/encrypting code (if possible) etc.. What steps have you taken to help prevent people using yours without paying for them?
You can use any commercial obfuscater which encrypt your functionality and giving error if decompile.
Here i have the whole list which are available in market.
I used many of them some are just encrypt string, public method, private methods,properties and all.
Just go through it.
see the whole list and article
The only truly secure way to protect your dll is not to give it to them. Expose it instead via a web-service etc (obviously this doesn't work in all cases). Every obfuscator can be broken with patience. Think how much the games industry spends on this, and things are broken / reverse-engineered within days, sometimes hours.
"Lawyers" may serve as a layer of protection, and obfuscation will certainly discourage idle browsing. But a determined hacker (for example, for commercial illegal spying) will be able to get at your code eventually.
I guess you simply need to weigh the costs and benefits...
Well, I will definitely put my copy right,company name and production name information to my DLL. Whenever anybody use it,those information still appear on my DLL. And if possible,I will try to use Dotfuscator tool from visual Studio which helps to obfuscate my DLL.
Related
i need to use SLGetWindowsInformation in slc.dll but i would rather implement my own version than pinvoking it 200 times on application start up and create the datatypes it need, so is it illegal to disassemble the library and write my own code that leech the behavior of this function
p.s i'm using c# so i won't inline an assembly, ill just copy the behavior
is it illegal to disassemble the library and write my own code
That depends on where you are. There are jurisdictions where reverse engineering is a protected consumer right, and so any attempt to prohibit it in a user agreement is null and void. There are jurisdictions where reverse engineering is not a protected consumer right, and therefore you may only do so if your license agreement allows it.
If you are somewhere where you can reverse engineer legally, there may still be restrictions from other laws (such as patents) on the code produced, though patents can get in the way even if you don't copy anyone and arrive at the idea in an independent manner, along with further innovations (though ironically patents were originally designed to actually encourage innovation).
Really, you're better off avoiding the issue entirely and never look at code that does something while you're trying to do the same thing, unless that code is released under a license that allows it.
i would rather implement my own version
Why not just implement your own version? If you think you can do better than someone else, do you really need to copy that someone else?
This is really a question for a lawyer and not for a programmer, but...
It all depends on the license of the library. AFAIK system dlls are subject to MS license you agree with before the installation and I bet there's a little line that forbids any kind of disassembling. Even with free libraries you should be careful, because most don't like reverse-engineering. If you need to modify a library, it should be open-source with a license, that permits it.
I just found out that even though I obfuscate my application it can still be cracked using code injection. This pretty much makes C# completely useless for me. Is there really no way to protect or make the process very difficult to do? Do 'crackers' have to know any class names etc. to do this? Thanks!
UPDATE: I'm trying to protect a binary (exe) not code.
I've read somewhere on here from several users that whatever the code is written in, it can be decompiled. Think of it like this, how else would the system know how to run the code? It is the same concept.
Usually though, most developers(that I know of) don't worry so much about this. Of course, this is a good reason not to have any sensitive details within your code but rather somewhere else.
If you're worried about protected industry secrets, it's impossible to send a computer the right instructions, but expect those instructions cannot be read by a capable person. If your goal is to stop somebody from modifying your EXE, why not simply sign your executable?
http://blogs.msdn.com/b/shawnfa/archive/2007/01/10/combining-strong-names-with-authenticode.aspx
Any of the .NET languages, and Java can be de-compiled. This includes .Exe and .dll files. What you will need to do is get an tool that obfuscates the code.
I've listed one below for you so you can get an idea:
http://www.red-gate.com/products/dotnet-development/smartassembly/
Are you sure your code is worth the trouble for someone to do that? Very very few applications are.
There are loads of profilers and static code analyzers out there for C# assemblies.
Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.
I have searched all over the Internet and stackoverflow. There seems none for my wonder.
What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):
"Assembly Manipulation and C#/VB.NET Code Injection"
"How To Inject a Managed .NET Assembly (DLL) Into Another Process"
Is it just me being too worried or what?
BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.
If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.
To prevent someone tampering with your deployed assmebliles, use Strong Names.
Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.
Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.
Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.
The first thing you need to decide against what you are trying to protect?
Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money.
If the attacker has physical access there is not much you can do.
If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...
Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.
How do I protect the dlls of my project in such a way that they cannot be referenced and used by other people?
Thanks
The short answer is that beyond the obvious things, there is not much you can do.
The obvious things that you might want to consider (roughly in order of increasing difficulty and decreasing plausibility) include:
Static link so there is no DLL to attack.
Strip all symbols.
Use a .DEF file and an import library to have only anonymous exports known only by their export ids.
Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
Use anti-debugging techniques borrowed from the malware world to prevent reverse engineering. (Note that this will likely get you false positives from AV tools.)
Regardless, a sufficiently determined user can still figure out ways to use it. A decent disassembler will quickly provide all the information needed.
Note that if your DLL is really a COM object, or worse yet a CLR Assembly, then there is a huge amount of runtime type information that you can't strip off without breaking its intended use.
EDIT: Since you've retagged to imply that C# and .NET are the environment rather than a pure Win32 DLL written in C, then I really should revise the above to "You Can't, But..."
There has been a market for obfuscation tools for a long time to deal with environments where delivery of compilable source is mandatory, but you don't want to deliver useful source. There are C# products that play in that market, and it looks like at least one has chimed in.
Because loading an Assembly requires so much effort from the framework, it is likely that there are permission bits that exert some control for honest providers and consumers of Assemblies. I have not seen any discussion of the real security provided by these methods and simply don't know how effective they are against a determined attack.
A lot is going to depend on your use case. If you merely want to prevent casual use, you can probably find a solution that works for you. If you want to protect valuable trade secrets from reverse engineering and reuse, you may not be so happy.
You're facing the same issue as proponents of DRM.
If your program (which you wish to be able to run the DLL) is runnable by some user account, then there is nothing that can stop a sufficiently determined programmer who can log on as that user from isolating the code that performs the decryption and using that to decrypt your DLL and run it.
You can of course make it inconvenient to perform this reverse engineering, and that may well be enough.
Take a look at the StrongNameIdentityPermissionAttribute. It will allow you to declare access to your assembly. Combined with a good code protection tool (like CodeVeil (disclaimer I sell CodeVeil)) you'll be quite happy.
You could embed it into your executable, and extract and loadlibrary at runtime and call into it. Or you could use some kind of shared key to encrypt/decrypt the accompanying file and do the same above.
I'm assuming you've already considered solutions like compiling it in if you really don't want it shared. If someone really wants to get to it though, there are many ways to do it.
Have you tried .Net reactor? I recently came across it. Some people say its great but I am still testing it out.
Well you could mark all of your "public" classes as "internal" or "protected internal" then mark you assemblies with [assembly:InternalsVisibleTo("")] Attribute and no one but the marked assemblies can see the contents.
You may be interested in the following information about Friend assemblies:
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx
i am creating my own CMS frame work, because many of the clients i have, the have same requirements, like news module, newsletter module, etc.
now i am doing it fine, the only thing that is bothering me, is if a client wants to move from my server he would ask me to gibe him his files, and of course if i do so the new person who will take it he will see all my code, use it and benefit from i, and this is so bad for me that i spend all this time on creating my system and any one can easily see the code, plus he will see all the logic for my system, and he can easily know how other clients of mine sites are working, and that is a threat to me, finally i am using third party controls that i have paid for their license, and i don't want him to take it on a golden plate.
now what is the best way to solve this ? i thought it is encrypting, but how can i do that and how efficient is it ?
-should i merge all my CS files and Dlls in bin folder to one Dll and encrypt it, and how can i do that ?
i totally appreciate all the help on this matter as it is really crucial for me.
you should read this
Best .NET obfuscation tools/strategy
How effective is obfuscation?
In my experience, this is rarely worth the effort. Lots of companies who provide libraries like this don't bother obfuscating their code (Telerik, etc).
Especially considering what you are writing (CMSes are everywhere), you'd likely see more benefit from your time spent implementing features that put your product/implementation in a competitive advantage and make companies see that the software you are capable of writing has value, rather than the code itself.
In the end, you want to ensure you are a key factor in making software work for a company, not the DLLs you give them.
You'll need to precompile your site and obfuscate dlls.
Visual Studio has something like Dotfuscator Community Edition shipped with it. You could give it a try.
Of course, HTML output, CSS declarations, database structure and stored procedures code cannot be encrypted.
You can however try to compress CSS which will also reduce its readbility by humans.
Check here: The best approach to scramble CSS definitions to a human-unreadable state throughout an ASP.NET application
One other idea would be to use a frame in your HTML and put the most of the site pages inside of it. This way, it will not be visible when doing "View source".
Or just state it clearly that you offer whatever you're doing as a service and do not provide source codes of your work. I somehow doubt salesforce would be willing to give their sources to anyone who asks.