Nullify the Sharify Scheme

Since it seems like we are on the roll, I decide to give another commercial Flash application protection scheme a try. This time our candidate is a tool called Sharify. For the record, Sharify is NOT marketed as an intellectual protection scheme. Instead, it is a license management system that claims to turn any Adobe Air applications into a shareware.

My goal is to see if one can easily bypass the licensing scheme. After all, if you were to depend on Sharify to protect your revenue stream, you may want to know if it actually works. In this example, I use the sample application included with the Sharify library.

What is in Mochicrypt Secret Encryption Sauce?

I stumbled upon Mochicrypt recently in a news article announcing the purchase of Mochi Media by Shanda Games. For those of you who are not familiar with Mochi Media, it is a California-based company that provides game developers with tools to monetize and distribute Flash-based games.

One of their producs, Mochi Live Update Service, claims to help secure games by providing an extra layer of encryption to protect against decompiling. I was interested to see if this intellectual property protection scheme can be extended to other Flash-base applications. Of course, the best way to test this protection scheme is to see if I can break it easily.

Homebrew Flash Intellectual Property Protection Scheme

My search for an ideal intellectual property protection tool that could be used for protecting my Flash projects. After spending months to test out dozens products (and eventually break all of them), I begin to wonder if it's worth developing one from scratch myself.

I normally would advise my clients against implementing any homebrew security schemes, since most of us are not experienced cryptographers and security experts. In addition, there are so many open-source and thoroughly tested security schemes available online, it's just doesn't make a lot of business sense to waste resources on research and development. Unfortunately, securing a Flash application is a bit trickier than securing a password. Since the SWF specification is open to the public, any text, pictures, and logic embedded in an SWF file can be extracted by anyone with a decompiler. Furthermore, developers have essentially no control over the runtime environment (the Flash Player), any custom security scheme must eventually comply with the normal operation of the Flash Player.

Practical Aspects of Modern Cryptography

It has been a while since I last updated this blog. I have been quite busy working on several iPhone/iPad projects and providing consulting services on computer security. A few weeks ago, I stumbled upon a very interesting website at the University of Washington, Computer Science & Engineering Department. Basically, you can access all the powerpoint presentations and video recordings of all the lectures of a master-level cryptography class. There are some very detailed discussion on public-key ciphers, AES, protocol design, and differential cryptanalysis. I certainly learnt a few new things after listening to all the lectures. For anyone interested in learning about computer security, this is definitely some high-quality study materials, completely free, that you don't want to miss.

The Rise of HTML5 and the Doom of Flash

There has been much discussion on HTML5 and Flash lately, and I just want to put in my two cents on this matter.

First, let's make it clear that I am pro-Flash. It is not intended to be an unbiased evaluation of the pros and cons of HTML5 and Flash. I do try to compare the two technologies in an objective and logical manner, as best as I could.

Updates on Defeating Nitro-LM

Several weeks ago, I posted an article on how to defeat Nitro-LM, a commercial licensing and encryption tool for Flex/Air application developers. I came across this product during my search for a satisfactory intellectual property protection solution for my other projects. Of course, one way to test if this Nitro-LM framework is really as secure as it claims to be is to try breaking it myself.

While the Nitro-LM product website boasts a whole array of advanced security features, the architecture of the product is ultimately flawed. It only took me one evening to break the protection and to obtain the encryption key. There were a few challenging moments, and it was a fun academic exercise. I posted the procedures and my experience on this blog in hope to spark discussion on intellectual property protection solutions and encryption technology.

Tamarin Gems

While working on one of my recent actionscript project, I came across some interesting and useful information on the Tamarin project site. Tamarin, of course, is the actionscript virtual machine responsible for running actionscript codes in the Flash Player. I am sure someone else must have blogged about them somewhere on the web, but I still want to mention them again here.

Defeating Nitro-LM

I have been working on a flash project that calls for some basic intellectual property protection mechanisms, which led me to discover a neat little commercial encryption framework called Nitro-LM.

Before I go any further, I want to point out two things. First, I am all for open-source and sharing codes (which is the main reason why I started this blog), but there are definitely situations when you want to encrypt part of the code, for your own benefits as well as the protections of your users. For instance, let's say you have developed an awesome online game, you certainly do not want a cheater to reverse-engineer your code, exploit it, and ruin the fun for other players, right? Second, I admit that client-side code is never 100% secured. This is especially true for flash applications, which can easily be decompiled. Even if you apply all the encryption and obfuscation technologies in the world to protect your code, an overly zealous hacker can still, given enough time and effort, reconstruct the source code from bytecode.

Therefore, let's agree that the purpose of any intellectual property protection mechanism is not to prevent others from exploiting your code, but rather to make the process of reverse-engineering less cost-effective than actually playing by the rules. That's said, I set out to test if this Nitro-LM framework is enough for my task.

Facebook and Google Map with PhoneGap

I have been experimenting with a neat little framework created by the folks at PhoneGap recently, and I am quite impressed by the results. This framework allows developer to build HTML and Javascript applications that take advantage of the special features, such as GPS, on iPhone, iPad, Android, Palm, and Blackberry.

The first thing I tried is to get the GPS location and display the coordinates on Google Map. It works quite perfectly. Next, I want to connect the application to Facebook. Things get a little trickier. Since the HTML and Javascript code are stored and run locally on the device as part of the application, I need to find a way to get the session key and the session secret from Facebook. While there exists third party libraries for developing Desktop Facebook applications, I prefer to write my own code.

Loading the session key and the session secret from Facebook is rather trivial. I simply tell Facebook to post the information to a callback page on a server and remit the information. The problem is, however, that the callback page and the local javascript run in separate security sandboxes; the local javascript cannot access the information remitted by the callback page. Here is where HTML5 comes to the rescue.

Simple PHP Facebook API

Facebook is by far the most popular social networking site on the web. If you are a web application developer, chances are you have tried to use the Facebook API at least once. While the Facebook developer platform offers Facebook Connect and Client Libraries for various languages, including PHP, Javascript, ASP.NET, and Actionscript, these libraries are, in my opinion, rather hefty.

In one of my recent projects, I wanted to allow my client and server code to interface with Facebook "directly". Of course, one should avoid hardcoding the Facebook App API Key into the client code, and one should NEVER transmit the Facebook App Secret to the client side at all. Therefore, any client calls to the Facebook API should be passed through a server.

Welcome to HackaBee

Welcome to HackaBee.

As an amateur web application developer and an all-too-typical geek, I come across some interesting discoveries and new tricks on software architecture and system security every now and then during research and development. The purpose of this blog is to document these findings for my personal amusement, to share them with other developers, and to connect with like-minded individuals across the web.

I would like to stress that while I enjoy, as a hobby and an academic exercise, hacking and reverse-engineering, I think the matter of internet security very seriously. The ultimate goal of any hacking attempt is to use the knowledge to help improve overall security. Please do not use any of the information posted on this blog to exploit others or to carry out unauthorized attacks on a security system. Remember "with great power comes great responsibility".

Hope you enjoy this blog and have fun hacking ethically.