How to: Prevent cracks of your windows phone applications

Following is an article authored for PPCGeeks News by our very own member, Ziggy471. He has many years of experience in computer programming and coding, and has written the following to help both aspiring and veteran mobile application developers deal with an issue that may arise.

So you have decided to download the Windows Phone Developer Tools in order to start developing applications for Windows Phone 7. You spend hours upon hours coming up with the greatest app ever developed to date. You decide to release it as shareware with the best licensing key algorithm that no one could ever crack. You start up a new website, spend hours making it look professional, and once you are happy with it, you decide to finally post your application. Within the first hour, 3000 people have downloaded your application, so figuring that 5-10% of those people will register the application; you start doing the math, and realize that it was all worth it. [Ed’s Note- Some MightyMike Rom’s experience 3ooo people downloading per second.]

The next day you decide to do a Google search on your application to see if Google has indexed your site correctly, but to your surprise, the top hit is a crack for your application. How could that be? You have spent way too many hours coming up with algorithms that would make NSA jealous for it all to be for naught.

This could and has happened to a lot of developers out there, but how does this happen? Well, this has to do with how Microsoft Visual Studio compiles .Net applications. In .Net applications, they are not really compiled to what you and I would consider a true .EXE file; instead, they are compiled to Common Language Infrastructure (CLI). So what is CLI you ask, CLI is a byte-code, like Java uses, so when you run the .Net application, it first uses a Just In Time (JIT) compiler to compile it for the computer or device it is being run on.

So know you’re asking, what’s wrong with CLI code? Well, with the correct application you can re-create the original code from the CLI. The code turns out to be very close to the original, with only minor differences. The application in question is .Net Reflector.

Your next question is why anyone would use this for good and not evil. Well, I had made quite a few changes in a program I maintain while deployed, compiled it, installed it on many machines, but forgot to back up the changes. My laptop was stolen after that, so I figured I had lost all that hard work, but I still had the install file. While developing ZURN for MightyMike, I was having wait cursor issues, and started researching why; well it had to do with the JIT compiler compiling the program prior to running. I kept reading about it, found .Net reflector, but that didn’t help me with Zurn at the time. However a few months later, someone needed me to fix a few problems in my application, so I had to go back to an earlier version, made the changes, but then remembered .Net Reflector, so after a few hours, I had all my other changes back in. It really was a life saver for me.

Now, how can you protect yourself from this very thing if you’re a programmer? Well, there are other applications for just that, they are referred to as Obfuscators. What they do is go through the CLI code, and rename every function and variable to simple names. For example, if you have a function called HelloWorld(String strText, String strTitle), it might change it to A(String a, String b). This does not change the actual function; it just makes it really difficult to follow. A really good example of one of these programs is Obfuscar, and it is open source, which always makes me happy.