Paul Mason

I was at a friends house the other day and he handed me a book. "You've gotta read this - it's written by the guys from Basecamp and... well just read it." Intrigued, I put the book in my napsack (sounds better than in my pile of papers) and took it home with me. I put it on my desk and then went about my day. It stayed sitting on my desk for a couple of days, partially forgotten, and then a strange twist of fate (a rainy Sunday) made me pick it up and start reading.

As soon as I started reading, I couldn't put it down. I tried... twice. However before I knew it I had read it cover to cover. This isn't quite as cool as it sounds as the book is padded a bit with illustrations however don't let that fact distract you from the quality of the content.

The book I'm talking about is Rework written by the founders of Basecamp.It is essentially a list of micro tips that the authors have discovered while building their business. And to be quite honest, it is very insightful. I found a lot of value between the two covers of the book; it all seemed to sit well with me based on my previous and current experiences with business. In fact, I've already started implementing some of those lessons in my everyday life - hence this blog post.

Sell your by-products

One of the "tips" that stood out for me (btw there were many, however this one relates to the blog!), was to understand that business production creates by-products. For example, a saw mills by-product is obvious: sawdust. Rather than throw out that by-product they package it and sell it. Waste not want not! The book re-iterated that every business has by-products - even software development companies. The by-product of a software development company may, for example, be knowledge. Why not package that and sell it?

What are you talking about?

Now, I'm not going off to write a book (well, yet!), however I did realise that I need to make my blog more of a by-product of my work. I learn a lot of lessons day to day during development (ASP.NET MVC, C#, Testing, DI, Ruby, Objective C etc) and business therefore I realised that I should start to post more often about lessons I've learnt. This works three-fold:

1. I get to learn the lesson again
2. I get to share the lessons for others in that area
3. I save myself time

An important motivation for this change of direction is the 3rd point - time. My time has become extremely precious lately therefore I want to make sure that the time I have is used in the best possible manner.

What does this mean for your blog?

The reason I started the "Protecting your precious code" series was primarily because I have an interest in the topic of software security and wanted to learn some more. I never use this in my day to day work anymore (well very rarely - largely web-app development), therefore consider it a hobby project. Because it is a hobby project, I haven't had as much time as I'd have liked over the last few weeks to put into it; hence posting has suffered.

Rest assured, this blog is not going to stop - nor am I going to cease posting about security topics! However, I will be posting more often, mixing a lot more of my day to day lessons in there.

What about NCloak?

NCloak will still be maintained however it will be done in my spare time. My goal with this project is to stabalise it and get it ready for production use rather than adding more features after more features. Ideally, it is to make it really good at obfuscation before even considering further enhancements.

Hit me with it

I'm sure this post is going to disappoint a few people, however hopefully it also ignites excitement in many others. It certainly excites me as I love sharing knowledge. As mentioned above, I will not just drop software security from my topics, however moreso update periodically as new information/lessons come to light.

So... hit me with it... thumbs up or thumbs down? Even though I really need to make this decision for the good of myself and this blog I still would like to hear everyones opinions!

P.S. Anyone else read Rework? What lessons stood out for you?

Mono.Cecil was developed by JB Evain back in the fall of 2004 and since has had a fairly stable code base that has changed very little. The world has rather changed around Mono.Cecil... until now! Mono.Cecil has now been updated utilising many compiler features introduced with the .NET framework over the years, fixing many bugs, improving performance, and also improving code flow for developers.

Since NCloak is still in development (with many bugs - thanks to those logging them; I'm getting through them slowly!), I thought it would be a perfect chance to stay on top of the game and upgrade to the shiny new v0.9.2 of Mono.Cecil. This is a breaking version upgrade therefore, as expected, drove me a little insane ironing out all of the introduced bugs in the code! This article is essentially a summary of "gotchas" outside of the migration document to help anyone else performing a migration.

A summary of "gotchas"

I started this post as a diary of the migration process; to be honest it started to get extremely tedious and began to lose usefulness. Therefore, instead I've simply written up a summary of important changes so that it hopefully retains some form of value. Please note, these are notes over and above the migration document already released:

• Mono.Cecil comes with a "Mono.Cecil.Rocks" library now. This is a very useful library containing extension methods for various objects. It wasn't immediately obvious for me that this existed; I only discovered it when looking for the Optimize() and Simply() methods that used to be on MethodDefinition.
• ModuleDefinition.Types does not return the full type list anymore! We need to make sure that we call the Rocks extension: GetAllTypes()
• There is no TypeDefinition.Constructors collection on the type anymore; rather it is all included under the TypeDefinition.Methods collection. This means that you need to filter out constructors where necessary using the IsConstructor property on the method.
• The architecture of the assembly is now exposed! Check out the Architecture property upon each ModuleDefinition.
• When creating a new MethodDefinition, the "Body" is not automatically populated with an empty MethodBody. You now have to manually create an instance of this before retrieving any ILProcessor.
• Some helper functionality (such as saving the assembly to a byte array) has now been removed. Instead each assembly has a Write method which accepts a Stream. To get a byte array, you'd need to write to a MemoryStream and use the ToArray() method from there.
• Some interfaces have been deprecated; e.g. IMemberReference is no longer present and can be replaced with MemberReference.
• The ParameterDefinition constructor no longer requires the parameter position to be provided.
• MethodDefinition.GetOriginalMethod() has been replaced with MethodDefinition.GetElementMethod()
• FieldDefinition constructors have had their parameter ordering changed (more logical?)

Anything still broken in NCloak?

Unfortunately I couldn't fix everything just yet; there was one area which I believe either needs to be patched within Mono.Cecil or relaxed in NCloak. Currently in our ConfuseDecompilationTask we insert some invalid IL to throw off Reflector and other reverse engineering tools. It is a dodgy method of doing so, however perfectly legal within the framework - well, more specifically overlooked in the framework.

The new version of Mono.Cecil is much stricter than before in regards to faulty OpCodes. We use a framework hack to create an OpCode which is essentially a "nop" in disguise. It appears from initial investigation that Mono.Cecil adds it fine, however internally marks the operand type correctly when added to the IL body - i.e. instead of InlineNone, it may mark it as InlineBrTarget. In itself, this isn't an issue, however when it comes to optimization this causes an exception. The real error is that it has come across a "branch target" without an operand, thus causing a NullReferenceException (Mono.Cecil assumes a branch target has an operand).

So what could we do to fix this? Well, we have two options:

1. We could perform a check in Mono.Cecil.Rocks to check for a null operand and skip optimization for that instruction or...
2. We could relax NCloak and choose instructions which aren't branch related (but still short codes).

For the meantime I've just disabled optimization when invalid IL is inserted (works fine), however haven't decided for the long term fix. What do you think it should be?

Conclusion

As expected, we ran into a myriad of issues from upgrading to Mono.Cecil v0.9.2. Most of these issues were simply breaking changes due to member renaming or member functionality changing. While we managed to iron out a lot of the creases from the upgrade we still have a few that we'll get out over the next few irons (I love using metaphors :)).

However, now that we have now upgraded to the new version of Mono.Cecil which means that we can continue stabalizing NCloak bit by bit so that it is ready to be used in real world .NET projects as opposed to in my controlled "laboratory".

Future Episodes

As some of you have noticed the blog posts have slowed down substantially; I am aiming to get at least one post per fortnight at present - more as time permits. Nevertheless, I'm still hacking around when I get the chance therefore will share any interesting information I discover on my journeys.

Last week I put it out there as to what you would like to see in coming articles; I saw the Mono.Cecil v0.9.2 upgrade as a bit of a roadblock therefore now that is out of the way we'll be covering the following:

Definitely

Code flow transformations

Dead code removal

Dispatcher driven tamperproofing

Namespace obfuscation

Anti-debugging techniques

Creating a managed IL parser

Bug fixing articles - well interesting ones!

Lightspeed tips and tricks

Resource Encryption

There were also a few "maybe's" which we'll reintroduce in response to demand. As per usual; please feel free to add your opinions!

So, I've been busy lately; so much so that I've needed to put things on hold for this blog. To get back into it, I was going to pick a random topic - really just as a warm up process. So, I went about writing an article. After about an hour and a half into it, somehow my well used computer managed to lose it. Now this is strange as I was writing it online (with supposed auto-save) however it has now disappeared with no sign of it at all. To be honest it wasn't my best piece of work anyway (a sign?). Anyway, rather than write it all out again, I thought I'd come from a different angle:

What would you, the reader, like to read about?

I've come up with a few topics that have either been suggested before, or that I've had an urge to write about. What would you like to read about in the next few months?

• Using Mono.Cecil to automate string decryption decompilation - personally not sure about this one. It can be done, however it would be a "best guess" situation (i.e. find a ldstr that uses a bytearray, work out what method was called and assume that that function is used for decryption).
• Code flow transformations - maybe a good one once ncloak stabalises a bit more?
• Dead code removal - yep, we could do this. We just need to improve our mapping process to build a better graph
• Tamper proofing improvements - we've got a pretty basic implementation in there but it seems weird improving this when the product needs stabalising
• Dispatcher driven tamperproofing - this is quite an interesting one actually and would be good to have a look at.
• The .NET hacking toolkit - I started to write this but then realised this is quite a big one. Perhaps draw up a list which can then be added/modified by the reader? Think it'd be useful as I'm pretty old school with this; it'd be interesting to see what's out there.
• Anti-debugging techniques - I do see the usefulness of this, however the current state of ncloak does make it difficult to implement. Theory only doesn't interest me much... not sure about you guys?
• Watermarking - could be an interesting one; although I see its usefulness as fairly limited?
• Creating a managed IL parser - an interest topic really. I've got experience writing compilers, and thought it might be nice to be able to compile IL in memory as opposed to being forced to use the OO approach. Anyone else?
• Cecil 0.9 migration - A new version of Mono.Cecil is out(!) so this is inevitable. Is it worth writing an article about gotcha's?
• Bug fixing articles - there are a few bugs in ncloak at the moment. Bugs are always a good chance to learn something :)
• Lightspeed tips and tricks - big fan of their products and always discovering bits and pieces that make life a lot easier!
• Build process enhancements - big fan of process/standards!
• Writing a basic compiler - an interest topic really.

This isn't an exhaustive list! What would you like to see?