This is Google's cache of http://justinangel.net/HackingWindows8Games. It is a snapshot of the page as it appeared on 11 Dec 2012 03:17:37 GMT.

The current page could have changed in the meantime. Learn more Tip: To quickly find your search term on this page, press Ctrl+F or -F (Mac) and use the find bar. Text-only version

Hacking Windows 8 Games

JustinAngel
HI folks, This article is a follow-up to my previous 2011 article on Reverse Engineering and Modifying Windows 8 apps. In this article well see how to use innate Windows 8 security attack vectors in such a way that could compromise Windows 8 games revenue stream. Well review real-world examples for all Win8 programming languages and frameworks.

But first, why Games?

In the previous article weve seen security loopholes affecting all Windows 8 apps. However in this article well focus on how to use these techniques to compromise games security. The reason well be focusing on games is that they account for 51%+ of developer revenue on

every mobile developer platform. Let me repeat that, games account for the majority of developer revenue. For example we can see from official Microsoft statistics that 64% of app purchases on Windows Phone 7 are for games.

The majority of mobile apps make their money from a combination of in-app ads, in-app purchases or paid app downloads. Google IO 2012 had this great slide illustrating all the ways a mobile app developer can get paid:

In this article well show how insecure each of those payment streams are on Windows 8 with real-world examples from game development. Its important to mention the methods shown in this article can be applied to every app and not just games.

#1: Compromising in-app purchases by modifying IsoStore

The Win8 game Soulcraft is a top game on Android and is subjectively one of best examples of its genre on Windows 8. Its a basic RPG where you play an archangel battling the forces of evil in stylish 3D. Youve got a character, its got equipment and you pay with gold with gold to buy better equipment. The gold has to be purchased for real money using the platforms in-app

purchase. For example on Android here are the prices for gold:

Ive spent 20$+ on game gold for Soulcraft THD on my Google Nexus 7 so far. So I asked myself how does that games gold data gets stored on Windows 8, and whether or not we can change it. Quick refresher from the previous article all Windows 8 apps are stored on your local HD at: C:\Program Files\WindowsApps So for example all the assemblies for Soulcraft on Windows 8 will be stored at: C:\Program Files\WindowsApps\MobileBitsGmbH.SoulCraft_0.8. 5.3_neutral__n3knxnwpdbgdc

Also, all IsoStore files are stored at: C:\Users\<username>\AppData\Local\Packages\ So on my machine Soulcrafts IsoStore is at: C:\Users\Justin\AppData\Local\Packages\MobileBits GmbH.SoulCraft_n3knxnwpdbgdc\LocalState

When opening up these files in Notepad we can see some of these files are encrypted while others are not.

So now the question becomes, can we decrypt the AccountData.xml file, edit the amount of gold our character has and simply run the game? Well, as it turns out the answer is Yes. Normally encrypted files are bad news if youre trying to tamper with apps. But we should remember this is all running on the local machine. We have the algorithm used for encryption, we have the hash key and we have the encrypted data. Once we have all of those its pretty simple to decrypt anything.

Using dotPeek/ILSpy/JustDecompile its possible to reverse engineer most of the Soulcraft source code and find out how the AccountData.xml gets stored and how to change it. Lets assume weve done that and we know which classes and assemblies are used to decrypt, edit and encrypt this XML file. Well start off by create a new Win8 app and reference the appropriate DLLs from the Soulcraft game.

Next, since these assemblies read files from IsoStore well copy the encrypted game files to our own App2 IsoStore.

Now weve staged a new app with the proper assemblies and populated IsoStore with Soulcrafts Data. The next step is to reverse engineer the assemblies and figure out the correct calling order for methods. For example this code would load up AccountData.xml, edit the amount of gold and save it again. Heres the before and after of the XML file:

Copying the file back to Soulcrafts IsoStore and starting Soulcraft we can see a first level character with 1,000,000 gold.

At this point some of you must be thinking so what? its fake game money. True, but this fake in-game money would be worth over a thousand dollar on Android and iOS. Without a secure storage location for game state, we cant be surprised that 3rd party cracking will arise to make consumers avoid in-app purchases.

#2: Cracking trial apps to paid versions for free

One of the top revenue streams for Windows 8 developers is by shipping paid apps. At the same time consumers tend to be loss averse and are afraid to lose money on apps. The solution to that are Trial apps. Paid apps can offer a free version with limited functionality or on a time limited basis. That works fine unless consumers attempt to manipulate this tentative status-quo by cracking trial apps. To emphasize the impact of this problem we can look at the Windows Phone ecosystem where 45% of paid apps offer trials.

Lets have a look at Meteor Madness. Its a cool arcade asteroid shooter game. Meteor madness costs 1.5$USD and offers a free trial with limited functionality. It also happens to be open source so you can go check that out too.

When downloading the app as a trial we can see that it offers the options to buy the game and locks some game options. Note the Buy now rock at the bottom left and the locked Arcade game rock on the top right.

In the previous section weve seen theres a fundamental problem when storing game data on Windows 8. Storing encrypted data locally, alongside with the algorithm and the algorithm key/hash is a recipe for security incidents. One of the problems with allowing offline execution of trial apps is that it mandates the trial flag to be stored locally. And as weve seen, if its stored locally, we can find it, read it and modify it. Specifically the License for Windows 8 apps is stored in the following file: C:\Windows\ServiceProfiles\LocalService\AppData\L ocal\Microsoft\WSLicense\tokens.dat When we open this file up in Notepad we can find the license for Meteor Madness and where it says its a trial purchase.

Also, in the same file we can see there are other apps installed. Such as free apps, paid apps and preinstalled apps. Here for example if the Full installation of Bing.

An educational WinForms app named WSService_crk loads this file into memory, shows the License XMLs and modifies it as a Full Preinstalled license. Theres a lot

going on here other then simply reading and modifying files. WSService_crk has to decrypt the file, re-encrypt it and then store it. All of that is documented with WSService_crk as its distributed with full source code.

When opening up WSService_crk on my machine shows the following list of installs apps.

WSService_crk can then show the current license and even modify it from a Trial to a Full Preinstalled License.

When running Meteor Madness now we can see that it no longer has any trial app functionality limitations.

#3: Removing in-app ads from games by editing XAML files

Another way developers monetize their apps is through in-app advertising. Developers often take the path of least resistance and its quite easy to add ads to your app. If apps are popular and the viewcounts are racking

up it could become quite profitable. As a result consumers dont have to pay for some great titles and successful developers can get paid. That all works pretty well unless opportunistic consumers choose to keep the free app but disable ads. To emphasize the importance of mobile app ads lets mention that some 3rd party estimates put the field at over 10B in overall yearly revenue.

One app that is now (surprisingly) advertising supported on Windows 8 is Microsofts Minesweeper.

As weve seen previously the executable of all Windows 8 apps can be located easily. Minesweeper is installed locally at: C:\Program Files\WindowsApps\Microsoft.MicrosoftMinesweepe r_1.1.0.0_x86__8wekyb3d8bbwe In that folder we can find the file MainPageAd.xaml under the \Common\AdsModule\View folder. Alongside with other in-app ads used by Minesweeper.

We can make this ad disappear by simply adding the Visibility=Collapsed property to the aforementioned root user control.

After weve made this small change, when we run the Minesweeper app we wont be able to see the ad anymore.

By simply editing XAML files we can hide away in-apps ads from Windows 8 ads.

#4: Reducing the cost of in-game items by editing game data files
Most games out there are composed of two distinctive pieces: a game engine and game data files used by the engine. For more on this dichotomy you can read this great article Battle for Wesnoth from the creative commons book The Architecture of Open Source Applications. Lets look at a real world example in the form of the windows 8 game Ultraviolet Dawn. The game is my all time favourite iPad game and is a cool 2D space shooter. Like other games players start-off with a certain amount of in-game currency and can buy items to

improve their spaceship.

If we go back to the dichotomy weve heard about earlier then we can see how it applies to Ultraviolet Dawn. Theres a game engine that knows about store items and theres going to be a list somewhere of what they are. So one thing we could do is take advantage of Windows 8 on-disk storage and modify the games data files. As weve previously seen executables for windows 8 apps can be located and modified. Specifically, Ultraviolets Dawn can be found here: C:\Program Files\WindowsApps\8DF9EE77.UltravioletDawn_1.0. 0.37_x86__dd4ev9dvfndxm We can open up the res_store_items.txt file and edit the price of in-game items. In our example well edit all the weapons to be free.

When we run Ultraviolet Dawn again we can see the price of items in the store is now 0.

Weve just shown that using the simplest tools we can

edit game files to compromise the experience of Windows 8 games.

#5: Compromising In-app purchase items by injecting scripts into the IE10 process
Even though weve already shown that in-app purchases are comprisable Id like for us to see an example of that with Windows 8 HTML & JS apps. Up until now weve seen examples of C# and C++ apps, so lets see that with WinJS apps. Lets have a look at the massively popular and successful WInJS Windows 8 game Cut the Rope. The game follows a freemium model where the first few levels are free and additional levels cost 4.99$ to unlock.

As we know by now executables for Windows 8 games can be found on the local disk. Specifically Cut the Rope executeables can be found at: C:\Program Files\WindowsApps\ZeptoLabUKLimited.CutTheRop e_1.1.0.9_neutral__sq9zxnwrk84pj If we open up the default.js file in the js folder we can see the following code that obviously governs the in-app purchasing logic. We can see there are IS_PAID_FULL_VERSION and SIMULATE_PURCHASES

variables set to false. One wonder what happens if we change those values to true.

We dont really have to understand the specifics but we can see theres an if-else condition that determines inapp purchases. We cant directly change Javascript files as thatll corrupt the Javascript package and Windows 8 will refuse to open the app. So instead of changing the files on the local disk, we can inject JS scripts at runtime into IE10 process.

Visual Studio 2012 has a built-in debugging mechanism for any installed Windows 8 app. Even if that wasnt there we could still easily inject scripts to IE10, but since it is there we can use that familiar tool. Lets use VS2012 to Debug Installed App Package. (Here are the Jacascript docs, C# docs and C++ docs to those unfamiliar with the feature)

Next well choose to Debug Cut The Rope. Make sure to check the Stop at first Statement checkbox since well use it to navigate to default.js.

After we click start we can see were debugging the Cut the Rope app. This is the important bit, weve now got the full force of VS2012 Javascript runtime debugging in a Win8 store app. This first breakpoint will always be the same file at the same row: the first row of the base.js file from the WinJS framework.

Using a smart combination of Step over and using the Solution Explorer we can set the following breakpoint after setting the variables weve previously seen.

Stepping over this deceleration we can then see the following values in our Locals window.

And now using the Immediate Window we can execute any javascript wed like. For the purpose of this demo well set SIMULATE_PURCHASES=true. We could have saved some time by setting IS_PAID_FULL_VERSION=true, but Id like for us to see this runtime behaviour.

Now when we click the purchase button we can see Windows 8 in-app purchase simulator. Well tell it that the purchase was successful.

And now we can see all game levels are unlocked.

Weve just shown how to inject arbitrary javascript into a Win8 store bought WinJS IE10 app and weve affected inapp purchase items inventory.

Summary: What have we seen?

We were able to show that the majority of ways games and apps developers would make money arent secure by default on Windows 8. Weve shown this for C# & XAML apps (Minesweeper), weve shown this for C# + Direct3D apps (Soulcraft), weve shown this for C++ & Direct3D apps (Ultraviolet Dawn), weve shown this for HTML & WinJS apps (Cut the Rope) and weve shown this for any app using Trial (Meteor Madness).

Lets repeat what weve seen so far, what the root cause of the issue is and what could be done at the framework level to mitigate this issue: In-app purchase items Storage: In-app purchase is fast becoming the #1 revenue stream for game developers. Weve seen we can trick games local storage to acknowledge consumable items that havent been purchased. The real problem here is that Windows 8 apps dont have any truly secure location thats inaccessible to the user and can be secured in offline scenarios. One possible improvement here would be for Microsoft to offer such storage for all apps. Let developers have a secure encrypted isolated storage by default. Also, another possibility would be to turn on code obfuscation and minification by default in order to avoid the reverse engineering needed for this exploit. Trial apps: Trial apps will likely be adopted by around 50% of Windows 8 games. Weve seen how the Trial licenses are stored in the Tokens.dat file and how easy it is to edit it. The real problem here is that Trial apps are downloaded to the client machine with the full unlocked logic embedded in them. One way to fix this issue would be to have developers build two app packages (one limited functionality trial package and one full functionality package) and have those secured by the Win8 store purchasing system. In-apps ads: Mobile advertising in apps is a major industry and a source of revenue for developers. Weve shown how by simply editing the XAML files on disk we can turn off ads in games. It shouldnt be possible to tamper with XAML/HTML files and then

have them loaded to memory. One improvement Microsoft can undertake here is have better on-disk tampering checks. Game data files and in-game items: Weve shown game data files can be edited and theyll then be loaded into apps. It shouldnt be possible to modify any game file and then have it loaded to memory. Microsoft could follow tothe aforementioned recommendation from item #3 to help mitigate this issue. Injecting arbitrary Javascript affecting in-app purchase: Weve seen we can inject any javascript code to run inside the IE10 process for a Win8 WinJS store app. That shouldnt be possible. One possible improvement would be for the IE10 team to lock down the IE10 process for signed scripts only when not on a development machine. Weve seen a myriad of issues and offered potential fixes to them all. Any mildly competent developer can productize these security attack vectors into shipping products. If Microsoft doesnt take it upon itself to fix these security attack vectors its not because it couldnt, its because it chooses not to.

What havent we been able to do?

What has been fixed since early Win8 betas is editing DLLs or HTML/JS files on the disk is no longer possible. When thats attempted the code integrity system kicks-in verifies file hashes and prevents app execution. One is left to wonder about how secure those AppxBlockMap.xml hashes really are and if they can be reversed engineer to

be generated on the client side.

Heartfelt disclaimers
Games: The games appearing in this article are awesome and you should buy them and give them money. Ive been a generous benefactor of each game and so should you! go download them and give them money. In order of appearance in article: Soulcraft, Meteor Madness, Minesweeper, Ultraviolet Dawn and Cut The Rope. Game developers: The game developers for the aforementioned games are professionals. For the most part you cant work around a broken platform. Theres nothing obvious about any of these issues. Article format: This is an educational article written in the hope both developers and Microsoft can benefit from an open exchange of knowledge. My employer: I have an employer and they had nothing to do with this article. Both research and authoring this article was undertaken at my leisure time.

Feedback
Questions? Rebuttals? Thoughtful discussion? Sound off in the comments below. Remember to read the previous article Reverse Engineering and Modifying Windows 8 apps if anything is unclear as it outlines many of the techniques used here.

-- Justin Angel Published on 12/10/2012 12:00:00 AM by Justin Angel 2012. This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Comments
Search:
http://justinangel.net/Feed