Earlier in the week a blog post by Nokia engineer (and former Microsoft employee) Justin Angel highlighted a number of issues with applications from the Windows Store that enabled, among other things, the unauthorized conversion of trial apps into full versions, the modification of the prices of in-app purchases, and removal of embedded advertisements. Soon after publishing his post, Angel's blog was knocked offline in a flood of traffic; at the time of writing it remains unavailable, returning 503 error messages instead of content.
The integrity of Windows Store applications is an important issue. It forms part of the value proposition to developers, of the store itself; not only does the store provide easy, reliable billing, distribution, and updating, it also provides at least some degree of protection against piracy and other kinds of exploitation. If Windows 8 can't provide this then competing platforms (such as iOS) and competing delivery mechanisms (such as the Web) become more appealing.
Angel's examination of the store focused on games. Games are arguably the most popular category in app stores, and they provide some of the best demonstrations of the different business models that developers are using: ad-supported, free trials, and extensive use of in-app purchasing.
A new take on old problems
Some of the problems Angel highlighted were time-honored techniques used to subvert developers' design decisions. For example, the game Ultraviolet Dawn has an in-game currency. Players use this currency to buy various upgrades for their spaceships. The prices of the various upgrades are all stored in data files that form part of the game. These data files can be edited, making the upgrades cheaper, and hence making the in-game currency go a lot further than it normally would.
Modifying game data to make items cheaper isn't a new attack, and is far from unique to Windows 8. The widespread use of XML to store this kind of data might make Windows 8 apps a little easier to modify than software of old—no need to patch binaries in a hex editor when you can just use Notepad—but that's a minor detail.
A similar attack was used to remove the in-game ads from Microsoft's own Minesweeper. Most Windows Store apps have their interfaces written in XAML, Microsoft's XML language for user interfaces. These XAML files are stored as plain text as part of the application package and, like Ultraviolet Dawn's data files, they can be freely modified in Notepad. Editing Minesweeper's XAML allows the ad panel to be hidden from view. Removing it entirely might break the application, but hiding it is harmless and serves the purpose for the most part.
Again, the use of Windows 8 and the Windows Store is largely incidental. Patches to programs like Windows Messenger and ICQ that modify their user interfaces to hide or remove ads have been around for many years. As with the Ultraviolet Dawn modification, the use of XML may make this a little easier than it once was, but it's not fundamentally anything new or different.
It is, however, a little surprising that this can be done to Windows Store apps. To prevent side-loading, all applications in the Windows Store must be signed by Microsoft (or by an enterprise certificate for corporate applications that are distributed privately). Application binaries, the compiled executables and libraries that make up each program, can't be modified in this way, because any such modification would mean that their digital signatures were no longer valid.
What's surprising is that the same isn't true of these XML data files. Storing digital signatures for data files and verifying those signatures before each file is loaded would not be tremendously difficult. After all, Microsoft already does something comparable for HTML and JavaScript applications, after Angel highlighted similar flaws during Windows 8's beta period. For plain data, as used by Ultraviolet Dawn, the developer could in principle implement their own scheme to perform this integrity checking. But that's harder to do for XAML, as XAML is predominantly used by system libraries. A Microsoft-provided solution could cover both situations equally.
A slightly more complex example is found in Angel's examination of Soulcraft. Like Ultraviolet Dawn, Soulcraft has an in-game currency. In Soulcraft's case, that currency is purchased using real money. Soulcraft stores players' user profiles, which include the amount of currency they own, locally. The profiles are encrypted, which prevents casual modification, but the Soulcraft app itself contains everything it needs to decrypt, modify, and then re-encrypt the profiles—as indeed it must, to be able to modify the profiles.
Angel demonstrated that it was very easy to use Soulcraft's own application libraries to load and decrypt a profile, update the amount of currency, and then re-encrypt the profile. In this way, players can completely bypass the in-app purchasing system, giving themselves lots of gold but never having to shell out any real money for it.
As with the previous attacks, this is a new version of an old problem. Any user profile stored locally is at risk of modification. Encryption doesn't really help much as long as the game itself has the encryption keys and other information necessary to read the files, as indeed it must. Borderlands 2, for example, encrypted its savegames, in an attempt to prevent the kind of widespread modification that occurred in the original Borderlands. It didn't really help, and a fairly robust editor has been developed.
The wrinkle for Soulcraft is that these profiles modifications are depriving the developer of income. This is a problem that has been faced by developers before. The only robust solution is to not store profiles on end user machines. Profiles stored client-side are vulnerable to modification. Profiles stored server-side are not. If the profile contains something that's valuable, such as purchased currency, it should be stored server-side.
The difficulty with DRM
This is the standard DRM problem: DRM is designed to protect content that is stored and decrypted on client machines from the users of those machines. Necessarily the machines must contain all the information they need—encryption keys, algorithms—to perform that decryption. You can obfuscate this to make it harder—for example, Windows could offer its own encrypted storage with the encryption keys stored not by each application but by the operating itself—but such hurdles only give attackers a one-time cost. Once a way for extracting the keys has been devised (as it almost inevitably will be) then the DRM system can be attacked.
Server-side profiles solve the DRM conundrum by never putting the protected information on the client machine. The downside is that they create considerable complexity for developers—an entire server-side profile system must be implemented.
Angel demonstrated a similar undermining of in-app purchases with Cut The Rope. Cut The Rope in the Windows Store is a game built using HTML and JavaScript. It uses a fairly typical freemium model: the first few levels are free, the rest cost money. Angel showed that by attaching the Internet Explorer script debugger he could circumvent the purchase process and unlock the levels without having to pay. Cut The Rope made this particularly simple, as the code within it included a test/debug mode that allowed its developers to test the level unlocking logic without having to make a payment. Angel could use the debugger to enable this test mode and the game itself did the rest of the work for him.
Even without the debug mode, the fundamental problem Cut The Rope has is that the base game includes all the levels. The attacker's job is simply to trick the game into giving access to those levels. A more robust implementation would download the levels only on receipt of payment—with the payment validation performed server-side, of course. Another route would be to abandon in-app purchases entirely, and simply have two versions of the game; a no-cost Cut The Rope Free with a limited selection of levels, and a paid Cut The Rope with all the levels.
The final attack Angel demonstrated was in some ways the most serious, since it's the only attack that attacked not individual applications but the operating system itself. Windows 8 includes a license file that contains information about all the programs that you're entitled to use, and whether they're trial versions or full apps. The operating system maintains and strives to protect this file. However, a crack has been devised that allows trial versions to be converted into full versions. It also allows paid-only apps to be redistributed and used for free, as long as at least one person pays for the app in the first place.
The crack works by compromising the integrity of the Windows system services that maintain this license file. The guidelines for using the crack recommend that you leave it running all the time, to prevent Windows' own periodic re-validation of the license, so it's not a simple fire-and-forget thing. It also prevents the download and installation of app updates, as the Windows Store only provides updates to owners of legitimate licenses. Nor does it side-step server-enforced restrictions, such as the inability to re-download apps once their trials have expired (though there are ways around this).
What's Microsoft to do?
Pirating software is an age old problem. So too is patching programs and data to subvert the intentions of the developer. Even the crack for the Windows store licensing system is unexceptional in the world of software piracy. These things happen; they're practically an inevitability.
There are some small things that Microsoft could, and probably should, be doing. Blocking modification of XAML and application data files would be easy to do, and would help preserve the integrity of in-app advertising (which, like it or not, is a necessary feature for many zero-cost programs and services). There might also be value in giving developers easy-to-use, system-managed encrypted storage to keep user data in a manner that precludes trivial tampering.
Application developers, too, can take more care. The developers of Cut The Rope made subverting the payment system particularly simple by virtue of shipping testing code to end-users. Soulcraft should store user profiles and their purchases on a server somewhere, away from prying eyes.
Nonetheless, there is an underlying challenge for developers and Microsoft alike. The attacks Angel described are traditional attacks on the PC because the PC lets you run whatever software you like. PC software has always had to tolerate running in a hostile environment; an environment rife with debuggers, hex editors, disassemblers, and virtualization, the tools that allow the reverse engineering, modification, and cracking of that software.
Such attacks are much less typical of mobile platforms, particularly iOS, because those applications and tools can't easily run on iOS devices. By default, all iOS programs are sandboxed and isolated from one another, preventing the kind of inspection and analysis that Angel demonstrated for the Windows 8 programs.
But that's not always the case: on jailbroken iOS devices, those of a suitable bent can indeed run debuggers and other software—and this is exactly what they do in order to enable piracy of iOS apps. iOS applications are encrypted and have to have a legitimate digital signature, but jailbreaks remove the digital signature checking almost entirely, and decrypted applications can be generated by letting the operating system decrypt a legitimately purchased application, and then using a debugger to copy the decrypted app from memory.
Rooted Android devices are susceptible to similar attacks.
Microsoft, Apple, and Google all have systems whereby applications can verify their own licensing status, which defeats basic attempts to pirate, but once a cracker has a copy of the app to examine, they can easily remove these checks, so the value of such protection is limited.
Windows 8's PC nature may increase applications' exposure to these attacks to some extent. That's something that application developers should be aware of. Some might not like the exposure and could decide to abandon Windows, but ultimately application security and integrity are the responsibility of app developers, not operating system developers, and that's the case on every mobile platform around.
reader comments
101