Preventing .NET reverse engineering/decompilation - c#

Is there any way to stop .NET Reflector working at a program?
For example: I am developing a program that has confidential data (like gMail address and password), and I don't want to someone can see them.
How can I do this?

There are various tools that promise this, via different techniques.
For example, many commercial obfuscators will, in addition to encrypting strings and obfuscating the source, also introduce things into the IL that allow the program to run but which break (most/all) of the current reverse engineering tools like .NET Reflector.
That being said, keeping this type of data within the application will never be safe. The best a tool can do is make it more difficult to get the information, but never make it impossible.
A tool which "masked" it and breaks obfuscation tools is still not perfect - with enough time and energy, somebody can get that information out of your program. If the information is available to the runtime, it's available to somebody with enough determination and drive to find it. As such, important, private information like passwords should not be kept in the executable.

Yes, search for '.NET obfuscator'. There are several tools available.
However, you should never embed your email username / password in the code. This is just wrong. Putting security aside, what would you do if you need to change your email password? Can you upgrade all the copies of your software out there?

Obfuscators tend to offer little in defense of data such as what you are keeping in your application. They are mainly meant to protect the code and logic from being reverse engineered, not literals. A better way would be to have your client application talk to a server-side app that feeds it the data it needs instead of having your client negotiating with the secure servers directly. With this way, you can set up secure method of encryption between your server and client application.

Related

Protect code of WPF application written in .Net 4.7

I know this question is asked many times, I read every question but didn't find solution for my case.
Our team made an application in .Net 4.7.2 and in few days we have to deploy it. We are using web services, so even if user cracks license system, they won't be able to access services. Our only concern is to prevent its duplication (someone can resell under his brand and this happened to our previous versions) as these web services(simple CRUD operations) are very easy to implement, so someone can change URL to there servers and duplicate these services. For protection against this, we are using encrypted calls to server. Problem we are facing now is to protect this encryption algorithm and obfuscation is not enough for this.
Again our only concern is to protect code. Sorry for bad English.
I know about .Net Reactor but there are many unpacker that can unpack .Net reactor protected application. I don't know if these unpacker work on current version.
Should I use .Net Reactor?
Is there any solution out there to convert .Net 4.7 code to native code or any other way to prevent this(except for obfuscation or Ahead Of Time Compilation)?
Code you distribute can/will be analized (even copied/cloned) by all sorts of people, no way around that. Even only distributing compiled binaries is not a real hurdle for a determined adversary. Semi-compiled languages like Java's JVM or .NET often keep a lot of source information in the binary, to the point that sometimes decompiling to understandable source is more or less automatic. Source obfuscation can help a bit here, but that introduces another step (and possibly introduce bugs!), but an attacker will probably only be interested in localized swaths of code anyway.
If the services are "easy to duplicate", as you state, I wonder if they are really that valuable. Most extremely valuable 'net services use simple, even well known and publicly available protocols (as in "download a library to use our services here") to access them, but if I'd create my own clone of e.g. YouTube I'll get nowhere, the value is not in the interface but in the service offered.
Re keep encryption secret: Never forget Kerckhoffs' rules. In particular, homebrew encryption is usually ridiculously easy to break, getting at the exact algorithm is possible with some ingenuity even if it is only in hardware (like the MiFare card hack), and unless it has been carefully designed, it will be broken in short order. Do use the accepted cryptographic tools, like AES, Diffie-Hellman, RSA. Yes, it might be incur in some extra costs (in any case there are free/open source alternatives available for everything of interest), but it is much, much more secure than anything you could come up with.

Looking for good examples of tools with neat crash-reporting capabilities

The target platform is Windows. Sought-after languages: C++ (Native as well as CLI), C#. Java examples are al right as well.
I am not too worried about security, but I am curios about the language agnostic design aspect of this as well - what is a good way to deliver a crash report?
Something that I am looking for - code that can gather as much stack trace, environment as possible, then also lets the user type up steps that led to this, also leave their name and contact information optionally (they are paid clients who would want to hear back about their issue). Also, paranoid users should have the ability to send as little identifying information as possible.
For this reason I think it would make sense to compile an email message, channel it to the user's favorite email client, and then let the user preview it before sending, with the ability to modify plain-text fields when needed.
Maybe email is not the best way to go. I am using Visual Studio 2010 for development.
P.S. I asked for examples in 3 languages because we use all 3, and I am actually not certain whether native or managed code would catch all exceptions and thus have a chance to report an error (the app is huge and hard to dig through, but I do want to propose this new feature, not without researching first though).
Thanks.
Take a look at breakpad. You also might be interested in the UnhandledExceptionHandler and its ilk for C#. Also take a look at minidumps.

.NET obfuscation of a DLL: how can I protect my code?

I'm in the process of exploring a partnership with a small company. The company is looking for an algorithm that can improve their profits and I have some prototype software that can help them. The core of my software is very confidential and if the company gets a hold of it, then they will certainly not need me. I'm definitely going to sign a contract with them and I will have legal protection, but I still want to put as many protective layers between them and my "trade secret" as possible.
I might have to work close with their developers to automate my algorithm and integrate it in their system, but I want to offer the core functionality in a DLL so I can protect my "trade secret", yet still have the ability to work with their developers. Is obfuscation worth it given my situation? Are there other reasonable alternatives?
I don't know if this is an option for you, but you might consider providing the algorithm as a web service using WCF or Xml-rpc or REST or something.
With HTTPS, of course.
That way they can use the algorithm, but they can never get at your code.
Should work as long as the algorithm doesn't require too many round trips or huge amounts of data being transfered. Which is to say, as long as the algorithm doesn't need to be used in real time with a responsiveness of < 100ms or so.
Option 1: Dotfuscator or a similar product
http://www.preemptive.com/products/dotfuscator/overview
Option 2: Use C or C++ for the sections covered by trade secrets.
Obfuscation will give you more sense of IP protection. Check this free tool out, it may be a good starting point http://www.ntcore.com/phoenix.php
I think what will really protect your IP is contract and law. Make sure you have it clearly define at the start of the engagement and have an agreement draw up that will protect your interest.

How can I protect my .NET assemblies from decompilation?

One if the first things I learned when I started with C# was the most important one. You can decompile any .NET assembly with Reflector or other tools. Many developers are not aware of this fact and most of them are shocked when I show them their source code.
Protection against decompilation is still a difficult task. I am still looking for a fast, easy and secure way to do it. I don't want to obfuscate my code so my method names will be a,b,c or so. Reflector or other tools should be unable to recognize my application as .NET assembly at all. I know about some tools already but they are very expensive. Is there any other way to protect my applications?
EDIT:
The reason for my question is not to prevent piracy. I only want to stop competitors from reading my code. I know they will and they already did. They even told me so.
Maybe I am a bit paranoid but business rivals reading my code doesn't make me feel good.
One thing to keep in mind is that you want to do this in a way that makes business sense. To do that, you need to define your goals. So, exactly what are your goals?
Preventing piracy? That goal is not achievable. Even native code can be decompiled or cracked; the multitude of warez available online (even for products like Windows and Photoshop) is proof a determined hacker can always gain access.
If you can't prevent piracy, then how about merely reducing it? This, too, is misguided. It only takes one person cracking your code for it to be available to everyone. You have to be lucky every time. The pirates only have to be lucky once.
I put it to you the goal should be to maximize profits. You appear to believe that stopping piracy is necessary to this endeavor. It is not. Profit is simply revenue minus costs. Stopping piracy increases costs. It takes effort, which means adding cost somewhere in the process, and so reduces that side of the equation. Protecting your product also fails to increase your revenue. I know you look at all those pirates and see all the money you could make if only they would pay your license fees instead, but the reality is this will never happen. There is some hyperbole here, but it generally holds that pirates who are unable to crack your security will either find a similar product they can crack or do without. They will never buy it instead, and therefore they do not represent lost sales.
Additionally, securing your product actually reduces revenue. There are two reasons for this. One is the small percentage of customers who have trouble with your activation or security, and therefore decide not to buy again or ask for their money back. The other is the small percentage of people who actually try a pirated version of software to make sure it works before buying. Limiting the pirated distribution of your product (if you are somehow able to succeed at this) prevents these people from ever trying your product, and so they will never buy it. Moreover, piracy can also help your product spread to a wider audience, thus reaching more people who will be willing to pay for it.
A better strategy is to assume that your product will be pirated, and think about ways to take advantage of the situation. A couple more links on the topic:
How do i prevent my code from being stolen?
Securing a .NET Application
At work here we use Dotfuscator from PreEmptive Solutions.
Although it's impossible to protect .NET assemblies 100% Dotfuscator makes it hard enough I think.
I comes with a lot of obfuscation techniques;
Cross Assembly Renaming
Renaming Schemes
Renaming Prefix
Enhanced Overload Induction
Incremental Obfuscation
HTML Renaming Report
Control Flow
String Encryption
And it turned out that they're not very expensive for small companies. They have a special pricing for small companies.
(No I'm not working for PreEmptive ;-))
There are freeware alternatives of course;
Host your service in any cloud service provider.
How to preventing decompilation of any C# application
Pretty much describes the entire situation.
At some point the code will have to be translated to VM bytecode, and the user can get at it then.
Machine code isn't that much different either. A good interactive disassembler/debugger like IDA Pro makes just about any native application transparent. The debugger is smart enough to use AI to identify common APIs, compiler optimizations, etc. it allows the user to meticuloulsy rebuild higher level constructs from the assembly generated from machine code.
And IDA Pro supports .Net to some extent too.
Honestly, after working on an reverse engineering ( for compatibility ) project for a few years, the main thing I got out of my experience is that I probably shouldn't worry too much about people stealing my code. If anyone wants it, it will never be very hard to get it no matter what scheme I implement.
No obsfuscator can protect your application, not even any one described here. See this link, it's an deobsfuscator which can deobsfuscate almost every obsfuscator out there.
https://github.com/0xd4d/de4dot
The best way which can help you (but remember that they are also not full prof) is to use mixed codes, code your important codes in unmanaged language and make a DLL like in C or C++ and then protect them either with Armageddon or Themida.
Themida is not for every cracker, it's one of the best protector in the market, it can also protect your .NET software.
I know you don't want to obfuscate, but maybe you should check out dotfuscator, it will take your compiled assemblies and obfuscate them for you. I think it can even encrypt them.
I've heard about some projects that directly compile IL into native code.
You can get some additional info from this post:
Is it possible to compile .NET IL code to machine code?
We use SmartAssembly for .NET protection of an enterprise level distributed application, and it has worked great for us.
If you want to fully protect your app from decompilation, look at Aladdin's Hasp. You can wrap your assemblies in an encrypted shell that can only be accessed by your application. Of course one wonders how they're able to do this but it works. I don't know however if they protect your app from runtime attachment/reflection which is what Crack.NET is able to do.
-- Edit
Also be careful of compiling to native code as a solution...there are decompilers for native code as well.
Do you API?
Instead of trying to protect your one ddl file in one of your products on all of your customers devices, why not create an API service for your precious product features? Let the actual product that is saved on a device consume that API to deliver the product as you want it.
I Think this way you are 100% sure that your code is not decompiled and you set your own limits in your API so that developers / hackers don't consume your API in a way you don't want it.
Sure is some more work, but in the end, you are in control.
If someone has to steal your code, it likely means your business model is not working. What do I mean by that? For example, I buy your product and then I ask for support. You're too busy or believe my request is not valid and a waste of your time. I decode your product in order to support my relative business. Your product becomes more valuable to me and I prioritize my time in a way to resolve the business model for leveraging your product. I recode and re-brand your product and then go out and make the money that you decided to leave on the table. There are reasons for protecting code, but most likely you are looking at the problem from the wrong perspective. Of course you are. You're the "coder", and I'm the business man. ;-) Cheers!
ps. I'm also a developer. i.e. "coder"
I know this is old but, Themida is the most advanced anti-cracking software I've ever used.
It's not free, though.
Besides the third party products listed here, there is another one: NetLib Encryptionizer. However it works in a different way than the obfuscators. Obfuscators modify the assembly itself with a deobfuscation "engine" built into it. Encryptionizer encrypts the DLLs (Managed or Unmanaged) at the file level. So it does not modify the DLL except to encrypt it. The "engine" in this case is a kernel mode driver that sits between your application and the operating system. (Disclaimer: I am from NetLib Security)

.NET Compact Framework Connection String encryption/securing

I'm writing an application in C# for a smart device running Windows Mobile 6.1. It's pretty basic. Just querying a database and getting results. Nothing too fancy.
This program is only going to be deployed internally, but we still want to be secure with our SQL connection info.
What's the best way I should go about encrypting/securing my connection string in the program? I've seen examples for .NET programs using AppSettings, but I'm not seeing a Setting stab in my Solution properties.
This is my first time developing an application in C#/Visual Studio 2008, so there might be some kind of setting I'm missing.
Thanks for the help.
Be aware that if it's in your program, then it's inherently unsecure. No matter what you do, if the app has the ability to make that secure connection with info it contains, then that info can be pulled out by an experienced hacker with time and desire.
But are you that concerned about that level of threat? Obviously just throwing it into an app.config file is about as low-security as you get. All that has to happen is that someone opens the file with a text reader and ta-da, they have your credentials.
Maybe you would want to store an encrypted version in the config file and keep a private key in your app. At least a text reader can't "break" it. Of course someone might use reflector and decompile your app to get the private key.
Well you could obfuscate the app. That would make it harder to find that private key. Yes still not impossible.
Maybe you want that private key to be pulled off of a server through a web service or something. Then if someone has the app, they can't get it - though they can always reverse engineer how the web service call is made. Or do a man-in-the-middle and look at the key on the network.
Maybe you could use SSL to protect the transmission. Maybe do MAC filtering on the service to make it more difficult for an unauthorized device to get the key.
You can see the progression here. Each level of security requires more and more work. More and more maintenance. You have to decide what the return on the investment is going to be for your scenario and pick a level of security you're comfortable with for the amount of effort you're willing to spend on it.
Not sure if this helps, but I used OpenNETCF.AppSettings in a previous Windows Mobile 5 project under VS2005.
You can download the Community Edition of the OpenNETCF Smart Device Framework for free at www.opennetcf.com and browse the documentation.
I'm not sure it works with VS2008/CF3.5 though.

Categories

Resources