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.
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!
Partitions
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:
MainOS:\Windows\ImageUpdate\DeviceLayout.xml
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:\"
https://dev.windowsphone.com/en-US/OEM/docs/Phone_Bring-Up/Partition_layout
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) |
This MS document says:
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)
Music
Photos
Videos
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
Email
Text messages
Contacts
Anything else not mentioned in the supported content list
Text messages
Contacts
Anything else not mentioned in the supported content list
%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 ...
Registry
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).
NTUSER.DAT (256 KB)
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:
Software:\Microsoft\Comms\Security\Policy\LASSD\LAP\lap_pw
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:
Software:\Microsoft\Comms\Security\DeviceLock\Object22\CurrentCredentialHash
which also had an associated timestamp at:
Software:\Microsoft\Comms\Security\DeviceLock\Object22\CredentialSetupTime
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:
Software:\Microsoft\Comms\Security\DeviceLock\Object464
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:
System:\ControlSet001\Control\BackupRestore\FilesNotToBackup
We also found:
System:\ControlSet001\Control\BackupRestore\FilesNotToSnapshot
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:
http://www.windowsphone.com/my
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:
Alarms
Calculator
Calendar
Camera
Games
Help + Tips
Hotmail
Internet Explorer
Maps
Messaging
Music + Videos
Office
OneNote
People
Phone
Photos
Settings
Store
Wallet
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)
|
