I am writing a C# application with Visual Studio that is divided in several modules (namespaces). Every module of course is going to be in charge of some particular function. For example there is a module that will deal with calling some firmware some place else, another module that will deal with just the UI with the user etc.
So far I have no problem doing that. But while writing the first module, I realized that perhaps the classes that I create for this, could very well be used for other future projects since their architectures seem similar.
So I am wondering if it would be a good decision to:
write a separate DLL that deals with all this functionality from scratch and then call that in my project
or just write the project, make it work and then later separate the particular module and shape it like a DLL.
You have to look at all the options and consider everything.
If you create a separate library then you need to be sure that you know all the requirements ahead of time, so that you can keep the library as stable as possible. As, each time you update the library you will need to update all of your projects which use it.
Creating a library will be at least little more work initially.
A well designed and developed library will give you the ability to be able to just drop it into a future project and be sure that it will do what you want.
A badly designed one will mean that you keep going back to it to make changes time and time again and have to keep updating all your projects, or maintain backwards compatibility which means you could end up with multiple different versions of the same method. And end up with something difficult to maintain and update.
You have to weigh all of this up against the advantages you would gain by using a library.
My experience, is that if you need to do something twice then often copy and paste is better. If you need to do it more than that, or sometimes if it is quite complex, then a library starts to pay off. But still for little things copy and paste is still easier, quicker, and lighter.
I am working on a project using asp.net and c# and I need to pull in something like wkhtmltopdf. I realize that there have been several good wrapper classes written to simplify calls to the dlls using c#. But is there a reason why I should not invoke the executable directly? Is there any performance or security gain from using a wrapper library?
Although, my specific need now is to use wkhtmltopdf, I have had the same question in the past when using libraries like imagemagick as well.
It's a matter of preference. By using the wrapper classes you mentioned, the work that you do implementing components that you may not be so familiar with is reduced, thereby freeing up your valuable time to concentrate on those aspects of the application where perhaps you can make your strongest value-add, such as the overall application architecture and design, or perhaps the application's business logic.
If you choose to write all the code yourself, then you may find that you're a less productive developer than your competition.
And, as #UweKeim points out in his comment, performance may be a factor as well. If the wrapper code does not perform to your needs, you may well need to bypass it and go straight to the component/code library you're calling.
It's important to strike a balance between use of code that others have written, versus your own. Important factors are things such as, how well is the 3rd party code written, how well is it supported, how well it performs, etc. Choose wisely!
I built a simple demo application in C# using a modular approach so it consists of one executable and a couple of DLLs. Suppose I put it in a zip file and hand it over to somebody, with the sole purpose they can try out the demo application simply by extracting the file and doubleclicking the exe.
Now, to my understanding everybody that gets the application and the DLLs, can just add a reference to the DLLs in a Visual Studio project, and then start using whatever functions/classes they have as long as they are declared public. And hence, they can get access to a lot more than what I want them to access.
Is there a way to disable this, and get a system that is somehwat like with C++ DLLs (e.g. I can give anyone a lot of C++ DLLs and they'll have a rather hard time using the functions/classes in it if they do not have the header files)? Can I somehow strip the DLLs so that they are still usable by the exe, but do not expose references? Or are there attributes or so that I can use in the code that say "this class is usable only be DLLs/exes built by me"?
You could use the InternalsVisibleToAttribute and not make anything public, but...
You're mistaken if you think that anything stops someone from using non-public classes from your DLL. An application with full-trust can access private and internal content no problem, or they can decompile and rebuild the DLL with everything public.
People will suggest obfuscation, but that doesn't do much more.
You should read this answer (and question, but mostly answer): C#: How to Make it Harder for Hacker/Cracker to Get Around or Bypass the Licensing Check?
One possible solution is to leave public only the method that is supposed to be called from the executable. Everything else could be private or internal. You could also obfuscate the assembly. But remember that no matter what you do, there is always the possibility of using Reflection to invoke any method inside the assembly. Of course if it is obfuscated it will be a little harder but not impossible.
I think you can use Friend assemblies for that.
You may also obfuscate internals of your dlls so it become really hard to do reverse engineering and decompile your assemblies. Tools like Dotfuscator will rename all function/variable names inside your compiled dll to something like a0002345 so reading it will be really exhaustive.
Please notice that none of methods gives you 100% protection as still it is possible to use .NET reflection routines to access and use your private and internal classes. However making stuff internal or private will stop majority developers using those classes. Use obfuscation to stop advanced engineers who tries to dig into your compiled sources. In theory protection is considered safe enough if decompiling effort is greater than effort for writing similar tool from scratch. If somebody can't read your dlls the one won't be able to know how to use it.
No, sorry, not.
You could do ilmerge followed by obfuscation (I'm not sure what tool) for something similar.
It's a standard practice to decompile and reverse engineer .net assemblies.
I'd like to release some plugin assemblies that will add to existing applications, but I don't want them to be utilized by others.
What are some ways I can hide the source of these assemblies?
It's theoretically impossible to achieve 100% protection unless you control the target hardware. If the CPU is able to execute it, given enough time and knowledge, a human being can read it too. This is not even limited to C# (although it's usually easier to do in managed languages). You can use an obfuscator like Dotfuscator or XenoCode to make it harder to understand the decompiled code. If you're really concerned, you should move to a server-based application.
You can use an obfuscator tool, it will help but reverse engineering will still be very possible.
Your users' computer needs to know what it needs to do, so you have to tell it. The owner of the computer has total control over it, and can therefore know himself what you told the computer to do, and he can tell it to do something else.
There is a way to hide the data, its called steganography. There's an author of a number of articles covered on CodeProject, who wrote a framework for doing exactly this. The title of the articles were 'Steganography ' in a series from 1 up to 12 I think. This is the website that is affiliated with the author.
There is a also a obfuscator called 'Phoenix Protector', found here, which can obfuscate the .NET code, personally, I have not tried it but it sounds good.
Hope this helps,
Best regards,
Tom.
It's software; anything is possible. You can encrypt your binaries, and then decrypt all or part of them into your application at runtime. It's not foolproof, but it's up to you to decide how draconian you want to be.
You can write an app that will host CLR using the CLR COM api, that way you can first load and decode the assembly at the native code level. If you reinforce the native loader using several anti-reverse engeneering techniques, you can achieve good enough security.
At the very least, you should obfuscate your dlls to prevent hackers & competitors from viewing and making sense of your code. Obfuscation is not 100% foolproof, but it presents a big enough obstacle in their path.
Some obfuscators such as Crypto Obfuscator have a feature of embedding all dlls in the main exe so your dlls are not explicitly visible and available on disk to open in reverse-engineering tools such as Reflector.
I was thinking about obfuscating a commercial .Net application. But is it really worth the effort to select, buy and use such a tool? Are the obfuscated binaries really safe from reverse engineering?
You may not have to buy a tool - Visual Studio.NET comes with a community version of Dotfuscator. Other free obfuscation tools are listed here, and they may meet your needs.
It's possible that the obfuscated binaries aren't safe from reverse engineering, just like it's possible that your bike lock might be breakable/pickable. However, it's often the case that a small inconvenience is enough to deter would be code/bicycle thieves.
Also, if ever it comes time to assert your rights to a piece of code in court, having been seen to make an effort to protect it (by obfuscating it) may give you extra points. :-)
You do have to consider the downsides, though - it can be more difficult to use reflection with obfuscated code, and if you're using something like log4net to generate parts of log lines based on the name of the class involved, these messages can become much more difficult to interpret.
Remember that obfuscation is only a barrier to the casual examiner of your code. If someone is serious about figuring out what you wrote, you will have a very hard time stopping them.
If you have secrets in your code (like passwords), you're doing it wrong.
If you worried someone might produce your own software with your ideas, you'll have more luck in the marketplace by providing new versions that your customers want, with technical support, and by being a partner to them. Good business wins.
At our company we evaluated several different obfuscation technologies, but they all had problems. The biggest problem was that we rely a lot on reflection, e.g. to dynamically create grids based upon property names.
So all of the obfuscators rename things, you can disable it of course, but then you lose a lot of the benefit of obfuscation.
Also, in our code we have a lot of NUnit tests which rely on a lot more of the methods and properties being public, this prevented some of the obfuscators from being able to obfuscate those classes.
In the end we settled on a product called .NET Reactor
It works very well, and we don't have any of the problems associated with the other products.
"In contrast to obfuscators .NET Reactor completely stops any decompiling by mixing any pure .NET assembly (written in C#, VB.NET, Delphi.NET, J#, MSIL...) with native machine code. In detail, .NET Reactor builds a native wall between potential hackers and your .NET code. The result is a standard Windows based, not MSIL compatible, file. The original .NET code remains intact, well protected by native code and invisible for prying eyes. The original .NET code is not copied on harddisk at any time. There is no tool which is able to decompile .NET Reactor protected assemblies."
The fact that you actually can reverse engineer it does not make obfuscation useless. It does raise the bar significantly.
An unobfuscated .NET assembly will show you all the source, highlighted and all just by downloading the .NET Reflector. Add obfuscation to that and you'll reduce very significatively the amount of people who'll be able to modify the code.
It depends on you are you protecting yourself from. If you'll ship it unobfuscated, you might as well open source the application and benefit from marketing. Shipping it obfuscated will only allow people to relatively easily generate modified binaries through patches instead of being able to steal your code and create a direct competitor. Getting the actual source from obfuscated code is very hard, depending on the obfuscator, of course.
I think that it depends on the type of your product. If it is directed to be used by developers - obfuscation will hurt your customers. We've been using the ArcGIS products at work, and all the DLLs are obfuscated. It's making our job a lot harder, since we can't use Reflector to decipher weird behaviors. And we're buying customers who paid thousands of dollars for the product.
So please, don't obfuscate unless you really have to.
Things you should take into account:
Obfuscation does not protect your code or logic. It just makes it harder to read and understand.
Obfuscation does no one stop from reverse engineering. It just slows the process down.
Your intellectual property is protected by law in most countries. So if an competitor uses your code or specific implementation, you can sue him.
The one and only problem obfuscation can solve is that someone creates a 1:1 (or close to 1:1) copy of your specific implementation.
Also in an ideal world reverse engineering of an obfuscated application is economical unattractive.
But back to reality:
There exists no tool on this planet that stops someone from copying user interfaces, behaviors or results any application provide or produce. Obfuscation is in this situations 100% useless
The best obfuscator on the market cannot stop one from using some kind of disassembler or hex editor and for some geeks this is pretty good to look into the heart of an application. It's just harder than on an unobfuscated code.
So the reality is that you can make it harder and more time consuming to look into your application but you won't really get any reliable protection. Regardless if you use a free or an commercial product.
Advanced technologies like control flow obfuscation or code virtualization may help to make understanding of logic sometimes really hard but they can also cause a lot of funny and hard to debug or solve problems. So they are sometimes more like an additional problem than a solution.
From my point of view obfuscation is not worth the money some companies charge for their products. If you want to nag casual developers, open source obfuscators are good enough. If you want to make it as hard as possible to look into the heart of your applications, you need to use cryptographic containers with virtual execution environments and virtual filesystems but they also provide attack vectors and may also be a source for a bag full of problems.
Your intellectual property and your products are in most countries protected by law. So if there's one competitor analyzing and copying your code, you can sue him. If a bad guy or and hacker or cracker takes your application you are pranked - but an obfuscator does not make a difference.
So you should first think about your targets, your market and what you want to achieve with an obfuscator. As you can read here (and at other places) obfuscation does not really solve the problem of reverse engineering. It only makes it harder and more time consuming. But if this is what you want, you may have a look to open source obfuscators like e.g. sharpObfuscator or obfuscar which may be good enough to nag casual coders (a List can be found here: List of .NET Obfuscators on Wikipedia).
If it is possible in your scenario you might also be interested in SaaS-Concepts. This means that you provide access to your software but not the software itself. So the customer normally has no access to your assemblies. But depending on service level, security and user base it can be expensive, complex and difficult to realize a reliable, confident and performant SaaS-Service.
No, obfuscation has been proven that it does not prevent someone from being able to decipher the compiled code. It makes it more difficult to do so but not impossible.
I am very confortable reading x86 assembly code, what about people that is working with assembly for more than 20 years ?
You will always find someone that only need a minute to see what your c# or c code is doing...
Just a note to anyone else reading this years later - I just skimmed through the Dotfuscator Community Edition (that comes with VS2008) license a few hours ago, and I believe that you cannot use this version to distribute a commercial product, or to obfuscate code from a project that involves any developers other than yourself. So for commercial app developers, it's really just a trial version.
...snip...
these messages can become much more
difficult to interpret
Yes, but the free community edition that comes with Visual Studio has a map functionality.
With that you can back track the obfuscated method names to the original names.
I've had success putting the output from one free obfuscator into a different obfuscator. In Dotfuscator CE, only some of the obfuscation tricks are included, so using a second obfuscator that has different tricks makes it more obfuscated.
It's quite simple to reverse engineer a .net app using .net reflector - since the app will generate VB, VC and C# code straight from the MSIL, and it's possible to pull out all kinds of useful gems.
Code obfuscators hide code quite well from most reverse engineering hacks, and would be a good idea to use on proprietary and competitive code that adds value to your app.
There's a pretty good article on obfuscation and it's workings here
This post and the surrounding question have some discussion which might be of value. It isn't a yes-or-no issue.
Yes you definitely should. Not to protect it from a determined person, but to get some profit and have customers. By the way, if you reach a point here someone tries to crack your software, that means you sell a popular software.
The problem is what tool to choose for the job. Check out my experience with commercial obfuscators: https://stackoverflow.com/questions/337134/what-is-the-best-net-obfuscator-on-the-market/2356575#2356575
Yes, we do. We use BitHelmet obfuscator. It's new, but it works really well.
But is it really worth the effort to select, buy and use such a tool?
I found Eazfuscator cheap (free), and easy to use: took about a day.
I already had extensive automated tests (good coverage), so I reckon I could find any bugs that are/were introduced by obfuscation.