Microsoft does little to protect revenues for Windows Store devs

What's been emerging over the past year or so is that a pretty decent way of making money out of apps for tablets and smartphones is in-app purchasing (IAP). The idea of IAP is it allows you to build a game that you give away for free, but you allow users to buy premium items. For example, you may be able to earn gold coins by completing tasks in the game, but if that's too much effort you can just buy the coins that you want using real money.

This kind of "freemium" model is shaping up to be the only way to make money out of mobile apps and any platform owner that's a newcomer to the market -- and I'm talking about Windows-based phones and tablets - needs to have its act in order when it comes to helping developers take advantage of this opportunity. 

Earlier this week Justin Angel, a Windows Phone engineer at Nokia published an article on his personal blog of showing various ways of exploiting IAP to get goods that you haven't paid for, hide ads in ad-supported software, and flip trial versions to full versions without payment, on both Windows 8 and Windows RT. 

Whilst Justin's work is diligent and well-executed, the main problem here is that what he shows is very, very easy. Although no one's put all these pieces together quite so publicly, a decent developer could create a proof-of-concept for everything he's done from first principles in a few hours. In all cases, there is essentially no level of protection at all. Windows 8 and Windows RT are wide open. If you're a developer targeting Windows tablets, your entire userbase can click a few switches and your revenue stream is cut off. (Of course, they have to be inclined to do so.)

Peculiarly (well, maybe it's not that peculiar given his employer's relationship with Microsoft), his website is down so I can't link to his article. But I can talk through the problem and his findings.

Getting stuff you haven't paid for

Let's say you're a developer who builds a game that you want to put some premium content in. What you would normally do is have the normal game mechanics rewards you with some items -- we'll use gold coins in this example -- but users can buy extra coins using real money. Regardless of platform, you will need to store, persistently and locally, the number of coins that the user has. When the user earns coins in the game, the local value is updated. If the user buys more coins using IAP, you simply increment that same local value with the number of coins that they bought in response to the IAP server confirming a successful purchase.

(The actual IAP process is roughly similar on iOS and for Windows Store apps -- you issue a request up to the store server, it validates the payment and returns back to you some confirmation. You then act on that confirmation by incrementing your local value.)

When you install an app on Windows 8 and Windows RT, two things happen. The actual app is packaged as a zip file. (I've simplified this a bit, but it's good enough for this explanation.) This is exploded onto disk in a known location and a whole load of registry changes are made so that Windows knows where the app is and what it can do. (For example, whether it can share, search, etc.) As well as this, Windows will create a folder on disk where the app can store all of its local state. Windows Store apps are sandboxed so that each app can (in most cases) programmatically access this special folder only. If you want to persistently store the number of gold coins that the user has, you have to store it in this folder in some way.

However, on Windows 8 and Windows RT, the file system is wide open. Thus any user with administrative access (which is basically "every user") can just go into that folder and change it. What Justin found at its basic level is that, assuming you know the file format, you can go in and change the 10 gold coins you earned in the app to 10,000,000. Justin shows exactly how to do this for one commercially available game in his article.

(There are some subtleties with this, namely that you can encrypt the files, but Justin points out that you can readily get around his is the app is written in .NET using existing technology that offers decompilation and deep inspection of .NET assemblies. The moral here is that if you are a developer, you need to obfuscate your code.)

On iOS you can't hack an application's data files as readily because although iOS has a file system, you can't get to it unless you jailbreak the device. In theory you could do the same thing on iOS as you can on Windows, but Microsoft has made it stupidly easy through the inclusion of root access to the file system for everyone. In essence, Windows 8 and Windows RT devices come "pre-jailbroken".

Jailbreaking on iOS is a niche activity. Whereas on iOS you may find that 2% of your user base has a jailbroken device (I've guessed "2%", it's likely to be much less than that), effectively on Windows 100% of your user base is jailbroken.

The scenario I'm trying to sketch out here is one where, say you have a popular game, what you could do is allow the user to download a small app onto the Windows 8 device that finds the game's private data store, uploads the files to the server whereupon those files are then modified to your specifications, downloaded back again, and made to replace the originals on disk. You could in theory even charge for such a service -- a $10 charge to enable you access hundreds or thousands of dollars worth of IAP items is attractive, and obviously won't yield revenue for the original developer. I probably don't need to labor the point that throughout our industry's history, even people with well developed moral compass's find it easy enough to justify pirating content or -- in this case -- diddling a developer out a few dollars. People will do this if they can, and probably more people than you would think.

Incidentally, on Windows RT this process is slightly trickier as you wouldn't be able to download an agent to do this for you because of the restrictions imposed by the ARM port. What you'd have to do here is manually transfer the files off of the device and then upload them to the exploit server manually. You'd then replace the files on the device with whatever ones the server gave you. However it's important to note here that even if Windows RT takes off big time, there's isn't significantly better protection on Windows RT than Windows 8. On Windows RT it's harder to automate the exploits, but the exploits themselves are no more difficult.

Removing ads

Another way that developers can make money from their software is by putting ads on the screen. And on Windows, if you want, you can go and remove those ads from the app using nothing more sophisticated than Notepad. Justin shows how to do this in the third part of his article.

Describing this next part is tricky without going deep into the technology, but the easiest way to think about this is that, mostly, Windows Store apps are written in a way where you create separate files for each discrete view. For example, if you're building a news reader app, you might create a layout file that defines the main view as having a list of news articles on the left, and the actual detail of an news item that the user selects on the right. What a developer will do if they want to include ads is simply write into that layout where they want the ad to appear. The app starts, the layout is interpreted, and the ad is shown.

These layout files are included in the zip file that gets downloaded before installation, and are exploded onto disk as part of that installation. The problem here is that the layout files are text files and because we have full access to the file system, it's possible to open up these layout files in Notepad and just remove the ads post-installation. After you've done that, when the app starts the ad simply won't appear. Again, it's this problem with Windows devices being more-or-less jailbroken.

On iOS this isn't possible as generally apps define their layout as binary code that's compiled into the application as opposed to being text files on disk. Thus even if you have a jailbroken iOS device and can access the file system, you still can't remove the ads.

I'd suggest this one is less serious than the IAP circumvention vector that we discussed earlier, but it's still a good way of seeing your app revenue get sucked away.

Changing trial versions into full versions

This one is a bit more of a traditional crack, and less readily doable using File Explorer and Notepad.

Unlike iOS and the Apple App Store, the Windows Store supports trial apps. Windows maintains a single file that keeps track of whether an application is in "full" mode, or "trial" mode. By changing the contents of this file you can flip any app from trial mode and into full mode, without actually buying the app.

In his article, Justin talks about using a utility called WSService_crk to do this. I haven't included a link to this utility for various reasons, not least because it's hard to guarantee the safety of such things. However, what this utility does is display a list of apps, let you select one, and then let you reset the trial marker against any installed app. Next time you start the app, it will no longer be in trial mode.

It's hard to draw a comparison to iOS here as trial apps aren't available. It's likely that any such system on iOS would look roughly the same -- i.e. you'd have a central register of apps and a flag indicating whether they were in trial mode or not. Jailbroken devices would likely have the same vulnerability as Windows. But, again, the problem here is that Windows 8 and Windows RT come already "jailbroken" and so it's easy for a utility like WSService_crk to get at and manipulate the data needed to change the flag.

Conclusion

Let's talk about Raymond Chen. He's a Microsoft engineer, who happens to run a fascinating blog called The Old New Thing. Raymond's position at Microsoft is one where he's spend a good deal of his career dealing with the deep internals within Windows, and he often blogs about deliberate or accidental exploits of the OS.

The reason why I bring Raymond's blog up is that he often talks about "being on the other side of this airtight hatchway", by which he usually means "yes, you can do that, but you have to some sort of unusual privilege in order to it". Typically its in response to customer enquiries where they'll flag up some horrendous problem, but which happens to turn out to not be so horrendous because it relies on a certain astral alignment, or somesuch weird arrangement of circumstance.

We know that Microsoft's mobility strategy is (for better or worse) based on running after the market leaders trying to emulate where it makes sense, and doing a little better than basic emulation where they can. However, whereas Microsoft's competitors have rebooted the whole approach when it comes to devices, Microsoft's tablet strategy is to just keep adding more and more bits to Windows. Apple and Google are building "post-PC" devices. Microsoft has built a "PC Plus".

The problem is that by building a "PC Plus", Microsoft has grandfathered in stuff that people think they need, but that also puts everyone on the wrong side of the Raymond's "airtight hatchway" talks about. The file system and elevated privileges on Windows provides more utility compared to iOS, but on iOS you start off on the right side of the airtight hatchway, and only by jailbreaking can you end up on the wrong side. (And, of course, by using "right" and "wrong" in the way that I am here I'm making a judgement over which personal philosophy is the right one. What I'm really saying is that locking down a computing appliance so that it's more trustworthy and trustable is good for users and developers, but I'm making a distinction between an appliance and an Old World PC.)

As a developer, you have to ask yourself some serious questions about this state of affairs. What's emerged here thanks to Justin's work is that protection of developer revenues has not been considered by Microsoft in the platform as it stands today. It's a shame, as there are many things that Microsoft could have done to alleviate this.

For now, Windows developers have to deal with the double-whammy of not only being a niche platform, but also one where the platform owner isn't doing you any favours when it comes to revenue protection. And you can bet that it if Office was dependent on IAP or ad revenue this whole story would have been a lot better.

What do you think? Post a comment, or talk to me on Twitter: @mbrit.

Thanks to Paul Ardeleanu and Nic Wise for their help in writing this article.