The Business of Software

I had an old VB.Net class that I wanted to update but at the same time move into C#. Looking on the net I found a few tools that could save me time by auto-translating from VB to C# so I downloaded a few to try.

They were all demos and restricted in some way, so after more searching someone pointed out that Reflector has an MSIL disassembler built-in (which I'd overlooked) so I built my VB.Net and used Reflector to disassemble as C#. Unfortunately it doesn't make it easy to do large blocks of code but it got me thinking ...

I opened up one of the demo translators in Reflector and checked the classes. Although variable names are not carried from the original source into the IL the methods are, and sure enough I could see the form where the registration code was entered. Looking at the disassembly it was obvious what method was called to validate the registration so I looked at the code for that too.

Less than 15 minutes later I had a small app built that worked the validation logic in reverse to generate a registration code - which worked first time.

In this case, it was done as an experiment to see how secure .Net is after I had discovered Reflector's disassembler. I am not retaining the 'hacked' version or condoning it. However, I am more than a little concerned that from discovering Reflector it took me less than half an hour to crack the registration on an application costing over $100 and open up all it's features.

An obfuscator obviously would have hindered me somewhat but I am just stunned that the IL generated cqn give a virtually perfect representation of the original source - complete with method names - by default. What happened to Microsoft's much vaunted focus on security?

You are talking about a different kind of "security".

It is well known that what you have done is possible in both .NET and Java. But the fact is that it is also quite easy to do in C++ and even Assembly Language. There is no such thing as perfectly secure code. There is another thread here that talks about this quite a bit so I won't go into details.

There is a rule of thumb that as long as the code is actually running on your PC on your processor, then it is not secure, can be tampered with and is generally under your control.
Some advanced obfuscators out there, as well as obfuscating, are putting code in there that will crash ILDasm (used by the Reflector). So again, maybe an advanced cracker could have its own IlDasm that doesn't get crashed by the obfuscating code, but then we are talking about a little more effort involved, which would act as a deterrent.

Reverse engineering .Net code is no secret...has nothing to do with security per se....Microsoft interprets security through its CAS (Computer Access Security) protocol which involves things like permission sets granted to write to a server, and other I/O services.

You have to obfuscate or encrypt your executable if you want to PROTECT it.....

I've spent the money already for this software as an added piece of the protection scheme.....welcome to the world of complexity also known as technological innovation...

Karl,

You might want to read my recent essay "Fighting the software Pirates".
http://sleeksoft.co.uk/public/techblog/articles/20050621_1.html

If somebody is determined enough, they're going to be able to reverse-engineer your code, regardless of whether it's written in .NET or not. But you can raise the barrier fairly high - there's a significant opportunity cost to do this with obfuscated code.

Karl Cartlidge-

It is clear you have no serious and/or intensive education in computer science and/or software engineering. Do you know why .NET is every bit as vulnerable to decompilation as Java? Do you know why langages such as C/C++ are less a target to decomilation? Can you explain why?

thank you for your contribution to the field of software engineering. you are a true patriot. God bless. You are a true idiot.

Mark, very nice blog post on the subject! There are some real golden nuggets provided in your post.

I have grave doubts about the future if shrinkwrap software as a business model, unless you can force bundle as Microsoft does, precisely because there's no way to copy protect or enforce a license in a way that's very hack resistant.

compilation != obfuscation != security

Rowland. I disagree. Microsoft will find a way. They will have no other choice. It may mean constantly phoning home but that is becoming more and more acceptable every day.

To respond to Arrg first - I must admit to a little confusion at the tone of your response. There is nothing in my post to warrant such an offensive reply.

However, to answer you I have been a software developer since the mid 1980's, from DEC Vax through Act Sirius to DOS then Windows, using everything from Pascal and Modula-2 through 8086 assembler and onwards past Forth and Cobol, Delphi and PHP, Perl, Visual Basic and C#. I know exactly why IL and Java are more vulnerable given their byte-code nature and their almost one-to-one relationship between the op-codes and the original source in comparison to the low-level code produced by C++ etc where a single line of source is very tricky to deduce from the resultant machine code - though I have done it on occasion.

My post was not about disappointment that the bytecodes could be disassembled (which as you say is obvious) but the fact that not even a basic level of obscuration is implemented - in particular the surprise that method names were plainly visible.

To other posters, many thanks for the comments and links. I am aware that at a development level this is a different kind of security as Turtle Rustler elegantly details. At a business level (and this post was in the Business area not Design or specifically .Net questions) this is definitely a security issue.

Alexis, thanks for the advice on the obfuscators - I wasn't aware they could crash ILDasm, I've not looked at them for a while but I'll take another look now.

Brice, thanks for the example. I'll probably have to follow you on that. Is there anything you'd especially recommend?

Rowland, I'm inclined to agree. I'm heading down the road of pure web-based so I have total control of this aspect.

Mark, I have to agree with Turtle Rustler again; excellent advice and very nice (and helpful) code. Thanks.

With the exception of Aaargg's unhelpful rudeness a big thanks to the replies. My post was mainly to get it off my chest with people who'd understand so it's a pleasure to get such good replies.

My mother will purchase software, and so will the rest of mainstream society.  They simply dont have the means, knowledge or time to learn how to crack software, nor do they have the means, knowledge or time to download cracked software from the internet.

@Marc,

as you just mentioned your article. It has been helpful for me and I've used your techniques in my product. One pitfall I think you should add to your article: the code seems to crash on certain systems. I had one customer running Win ME and one Win 2K. And these are only the two that actually told me via email. Most trial downloaders probably just looked elsewhere.

Putting the whole security procedure into a try/catch block solved the issue for me.  :)

Just a thought .. what are .NET component vendors such as Infragistics and Component One doing to protect their source?

Security can mean many many things. This is not generally a security issue, as it has little effect on the user, who is the normal subject of a computer software security discussion.

Presumably the method names are there because of reflection. Reflection is one of the very powerful features of C# and other .NET languages, and with Java and Python and a whole host of other languages. It has its costs, and this is one of them.

The combination of reflection, obfuscation and refactoring tools is providing me endless amusement, as the developers of each each of them compete in an endless game of rock-tissue-scissors.


> My post was not about disappointment that the bytecodes could be disassembled (which as you say is obvious) but the fact that not even a basic level of obscuration is implemented - in particular the surprise that method names were plainly visible

Well, what you have to remember is that reflection is considered a *feature* and not a flaw.

It's not just unsurprising but completed expected that a necessary component of the reflection feature has actually been implemented. Any vaguely pseudo-effective obfuscation is going to kill reflection dead in its tracks.    ;)


Incidentally, the real flaw is that the key checking code could be operated in reverse to produce a valid key. If they had real protection it would use asymetric key generation and have the keys checked in many places, probably using carefully managed obfuscation, so that you couldn't have generated a key and finding every place that it's checked would be problematic.


> What happened to Microsoft's much vaunted focus on security?

Even Microsoft doesn't think that security through obscurity is a good plan.

Philipp,

Thanks for the heads-up. I'll shortly add the obvious caveat to my essay saying that this isn't production code, and it hasn't been tested like production code. Use at your own risk! In fact, I've only tested it under Windows XP with CAS set to FullTrust for my test assembly.

Do you have any idea what the exception produced for Windows ME or Windows 2000 was? The most likely problem is something to do with security - as noted in the essay, some of the code requires FullTrust to execute properly. In fact, I'm probably going to change the code to test the exact security context required by each procedure.

The security permissions that Microsoft requires relative to a .net executable are programmed through the CAS (Code Access Security). I wanted to correct the acronym as I had defined it incorrectly in an earlier post here...

I personally think that CAS is a pain in the ass to work with because it CAN create barriers to software distribution protocols within a network. In short, it requires another level of complexity (IMHO) to deploy successfully.

I get around using CAS by NOT deploying those services for which a permission set is required. For example, if you are looking to write files, do NOT write them to a server but to the local drive instead - when using I/O I opt for writing to the local root directory because anyone can find files there, and no permission set is needed to write to the local drive.

While I understand the need for CAS in today's crazy computing world, I certainly want to avoid it like the plague whenever I can...

As for the question of what encryption software I use for my .Net executables.....I use a software package called the .Net Reactor. It does NOT obfuscate .Net executables but encrypts them in a way that extends beyond obfuscation protocols.

The software is very reasonably priced (about $123 per license) and it is a STAND ALONE app. Because VS is updated every 2 years, I was NOT looking for an encryption solution that was integrated into the VS IDE....I want a stand alone app that will support multiple versions of VS.

I've tested the tool and found it to work quite effectively for my purposes. There are a host of other things the software accomplishes, but I was only interested in using it to protect my .Net executables.

For those interested the website is: http://www.eziriz.com/

I've updated my essay to add the caveat about not using this code in production without doing some thorough testing first. Of course, this is true about all code that you find on that thar Intraweb.

"old lady" said it best, IMO.  This is a good motivation to produce software that targets regular people as customers, who don't have the technical wizardry to crack software and don't consider it worth their time to seek out a cracked version.

Software piracy has been around since the dawn of the personal computer (I remember plenty of cracked Apple ][ games), but it has yet to wipe out the software industry.

MS does provide a basic obfuscator in VS for free.
The same co. sells a pro model, which I like.
http://www.preemptive.com