{"id":3560,"date":"2012-05-31T17:11:00","date_gmt":"2012-05-31T17:11:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/postsharp-obfuscation-and-il\/"},"modified":"2016-07-28T10:50:49","modified_gmt":"2016-07-28T10:50:49","slug":"postsharp-obfuscation-and-il","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/postsharp-obfuscation-and-il\/","title":{"rendered":"PostSharp, Obfuscation, and IL"},"content":{"rendered":"

Aspect-oriented programming (AOP)<\/a> is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp.<\/p>\n

Attributes and AOP<\/h4>\n

Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member.<\/p>\n

PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect<\/code>, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare ‘clever’ attributes that change the behaviour of whatever the aspect has been applied to at runtime.<\/p>\n

A simple example of this is logging. By declaring a TraceAttribute<\/code> that derives from OnMethodBoundaryAspect<\/code>, you can automatically log when a method has been executed:<\/p>\n

public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect\n{\n    public override void OnEntry(MethodExecutionArgs args)\n    {\n        MethodBase method = args.Method;\n        System.Diagnostics.Trace.WriteLine(\n            String.Format( \n                \"Entering {0}.{1}.\",\n                method.DeclaringType.FullName,\n                method.Name));\n    }\n    \n    public override void OnExit(MethodExecutionArgs args)\n    {\n        MethodBase method = args.Method;\n        System.Diagnostics.Trace.WriteLine(\n            String.Format( \n                \"Leaving {0}.{1}.\",\n                method.DeclaringType.FullName,\n                method.Name));\n    }\n}\n\n[Trace]\npublic void MethodToLog() { ... }<\/pre>\n
Now, whenever MethodToLog<\/code> is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog<\/code> itself.<\/p>\n
PostSharp Performance<\/h4>\n
Now this does introduce a performance overhead – as you can see, the aspect allows access to the MethodBase<\/code> of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase<\/code> instance using Type.GetMethod()<\/code>, matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things.<\/p>\n
Ldtoken<\/h4>\n
C# allows you to get the Type<\/code> object corresponding to a specific type name using the typeof<\/code> operator:  <\/p>\n
Type t = typeof(Random);<\/pre>\n
The C# compiler compiles this operator to the following IL:<\/p>\n
ldtoken [mscorlib]System.Random\ncall class [mscorlib]System.Type\n    [mscorlib]System.Type::GetTypeFromHandle(\n        valuetype [mscorlib]System.RuntimeTypeHandle)<\/pre>\n
The ldtoken<\/code> instruction obtains a special handle to a type called a RuntimeTypeHandle<\/code>, and from that, the Type<\/code> object can be obtained using GetTypeFromHandle<\/code>. These are both relatively fast operations – no string lookup is required, only direct assembly and CLR constructs are used.<\/p>\n
However, a little-known feature is that ldtoken<\/code> is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle<\/code> or RuntimeFieldHandle<\/code>:  <\/p>\n
\/\/ get a MethodBase for String.EndsWith(string)\nldtoken method instance bool [mscorlib]System.String::EndsWith(string)\ncall class [mscorlib]System.Reflection.MethodBase\n    [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle(\n        valuetype [mscorlib]System.RuntimeMethodHandle)\n\n\/\/ get a FieldInfo for the String.Empty field\nldtoken field string [mscorlib]System.String::Empty\ncall class [mscorlib]System.Reflection.FieldInfo\n    [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle(\n        valuetype [mscorlib]System.RuntimeFieldHandle)<\/pre>\n
These usages of ldtoken<\/code> aren’t usable from C# or VB, and aren’t likely to be added anytime soon (Eric Lippert’s done a blog post<\/a> on the possibility of adding infoof<\/code>, methodof<\/code> or fieldof<\/code> operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken<\/code> to get MethodBase<\/code> objects quickly and cheaply, without having to resort to string lookups.<\/p>\n
The kicker<\/h4>\n
However, there are problems. Because ldtoken<\/code> for methods or fields isn’t accessible from C# or VB, it hasn’t been as well-tested  as ldtoken<\/code> for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken<\/code> and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way.<\/p>\n
So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase<\/code> of generic methods is to use reflection: Type.GetMethod()<\/code>, passing in the method name as a string along with information on the signature.<\/p>\n
Now, this works fine. It’s slower than using ldtoken<\/code> directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated.<\/p>\n
PostSharp and Obfuscation<\/h4>\n
When using ldtoken<\/code>, obfuscators don’t affect how PostSharp operates. Because the ldtoken<\/code> instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase<\/code> at runtime. If the name then changes, PostSharp can’t find it anymore, and the assembly breaks.<\/p>\n
So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra ‘name table’ resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table:<\/p>\n
MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22));\n\nPostSharp.NameTable resource:\n...\n20: get_Prop1\n21: set_Prop1\n22: DoFoo\n23: GetWibble<\/pre>\n
When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected:<\/p>\n
MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22));\n\nPostSharp.NameTable resource:\n...\n20: #kkA\n21: #zAb\n22: #EF5a\n23: #2tg<\/pre>\n
As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly<\/a> does too.<\/p>\n
So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don’t see those every day!<\/p>\n","protected":false},"excerpt":{"rendered":"
Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary……<\/p>\n","protected":false},"author":186659,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[],"class_list":["post-3560","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3560","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/186659"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3560"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3560\/revisions"}],"predecessor-version":[{"id":42165,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3560\/revisions\/42165"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3560"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}