விண்டோஸ் 8 விளையாட்டுக்களை திருடுவது எப்படி? நோக்கியா பொறியாளர் கசிய விட்ட வழிமுறைகள்:

Justin Angel எனும் நோக்கியாவில் பணியாற்றும் பொறியாளர் விண்டோஸ் 8
இயக்குதலத்தில் உள்ள பணம் கட்டி விளையாடும் விளையாட்டுக்களில் பணம்
செலுத்தாமல் பல வசதிகளை அனுபவிக்கும் குறுக்கு வழிகள் பற்றிய குறிப்புகளை தனது தளத்தில் வெளியிட்டார். அவர் வெளியிட்ட சில மணி நேரங்களில் அவரின் தளம் வேலை செய்யவில்லை. ஆனால் அவரின் பக்கத்தை Google Cache மூலம் பார்த்து தகவல்களை
தெரிந்துகொள்ள நாம் முற்பட்ட போது Googleலும் அந்தப் பக்கத்தை
நீக்கிவிட்டது. இந்த விசயத்தில் Google Microsoftக்கு உதவும் வகையில்
செயல்பட்டுள்ளது.

ஆனால், Windows 8 apps reverse engineering செய்யும் வழிமுறைகள் இன்னும்
காணக் கிடைக்கப்படுகின்றன. Reverse Engineering என்பது ஒரு மென்பொருளை
சிறு சிறு துண்டுகளாக உடைத்து அதன் மூல நிரலை (Source Code) அறிய முற்படும்
ஒரு வழிமுறை.

மைக்ரோசோப்ட் நிறுவனமும் நோக்கியா நிறுவனமும் கடந்த சில ஆண்டுகளாக
கைகோர்த்து பல வன் / மென்பொருள்களை விற்று வருகின்றன. நோக்கியா நிறுவனம்
அடைந்த கடும் நட்டம் காரணமாக பல பொரியாளர்களை வேலையில் இருந்து
நீக்கியுள்ளது. இவரும் வேலையில் இருந்து போய்விட்டாரா அல்லது விரக்தியால்
இந்த வழிமுறைகளை வெளியே தெரிய வைத்துள்ளாரா என சில தினங்களில் தெரிய வரும்.
நன்றி :techtamil

Reverse Engineering and Modifying Windows 8 apps



Justin
Angel





Hi folks,
In this article I’ll share the results of
ad-hoc security vulnerabilities research I’ve done on windows 8 apps
deployment. Specifically, we’ll discuss fundamental design flaws that
allow to Reverse Engineer Win8 apps, modification of installed apps and
the negative implications on Intellectual Property rights protection,
Licensing models and overall PC security. Finally we’ll discuss some
creative ideas on how to mitigate these security issues.

Meet the mother-load: C:\Program Files\Applications

All Windows 8 applications in the developer preview are installed under the clandestine C:\Program Files\Applications
location. I will hazard a guess and say that once the Windows App Store
goes online it will install all apps under that folder. Currently the
folder is an invisible one and cannot be accessed from Windows Explorer
user interface on a new Win8 developer preview install.

Here’s an example of some of the 29 apps Win8 apps installed on the Win8 developer preview:


And here’s the hidden folder backing it up:


Gaining Access to C:\Program Files\Applications

In
essence you’ll need to navigate to that folder, hit “Security Tab” and
set yourself up as the owner. Let me walk you through that process
step-by-step.
1. Type in “C:\Program Files\Applications” in the Windows Explorer address bar and hit enter.

2. Observe in shock and dismay the system dialogue saying you don’t own a folder on your own machine. Hit “Continue”.

3. After hitting “Continue”, you’ll be confronted by the following dialogue:

Do not hit “close”, instead click the “security tab” link.
4. In the following system dialogue click “advanced”.

5. Click the “change” link in the owner security field.

6. Add in your live ID or windows 8 user name to the “select user or group” system dialogue.


7. Click “OK”, Click “OK”, Click “Ok”.


8.
Type in “C:\Program Files\Applications” in the Windows Explorer address
bar and hit enter. You now have access to the Applications folder.


What type of apps ship with Windows 8?

Looking at this folder it’s fairly easy to determine what type of apps ship with Windows 8 developer preview.


What’s in C:\Program Files\Applications?

For HTML apps the folder contains all of their source code and it can modified.
For C# apps the folder contains the XAML source code and a compiled reverse-engineerable and modifiable version of the C# code.
For
C++ directX apps the folder contains compiled binaries. Honestly, C++
isn’t my specialty so I’ll avoid discussing it at any great length.

Reverse Engineering HTML & Javscript & CSS Win8 apps

There’s
a fundamental design flaw in the concept of HTML apps. HTML, Javascript
and CSS are all interpreted languages, and not compiled languages.
Meaning you have to ship the source code for your app instead of
shipping compiled binaries. That puts the Intellectual Property of
anyone choosing to write any HTML & JS & CSS only app for any
platform under risk.

For example, here’s the HTML source code for the Tweet@rama Win8 app code:


And here’s the tweet@rama Javascript code that does the actual posting to Twitter:


Modifying HTML & Javscript & CSS Win8 apps

Part
of the problem with interpreted languages is that they don’t compile
until the very instance they are executed. Which allows evil-doers to
edit the code prior to execution.

For example, here’s a print screen of the tweet@rama default app;

Let’s
modify the HTML, Javascript and CSS for this application: (for the sake
of brevity we’ll only walkthrough a simple HTML change)




By
modifying the HTML & CSS & Javascript source code we can change
the visual design to something a bit more visually pleasing:

Notice that we’ve changed both the design and behaviour of
the app by modifying the source code. The new design has a different
title, and the new behaviour is using the picture of the logged in user
as the background. We have the power to completely change both the
visual design and the executing source code of HTML & CSS & JS
win8 apps.

New breed of viruses?

Any unauthorized malware that gains access to C:\Program Files\Applications could
potentially modify source code to execute in malicious ways. Since this
is the direction Win8 apps are taking writing this type of viruses is
likely to become a growth industry.
For example we could look
at the tweet@rama app once again. The most valuable asset that app has
is our twitter oauth credentials. A virus would be able to modify the
tweet@rama source code so once it executes it retrieves those
credentials and sends those to a malicious remote endpoint. The
following code interjected into the Javascript code of tweet@rama would
do just that:


New breed of cracks?

Any unauthorized executable that gains access to C:\Program Files\Applications could
potentially modify source code to workaround Windows Store app
purchasing and licensing logic. The whole concept of Trials and feature
purchases are based on Javascript, C# or C++ code invoking Windows 8
RuntimeTime APIs for the Windows Store. Any change to that code could
potentially change the purchasing and licensing logic for that app.
For example, In BUILD conference Microsoft’s Arik Cohen demonstrated (35:25) the following code that performs a Javascript check for isTrial.

It
would be a trivial endavour to manually edit this Javascript file and
remove the “licenseInformation.isTrial” check. And by doing so removing
Trial restrictions from this sample Win8 app.
If this set of
problems are not mitigated, app piracy through app modification for
Windows Store apps will likely become quite prevalent.

Reverse Engineering C# + XAML Win8 apps

C#
code is shipped in compiled EXE & DLL binaries. XAML is shipped as
plain text source code. That makes both forms of code extremely
susceptible to reverse engineering.


For example, we could open up the “Memories” (C# WinRT XAML app) MainPage.xaml in KaXaml and see the XAML source code:


Using JetBrains dotPeek it would be possible to see the C# source code for the Memories app:



Modifying C# + XAML Win8 apps

The
XAML for Win8 apps is stored in plain-text and can be edited from any
text editing tool. The .net binaries are unsigned and thus can be edit
using the MSIL Weaving tool Reflexil.

For example, here’s the “Memories” C# XAML app shipping with Windows 8 developer preview:


Editing the XAML is fairly trivial since it’s stored as a plain text file:



Editing C# can be done using Reflector’s Reflxil MSIL Editor:



With some light modifications to the XAML and C# code we can change the display and behaviour of the app:



Reverse Engineering C++ Win8 apps

I’ll
confess to not being a strong C++ developer (gasp!) so I’ll keep this
brief by showing C++ apps are also susceptible to reverse engineering.
It appears that Microsoft’s Store app is written in C++. The most
important asset that app would have are the endpoints for the Microsoft
store. Opening the C:\Windows\System32\WinStore\WinStoreUI.dll in notepad and searching for “https” addresses reveals the following URL:

Following the [You must be registered and logged in to see this link.] URL leads to a currently inactive URL of [You must be registered and logged in to see this link.] I would hazard a guess that this is the URL currently being used to test the Windows App Store.

What have we conclusively proven during this blog post?


Keeping in mind that Windows 8 is only an alpha developer release, we’ve seen a couple of disturbing things:

1. It is possible to reverse engineer and modify HTML, JavaScript and CSS code shipped in Win8 apps.
   
2. It is possible to reverse engineer and modify C#/VB.Net source code shipping with Win8 apps.
   
3. It is possible to reverse engineer and modify XAML source code shipping with Win8 apps.
   
4. It is possible to (at some limited level?) reverse engineer C++ Win8 apps.
   

Can Microsoft completely solve this problem?

No.
In my opinion, apps shipping as part of all app stores will always be
vulnerable at some limited level to reverse engineering and
modification.

Can Microsoft mitigate this problem?


Yes,
Microsoft can make apps significantly more temper-proof and pile a lot
of hardships on those seeking to reverse engineer and modify Win8 apps.
Assuming malicious code and people can’t access C:\Program Files\Applications seems naïve at best.
Here are few suggestions for what some of those potential aforementioned hardships might be:

1. Obfuscate C#/VB.Net projects by default: .net
   projects default to shipping with unobfuscated source code. If
   Microsoft is serious about introducing a Windows App store obfuscation
   has to be turned on by default for all .net project, not just a
   nice-to-have addon like it is right now. The VS2011 team should
   investigate and integrate an obfuscation solution directly into the
   product and turn it on for all new .net projects. This would make it
   harder to reverse engineer .net apps.
   
2. Minify HTML, Javascript and CSS projects by default: With
   the joys of desktop deployment web developers will likely forsake
   Javascript, HTML and CSS minification. Again, a good path forward here
   is to make sure all HTML, Jacascript and CSS code is minified by
   default. This step would make it harder to reverse engineer HTML apps.
   
3. Strongly sign all .net assemblies by default: Strong-signing
   has been part of the .net framework for 10 years now. Turn it on by
   default with a unique developer license certificate for all Win8 .net
   apps. Make sure Win8 AppContainers only run signed apps, don’t even have
   a hidden registry key to enable unsigned apps (like WP7 does). That would make it harder to modify .net apps.
   
4. Checksum HTML, Javascript and CSS project before startup:
   Even if it’s unpreventable that modifying Win8 HTML apps would take
   place, run a checksum on all files before loading the app into memory.
   That would make it harder to modify Win8 HTML apps. It sounds like
   AppBlockMap.xml is supposed to do something similar, but it doesn’t seem
   to work.
   
5. Don’t store App’s executing files as plain-old files on the user’s hard-drive: It
   shouldn’t be possible to even see the files shipping with an app by
   default using just Windows Explorer. A lossless compressed folder with
   DRM protection would be a good step forward here. This should make it
   harder to reverse engineer Win8 apps.
   

tl;dr:
If Microsoft doesn’t undertake the aforementioned steps or comparable
ones it’s not because it can’t, it’s because it doesn’t want to. If
Microsoft chooses to ignore this problem for the remaining one year (?)
development lifecycle for Windows 8 then it’s not because it couldn’t
solve these problems.

Visual Studio 2011 App Deployment

Apps deployed by Visual Studio 2011 do not get deployed to C:\Program Files\Applications but rather get deployed to C:\Users\\AppxLayouts.

The alternate location for Visual Studio app deployment and all other app deployment are controlled by the registry folder HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel.


Feedback

Have questions about the methodologies used in this article?
Have more interesting workarounds you’ve tried and like to share?
Have interesting suggestions for the Microsoft folks on how to help mitigate this problem?
Sound off in the comments!

-- Justin Angel
(Disclaimer:
this article represents research I undertook on my own and is
unsanctioned by any organizations or corporations I might be related
with.)




Published on 9/20/2011 12:00:00 AM by Justin Angel ©2012.

This work is licensed under a Creative Commons Attribution 3.0 Unported License.