I tried to use code protection (code is encrypted and can't be reflected) made by clisecure with postsharp but secured dlls won't compile when post sharp is used in solution. I use just PostSharp.Laos and PostSharp.Public
Have You ever tried such combination? Did you manage to make it work. If so please tell what obfuscation tool and what code weaving framework have you been using?
I have successfully used Dotfuscator and Postsharp in combination but only with the compile time IL Weaving and not yet with any runtime interception. Everything should be fairly straightforward as long as you obfuscate the binary that PostSharp post-compilation weaving outputs.
The usual obfuscation caveats apply to any of your cross cutting code (especially where you use reflection) as obfuscation changes symbol names and you will need to exclude any symbols from being renamed or pruned that will be reflected upon or that use late binding.
There are some tricks when using an obfuscator. For instance, you cannot change the name of aspect types and fields of aspect types because aspect are serialized by PostSharp and deserialized at runtime. You may want to use obfuscation exceptions for aspects.
Another issue is that you cannot rename some methods that are the target of aspects. I think this happens only with generic methods or methods of generic types.
An alternative is to use an obfuscator that does not rename the code, such as WIBU. I did not try, however.
Related
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'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.
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've been using some basic AOP style solutions for cross-cutting concerns like security, logging, validation, etc. My solution has revolved around Castle Windsor and DynamicProxy because I can apply everything using a Boo based DSL and keep my code clean of Attributes. I was told at the weekend to have a look at PostSharp as it's supposed to be a "better" solution. I've had a quick look at PostSharp, but I've been put off by the Attribute usage.
Has anyone tried both solutions and would care to share their experiences?
Couple of minor issues with PostSharp...
One issue I've had with PostSharp is that whilst using asp.net, line numbers for exception messages are 'out' by the number of IL instructions injected into asssemblies by PostSharp as the PDBs aren't injected as well :-).
Also, without the PostSharp assemblies available at runtime, runtime errors occur. Using Windsor, the cross-cuts can be turned off at a later date without a recompile of code.
(hope this makes sense)
I only looked at castle-windsor for a short time (yet) so I can't comment on that but I did use postsharp.
Postsharp works by weaving at compile time. It ads a post-compile step to your build where it modifies your code. The code is compiled as if you just programmed the cross cutting concerns into you code. This is a bit more performant than runtime weaving and because of the use of attributes Postsharp is very easy to use. I think using attributes for AOP isn't as problematic as using it for DI. But that's just my personal taste.
But...
If you already use castle for dependency injection I don't see a good reason why you shouldn't also use it for AOP stuff. I think though the AOP at runtime is a bit slower than at compile time it's also more powerful. AOP and DI are in my opinion related concepts so I think it's a good idea to use one framework for both. So I'll probably look at the castle stuff again next project I need AOP.