I'm trying to think of a way that prevents others from using your published dlls. For example let's say you create a cool lightweight WinUI photo processing tool that's separated into several assemblies. One of them is your precious filters.dll assembly that basically does all of the core filtering work. Once you publish your application, how can you prevent others from taking this filters.dll and using it in other projects?
I've already tried to look at the StrongNameIdentityPermissionAttribute which has a good example here but it doesn't seem to work for me, the code just works without throwing any security exceptions..
Any ideas?
Strong names have nothing to do with preventing or inhibiting reverse engineering. They only serve to stop people substituting assemblies with hacked versions - and only if people havent turned off strong name verification. There's nothing to stop people taking your code, ILDASMing or Reflectoring and re-ILASMing as they see fit.
InternalsVisibleTo and friends are on an honour system at the compiler level too, so not much use for what you're looking for (although for some obfuscators, internals get more agressively obfuscated than publics by default - though this can generally be overcome). My main concern here is to point out that jsut because something is 'internal' doesnt bestow on it any magic code protection pixie dust that stops reverse engineering.
Most of this stuff re why these sort of approaches arent a solution for code protection is summarised very well in this article
There are also code protection products on the market that go beyond obfuscation which sound like the tool for the job you describe.
One method that may work for you is to declare the the methods and classes in the filter assembly to be internal and explicitly specify the assemblies that can access it as "friends".
You do this with an assembly declaration (ususally in assemblyinfo) like:
[assembly:InternalsVisibleTo("cs_friend_assemblies_2")]
see Friend Assemblies for more info.
Also make sure you obfuscate the assembly or people can dig into the code with reflector.
Don't bother worrying too much about protecting your .NET code. If you deploy it to someone elses computer, and that person wants to use or read your code, they will.
If your code is valuable enough you need to keep it on a computer you control (such as a web server) and guard against unauthorised access.
Obfuscation will only slow determined people down. Strong naming and signing is not used to protect your code, but instead to ensure that the user can confirm the code originates from who they expect it to come from (ie ensure it hasn't been tampered with).
Related
We maintain an ASP web app, which has a publicly visible interface that has to be localised into a large number of languages, and a private interface that still needs localisation, but only into a subset of the languages.
As much as possible, when we localise we put them into different resource files according to whether the string could appear on the public interface, or only the private one. However, inevitably mistakes are made, and I'd like to find ways to find resources that have been classified incorrectly. There's a lot of code shared between them, so the assembly that some code is in is not sufficient to determine this.
One way of doing this would be to record the resource name & location of every resource that gets accessed via the public interface, which allows us to (a) detect any that have been misclassified as private, and (b) investigate any that have been categorised as public but don't appear in this list. It looks like this might be possible by providing custom resource providers that wrap the default ones but record resource keys.
An alternative, but potentially more useful, option would be to record when a resource couldn't be found in a specific culture, and the system has had to fall back to the invariant culture resource. This will help us track down any untranslated messages. However, I'm struggling to find a way to do this.
Are there any good solutions here to avoid me writing my own? How do others manage similar scenarios? We'd rather avoid the cost of unnecessarily translating strings that can only be seen in the private interface into languages that it's not supported for.
In the interest of full disclosure, I'm the (sole) author of a commercial localization program for Visual Studio. I therefore stand to profit if you decide to research and purchase it. I'm not here to sell you a copy of it though (I don't work that way). I'm trying to legitimately help you and my program may be able to (though it's still unclear to me at this stage). You'ld also have to be open to a paid solution of course, assuming you can't find a better way. If I knew of a way for free I'd post it here. In fact, if my app didn't take so long to originally develop I would have given it away for free. I suggest you download the evaluation copy at http://hexadigm.com/FreeDownLoads.aspx (developer's version) to get an idea of what it can do (and ideally read about it on the site first). The evaluation version can only translate 10% of your strings however so it may be unwieldy to properly test what you're after. The program may have potential ways to deal with your situation though, if I understand it correctly, but it remains to be seen (for instance, you could bundle your public and private strings into separate ".trn" files, which you'll learn about if you research the app, but you obviously need to identify these strings first of course - how my app can help in that regard is still unclear). The upshot is you'll need to get a basic understanding of the program first though. It may be better to contact me offline at support#hexadigm.com. I don't believe any further discussion here will benefit other users but if the moderators feel otherwise then they can weigh in (I'd be happy to discuss it here if they wish, since the app does address various localization deficiencies in Visual Studio, but I don't want to violate the site's rules - I'm not here to promote the app so I won't discuss any specifics without their approval).
I just recently found out here that it is possible (at least in c#) to look up private fields and properties due to reflection.
I was surprised, although I knew that somehow constructs like the DataContractSerializer class need the possibility to access them.
The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it? I mean what if someone has a private bool _isLicensed field. It could be changed easily!
Later I found out here that the field accessors are not meant as a security mechanism.
So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?
The question now is, if anyone can access every field in my classes, this is kind of insecure, isn't it?
Not everyone can. Only code with sufficient permissions - trusted code. Untrusted code is restricted quite a bit. On the other hand, if the person who wants to use reflection has your assembly, they can run trusted code on their own machine. That's not a new attack vector though, as if they've got your code they could also modify it to make the field public in the first place.
Basically, if code is running on their machine, you should expect them to be able to do pretty much anything with it. Don't rely on access modifiers to keep anything secret.
So how do I make my Application safe, meaning how do I prevent anyone other than me from changing essential status values inside my classes?
If the hostile user is running your code themselves, you pretty much can't. You can make it harder for them, but that's an arms race which is no fun.
So one option in some cases is not to let anyone else run your code - host it on the web in an environment you've locked down. That's not appropriate in all cases, of course.
If you have to let users run the code themselves, you need to weigh up the downsides of them tampering with the costs of making that tampering difficult. We can't really help you with that balancing act - we don't have any idea what your application is, or what the costs involved are (reputational, financial etc).
private public and so on are a part of http://en.wikipedia.org/wiki/Encapsulation. the use is to make your API clear and to avoid mistakes.
there is no solid way to avoid people messing with your program.
you may have noticed that all programs are cracked in a few days usually.
in .net it is VERY easy because of IL code been very readable http://ilspy.net/ and such allow you to take any DLL and just read it like C# code.
you can make it more annoying to read your code using obfuscator
http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET
but applications like http://de4dot.com/
break this VERY easily.
SecureString is a nice trick: https://msdn.microsoft.com/en-us/library/system.security.securestring%28v=vs.110%29.aspx
writing your code in low level language like c++ might make cracking your code really annoying. but soon a skilled hacker will do whatever he wants with your program.
the only option that might be safe is providing your application as a cloud service where the user only sees the screen output and sends keyboard/mouse input.
This was meant to be a comment for John Skeets answer but ran out of room..
Great answer by the way, but I also must add that code is not meant to be secure its meant to clearly defined.
Most developers know how to change classes and inject into classes. There are many utilities to not only decompile your code but to also allow injection into it.
I wouldn't spend to much effort trying to your make code more secure, I would try and expect the code to be changed. Many programming languages do not have such modifiers as private, public, internal, protected etc. They rely on the developers to understand the consequences of using this code on their own. These programming languages have been quite successful as the developers understand that modifying, calling or injecting into code the API does not specify has results that the developing company cant and will not support.
Therefore, expect your code to be modified and ensure your applications responds to invalid changes appropriately.
Sorry if this seems like a comment...
To add to all the other answers, a simple way of looking at it is this: If the user really wants to break your code, let them. You don't have to support that usage.
Just don't use access modifiers for security. Everything else is user experience.
I need to provide a copy of the source code to a third party, but given it's a nifty extensible framework that could be easily repurposed, I'd rather provide a less OO version (a 'procedural' version for want of a better term) that would allow minor tweaks to values etc but not reimplementation using the full flexibility of how it is currently structured.
The code makes use of the usual stuff: classes, constructors, etc. Is there a tool or method for 'simplifying' this into what is still the 'source' but using only plain variables etc.
For example, if I had a class instance 'myclass' which initialised this.blah in the constructor, the same could be done with a variable called myclass_blah which would then be manipulated in a more 'flat' way. I realise some things like polymorphism would probably not be possible in such a situation. Perhaps an obfuscator, set to a 'super mild' setting would achieve it?
Thanks
My experience with nifty extensible frameworks has been that most shops have their own nifty extensible frameworks (usually more than one) and are not likely to steal them from vendor-provided source code. If you are under obligation to provide source code (due to some business relationship), then, at least in my mind, there's an ethical obligation to provide the actual source code, in a maintainable form. How you protect the source code is a legal matter and I can't offer legal advice, but really you should be including some license with your release and dealing with clients who are not going to outright steal your IP (assuming it's actually yours under the terms you're developing it.)
As had already been said, if this is a requirement based on restrictions of contracts then don't do it. In short, providing a version of the source that differs from what they're actually running becomes a liability and I doubt that it is one that your company should be willing to take. Proving that the code provided matches the code they are running is simple. This is also true if you're trying to avoid license restrictions of libraries your application uses (e.g. GPL).
If that isn't the case then why not provide a limited version of your extensibility framework that only works with internal types and statically compile any required extensions in your application? This will allow the application to continue to function as what they currently run while remaining maintainable without giving up your sacred framework. I've never done it myself but this sounds like something ILMerge could help with.
If you don't want to give out framework - just don't. Provide only source you think is required. Otherwise most likely you'll need to either support both versions in the future OR never work/interact with these people (and people they know) again.
Don't forget that non-obfuscated .Net assemblies have IL in easily de-compilable form. It is often easier to use ILSpy/Reflector to read someone else code than looking at sources.
If the reason to provide code is some sort of inspection (even simply looking at the code) you'd better have semi-decent code. I would seriously consider throwing away tool if its code looks written in FORTRAN-style using C# ( http://www.nikhef.nl/~templon/fortran/fortran_style ).
Side note: I believe "nifty extensible frameworks" are one of the roots of "not invented here" syndrome - I'd be more worried about comments on the framework (like "this code is ##### because it does not use YYY pattern and spacing is wrong") than reuse.
Here's an example of the code which will be used for the reflection:
var i = typeof(Program).Assembly.CreateInstance("test.Program");
After the software is obfuscated, the code will obviously stop working.
I'm trying to find a way around it by searching for properties of a class, which do not change after obfuscation has been done. I've tried that with type.GUID, but when I run the debug version, I get one GUID, and in the release after the obfuscation is completed, the guid is changed.
I'm using Eazfuscator.NET for obfuscation.
I would like to avoid using attributes to mark class/method if possible.
Any ideas on what would work?
I'm sure there are ways to iterate over all types and find the one you're looking for, but the things that come to mind would all produce the least maintainable code ever.
Some obfuscators (we use DeepSea, I don't know Eazfuscator) allow preventing obfuscation of specific classes, allowing reflection on those. In DeepSea's case, this is indicated by attributes but those won't/shouldn't (I never checked :o) make it to the final assembly.
If you regard reflection as "an outside process looking at your assembly" and obfuscating "preventing outside processes from looking at your assembly" you're really stopping yourself from doing what you want to do.
don't want the obfuscator to defeat the attackers. Just make the job of understanding the code more difficult. And I want this as a part of advanced piracy protection
After obfuscation; zip, encrypt and do whatever you want with your assembly. Then create another wrapper project and add your assembly as a resource into that project. Attach to AppDomain.CurrentDomain.AssemblyResolve event (in your new project) and whenever an unresolved assembly event occurs, read your resource(decrypt,unzip etc.) and return the actual assembly.
You may also try to obfuscate your final wrapper application.
How secure? At least, you can make life more harder for attackers.
I don't have exact answer, but ILSpy's source might help you.
This question appears to have died, so I've decided to offer a bounty.
What I'm most interested in knowing is if my scenario in the ETA1 below is viable and is used. If it isn't, then a good explanation of why not would be a good answer. Another good answer would be an alternative (but not including the internalsvisibleto attribute).
The best answer would be, yes, it's viable, everyone does it and customers love it!
ETA2: I think I've thought of a good solution. I provide the customer with a distributable edition that is as functional as their edition but is unlicensed and has the classes and members hidden, using attributes.
I can do this with compiler directives, on every single important member, but I wondered if there was some global way to hide all members of a class?
A simplified scenario:-
I have a class that extends a control in someway and I want to sell my class under two licenses;
(1) Standard - The customer gets x number of controls that use my class but can't instantiate the class (its internal).
(2) Developer - The same as Standard except they can create their own controls that use my class.
My problem is that when the developer customer comes to sell their controls, they can't help but expose my class to all their customers.
--- Ignore this
The only way around it, in my scrambled mind, would be for the developer to somehow integrate my assembly into theirs, and in that way I can keep the constructor internal. Or, use the internals visible to attribute. / Ignore this ---
I'm sure someone here has had the same situation and any help would be greatly appreciated.
ETA1: I'm thinking aloud here, but, I could have a list of permissable calling assembly names which the customer could add to. When they ship their product, their customers' assemblies would not be in the list and therefore they wouldn't be able to instantiate certain classes. (The list could obviously be hashed).
I believe you will store the licensing information (i.e, Standard and Developer) somewhere in the registry. In such case, I suppose the simpler solution would be to implement LicenseManager. This is what most .NET component vendor use.
http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx
Hope this helps !
I believe you've come up with the only real solution, assuming the runtime will support it. As long as yours is a separate DLL, if the developers can instantiate your objects then so can anyone else, whether you try to hide it behind a constructor, a factory, whatever.
I wonder, though, whether consumers might not even be able to get around that restriction by integrating the shipped assembly into their own?
Why don't you use license keys? Your class reads the license key and depending on what permissions the license offers it disables methods at runtime?
The license key could be defined in the config file.
It's a tough one, just due to the nature of .NET. It's a shot in the dark, but you could look into products such as CodeVeil which provides assembly encryption at the IL level. Your assembly would essentially be shipped encrypted and the key would be handed to your customer. The customer would then be the only entity with the ability to decrypt your assembly instructions. Now, CodeVeil claims the following about its decryption keys:
Even though the key is stored in the application that does not make is insecure. In fact the key itself is not as important as the transformation of the data itself. CodeVeil also uses many runtime-protection operations to frustrate hackers attempting to capture the decrypted assembly. In addition CodeVeil uses a very special decryption system that decrypts only enough information for the .NET runtime to execute that specific method. The code is never stored in the same memory as the assembly itself so the decrypted code cannot be dumped to disk for analysis.
This is obviously a good thing, but this is the part you'd have to research because i am not familiar with the other techniques they use as part of their decryption algorithm. The cool thing about this is if it works, your customers will be happy and THEY can make their customers happy by exposing parts of your assembly through their own API. At the same time your code stays protected from tools such as ILDASM and Reflector.