Tuesday, 7 October 2014

"Awesome" Windows Phone 8 Stuff

Mobile Forensics is AWESOME! Teamwork is AWESOME! Researching Windows Phone 8 is ... er, "no comment" ;)

Our previous Windows Phone posts here and here described the call history/SMS/contacts areas of Windows Phone 8.0 and provided their respective Python extraction scripts. Now that we've had some extra time to snoop around, we thought it would be a good time to relay some of our other Windows Phone findings.
Most of the observations in this post relate specifically to Nokia Lumia 520s running Windows 8.0 and are sourced from data sets provided by Brian McGarry (Garda, Ireland) and Cindy Murphy (Madison Police Department, USA). This information complements our recent research paper entitled "Windows Phone 8 Forensic Artifacts" that has been submitted for DFRWS EU 2015. The paper was co-authored by Cindy Murphy (Madison Police Department, USA), Maggie Gaffney (Teel Technologies, USA), Shafik G. Punja (Calgary Police Service, Canada), JoAnn Gibb (Ohio Attorney General’s Bureau of Criminal Investigation’s Cyber Crimes Unit, USA), Brian McGarry (An Garda Siochana, Ireland) and this awestruck little monkey.

So ... Let the brain dump begin! Warning: It's a bit of a long post ...

A Bit Of Background ...

Because it will help us understand our observations better, we will start by discussing how Windows Phone 8 fits together. Yes Jr, you have to eat your vegetables too!
Most of the information in this section is copied directly from this Microsoft Windows 8 Security Overview document.

Windows Phone 8 uses the same NT Kernel as Windows 8 and Windows Server 2012. It shares the same driver model, developer platform, security and networking stack, and graphics and media platform with the desktop operating systems.
It validates firmware images on Windows Phone devices before they are allowed to load the operating system (via Trusted Boot). All binaries must be signed by a trusted authority.
Windows Phone architecture uses a System-on-a-Chip (SoC) design provided by SoC vendors (eg Qualcomm). The SoC vendor and device manufactures provide the pre-UEFI boot loaders and the UEFI environment. Microsoft then provides the Windows Phone boot manager in the UEFI environment. After the pre-UEFI and UEFI components complete their boot processes, the Windows Phone boot manager completes the Windows Phone 8 boot process.

All code in the Windows Phone operating system is signed by Microsoft (eg drivers and applications). Applications that are added after manufacturing, or installed from the Windows Phone Store or a private enterprise store must be properly signed to execute.
Every app on Windows Phone runs in its own isolated chamber. A basic set of permissions is granted to all app chambers by default. However, the set of permissions for a chamber can be expanded by using "capabilities" that are granted during app installation. App permissions cannot be elevated at run time. No communication channels exist between apps on the phone. Apps are isolated from each other and cannot access memory used or data stored by other applications, including the keyboard cache.
All Windows Phone apps that are submitted to the store must be certified before they can be made available to users for downloading and installation. The certification process checks Windows Phone apps for inappropriate content, store policies, and security issues. Microsoft scans all apps for known viruses before publication. Apps must also be signed during the certification process before they can be installed and run on Windows Phones. (Note: Developers can register their phone devices so they can download/test their apps directly to/on their device without having to first submit to the store)

A user can set a PIN or password via the settings panel to lock their phone. IT departments can use Exchange ActiveSync policies to require users to set PINs or passwords, and also to configure additional password policies to manage password length, complexity, and other parameters. The Exchange Server Management Console and / or the Outlook Web App can initiate a remote wipe of the device. After registering their phone at http://www.windowsphone.com, users can map the location of their phone, make it ring, and wipe its data if necessary.

Windows Phone 8 uses BitLocker technology to support the encryption of all internal data storage on the phone with AES 128. The encryption key is protected by the Trust Platform Module (TPM), which is bound to UEFI Trusted Boot to ensure that the encryption key will only be released to trusted boot components.

The Windows Phone operating system allows users to store only media files on SD cards (Note: More recent documentation claims Windows Phone 8.1 now allows apps to be stored). Although the Windows Phone 8 operating system and user data partitions can be encrypted, files that are stored on SD cards that are inserted in the phone are not encrypted.

According to this MS document:
Microsoft will support Windows Phone 8.0 for the 36 month period from December 2012 until December 2015.
Similarly, Windows Phone 8.1 will be supported from June 2014 until June 2017. So this post should remain relevant for a few years yet :)
And now we can actually start discussing our observations!


There were 28 partitions visible on our data sets from MPD and Garda. Various forensic toolkits can be used to parse the JTAG .bin image including X-Ways Forensics (V17), EnCase (v7), FTK (v5.4) and FTK Imager (v3.2). OS Forensics (v3.0) has also been used for both mounting individual partitions and for further examination using the in-built Registry Viewer.
Information (of varying detail) for each of the partitions can be seen from an XML file located on partition 27 labelled "MainOS". Here is the file location:

From our observations, the interesting user related data lies on 2 NTFS partitions - partition 27 "MainOS" and partition 28 "Data". For the Garda Nokia Lumia 520, "MainOS" was ~1.8 GB and "Data" was ~5 GB.
The other 26 partitions seem to be related to the QUALCOMM 8960 System On Chip (SOC) (eg bootloaders / backups).

The relevance of the MainOS and Data partitions is also highlighted by this MS document which shows:
Main OS (aka %SystemDrive%) is mapped to "C:\"
User Data (aka %DataDrive%) is mapped to "C:\Data"
Removable User Data (aka %RemovableUserData%) maps to "D:\"

probably describes the partitions in further detail but its only accessible to paying developers. :(

File System

MainOS seems to be the equivalent of the desktop Windows OS partition - for example, it contains Registry hives, a pagefile.sys and a System Volume Information folder.
MainOS has 2 folders under \USERS - called DEFAULT and PUBLIC but only DEFAULT contains an NTUSER.DAT
MainOS does not have:
- the \Windows\system32\winevt\Logs folder (for event logs)
- the \Prefetch folder
- the hiberfil.sys file
The MainOS & Data partitions do not have $RECYCLE.BIN files either.

According to this MS document, MainOS (%SystemDrive%)  follows this structure:

MainOS file system structure (Source: Microsoft)

The Data partition includes a Users folder containing various sub-folders per Application/Service. Each sub-folder has its own NTUSER.DAT. Each app runs in it's own chamber with the app's specific permissions so that is probably why each app gets it's own user profile. For the Garda data there were 25 such sub-folder profiles.

According to this MS document, Data (%DataDrive%) follows this structure:

Data file system structure (Source: Microsoft)

It also says:
The root folders are generated on the device during initial provisioning startup. The storage boot service creates any folders that must exist before the remainder of the system can operate. The root folders are:
\Programs = Contains Windows Phone Store application code.
\Users = Contains default user account, built-in services, and public data folders.
\SystemData = Contains systemwide files, such as logs and Device Update. The data contained in this folder is not applicable to a particular application.
\SharedData = Contains systemwide shared data, or data shared between multiple applications.
\Test = Contains test code and the data in its subdirectories.

Built-in applications, or applications that are “in-ROM” and are serviced by Device Update store their code and installation files in the (MainOS) %SystemDrive%\Programs directory. Windows Phone Store applications store their code and installation files in the (Data) %DataDrive%\Programs directory.
Both built-in applications and Store applications store their data in their own isolated storage folder.
The application data folder is separated into Local, Roaming, and Temp folders so that applications can state-separate their data. See the next section on App data storage for more details.

Applications can use the %DataDrive%\SharedData folder to share content, but Microsoft does not recommend this approach. Applications that create shared data must delete content when it is no longer required. Each component should create its own subfolder and put the appropriate ACL/capability in place to restrict access to it.

Public data does not exclusively belong to a single application. Public data is stored outside of the application isolated storage. Each folder has an ACL based on a capability, which can be assigned to an application through the package manifest.
%DataDrive%\Users\Public directory contains
\Music = Stores music
\Video = Stores videos
\Pictures = Stores pictures
\Documents = Stores Office documents

LocalService and NetworkService system services are apparently also stored in the %DataDrive%\Users directory but we did not observe these directories in the Garda data. User accounts for services are also apparently stored in %DataDrive%\Users.

App data storage

In Windows Phone 8, apps have two types of data to store - app data (specific to the app) and user data (user created/managed). This MSDN article says: 

App data includes runtime state, user preferences, reference content (such as the dictionary definitions in a dictionary app), and other settings. App data is tied to the existence of the app and is only meaningful to that app.

User data includes document or media files, email or communication transcripts, or database records holding content created by the user. Note that user-selected preferences or app configuration options are considered app data, not user data. User data may be useful or meaningful to more than one app (eg documents).

According to this MSDN article :

"You don't need to know where or how this data exists, because the system is responsible for managing the physical storage. Just use the app data API ..."

Er, thanks Microsoft! Anyway, it goes on to say that app data can be stored under several categories and if the app is removed, these data stores are deleted. The categories are:
local = Data that exists on the current device only and is backed up in the cloud.
roaming = Data that exists on all devices on which the user has installed the app.
temporary = Data that could be removed by the system at any time.
localcache = Persistent data that exists only on the current device.

Local app data should be used for any information that needs to be preserved between app sessions and is not suitable type or size wise, for roaming app data. Data that is not applicable on other devices should be stored here as well. There are no general size restrictions on local data stored.

Roaming app data keeps the app's app data in sync across multiple devices. If a user installs the app on multiple devices, the OS keeps the app data in sync, reducing the amount of setup work that the user needs to do for the app on their second device. Roaming also enables the users to continue a task, such as composing a list, right where they left off even on a different device. The OS replicates roaming data to the cloud when it is updated, and synchronizes the data to the other devices on which the app is installed.
The OS limits the size of the app data that each app may roam. If the app hits this limit, none of the app's app data will be replicated to the cloud until the app's total roamed app data is less than the limit again. For this reason, it is a best practice to use roaming data only for user preferences, links, and small data files.
Roaming data for an app is available in the cloud as long as it is accessed by the user from some device within the required time interval. If the user does not run an app for longer than this time interval, its roaming data is removed from the cloud. If a user uninstalls an app, its roaming data isn't automatically removed from the cloud, it's preserved. If the user reinstalls the app within the time interval, the roaming data is synchronized from the cloud. The current policy specifies that this time interval is 30 days.
The operating system roams app data opportunistically and doesn't guarantee an instant sync. In scenarios where a user is offline or on a high latency network, roaming could be delayed significantly.

By doing some snooping, we found these app storage areas in the various application sub-folders under "Data:\Users". Each app gets its own sub-folder which in turn has an APPDATA folder containing Local / LocalLow, ROAMING, and Temp folders. From our sample Garda data, we did not observe a localcache folder.

Additionally this MSDN article says that App data settings are stored in the registry (presumably meaning in the Software hive) and that App settings can also be local or roaming. The settings that the app adds to the local data store are present only on the local device. The system automatically synchronizes settings the app adds to the roaming data store on all devices on which the user has installed the app.

SD Card Access (Not Tested)

There have been some changes regarding SD card use between Windows Phone 8.0 and 8.1. This MSDN article says:
Windows Phone 8 supports read-only access to the SD card where as Windows Phone 8.1 provides read/write access.
Windows Phone 8.1 also lets users install apps on the SD card, or move apps that are already installed to the SD card.

SD Card files are stored in the %RemovableDataDrive% (D:\) using the following structure:

SD Card file system structure (Source: Microsoft)

The storage card stores content that is generated or downloaded onto the phone, in addition to content that is sideloaded by the user. Content that is generated on the phone follows a prescribed folder layout, which mirrors the Public data folder layout on internal storage. Sideloaded content can be in any folder layout, and any content requester needs to scan these folders. Windows Phone uses only one storage card, which is mounted on a separate drive (drive D).

According to this MS document, Windows Phone 8.1 supports the following content on SD cards:
Apps (new in Windows Phone 8.1)
Map data
Side loading application XAPs
Some app data, in particular, user content in non-system managed locations (for example, e-books)

SD cards do not support the following content:
Microsoft Office files
Text messages
Anything else not mentioned in the supported content list
This actually contradicts this MS document, which says that for Windows Phone 8.1:

%RemovableDataDrive%\Documents = Stores Office documents generated on or downloaded onto the device. The user also is able to sideload content into this directory.

Our data sets did not include SD card data so we are unable to figure out what MS actually means here ... :S

Another inconsistency regarding SD cards can be found here which says (dated August 25, 2014) that:
There is currently no method to move files between an SD card and the internal storage.

and yet there's a "Files" app in the Windows Phone Store here that purports to do just this ...


The Windows Phone 8 registry files are named/located similar to those from a Windows Desktop OS and there is a TON of potential squirrel chasing there.

Partition 28 MainOS: \Windows\System32\config contained the following hives (amongst others).
Software (3640 KB)
System (2884 KB)
Security (8 KB)
SAM (8 KB)

The Software and System hives contained the most useful data (in monkeys humble opinion).
The NTUSER.DAT and SAM hives were not very useful. Similarly, nothing obviously useful was found in the Security hive except for the ActiveSync value under Security:\Software\Microsoft\ActiveSync\MergedPolicy\RequireDeviceEncryption (set to 0).

There was also a ProvisionStore hive found which seems to define access controls for capabilities/files/directories/registry entries (ie links SIDs to permissions). It was the largest hive at approximately 10 MB for both MPD and Garda data.

Also observed in the MPD data was an extra NTUSER1.DAT (96 KB).
James Macfarlane's "regcompare.pl" GUI tool (as installed on SIFT v2.14) was used to compare NTUSER.DAT with NTUSER1.DAT but nothing significant was found. This might be related to the phone being re-used/re-gifted by another person during its lifetime.

System:\Versions\ MajorVersion (eg 8) and System:\Versions\MinorVersion (eg 00) contains OS version information. Under System:\Versions\ there is also an associated TimeStamp value (eg 20131007-1506 for Garda, 20130513-1612 for MPD) and a Label value (eg WP8_CXE_GDR3 for Garda and WP8_CXE_GDR2 for MPD). Note: According to this article, GDR3 was an update issued on Oct 14 2013. So the Label can indicate how recently the phone was updated. The slightly different Label values possibly explains the discrepancies observed between MPD/Garda data sets.
In contrast,
Software:\Microsoft\Windows NT\CurrentVersion\CurrentVersion was set to 6.2 for BOTH MPD/Garda. They also had the same CurrentBuild, CurrentBuildNumber values but different BuildLab and BuildLabEx values.

System:\Platform\DeviceTargetingInfo contains several device related values such as PhoneFirmwareRevision, PhoneManufacturerModelName (eg RM-915_nam_usa_228), PhoneMobileOperatorName (ie service provider) and PhoneModelName (eg Lumia 520).

System:\ControlSet001\Control\ComputerName contains ActiveComputerName and ComputerName sub-keys which both had ComputerName values set to "Windows Phone".

System:\ControlSet001\Control\TimeZoneInformation contains TimeZoneKeyName (eg Pacific Standard Time) as well as ActiveTimeBias.
System:\State\DateTime contains DSTOverride, NetworkTime Enabled and NetworkTime Sync values.

System:\ControlSet001\Control\Windows\ShutdownTime appears to contain an MS FILETIME value for the last shutdown time. This will obviously depend on the phone's current time setting.

Phone Number

The device's phone number does not appear to be stored in the registry. A search was performed on the system hives but no data hits were found. Neither was the phone number found in the store.vol or Phone files.
StackOverflow claims its not programmatically possible to access the device's phone number.
Assuming its a GSM phone, you can determine the phone number from the SIM card. We did not have any CDMA phone datasets to see if they stored the phone number. If you do happen to know/find where its stored, please let us know in the comments section.

Phone PIN configuration

The PIN value seems to stored as a hash in the registry. A very dated (6/2/2010) Technet article for Win Mobile 6 says:

The PIN value is stored as a hash so there is no way to determine if an existing PIN satisfies the policy.

There's also a bunch of PIN related configuration stuff under:
which contains such values as AllowSimplePIN (set to 1 for MPD data), ExpirationPeriod (0), MinimumPasswordLength (4) and NumberOfPasswords(0).

For both Garda/MPD data sets, we observed data regarding this PIN hash at the following Software hive locations:
Software:\Microsoft\Comms\Security\DeviceLock\Object21\CredentialHash (which was a binary type)
Software:\Microsoft\Comms\Security\DeviceLock\Object21\CredentialActualLength (set to 8 for an 8 digit Garda PIN, set to 4 for 4 digit MPD PIN)

For Garda, the same credential hash value was observed at:
which also had an associated timestamp at:
This timestamp seems to be a MS FILETIME (eg binary value was 0x4043171AF184CE01 = Sat, 20 July 2013 02:30:30 UTC)
Note: After a factory reset, Object21 and Object22 keys were no longer present in the registry.

For MPD, the corresponding CurrentCredentialHash and CredentialSetupTime was located under:

For both Garda/MPD data sets, 
Software:\Microsoft\Comms\Security\DeviceLock\Object10 also has a DeviceWipeThreshold value (set to 0 for MPD/Garda data)
According to this Technet article, this setting's value is the number of incorrect password attempts to allow before the device's memory is erased. The value can be 1 through 4294967295 (0xFFFFFFFF). This registry key does not exist by default. If it does not exist, is set to zero (0), or is set to 4294967295 (0xFFFFFFFF), the local wipe feature is turned off.
So it might be handy to know if DeviceWipeThreshold is set to 0 or 0xFFFFFFFF as it might then be possible to brute force guess it if its only 4 digits ... its only 10000 combos LOL.

Encryption configuration

Regarding encryption, there are a few registry locations which may be informative:
Software:\Microsoft\DeviceEncryption\Enabled (set to 0 for MPD/Garda data which was not encrypted).
Software:\Microsoft\Provisioning\DeviceEncryption\Enabled (set to 0 for MPD/Garda data).
System:\ControlSet001\Control\FileSystem\NtfsDisableEncryption (set to 1 for MPD/Garda data)

File System configuration

The following keys might prove useful when looking at the file system:
System:\ControlSet001\Control\FileSystem\NtfsDisableLastAccessUpdate (set to 1 for MPD/Garda data which implies that filesystem access times are not updated)
System:\ControlSet001\Control\FileSystem\NtfsDisableEncryption (set to 1 for MPD/Garda)
System:\ControlSet001\Control\FileSystem\NtfsEncryptPagingFile (set to 0 for MPD/Garda)
System:\ControlSet001\Control\CrashControl which contains a DedicatedDumpFile value set to "c:\Data\SystemData\DedicatedDump.sys". So that file might have some forensic goodies in it if/when an app crashes.
System:\ControlSet001\Control\Session Manager\Memory Management has bunch of paging config parameters such as ClearPageFileAtShutdown (set to 0) and PagingFiles (set to "c:\pagefile.sys 256 256").

Note: We have observed/retrieved valid SMS data structures from the pagefile.sys.

MTP configuration

Software:\Microsoft\MTP lists a bunch of MTP (Media Transfer Protocol) keys/values which might be handy if you need to link a Windows Phone to a PC (eg media transfers). For example:
Software:\Microsoft\MTP \DataStore was set to "C:\Data\Users\PUBLIC".
MTPStorageName was set to "Phone".
There's also values for various MTP services and File types. Interested readers should refer to Nicole Ibrahim's SANS presentation for a more comprehensive discussion of MTP issues.

System Directory configuration

The following registry keys link various system placeholders with their respective file system directories:
Software:\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders (eg "Common Documents" set to "x:\Users\Public\Documents")
Software:\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (eg "CommonPictures" set to " %PUBLIC%\Pictures")

Backups and Volume Shadow Copy configuration

According to this MSDN article, the FilesNotToBackup registry key can be used to specify the names of the files and directories that backup applications should not backup or restore. However, it does not exclude those files from shadow copies.
We found this key at:
We also found:
which would seem to imply Volume Shadow Copies. However, no volume shadow copy information was observed under the Garda's MainOS:\System Volume Information\. But perhaps the phone had not triggered a VSC yet...

Missing Desktop Windows Artifacts

Windows Phone 8 does not seem to utilize all of the same mechanisms as a Windows Desktop system.
There was:
- no Prefetch directory
- no hiberfil.sys
- no event logs (under the expected \Windows\system32\winevt\Logs)
- no shellbags

Regarding shellbags ...

NTUSER.DAT usually appears under c:\Users\<user>\
For the Garda data, there were 2 User profiles under MainOS:\Users.
MainOS:\Users\DEFAULT\NTUSER.DAT did not contain a Shell key under \Software\Microsoft\Windows
MainOS:\Users\Public did not have a NTUSER.DAT

Data:\Users\ contained a sub-folder for each app/service. Each sub-folder had an NTUSER.DAT but only two folders had sizes greater than 96 kBytes. These were the DefApps and the WPNETWORKPII folders (256kB each). They didn't store a Shell key under \Software\Microsoft\Windows and neither did the 96kB sized WPCOMMSERVICES\NTUSER.DAT.

UsrClass.dat hives usually appear under C:\Users\<user>\AppData\Local\Microsoft\Windows.
There was no \Local folder under MainOS:\Users\DEFAULT\APPDATA.

Data:\Users\DefApps\APPDATA\Local\Microsoft\Windows had a (768 kB) UsrClass.dat file
However it's
\Local Settings\Software\Microsoft\Windows key did not contain Shell or ShellNoRoam sub-keys.

Most other User profiles under Data:\Users\ had 256 kB UsrClass.dat files but some did not.
Inspecting selected UsrClass.dat files showed they also did not contain Shell or ShellNoRoam keys under \Local Settings\Software\Microsoft\Windows
This makes sense as most of the usernames under Data:\Users\ indicated services (ie contained SVC in their name).

Miscellaneous Stuff

Monkey wasn't sure where to fit some interesting stuff from this Windows Phone 8 Introduction, hence this section.

For web management of a Windows Phone go to:

and login to see how you can access your phone from the web. You’ll see links to your photos and documents on SkyDrive, a link to your Xbox info, and links to your inbox, contacts, and calendar on Hotmail. My Windows Phone also provides tools for finding and managing your phone, viewing/editing your account and billing info, and viewing and reinstalling your apps.

The document also lists some default apps in the appendix:





Help + Tips


Internet Explorer



Music + Videos









It appears that some of these default Apps data can be found under Data:/Users/DefApps/APPDATA/

Additionally, this MS article mentions preinstalling apps on the phone as part of the OS image so that they are available to customers when the phone first boots. These apps can be first-party applications, Microsoft apps, or third-party apps.
So it's likely that each phone/service provider combination will have it's own configuration of default apps.

Final Thoughts

This has been a pretty voluminous/vomitus post because it's the result of multiple days worth of Googling and trawling through the Windows Phone 8.0 registry and filesystem ("Make it stop!"). Whilst its not 100% definitive, it should give readers an initial understanding of how the Windows Phone 8 OS is structured without having to refer to multiple MS articles. It also provides a convenient outlet for some of the interesting stuff that might not have made it into our DFRWS research paper due to space constraints. At the very least, it ensures monkey can free up some space in his cluttered head for other awesome things ...

And remember ... EVERYTHING is AWESOME! (*For some things, awesome-ness is sold separately)
(Picture Source: IMDB.com)


  1. Very interesting post for law enforcement. We're pulling our hair out when we see the windows phones. I think UFED might be coming out with a cable extraction but something tells me they will be taking a good look at your post before launch. Keep up the hard work monkey!!

    1. Thanks for the encouragement :)
      And just when we kinda understand Windows Phone 8.0, Windows (Phone) 10 is just around the corner ...

  2. That is amazing. I am currently writing my bachelor-thesis about forensics on mobile devices with windows phone 7.x and 8.0 OS and havent seen ANY information that was as useful as yours. Do you have access or know, where I can find an image from a Nokia Lumia 800 or 920 for further investigation?
    Thx anyway for that good work.

    1. Glad you found it useful!
      Unfortunately, the images used were provided by others so they're not mine to give. Sorry.

  3. Thank you for this article, even though I do not understand what most of the words mean it still fascinates me learning how WP8/8.1 works :)

    One question though, it says that apps are effectively walled from one another in a sandbox and cannot change other apps in any way. How is Cortana able to open other apps and add and delete notes and reminders from Onenote and Calendar?

    Edit: sorry if this comment shows up 3 times. This is my first time commenting on a blog with google.

    1. Hi there,

      Interesting question. I did a quick Google but couldn't find anything much ... Cortana seems to be in limited regional beta/user testing.

      I haven't tested/used Cortana much but I suspect that as she / it is baked into the operating system, I'm guessing that OneNote and Calendar are registering themselves and/or calling functions from a Cortana library so they can interface with the Cortana app. Just a guess, but this way, apps could pass their data/some functionality to Cortana if they subscribed without breaking the sandbox model (too much).