I've been trying to apply code protection using the SmartAssembly obfuscator to a WPF Prism application, but it the application refuses to work properly when being obfuscated.
The only option that works for it is: Prevent Microsoft IL Disassembler from opening my assembly.
The Red-Gates help describes it as: SmartAssembly can add an attribute to your assembly that prevents Microsoft's Common Intermediate Language (IL) Disassembler (ildasm.exe) from opening your assembly.
I wonder how serious is this protection, is it worth to be applied if the code isn't really obfuscated.
Or, in other words, what is it this Microsoft's Common Intermediate Language (IL) Disassembler (ildasm.exe)? Is it the main part of every known .NET reverse engineering tool or is it just one of the many such tools?
ildasm.exe is the IL disassembler that comes with the .Net Framework. It's the one tool that everyone has if they have .Net. It's not a component, so other disassemblers are not based on it or anything.
The attribute in question is the SuppressIldasmAttribute. I do not know if other disassemblers such as Reflector or ILSpy respect this attribute, but I doubt it. A cursory Google search suggests that is not the case, and that the SuppressIldasmAttribute only affects ildasm.exe itself.
As such, it doesn't really protect your assembly and isn't much use as an obfuscation tool. But if you are obfuscating anyway, I don't see any reason why you wouldn't apply this attribute, as it at least blocks the easiest (most commonly available) method of disassembly and I don't think it does any harm.
Related
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 have a desktop(winforms) application, and I'm looking for .net linker that links the assembly to assembler level(lower than IL) in order to prevent reverse engineering. another solution might be acceptable as well.
does anyone know of such a linker?
What you're looking for is an obfuscator. It jumbles up the compiled code so that it still does what it is supposed to do, but if you decompile it, it is incomprehensible to most.
Note that any attempt to make it 100% safe is guaranteed to fail, all you can strive for is making it as hard as possible.
There's many solutions that will do this in various ways:
Dotfuscator
Remotesoft Salamander Protector
Spoon Studio
Note, the last one isn't an obfuscator, it virtualizes out your application. Some of the benefits of that is that it is a bit harder to get to the underlying code, but it is primarily a product that solves different problems, namely the need to separate out the application from the rest of the applications installed (ie. no need for .NET to be installed, no conflicting registry settings, etc.)
You may want to have a look at the The Mono AOT (Ahead of Time) Compiler :
Ahead of Time Compilation
Mono Ahead Of Time Compiler
There are some limitations though: you obviously can't compile an assembly that uses CLR dynamic features, reflection, etc.
.Net Reactor is what you are looking for I guess (it is hackable - but way harder than classic obfuscation).
XenoCode has a cool tool that will help you do that:
http://www.xenocode.com
Checkout Code Projection by Xeno, its effective.
Obfuscation is may be good for your needs. But it still hackable.
I don't know any programs and utilities that you asking for but I have an advice for you.
If you need to protect not all application code but only critical sections, you can implement this sections in C++/C and use Platform Invoke to interop with unmanaged code.
Jeffrey Richter recommended this approach.
I recently got excited by the idea of statically check design by contract in .net 4.0 / Visual Studio 2010.
However I was saddened to find out that it will only be available in Visual Studio Team System. http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx
Are there any alternatives which give statically checked design by contract for c#?
Will the mono project be adding this functaionality to there compiler?
He's referring to the theorem prover.
There's nothing stopping the open-source or commercial community from implementing their own. The Contracts classes are part of the BCL and trivially easy to add to, say, Mono. "We'll" need to make a theorem prover if we want to statically check things.
The prover is not part of the compiler. It basically runs as follows:
Compile a version of the binary with CONTRACTS_FULL defined. This emits all Contract attributes and calls to the Contract class static methods.
Load the assembly "for reflection only," and parse all the method's byte code. A detailed flow analysis with state information will allow certain contracts to be shown "always true." Some will be "known false at some point." Others will be "unable to statically prove the contract."
As the tool gets better, it will go from giving warnings about every contract to eventually offering similar proving results to the Microsoft version.
Edit: Man, if Reflector was open sourced it would be great for this. A first-pass implementation could certainly operate as a plugin. That way the prover logic can be designed without worrying about how the binaries are loaded. Once it proves functional (get it?), the logic could be extracted and built to operate on the syntax trees produced by another assembly loader (one that is open source). The important/novel thing here is the prover logic - the assembly loader has been done multiple times and nothing changes spectacularly for this use.
Code contracts do not require the C# compiler as they are implemented as classes in the .NET Framework 4.0. Any .NET compiler that can emit a managed assembly is usable, although C++/CLI will likely emit an incompatible assembly when mixing managed and native code.
There are additional tools executed by the IDE to rewrite the resulting IL so that the contracts appear in the correct location, and thus the Mono project authors would need to write similar tools for contracts to work on the Mono platform.
See this post for more information.
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.
HI,
Is there a way to prevent a particular dll in C# being opened in reflector. I can open many of the dll's and can get the code using reflector. But when trying to open some dll's it shows an error message stating that "The particual dll does not contain a CLI header.".
How can I make a dll like this??
Are you sure that these DLLs are managed-code-dlls? I don't think so, if they don't contain the CLI header, they aren't written in C#.
And for your question, you can't prevent a managed-DLL from being opened in a decompiler, all what you can do is to obfuscate it.
If you want to protect your .net dll you could obfuscate your assembly
Free .NET Obfuscation Tools
You have commercial ones too...
"The particual dll does not contain a CLI header.". message appears in Reflector because they are not managed dlls (.net).
I thought there was once a certain IL code which caused a crash in the reflector. But this bug is fixed now.
Obfuscation is nice - You can also try to encrypt certain critical parts of your code and decrypt+load+compile it at runtime. The problem is how to store the password.
You can't prevent it from being opened by the reflector.
There is no way to prevent Reflector from opening .Net assemblies, but you make make it pointless by obfuscating your assemblies. After obfuscating, class/method/fields are renamed, inline strings in methods are encrypted, method calls are hidden, method control flow is scrambled and so on. So, anybody who use Reflector will see a lot of garbage and will not be able to make sense of most of it.
DISCLAIMER: I work for LogicNP Software, the developers of Crypto Obfuscator