ut first, why Games?

In the previous article we’ve seen security loopholes affecting all Windows 8 apps. However in this article we’ll focus on how to use these techniques to compromise games security. The reason we’ll be focusing on games is that they account for 51%+ of developer revenue on every mobile devel-oper platform. Let me repeat that, games account for the majority of developer revenue. For exam-ple 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 we’ll show how insecure each of those payment streams are on Windows 8 with real-world examples from game development. It’s important to mention the methods shown in this arti-cle 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. It’s a basic RPG where you play an archangel battling the forces of evil in stylish 3D. You’ve 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 platform’s in-app purchase. For example on Android here are the prices for gold:

I’ve spent 20$+ on game gold for Soulcraft THD on my Google Nexus 7 so far. So I asked myself how does that game’s 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__n3knxnw-pdbgdc

 

Also, all IsoStore files are stored at:

C:\Users\<username>\AppData\Local\Packages\

So on my machine Soulcraft’s IsoStore is at:

C:\Users\Justin\AppData\Local\Packages\MobileBitsGmbH.SoulCraft_n3knxnwpdbgdc\Lo-calState

 

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 en-crypted files are bad news if you’re 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 it’s pretty simple to decrypt anything.

 

Using dotPeek/ILSpy/JustDecompile it’s possible to reverse engineer most of the Soulcraft source code and find out how the AccountData.xml gets stored and how to change it. Let’s assume we’ve done that and we know which classes and assemblies are used to decrypt, edit and encrypt this XML file. We’ll 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 we’ll copy the encrypted game files to our own App2 IsoStore.

 

Now we’ve staged a new app with the proper assemblies and populated IsoStore with Soulcraft’s 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.

using Delta.Utilities.Helpers; using Delta.Utilities.Xml;

public sealed partial class MainPage : Page { public MainPage() {

this.InitializeComponent(); this.Loaded += MainPage_Loaded; }

private async void MainPage_Loaded(object sender, RoutedE-ventArgs e) { var filePath = Path.Combine(DirectoryHelper.GetBaseDi-rectory(), "AccountData.xml"); var accountDataXml = XmlNode.LoadFile(filePath); accountDataXml.Children.First().AddAttribute("Gold", "1000000"); accountDataXml.Save(filePath); } }Here’s the before and after of the XML file:

 

Copying the file back to Soulcraft’s 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? it’s 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 can’t 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 ba-sis. 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.

 

Let’s have a look at Meteor Madness. It’s 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 we’ve seen there’s a fundamental problem when storing game data on Win-dows 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 we’ve seen, if it’s 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\Local\Microsoft\WSLicense\tokens.dat 

When we open this file up in Notepad we can find the license for Meteor Madness and where it says it’s 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 Li-cense XMLs and modifies it as a “Full Preinstalled” license. There’s 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 it’s 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 Prein-stalled License.

 

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

 

#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 it’s 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 don’t have to pay for some great titles and successful developers can get paid. That all works pretty well unless op-portunistic consumers choose to keep the free app but disable ads. To emphasize the importance of mobile app ads let’s 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 Microsoft’s Minesweeper.

 

As we’ve seen previously the executable of all Windows 8 apps can be located easily. Minesweeper is installed locally at:

C:\Program Files\WindowsApps\Microsoft.MicrosoftMinesweeper_1.1.0.0_x86__8weky-b3d8bbwe

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 afore-mentioned root user control.

 

After we’ve made this small change, when we run the Minesweeper app we won’t 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.  Let’s 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 cer-tain amount of in-game currency and can buy items to improve their spaceship.

 

If we go back to the dichotomy we’ve heard about earlier then we can see how it applies to Ultravi-olet Dawn. There’s a game engine that knows about “store items” and there’s 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 game’s data files. As we’ve previously seen executables for windows 8 apps can be located and modified. Specifically, Ultraviolet’s 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 we’ll 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.

 

We’ve 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 we’ve already shown that in-app purchases are comprisable I’d like for us to see an example of that with Windows 8 HTML & JS apps. Up until now we’ve seen examples of C# and C++ apps, so let’s see that with WinJS apps. Let’s have a look at the massively popular and suc-cessful 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.CutTheRope_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 gov-erns the in-app purchasing logic. We can see there are IS_PAID_FULL_VERSION and SIMU-LATE_PURCHASES variables set to false.  One wonder what happens if we change those values to true.

 

We don’t really have to understand the specifics but we can see there’s an if-else condition that de-termines in-app purchases. We can’t directly change Javascript files as that’ll 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 wasn’t there we could still easily inject scripts to IE10, but since it is there we can use that fa-miliar tool. Let’s use VS2012 to “Debug Installed App Package”. (Here are the Jacascript docs, C# docs and C++ docs to those unfamiliar with the feature)

 

Next we’ll choose to Debug Cut The Rope. Make sure to check the “Stop at first Statement” check-box since we’ll use it to navigate to default.js.

 

After we click start we can see we’re debugging the Cut the Rope app. This is the important bit, we’ve 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 we’ve 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 we’d like. For the purpose of this demo we’ll set SIMULATE_PURCHASES=true. We could have saved some time by setting IS_PAID_FULL_VERSION=true, but I’d like for us to see this runtime behaviour.

 

 

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

 

And now we can see all game levels are unlocked.

 

We’ve just shown how to inject arbitrary javascript into a Win8 store bought WinJS IE10 app and we’ve affected in-app 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 aren’t secure by default on Windows 8. We’ve shown this for C# & XAML apps (Minesweeper), we’ve shown this for C# + Direct3D apps (Soulcraft), we’ve shown this for C++ & Direct3D apps (Ultraviolet Dawn), we’ve shown this for HTML & WinJS apps (Cut the Rope) and we’ve shown this for any app using Trial (Meteor Madness).

Let’s repeat what we’ve seen so far, what the root cause of the issue is and what could be done at the framework level to mitigate this issue: 

1. In-app purchase items Storage: In-app purchase is fast becoming the #1 revenue stream for game developers. We’ve seen we can trick games local storage to acknowledge consumable items that haven’t been purchased. The real problem here is that Windows 8 apps don’t have any truly secure location that’s inaccessible to the user and can be secured in offline scenar-ios. 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 pos-sibility would be to turn on code obfuscation and minification by default in order to avoid the reverse engineering needed for this exploit.

2. Trial apps: Trial apps will likely be adopted by around 50% of Windows 8 games. We’ve 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 un-locked 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 pack-age) and have those secured by the Win8 store purchasing system.

3. In-apps ads: Mobile advertising in apps is a major industry and a source of revenue for devel-opers. We’ve shown how by simply editing the XAML files on disk we can turn off ads in games. It shouldn’t 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. 

4. Game data files and in-game items: We’ve shown game data files can be edited and they’ll then be loaded into apps. It shouldn’t 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.

5. Injecting arbitrary Javascript affecting in-app purchase: We’ve seen we can inject any javascript code to run inside the IE10 process for a Win8 WinJS store app. That shouldn’t 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. 

We’ve seen a myriad of issues and offered potential fixes to them all. Any mildly competent devel-oper can productize these security attack vectors into shipping products. If Microsoft doesn’t take it upon itself to fix these security attack vectors it’s not because it couldn’t, it’s because it chooses not to.

 

What haven’t 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 that’s 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

1. Games: The games appearing in this article are awesome and you should buy them and give them money. I’ve 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.

2. Game developers: The game developers for the aforementioned games are professionals. For the most part you can’t work around a broken platform. There’s nothing “obvious” about any of these issues.

3. Article format: This is an educational article written in the hope both developers and Microsoft can benefit from an open exchange of knowledge. 

4. 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:

ut first, why Games?In the previous article we’ve seen security loopholes affecting all Windows 8 apps. However in this article we’ll focus on how to use these techniques to compromise games security. The reason we’ll be focusing on games is that they account for 51%+ of developer revenue on every mobile devel-oper platform. Let me repeat that, games account for the majority of developer revenue. For exam-ple 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 we’ll show how insecure each of those payment streams are on Windows 8 with real-world examples from game development. It’s important to mention the methods shown in this arti-cle can be applied to every app and not just games. #1: Compromising in-app purchases by modifying IsoStoreThe Win8 game Soulcraft is a top game on Android and is subjectively one of best examples of its genre on Windows 8. It’s a basic RPG where you play an archangel battling the forces of evil in stylish 3D. You’ve 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 platform’s in-app purchase. For example on Android here are the prices for gold:

I’ve spent 20$+ on game gold for Soulcraft THD on my Google Nexus 7 so far. So I asked myself how does that game’s 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 Soulcraft’s IsoStore is at:C:\Users\Justin\AppData\Local\Packages\MobileBitsGmbH.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 en-crypted files are bad news if you’re 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 it’s pretty simple to decrypt anything.

 Using dotPeek/ILSpy/JustDecompile it’s possible to reverse engineer most of the Soulcraft source code and find out how the AccountData.xml gets stored and how to change it. Let’s assume we’ve done that and we know which classes and assemblies are used to decrypt, edit and encrypt this XML file. We’ll 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 we’ll copy the encrypted game files to our own App2 IsoStore.

 Now we’ve staged a new app with the proper assemblies and populated IsoStore with Soulcraft’s 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. using Delta.Utilities.Helpers; using Delta.Utilities.Xml;

public sealed partial class MainPage : Page { public MainPage() { this.InitializeComponent(); this.Loaded += MainPage_Loaded; }

private async void MainPage_Loaded(object sender, RoutedEventArgs e) { var filePath = Path.Combine(DirectoryHelper.GetBaseDirectory(), "AccountData.xml"); var accountDataXml = XmlNode.LoadFile(filePath); accountDataXml.Children.First().AddAttribute("Gold", "1000000");

accountDataXml.Save(filePath); } }Here’s the before and after of the XML file:

 Copying the file back to Soulcraft’s 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? it’s 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 can’t be surprised that 3rd party cracking will arise to make consumers avoid in-app purchases. #2: Cracking trial apps to paid versions for freeOne 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 ba-sis. 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.

 Let’s have a look at Meteor Madness. It’s 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 we’ve seen there’s a fundamental problem when storing game data on Win-dows 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 we’ve seen, if it’s 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\Local\Microsoft\WSLicense\tokens.dat When we open this file up in Notepad we can find the license for Meteor Madness and where it says it’s 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 Li-cense XMLs and modifies it as a “Full Preinstalled” license. There’s 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 it’s 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 Prein-stalled License.

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

 #3: Removing in-app ads from games by editing XAML filesAnother way developers monetize their apps is through in-app advertising. Developers often take the path of least resistance and it’s 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 don’t have to pay for some great titles and successful developers can get paid. That all works pretty well unless op-portunistic consumers choose to keep the free app but disable ads. To emphasize the importance of mobile app ads let’s 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 Microsoft’s Minesweeper.

 As we’ve seen previously the executable of all Windows 8 apps can be located easily. Minesweeper is installed locally at:C:\Program Files\WindowsApps\Microsoft.MicrosoftMinesweeper_1.1.0.0_x86__8wekyb3d8bbweIn 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 afore-mentioned root user control.

 After we’ve made this small change, when we run the Minesweeper app we won’t 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 filesMost 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.  Let’s 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 cer-tain amount of in-game currency and can buy items to improve their spaceship.

 If we go back to the dichotomy we’ve heard about earlier then we can see how it applies to Ultravi-olet Dawn. There’s a game engine that knows about “store items” and there’s 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 game’s data files. As we’ve previously seen executables for windows 8 apps can be located and modified. Specifically, Ultraviolet’s Dawn can be found here:C:\Program Files\WindowsApps\8DF9EE77.UltravioletDawn_1.0.0.37_x86__dd4ev9dvfndxmWe can open up the “res_store_items.txt” file and edit the price of in-game items. In our example we’ll 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.

 We’ve 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 processEven though we’ve already shown that in-app purchases are comprisable I’d like for us to see an example of that with Windows 8 HTML & JS apps. Up until now we’ve seen examples of C# and C++ apps, so let’s see that with WinJS apps. Let’s have a look at the massively popular and suc-cessful 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.CutTheRope_1.1.0.9_neutral__sq9zxn-wrk84pjIf we open up the default.js file in the js folder we can see the following code that obviously gov-erns the in-app purchasing logic. We can see there are IS_PAID_FULL_VERSION and SIMU-LATE_PURCHASES variables set to false.  One wonder what happens if we change those values to true.

 We don’t really have to understand the specifics but we can see there’s an if-else condition that de-termines in-app purchases. We can’t directly change Javascript files as that’ll 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 wasn’t there we could still easily inject scripts to IE10, but since it is there we can use that fa-miliar tool. Let’s use VS2012 to “Debug Installed App Package”. (Here are the Jacascript docs, C# docs and C++ docs to those unfamiliar with the feature)

 Next we’ll choose to Debug Cut The Rope. Make sure to check the “Stop at first Statement” check-box since we’ll use it to navigate to default.js.

 

After we click start we can see we’re debugging the Cut the Rope app. This is the important bit, we’ve 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 we’ve 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 we’d like. For the purpose of this demo we’ll set SIMULATE_PURCHASES=true. We could have saved some time by setting IS_PAID_FULL_VERSION=true, but I’d like for us to see this runtime behaviour.  Now when we click the purchase button we can see Windows 8 in-app purchase simulator. We’ll tell it that the purchase was successful.

 And now we can see all game levels are unlocked.

 We’ve just shown how to inject arbitrary javascript into a Win8 store bought WinJS IE10 app and we’ve affected in-app 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 aren’t secure by default on Windows 8. We’ve shown this for C# & XAML apps (Minesweeper), we’ve shown this for C# + Direct3D apps (Soulcraft), we’ve shown this for C++ & Direct3D apps (Ultraviolet Dawn), we’ve shown this for HTML & WinJS apps (Cut the Rope) and we’ve shown this for any app using Trial (Meteor Madness).Let’s repeat what we’ve 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. We’ve seen we can trick games local storage to acknowledge consumable items that haven’t been purchased. The real problem here is that Windows 8 apps don’t have any truly secure location that’s inaccessible to the user and can be secured in offline scenarios. One possible im-provement here would be for Microsoft to offer such storage for all apps. Let developers have a se-cure encrypted isolated storage by default. Also, another possibility would be to turn on code obfus-cation 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. We’ve 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. We’ve shown how by simply editing the XAML files on disk we can turn off ads in games. It shouldn’t 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: We’ve shown game data files can be edited and they’ll then be loaded into apps. It shouldn’t be possible to modify any game file and then have it loaded to mem-ory. Microsoft could follow tothe aforementioned recommendation from item #3 to help mitigate this issue.Injecting arbitrary Javascript affecting in-app purchase: We’ve seen we can inject any javascript code to run inside the IE10 process for a Win8 WinJS store app. That shouldn’t 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. We’ve seen a myriad of issues and offered potential fixes to them all. Any mildly competent devel-oper can productize these security attack vectors into shipping products. If Microsoft doesn’t take it upon itself to fix these security attack vectors it’s not because it couldn’t, it’s because it chooses not to. What haven’t 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 that’s 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. I’ve 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, Ul-traviolet Dawn and Cut The Rope.Game developers: The game developers for the aforementioned games are professionals. For the most part you can’t work around a broken platform. There’s 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. FeedbackQuestions? 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 AngelPublished 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

http://justinangel.net/Feed