I wrote a windows application using C# .Net 2.0 and i want to do something which hide the source code, so when any one use refactor tool can't see the source code.
I used dotfuscator but it just changed the function names but not all the source code.
UPDATE:
I want to hide the source code, not because of hiding the key, but to hide how the code is working.
Thanks,
IL is by definition very expressive in terms of what remains in the body; you'll just have to either:
find a better (read: more expensive) obfuscator
keep the key source under your control (for example, via a web-service, so key logic is never at the client).
Well, the source code is yours and unless you explicitly provide it, youll perobably only be providing compiled binaries.
Now, these compiled binaries are IL code. To prevent someone "decompiling" and reverse engineering your IL code back to source code, you'll need to obfuscate the IL code. This is done with a code obfuscator. There are many in the marketplace.
You've already done this with dotfuscator, however, you say that it only changed the function names, not all the source code. It sounds like you're using the dotfuscator edition that comes with Visual Studio. This is effectively the "community edition" and only contains a subset of the functionality of the "professional edition". Please see this link for a comparison matrix of the features of the community edition and the professional edition.
If you want more obfuscation of your code (specifically to protect against people using tools such as Reflector), you'll need the professional edition of Dotfuscator, or another code obfuscator product that contains similar functionality.
As soon as people get a hand on your binaries they can reverse-engineer it. It’s easier with languages that are compiled to bytecode (C# and Java) and it’s harder with languages that are compiled to CPU-specific binaries but it’s always possible. Face it.
Try SmartAssembly
http://www.smartassembly.com/index.aspx
There are limits to the lengths obfuscation software can go to to hide the contents of methods, fundamentally changing the internals without affecting the correctness (and certainly performance) is extremely hard.
It is notable that code with many small methods tends to become far harder to understand once obfuscated, especially when techniques for sharing names between methods that would appear to collide to the eye but not to the runtime are employed.
Some obfuscators allow the generation of constructs which are not representable in any of the target languages, the set of all operations allowable in CIL for example is way more than that expressible through c# or even C++/CLI. However this often requires an explicit setting to enable (since it can cause problems). This can cause decompilers to fail, but some will just do their best and work around it (perhaps inlining the il it cannot handle).
If you distribute the pdb's with the app then even more can inferred due to the additional symbols.
Just symbol renaming is not enough of a hindrance to reverse-engineering your app. You also need control flow obfuscation, string encryption, resource protection, meta data reduction, anti-reflector defenses, etc, etc. Try Crypto Obfuscator which supports all this and more.
Create a setup project for your application and install the setup on your friends computer like a software. There are 5 steps to creating the setup project using microsoft visual studio.
Step 1: Create a Sample .Net Project. I have named this project as "TestProject" after that build your project in release mode.
Step 2: Add New Project using right click on your solution and select setup project and give the name this as "TestSetup".
Step 3: Right click on setup project and Add primary Output and select your project displayed.
Step 4: Right Click the setup project and select View-> File System -> Application Folder. Now copy what you want to be in installation folder.
Step 5: Now go to our project folder and open the release folder you can get the setup.exe file here. Double click on the "TestSetup" file and install your project to your and other computer.
Related
Is it possible to extract the code of a Xamarin Android application and inspect it?
I am in last stages of one Application which would be soon released on Play Store. However, I am worried if the code could be extracted and looked at by other people.
Please advise, how to secure my App from other people looking at the code for it.
Yes, it is possible to extract the code of a Xamarin.Android application. By default, the .dll files are just resources inside the APK, and they can be extracted with a zip utility and examined with e.g. ILSpy.
The Xamarin docs explain how to protect your application, including:
Disable debugging
Obfuscate with Dotfuscator
Bundle assemblies into native code (but see below)
Use AOT (native) compilation (but see below)
Note that #3 requires an Enterprise license and just puts the .NET .dlls a layer deeper in the APK; it is still possible to extract them and they are still unobfuscated.
Note that #4 is explicitly listed as an experimental feature that should not be used in production.
Full disclosure: I work for PreEmptive Solutions, and we make Dotfuscator.
You can select Ahead Of Time (AOT) compilation.
That won't prevent extraction, but will made it very difficult to do. On top of that, you can use
Crypto Obfuscator.
I would suggest to read about SafetyNet as well, which provides a set of services and APIs that help protect your app against security threats, including device tampering, bad URLs, potentially harmful apps, and fake users:
https://developer.android.com/training/safetynet/index.html
Obfuscating of Xamarin Android apps is of no sense (you can turn on "Enable ProGuard" option if you want but it will not Obfuscate your code) its better to turn on "Embed assemblies to native code" which will convert all code into a binary .so file. and it will make it difficult for hacker or reverse engineer to read that code and do reverse engineering AOT but that is in experimental and might create problem for some device after updated on play store. in order to play safe i would suggest to go with "Embed assemblies to native code"
I'm not sure if the title is accurately describing what I'm trying to ask...
Basically, how does Visual Studio look at a code file in a CSPROJ and determine references for a method or variable, or if a using statement is not being used in the code? Obviously it's not just doing simple text parsing, and it seems to work before ever doing a build so I don't think it's referencing the assembly/CLR.
Is there an API that I can tie into from an external app, if I have the user select their CSPROJ or SLN file and be able to report on unused using statements in files, or methods/vars that aren't being called anywhere in their code?
I'm asking because I'm considering building some sort of reporting tool to show areas where code cleanup could occur, but I'm not really sure where to begin.
Thanks!
EDIT: As a followup question, is there a similar tool already out there?
Visual Studio does compilation on the fly, in order to determine many of the things like this, in addition to providing functionality like Intellisense.
Right now, the compilers are all a "black box" and not directly usable. The Roslyn project has the goal of changing this, allowing the full breadth of code analysis being done to be usable. It's currently in a CTP, and could be used now.
EDIT: As a followup question, is there a similar tool already out there?
Many third party extensions, such as Resharper, provide much of this functionality (such as their Safe Delete refactoring and Solution Wide Inspections).
I'm developing a TypeScript code generator that will use custom attributes on C# classes to generate TypeScript definitions and code files.
I'm considering two options for TypeScript code generation / source file analysis:
Reflection on compiled assemblies
Roslyn CTP
The tool would use custom attributes on properties and methods to generate a TypeScript file. Right now I'm not planning to convert the C# method body to JavaScript, but in the future this may be done. So for this reason I am seriously considering Roslyn. However to simply generate the outline of my TypeScript classes I think I could use reflection and custom attributes.
I am wondering:
a) Does Roslyn provide functionality that is impossible with Reflection? My understanding is that I cannot get method bodies with Reflection.
b) Would the Roslyn CTP license prevent my from distributing the tool under an open source license? This is not clear to me after reading the license
I just did something along these lines - works great for creating your datamodel in Typescript from your c# classes. I built it to generate a single AMD-module with an interface which mimics the basic data of your Models. Also supports Generics, and creates a class with Knockout properties, including a toJS() method and an update(data:Interface) method to update your class.
The whole thing is just a single T4 template. If anyone finds this and is interested: http://spabuilder.wordpress.com/2014/07/31/generating-typescript-from-c/
Also honors [KeyAttribute] and [Timespan] attributes for data models if you are using data annotations.
I've been messing around with generating js, and I'm finding Reflection to be a better tool for this. I'm basically pointing my generator at the bin folder of the project which the metadata comes from. There might be some difficulties with loading all the needed assemblies, and caveats with versions of assemblies in the bin folder, and versions of the same assemblies that your generator project references. But once you get over all of this, which I did with minimal difficulty, Reflection is a lot easier to use, and more reliable.
With Roslyn, you are basically just parsing c#. Roslyn does this very well, but I'm hesitant to switch to it from Reflection. With reflection, you get metadata more reliably.
Let's say you want the Prefix property of a RoutePrefixAttribute that decorates a controller class. If you're parsing c#, you may have:
[RoutePrefix("stringliteral")] or [RoutePrefix(constantString)]. So, you have to worry about whether it's a literal or a constant expression, then find out how to get the value of a constant expression, worry about all the different ways in which you can pass parameters to an atatribute (for example, will this break your code: [RoutePrefix(Prefix="literal")]...
Once you're dealing with the actual runtime objects with reflection, everything is just easier. You have a nice RoutePrefixAttribute object, and you can go routePrefix.Prefix to get, reliably, the value of the prefix.
This is just one example of how doing things with Reflection is easier. It's the difference between gathering metadata from a set of c# objects in a type-safe way, and scraping data from c# code, albeit with a really nice scraping tool.
EDIT: Since writing this answer, I've bit the bullet and switched to Roslyn. It's fairly powerful once you get the hang of it, and I did find one big advantage: you can get a reference to the workspace from a visual studio plugin, and easily do all kinds of stuff within the plugin.
Update Nov, 2018
The accepted answer is valid because it's dated in Aprl,2013
Now roslyn is distributed under Apache License Version 2.0
excerpt from the license:
Redistribution.
You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You meet the following conditions:...
Roslyn have a number of nuget packages
Doesn't the license only forbid you personally from distributing the binaries? It doesn't forbid you from adding a dependency from your NuGet package to the Rosyln CTP NuGet package. You personally cannot deliver the bits, but you can have NuGet pull in Roslyn automatically.
So just avoid checking Rosyln source or binaries into your version control.
The Roslyn website not clearly states that:
The current license is for evaluation and preview purposes only and
does not allow redistribution of the Roslyn binaries. Sharing of
sample projects built on the Roslyn APIs is permitted, but sample
users must have either the Roslyn CTP or the Roslyn NuGet package
installed in order to build and run.
I wouldn't use the current Roslyn CTP - simply because there will be new versions in 2014 and those will bring many breaking changes for sure. So you might end up with totally deprecated code.
(There recently was a blog post on this by a MS team member, but I'm afraid I currently don't have the link at hand.)
EditThere's a good chance that Roslyn then will get a license that also permits for commercial use...
Update - July 2015
Roslyn is still in CTP, but their FAQ on GitHub is much more to the point:
For sample code or learning purposes, the recommended way to redistribute the Roslyn DLLs is with the Roslyn NuGet package: [url:Microsoft.CodeAnalysis|http://www.nuget.org/packages/Microsoft.CodeAnalysis].
So it appears that you still cannot redistribute the DLLs in finished products. The project will need to be open sourced and the solution will need a reference the NuGet package.
Original Answer (November 2012)
I don't believe you can distribute under open source.
6.DISTRIBUTABLE CODE. The software contains code that you are permitted to distribute in programs you develop if you comply with the
terms below.
6.c Distribution Restrictions you may not modify or distribute the source code of any Distributable Code so that any part of it becomes
subject to an Excluded License. An Excluded License is one that
requires, as a condition of use, modification or distribution,
the code be disclosed or distributed in source code form; or item
others have the right to modify it.
At first it sounds like you could do it if you just include the Roslyn binaries, but the Distributable Code definition specifically says "The software contains code..." and I believe that is what everything after is referring to.
To your other question, Roslyn isn't fully finished and is still Beta. I don't know exactly if it is currently in a state that allows it to handle your needs. That's something you may just want to spend a couple of hours tinkering with. I wouldn't think it had more functionality than what .NET currently allows. You can see what they recently added in September here and what is currently not implemented here.
For my experience using T4 generations based on reflection, as TypeLite does, is somehow simpler but has some drawbacks, like once the project depends on the classes that have been generated, regenerating them with a breaking change (renamed a class) will lead to a non compiling project so running the template again will output a blanck file and the user will have an hard time making everything compile again.
So, having the same need, i started experimenting with Roslyn, and it seems very promising, but i have many doubts on how to use it properly...
You can take a look at what i'm doing and maybe help me here: https://github.com/TrabacchinLuigi/RoslynExporter
I have written a program in c# with Vistual studio 2008.
I've compiled and build it and got a .EXE file. My question is this - if I give someone else this .EXE file can he in any way see the source code? functions, variables, calls, stack states, anything? I wish to keep those as discreet as possible.
They can use a tool like Reflector to decompile the executable, this will not be identical to your code, but they will be able to see most of what you wrote. It is a free tool, so you can download it to see what it can do with your exe.
You will need to obfuscate your code if you want to keep others from seeing it easily (though even that can be overcome with enough time and determination). A tool you can use for this is dotfuscator.
According to this SO post, one can reverse engineer a given executable and obtain the code that was used to build it. This msdn blog shows some ways you can make the process of reverse engineering a bit tougher, mainly through the use of obfuscation.
The exact same source code as you have written it no. But he could use tools like Reflector to disassemble it. In order to make the disassembled code difficult to read you could obfuscate it.
Yes.
You can use reflector to decompile any .net assembly.
http://www.red-gate.com/products/dotnet-development/reflector/
There are tools that will obfuscate your code. But it will still be visible. Security by obscurity does not work anyway.
As all have said - it's easy to decompile an assembly. Obfuscation offers very little real protection unless you're using some of the really high end commercial tools. The key things to really watch out for is if you have things like encryption keys or security tokens/credentials in your source code these are pretty easy to find.
There are a range of products available that will allow you to compile a .net app to native code which offers much greater protection.
i'm totally new to .net especially with c# 3.0 and i'm working on an access database wrapper application because we need to protect the password and content of the database from being directly accessed by a third party developer.
I'm currently testing to write a simple client app to trigger the functions in the dll and to my suprise, everytime i hit a bug i can see all the source codes in this project which shows the exact source code.
So i know i'm probably missing a lot of obvious stuff here, but how do i code it so that this won't happen, so we can hide the code in the dll from the third party developer? Or is this a setting thing which only happens because both projects is in my pc?
thanks :)
Updates:
After some browsing around, i found this previous discussion on good obfuscation tool
and i try this one tool called Eazfuscator.Net and after obfuscating the dll, i try to view it again using .net reflector or debug it via vs express2008, nothing shows no more :)
You're seeing the exact code because the source is on your machine, however, it will be trivial for your third-party developer to reverse engineer the code from the DLL using a tool such as Reflector. To prevent something like this, you may want to use a code obfuscation utility, such as Dotfuscator (you may want the paid version instead of the community version), to make it more difficult to reconstruct the code from the intermediate code.