In this article we will learn how to analysis the local storage of device and will look into way to do static analysis by doing reverse engineering. If you had not yet rooted your device please read my previous article where I have written the process to root the device.
Exploring application binaries, .NET assemblies, and other assets
In device installed applications have two main directories one is where application binaries, .NET assemblies assets are stored and another is app’s local storage directory where the app can store the local data.
All installed app have their own installation directory located at D:\Computer\Windows Phone\Phone\Data\PROGRAMS\{GUID}\Install\.
Also each app has its own local storage directory which run in their own filesystem sandbox. The local storage directory for an app is located at D:\Computer\Windows Phone\Phone\Data\Users\DefApps\APPDATA\{GUID}
Application Manifests file
Let's start with Manifest file of application which give us information about the application and their structure which help us to understand about the application.
In Windows Phone 8 Manifests file name as WMAppManifest.xml in XAP files and in Windows 8.x application Manifests name as Package.appxmanifest in APPX packages.
Manifest file support multiple XML elements, some of them are interesting as security view.
Check the capabilities
- Capabilities (<Capabilities>) - Which defines the capabilities required by the application.
- File Type Association (<FileTypeAssociation>) - Which defines the file extensions that are associated with the application.
- Protocol (<Protocol>) - Defines URL schemes that the app wishes to register for Activatable Class (<ActivatableClass>) - Defines classes that are used by the app that are external to it.
- Interface(<Interface>) - Specifies interfaces that the app implements that are external to it
Check the capabilities
<Capabilities> <Capability Name="ID_CAP_IDENTITY_DEVICE" /> <Capability Name="ID_CAP_IDENTITY_USER" /> <Capability Name="ID_CAP_LOCATION" /> <Capability Name="ID_CAP_MICROPHONE" /> <Capability Name="ID_CAP_NETWORKING" /> <Capability Name="ID_CAP_PHONEDIALER" /> <Capability Name="ID_CAP_PUSH_NOTIFICATION" /> <Capability Name="ID_CAP_SENSORS" /> <Capability Name="ID_CAP_WEBBROWSERCOMPONENT" /> <Capability Name="ID_CAP_ISV_CAMERA" /> <Capability Name="ID_CAP_CONTACTS" /> <Capability Name="ID_CAP_APPOINTMENTS" /> <Capability Name="ID_CAP_MEDIALIB_AUDIO" /> <Capability Name="ID_CAP_MEDIALIB_PHOTO" /> <Capability Name="ID_CAP_MEDIALIB_PLAYBACK" /> </Capabilities>
Seems that application using Capability Location, Microphone, Networking, phone dialer, contacts, Medialib Photo. These all susceptible and collecting user information.
Analysis Local Storage
As we know that application need local storage to save or cache file and folder for further uses. Lets analysis the local storage of the application into device.Install directory — C:\Data\Programs\{GUID}\Install\...
INetCache - Storing webView cache files
INetCookies - Storing WebCookies data.
INetHistory - Storing History of the web pages
Local - This is the folder where most of the application storing sensitive data. Also we can call isolated storage of application.
LocalLow - Low integrity code execute in this folder. Code executing with low integrity can only write to a small number of locations on the disk, such as the LocalLow folder you mentioned. (FOLDERID_LocalAppDataLow)
PlatformData - The system will create a directory in the top level of the app’s isolatedstorage.
Let's move into the local storage >
D:\Data\Users\DefApps\APPDATA\{513D7B13-D7A9-4B59-ACB0-B4629E4A7EEE}\Local
So above we have list of all local storage data. __ApplicationSettings and userdata seems that storing sensitive data. Lets open the __ApplicationSettings file.
Wooo!! application login username and password stored plain text in__ApplicationSettings
Reverse Engineering on the Application
In order to analyzing application binaries we have to extract all application binaries and .NET assemblies from the device where application installation files has been installed. Move into install directoryC:\Data\Programs\{GUID}\Install\..
D:\Data\PROGRAMS\{513D7B13-D7A9-4B59-ACB0-B4629E4A7EEE}\Install
Okay, after extract all the binaries from the device we’ll going to disassembled/decompiled and analyzed by doing manual testing. It is also need to review source code.
Most of the .dll files are seems that googleAds and GoogleAnalytics but we have to decompiled application .dll file. PhoneApp5.dll is seems that application .dll file. Let’s decompile this file using ILSpy. Its allow you to decompile .NET assemblies.
Now let's load the PhoneApp5.dll file into ILSpy and decompile assemblies.
As above picture you can view all the class has dicomplied and we are able to view C# code. Now let's review the code and figure-out some security issue.
We can start looking into .net Libraries, namespace and classes. So let’s start from first class AboutUs as by name it's look like all information about the application.
If you look into the code, he has embedded his name with his mail ID. Which will used for further attacks. Many time and most of the application you can able to extract information about developers. Let’s move other classes.
On the top of the class you can review the .net Libraries which will help you to figure out security issues.
Here in the action class if you look on the top you can see there are some Libraries list.
using GoogleAds; using GoogleAnalytics; using Microsoft.Phone.Controls; using System; using System.ComponentModel; using System.Diagnostics; using System.IO.IsolatedStorage; // using System.Windows; using System.Windows.Controls; using System.Windows.Input;
In this class action using System.IO.IsolatedStorge which mean that the class using IsolatedStorage to store data.
If you look into snippet code username and password storing into __ApplicationSettings() without doing any encryption that found in our local storage analysis into __ApplicationSettings file.
Lets move another classes to check for local storage database.
If you look into snippet code username and password storing into __ApplicationSettings() without doing any encryption that found in our local storage analysis into __ApplicationSettings file.
Lets move another classes to check for local storage database.
using GoogleAnalytics; using Microsoft.Phone.Controls; using PhoneApp5.MyClasses; using System; using System.Diagnostics; using System.Linq; // using System.Windows; using System.Windows.Controls; using System.Windows.Navigation;
If you look into these Libraries list there is using System.Linq namespace provides classes and interfaces that support queries that use Language-Integrated Query (LINQ).
In this picture if you look closely UserDataContext is publicly used class were DB connection established and created as userdata.sdf database file were all the data has been stored.
Next things all Bank data has stored and updated by class userDataContext. If you look closely in the code before storing data into database they parse with Function Scramble.
In our local storage analysis we got userdata.sdf database file and using compactView we have view the data which being stored into userdata.sdf file. But data has encoded into some numeric value which is not in plain text. So the application using Scramble function to puzzle the words using some programming method.
Let's look closely and figure out how the data has been decoded.
Okay, we manage to get the function UnScramble which is using decoding the data stored into database file while display the information to the users. Also we got he unscramble program to decode all users data from the database.
By the way for this application we got the username password in plain text stored into __ApplicaitonSetting file which will use to unlock the application and view all data of users. But I want to show you approach for source code review by doing reverse engineering on the application.
Secure way Storing Data in Windows Phone
Microsoft have DPAPI (Data Protection API)to encrypt and decrypt entire isolated storage. DPAPI generating and storing a cryptographic key by using the user and device credentials to encrypt and decrypt data. You can use the Protected Data class that provides you access to DPAPI through Protect and Unprotect methods. You use the Protect method to encrypt the data and the Unprotect method to decrypt the data. On a Windows Phone device, every app gets its own decryption key, which is created when you run the app for the first time. Calls to Protect and Unprotect will implicitly use the decryption key and make sure that all the data remains private to the app.
Protect and Unprotect API using optional parameter call optionalEntropy.If you are using DPAPI recommended to use OptionalEntropy because of all data protected by DPAPI on Windows Phone is encrypted using the same key. If an attacker on the device or any app is able to get access to a DPAPI-encrypted data, and if the target app not using an optionalEntropy parameter, then it can recover the data by simply calling into ProtectedData.Unprotect().So you should always use the optionalEntropy parameter if you want to use DPAPI in your apps. However hard code optionalEntropy or store it on the device will allow to attackers to decrypt entire data if he/she have full access on the device. In this case you should base it on secret passphrase known only by the app user. You can use PBKDF2 which password only the user knows.
Windows Phone local database encryption
If you want to encrypt your database you can simply use the Password property in your database’s connection string:
// Create the data context.
MyDataContext db = new MyDataContext("Data Source='isostore:/mydb.sdf';Password='securepassword';");
// Create an encrypted database after confirming that it does not exist.
if (!db.DatabaseExists()) db.CreateDatabase();
But if you hard coding the key or secure credential is not good idea. As we see how we can decompile the code by doing reverse Engineering on the application and get the secrete key.
In this case you can use SQLite-based database and use SQLite Encryption Extension (SEE) and SQLCipher.
Conclusion:
In this article we did analysis internal device local storage and database of the application. Also we learned secure way to store data into the device. We learned how to perform source code review by doing reverse engineering.
If you want to learn more about the Windows Mobile Application security I recommend you to read
"The Mobile Application Hacker's Handbook".
