Collaborate Disseminate
Whenever [Ken Shirriff] posts something, it ends up being a fascinating read. Usually it’s a piece of computer history, decapped and laid bare under his microscope where it undergoes reverse …read more Continue reading Inside Globus, a Soviet-Era Analog Space Computer
There’s something enchanting about ancient tools and instruments. The idea that our forebears were able to fashion precision mechanisms with nothing but the simplest hand tools is fascinating. And watching someone recreate the feat, such as by building an astrolabe by hand, can be very appealing too.
The astrolabe is an ancient astronomical tool of incredible versatility, allowing the user to do everything from calculating when the sun will rise to predicting the positions of dozens of stars in the night sky. That it accomplishes all this with only a few moving parts makes it all the more fascinating. [Uri …read more
Continue reading Simple Hand Tools Turn Brass and Steel Into An Amazing Astrolabe
Dell adds a new 2-in-1 to the Latitude line for its business customers.
The post Dell Launches New Latitude 2-in-1 With ExpressSign-In, Upgraded Internals, More appeared first on Thurrott.com.
Continue reading Dell Launches New Latitude 2-in-1 With ExpressSign-In, Upgraded Internals, More
 |
| Monkey, just keep swimming through the WinPhone data … ya clown! |
UPDATE 6OCT2015: Edited FindMyPhone and Multimedia sections + added suspected main Location setting Registry location.
A couple of recent cases had this monkey investigating how Windows Phone 8.10 stores geolocation data on a Nokia Lumia 530.
There does not appear much forensic documentation regarding this, so this post is going to be a pretty voluminous / potentially narcoleptic episode of squirrel chasing (without any neat scripts to run at the end either). Despite the length of this post, monkey gets the sneaking suspicion that there is more to be discovered. I guess we have to start somewhere …
Carrier-locked versions of the 530 can be picked up for as little as $50 in Monkeytown so they could be more popular than you’d initially suspect. They also come bundled with Windows Phone 8.10 by default.
Downloading of the 4 GB capacity devices was done via eMMC read using the Z3X-Pro flasher box and took approximately 90 minutes per device. Note: The soldering points for these are not for the banana fisted. The points are so tiny that this monkey needed his big boy soldering pants AND special adult assistance (Thanks Boss Rob!).
For the 530, there are 3 potential storage areas for geolocation data – the Partition 26 (P26) “MainOS” NTFS partition, the Partition 27 (P27) “Data” NTFS partition and the removable SD Card.
The test data came from 2 well used 530 devices (Devices A and B), a factory fresh 530 (Device C) and a simulated test device (Device D). While all four were 8.10 (MajorVersion.MinorVersion) devices, their SYSTEM hive’s \Versions\BuildNumber values were not all the same (probably due to being configured for different service providers).
An X-Ways Forensics (XWF) “simultaneous search” for likely geolocation keywords was initially performed (eg “latitude”, “lat”, “GPS”, “GNSS”, “degree”). Subsequently, a regex search was also performed using some likely latitude regular expressions (eg1 “-1[2-5].” for “-12.” to “-15.”. eg2 “-1[2-5]°” for “-12°” to “-15°”).
Tip: To type the degree symbol, you hold down the Alt key as you type 248 on the numeric keypad (with numlock ON).
For accuracy purposes, it might also help to know that 1 nautical mile (approximately 1852 m) is 1 minute of a degree (there are 60 minutes to a degree).
Thanks to a Brian Moran (@brianjmoran) tip, we found some information on commonly used latitude/longitude formats here.
To simplify the number of searches, it was also assumed that any textual latitudes will have the corresponding longitude close by. Ideally, there will also be an associated timestamp so we can say that at a certain time, the device was at location X. The XWF regex search technique should find any plain text (UTF8, UTF16-LE) strings which contain relevant latitude information. However, it will not find any latitudes stored as binary data (ie floats/doubles).
The main Location setting (for this phone model) is suspected to be at:
P26:\Windows\system32\config\SOFTWARE\OEM\Nokia\GPS\LocationService which was set to 1 when the main Location setting was enabled and set to 0 when disabled. We’re not sure if this is the direct cause or a secondary result of the Location setting. Presumably, this location will vary with non-Nokia devices.
The proliferation of web based location/map services and the availability/storage capacity of P27:/pagefile.sys (which contains the swapped out contents of RAM) has resulted in a large number of readable lat/long pairs. Connecting a lat/long pair to specific phone functionality and/or proving a user’s direct knowledge was/remains a challenge.
To assist with this we have organized the lat/long information in this post into the following categories:
– ObservationLogWP8 (crowd sourced location logs)
– FindMyPhone (location tracking of device)
– Default Internet Explorer Browser
– Cortana (personal assistant)
– Multimedia metadata (from device pictures/video)
– WP8 Application data
– Registry
This appears to be related to Microsoft’s crowd-sourcing efforts to survey/report WiFi and cell tower information for device location (see here and here). Various UTF8 and UTF16-LE encoded XML fields belonging to a parent “ObservationLogWP8” XML element were found in Device A’s P27:/pagefile.sys. These fields included a timestamp, location, WiFi and Cell Tower signal information. Not all instances of these had latitude/longitude information, some only had timestamped WiFi and cell information (they may have been related to requests for location).
The string “ObservationLogWP8” was also found in a LocationCrowdsource.dll. The LocationCrowdsource.dll also existed in a Nokia 520 running Windows Phone 8.0 suggesting this functionality is not new to Windows Phone 8.10.
From the dates found in test data, it is suspected the initial phone setup is one event that triggers this data being recorded. According to the FAQ mentioned previously, enabled apps can also request the device location which could result in ObservationLogWP8 data being generated.
One of the more complete “ObservationLogWP8” XML elements (from P27:\pagefile.sys) looked like:
<Env Version=”1.0″><Body Type=”ObservationLogWP8″><LocationData><RequestHeader><Timestamp>2015-12-31T01:23:45.678+12:34</Timestamp><Authorization /><TrackingId>378130cb-e97f-4558-a3ac-123456789ABC </TrackingId><ApplicationId>d002970e-345b-409f-9e22-b360eb83f641</ApplicationId><DeviceProfile ExtendedDeviceInfo=”NOKIA/Lumia 530″ OSVersion=”8.10.14234.WPB_CXE_R1(wpbldlab).20150123-1722″ LFVersion=”2.0″ Platform=”” ClientGuid=”00000000-0000-0000-0000-000000000000″ DeviceType=”WP8″ DeviceId=”d002970e-345b-409f-9e22-123456789ABC” /></RequestHeader><LocationStamps><LocationStamp ts=”2015-12-31T01:23:45.678+12:34″><Loc la=”-XX.12345″ lo=”YYY.12345″ al=”12.00000″ spd=”5.25000″ hed=”180.50000″ hacc=”3″ hdop=”0.80000″ vdop=”0.80000″ herralong=”2″ haxis=”2″ /><CellTowers ts=”2015-12-31T01:23:45.678+12:34″><Umts7 mcc=”505″ mnc=”1″ lac=”12345″ ucid=”123456789″ uarfcn=”1234″ psc=”12″ rscp=”-100″ ecno=”-11″ /></CellTowers><WifiPoints ts=”2015-12-31T01:23:45.678+12:34″><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-86″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /> /></WifiPoints></LocationStamp></LocationStamps></LocationData></Body></Env>
Note1: The mcc = country id and mnc = carrier id.
Note2: Note the ApplicationId GUID field in the data which could potentially connect an app to this location data.
For privacy reasons, the above example had the following information modified:
– Timestamps
– Various GUIDs (except ApplicationId and ClientGuid)
– bssid (MAC address of WiFi access points)
– CellTowers
– Location/Movement information
If the main Location setting is OFF, ObservationLogWP8 data should not be written (in theory). This was possibly observed when we found that some devices contained hits for “ObservationLogWP8” in LocationCrowdsource.dll but no ObservationLogWP8 XML elements. Also, if an individual application does not have it’s Location capability enabled, the ObservationLogWP8 data should not be present for that app.
From the Microsoft “Personal Wi-Fi Access Point Opt-Out” section here:
“If you have a Wi-Fi access point or router and you wish to exclude it from Microsoft’s location positioning database … you can submit the MAC address to Microsoft’s block list”
This means by default (with a Location enabled device), the device gets to snoop around and map any/all WiFi access points it can. So you’d expect to see more of these ObservationLogWP8 XML instances, the longer a phone is used (assuming the phone moves around).
Windows Phone 8.10 has the capability to ring/lock/erase/locate a registered device from this website. This capability is not enabled by default and requires the user register their device and phone number with their Microsoft account. The FindMyPhone settings menu has a checkbox for “Save my phone’s location periodically and before the battery runs out to make it easier to find”. This is OFF by default. According to the (March 2014) Windows Phone 8 Privacy Statement:
“the location of your phone will be sent periodically to your online account at the My Windows Phone page”. It “only stores the last known location of your phone. When a new location is sent, it replaces the previously stored location”.
There were various FindMyPhone P26:\Windows\system32\config\SOFTWARE registry entries, FindMyPhone DLL libraries and a FindMyPhone executable present in our devices. The FindMyPhoneRuntimeDll.dll contains what appears to be a print format string for a “MyPhoneOperation” data element. Searching for “MyPhoneOperation” returned hits in Device A at
P27: \Users\WPNETWORK\APPDATA\Local\dcpsvc\StagingFiles\CssV1_1\*FOLDER_GUID*\*FILENAME_GUID*.csd – which contained a timestamp, Latitude, Longitude and possibly Altitude information stored in a .csd file. We are unsure of the significance of the GUIDs in the directory and file names as they varied between phones. For Device A (with FindMyPhone enabled), there were multiple directories and .csd files with two .csd files containing geolocation information. For Device D (with FindMyPhone enabled), there were multiple directories and .csd files but only one .csd contained geolocation information.
Devices B and C did not store this information potentially indicating that the FindMyPhone functionality was not enabled on those devices. The found XML string looked like:
<MyPhoneOperation> <UpdateLocation> <Location>(2015-12-31 01:23:45Z) -XX.123456,YYY.1234,ZZ.000000</Location> </UpdateLocation> </MyPhoneOperation>
Where XX is latitude and YYY is longitude. ZZ is suspected to be altitude. For Device A, the lat/long listed was about 400m W of the suspected location so the third parameter is probably not accuracy. Note the differences in precision (decimal places) between latitude and longitude. So if your device does contain a FindMyPhone location, the accuracy of the position can vary.
Two configurable FindMyPhone Registry settings are located at:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\LocationSyncEnabled
(which was set to 1 when “Save my phone’s location periodically and before the battery runs out to make it easier to find” is checked. 0 if unchecked (by default)) and
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\MpnEnabled
(which was set to 1 when “Always use push notifications (not SMS) to send commands and apps to my phone” is checked. 0 if unchecked (by default)).
There were also multiple hits for “FindMyPhone” in various GUID named sub-keys under:
P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID1*}
which suggests the regular running of a process/processes to report back the device’s current location. For example, the “Schedule” entry value under the GUID sub-key contains the strings “ProcessFindMyPhoneCommand”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe ProcessFindMyPhoneCommand”. This was also present on a factory fresh install.
There was also a “Schedule” entry under P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID2*} which contained the strings “FMPLastLocationSyncSchedule”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe SyncLocation”. This one was NOT present on a factory fresh install with FindMyPhone disabled.
The default Internet Explorer browser provides some potential geolocation data via cookies, webcache and the “GetLocationUsingFingerprintResponse” browser function. The P26:\Windows\system32\config\SOFTWARE\Microsoft\Internet Explorer\Version registry entry value was set to 11.0.0.0 for all test devices.
The browser also has an “Allow access to my location” setting which should affect how much location information is stored/accessed.
Cookies which contained (URL/percent encoded) textual latitude and longitude information were located in randomly named .txt files in P27: \Users\DefApps\APPDATA\INTERNETEXPLORER\INetCookies. The availability and format will vary depending on the website requesting the user’s location and the device’s Location settings. Using ESEDatabaseview from NirSoft to view the P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\WebCacheV01.dat tables (eg table “Container_21”) can help link a URL to the randomly named cookie file.
URLs with latitude/longitude information were also found in Webcache log files such as P27: \Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\V01tmp.log
For example, a (redacted) GoogleMaps directions URL:
http://maps.googleapis.com/maps/api/directions/json?origin=-XX.1234567891234,YYY.123456789123&waypoints=&destination=-XX.1234,YYY.123&mode=d&units=metric&language=en&sensor=true
Note1: XX = latitude and YYY = longitude.
Note2: Notice the precision (number of decimal places) of the latitude differs from the longitude. Similar entries were also observed in WebcacheV01.dat which makes sense if the .log files are being used as transaction logs for the WebcacheV01.dat ESE database.
The “GetLocationUsingFingerprintResponse” browser function appears to be used by Internet Explorer to submit various values (eg cell tower/WiFi signal strengths) to a web based service. The service then sends back the (estimated) device location. Various hits for “GetLocationUsingFingerprintResponse” with close by Latitude, Longitude, Altitude, ServerUtcTime and RadialUncertainty were found in P27:\pagefile.sys.
For example:
<GetLocationUsingFingerprintResponse xmlns=”http://inference.location.live.com” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”><GetLocationUsingFingerprintResult><ResponseStatus>Success</ResponseStatus><LocationResult><ResolverStatus Status=”Success” Source=”Internal”/><ResolvedPosition Latitude=”-XX.123456″ Longitude=”YYY.123456″ Altitude=”0″/><RadialUncertainty>2246</RadialUncertainty><TileResult/><TrackingId>7e8381e9-106c-45f2-8af9-123456789ABC</TrackingId></LocationResult><ExtendedV21Result CrowdSourcingLevel=”High” ServerUtcTime=”2015-12-31T01:23:45.1234567Z” CollectionType=”Wifi|Cell” InferenceType=”Wifi|Cell”/></GetLocationUsingFingerprintResult></GetLocationUsingFingerprintResponse>
For further information on “GetLocationUsingFingerprintResponse”, see the “Post Script” section in Rudy Huyn’s blog post (in French but Chrome translates it OK-ish).
Also see Chad Tilbury’s (@chadtilbury) series of posts on browser geolocation forensics here.
The Alpha version of Cortana comes installed with the 530. Search for “What does the fox say?” or “Who is Siri?” and prepare to be semi-amused. It appears Cortana requires an active Internet connection so it may not always be enabled by the user if they’re on a cheap pre-paid plan. If not enabled, searches are supposed to use Bing instead. Cortana can be voice activated and location aware so you can set it to remind you “When I get home, remind me to spank the monkey”. Such behaviour (the reminding, not the spanking) means there could be a register of locations which may help prove the user had prior knowledge of a location.
Most of the information in this section was sourced from Brent Muir’s (@bsmuir) recent Windows 10 forensics post here. Not all of the functionality mentioned in that post was applicable to Windows Phone 8.10 but it was still a great resource to have (Thanks to Brent for sharing!).
P27:\Users\WPNETWORK\APPDATA\Local\Graph\WP8LoggedInUser\Me\00000000.ttl
contained various Latitude and Longitude strings (preceded by the string “place.”). According to Brent, these types of file contain searched/favourite locations. Two other data sets had .ttl files but they did not contain any latitude/longitude data. It is likely that the recorded position data is dependent on the main Location setting being ON.
An example 00000000.ttl entry looked like:
p:me/place.-XX.123456_YYY.123456 <http://platform.bing.com/dateAccessed> “1601-01-01T00:00:00.000Z”^^s:Date ;
a s:Place ;
b:preferences/favorites.businessType “” ;
b:preferences/favorites.entityId “-XX.123456_YYY.123456” ;
b:preferences/favorites.entityType “http://schema.org/Place” ;
b:preferences/favorites.entityUrl “local_vdpid:\”-7995539123\”” ;
b:preferences/favorites.isBusiness false ;
b:preferences/favorites.originalName “Some Place Banana-ish” ;
s:ShowOnMap true ;
s:address p:me/postalAddress.-XX.123456_YYY.123456 ;
s:dateModified “2015-12-31T01:23:45.123Z”^^s:Date ;
s:displayCoordinates “Point(-XX.123456 YYY.123456)”^^geo:wktLiteral ;
s:geo “Point(0.000000 0.000000)”^^geo:wktLiteral ;
s:mapZoomLevel 18 ;
s:name “Some Place Banana-ish” ;
s:phone “” .
Note: The “dateAccessed” value above has NOT been modified from the original value.
There were other instances of latitude/longitude recorded in this .ttl file but they did not have a timestamp. For example:
p:me/list.recent. -XX.123456_YYY.123456 a rdf:List ;
rdf:first p:me/place.-XX.123456_YYY.123456 ;
s:displayOrder 25 ;
s:memberOf p:me/geoAnnotationCollection.recent .
which appears to be a recent search location.
Similarly, there were also latitude/longitude pairs observed in P27:/pagefile.sys preceded by “place.”. For example:
<http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456>
It is unknown if/how this example can be correlated to the previous Cortana .ttl examples but they do look similar.
Grammar files are used by speech recognition to define input speech words/phrases. They could also be used to indicate prior knowledge of a location. For more information, refer to the MSDN reference on “Grammars for Windows Phone 8” here.
Location data was found in Device A grammar files located at P27:\SharedData\Speech\Grammars\0809\PointsOfInterestGrammar.cfp.txt and P27:\SharedData\Speech\Grammars\0809\PointsOfInterest2Grammar.cfp.txt
These grammar files did not exist in Device C (factory fresh phone).
The grammar files contained entries like:
“Monkeytown, BananaState”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456”
“home”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456
which was followed by a timestamp in the format:
31/12/2015 1:05:45 PM
This timestamp matched the file system File Created date (in UTC) for the parent .txt file.
Unlike Windows 10 for PC, there was no IndexedDB.edb or CortanaCoreDb.dat (geofence) databases found in our test data. However, this may be due to our test data not being setup with any geofences.
Our device created multimedia’s file location, naming convention and metadata content was consistent with Det. Cindy Murphy et al’s SANS whitepaper on Windows Phone 8. That is, camera created media was found in the phone’s internal memory at P27:\Users\Public\Pictures\Camera Roll.
Additionally, under Device A’s SD Card’s \Pictures\Camera Roll\ directory there were various .mp4 videos whose filename started with WP and a datestamp (eg WP_20150101_001.mp4). Upon further inspection in XWF, there was “Xtra” metadata embedded in each video file which included an ISO timestamp (eg 2015-01-01T01:02:03Z) and location (eg -XX.3456+YYY.4567). This information was also visible using Phil Harvey’s ExifTool.
Also stored under the SD card’s \Pictures\Camera Roll\ were various .jpg files whose filename started with WP and a datestamp (eg WP_20150101_002.jpg). Upon further inspection in XWF, there was “EXIF” metadata embedded in each file which included the Phone model (eg “Lumia 530”), Date Original & Date Digitized timestamps (eg 2015:01:01 01:02:03), Latitude (eg 12° 34’ 5.678” S) and Longitude (eg 123° 45’ 5.678” E).
Photos from a different 530 device (media stored in internal phone memory), had similar EXIF data but did not contain GPS Latitude/Longitude information. This is possibly because the user did not enable the main Location setting and/or they did not enable the “Use Location info” in the “Photos” settings.
The following SOFTWARE hive entry value is suspected of configuring camera pictures/video with embedded location data:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Photos\Shared\CameraSettings\EmbedLocation
This entry value was set to 2 for device multimedia files with embedded GPS metadata and it was set to 1 when the “Photos” … “Use location info” setting was unchecked (no embedded GPS metadata). Presumably, the GPS data in EXIF also requires the main Location setting being enabled.
According to Microsoft, there are two location API libraries that Windows Phone 8.1 developers can use – the .NET Location API (for Windows Phone 7.1 and 8) and the Windows Phone Runtime Location API (new to Windows Phone 8 and 8.1).
The .NET Location API uses the System.Device.dll so whenever you see “System.Device.Location” you know the app was using the .NET Location API. See here for further details.
Alternatively, the MSDN Windows Phone Runtime uses the “Windows.Devices.Geolocation” namespace so if you see that string near latitude/longitude information, the Windows Phone Location API is potentially being used.
Both of these libraries are designed so the app can call a “Get Location” function and let the library calculate a position from the available resources (eg Cell, WiFi, GPS). As the library and results of the call are loaded into RAM, pagefile.sys can also potentially contain these app location artifacts.
The Facebook application comes bundled with the 530. Device A was the only data set that had Facebook user data. Various Facebook related location data was found in
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\LocalState\Log.txt
This file did not exist in Device C (factory fresh) which suggests that Facebook was not used on that device.
Anyway, here’s what the Facebook location data looked like:
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:45: POST: places.setLastLocation?coords{“accuracy”:0.0,”altitude”:0.0,”altitudeAccuracy”:0.0,”heading”:0.0,”latitude”:-XX.12345,”longitude”:YYY.12345,”speed”:0.0}
[Type: Navigation] [Severity: Low] 2015-12-31T01:23:45: Navigated to: Facebook.Views.Places
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:48: MULTIQUERY GET: Places:SELECT page_id, name, description, latitude, longitude, checkin_count, display_subtext, pic_square, distance(latitude, longitude, “-XX.12345”, “YYY.12345”) FROM place WHERE distance(latitude, longitude, “-XX.12345”, “YYY.12345”) < 750 LIMIT 25|Pages:SELECT page_id, name, fan_count, were_here_count, location FROM page WHERE page_id IN (SELECT page_id from #Places)
A potential Facebook “Last login” location was also found at:
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat and P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat.LOG1
Both setting files contained a string similar to:
“AllowLocationAccess”:true,”CacheExpirationInMinutes”:10,”ConfirmExit”:true,”CurrentUserName”:”Randy Monkey”,”CurrentUserProfilePicUri”:”https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xfa1/v/t1.0-1/p200x200/12345678_123456789ABCDEF12_123456789ABCDEF1234_n.jpg?oh=9b1356725bdbc1f30cb193068343123&oe=564DE360&__gda__=1438678992_c2802dc1e45c7998ca39c6f5dcf67484″,”GetHereNowEnabled”:true,”IsVerfified”:false,”HasLoggedIn”:true,”LastLatitude”:-XX.123456789012345,”LastLocationDate”:”\/Date(1430562061234)\/”,”LastLongitude”:YYY.12345678901234,”LockScreenState”:1,
For Device A, it also appears that the Windows Store app “GPS Voice Navigation” was installed, run and then uninstalled. There were location artifacts left in P27:\pagefile.sys such as:
app://8E116909-CF87-4176-894F-F54434EFB01E/_default#/Protocol?encodedLaunchUri=ms-drive-to%3A%3Fdestination.latitude%3D-XX.12345%26destination.longitude%3DYYY.123456%26destination.name%3DMonkey%2520Central%2520Headquarters
The GUID 8E116909-CF87-4176-894F-F54434EFB01E listed above is an alias for the GPS Voice Navigation app. This can be confirmed by visiting:
windowsphone.com/s?appId=8E116909-CF87-4176-894F-F54434EFB01E
Searching for “ms-drive-to” (as above) and “ms-walk-to” keywords can lead to further location data. According to this, these keywords can be used by an app to request walking/driving directions. So while it may not confirm a device’s actual location, it can prove a user looked up directions from/to specific places.
For the “GPS Voice Navigation” app, various location data was found with references to the System.Device.Location namespace. As mentioned previously, this is a .NET Framework library for calculating location via GPS, WiFi, Cell Tower triangulation. Any location strings found near a “System.Device.Location” string could be potential device locations.
So in P27:\pagefile.sys, we found:
<Latitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>-XX.1234</Latitude><Longitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>YYY.123</Longitude> <Speed xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>NaN</Speed>
Also found in Device A P27:\pagefile.sys was this more comprehensive gem:
<KeyValueOfstringanyType><Key>CurrentPosition</Key><Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/System.Device.Location” i:type=”d3p1:GeoPositionOfGeoCoordinate8rbsckdZ”><d3p1:Location><d3p1:Altitude>45</d3p1:Altitude><d3p1:Course>188.3</d3p1:Course><d3p1:HorizontalAccuracy>3</d3p1:HorizontalAccuracy><d3p1:Latitude>-XX.123456789012345</d3p1:Latitude><d3p1:Longitude>YYY.1234567890123</d3p1:Longitude><d3p1:Speed>3.72</d3p1:Speed><d3p1:VerticalAccuracy>3</d3p1:VerticalAccuracy></d3p1:Location><d3p1:Timestamp xmlns:d4p1=”http://schemas.datacontract.org/2004/07/System”><d4p1:DateTime>2015-12-31T01:23:45.1234567Z</d4p1:DateTime><d4p1:OffsetMinutes>600</d4p1:OffsetMinutes></d3p1:Timestamp></Value></KeyValueOfstringanyType>
As this only appeared in Device A, it is probably related to the “GPS Voice Navigation” app. This is potentially confirmed by nearby XML elements such as:
<Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/GPS_VN_BL_WP8″ i:type=”d3p1:Locales”>English</Value>
Also observed in Device A P27:/pagefile.sys, was an “EndLocation” keyword used by the “GPS Voice Navigation” app which showed the destination address details. So searching for that keyword could also reveal destinations entered into the app.
A basic app permission analysis was also performed on selected devices using the WP8_AppPerms.py script (see this previous post).
In Device A, There were 7 applications which required the ID_CAP_LOCATION capability (which provides access to device location):
WhatsApp
Facebook Messenger
*Facebook
*Skype
*XBox Video
*LumiaHelpTips_4?
*Nokia Music WP8 client
The apps that we preceded with an asterisk seem to be default apps that are pre-installed with the phone. Notice how even chat apps can require access to the device location. For example, Skype allows the user to “share location” from a chat. Similarly, WhatsApp can also send its location (as an attachment) in a chat.
Other permissions which a location aware app might need include:
ID_CAP_NETWORKING which would be required for accessing network services that can provide location information (eg “GetLocationUsingFingerprintResponse” data for Internet Explorer location queries).
ID_CAP_MAP which allows an app to display a map.
ID_CAP_CELL_API_LOCATION which seems to allow for/help location via Cellular position information.
ID_CAP_SENSORS which provides access to the phone’s accelerometer, compass, gyroscope.
According to XWF, Device A’s “Free space” (unallocated space) contained some UTF16-LE lat/long hits and a timestamp close to a “LastFoundAt” (ASCII) string.
For example, in close proximity to:
“lat=-XX.123456###long=YYY.123456###time=22/12/2015 01:23:45”
was an “hbin” string and a “LastFoundAt” string. The “hbin” signature suggests that the surrounding data belongs to a registry hive cell. Searching the P26:\Windows\system32\config\SOFTWARE hive resulted in a hit at \OEM\Nokia\NokiaAccessories\Devices\*FF:FF:FF:FF:FF:FF* (Hex string has been redacted) which contained an entry for “LastFoundAt” equal to the lat/long/time string observed.
However, this subkey did not exist in all test devices so this registry value may not always be available for providing a position.
P26:\Windows\system32\config\SOFTWARE\Microsoft\BingSuggests can have PreviousLatitude, PreviousLongitude entry values along with QueryAttemptTime, SuccessfulQueryTime and CacheUpdateTime entry values. It is unclear what the significance is of the Position information relative to Bing. Times appear to be LE 64 bit Number of 100 ns since 1 JAN 1601. The CacheUpdateTime was slightly later than the QueryAttemptTime (which equalled the SuccessfulQueryTime). The Registry Key’s “LastWrittenTime” occured AFTER the various timestamp values. The Timestamp values were zeroes for a new phone.
While squirrel chasing through the data, we noticed a few non-location related but interesting nuggets … (as if this post wasn’t already long enough!)
P27: \SharedData\Store\PurchaseHistory.xml
contains the purchased App GUID, the app name and the purchase date. If entering the app GUID to the “windowsphone.com/s?appId=” URL does not reveal the app name, try checking this file.
Calendar Reminders are stored in P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*} entry values. For example, SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*}
could contain a “Schedule” entry with value string containing the strings: “Reminder”, “Monkey’s New Year” and “All day event 01/01/2015”.
As mentioned by Brent Muir, notification messages are archived in a .dat file. For our test devices, this appears to be located at:
P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\Notifications\appdb.dat
This file was 24 MB in size but sparsely populated.
An example data string from the file looks something like:
<toast launch=”app://5B04B775-356B-4AA0-AAF8-6491FFEA5610/Chat?EntryId=00000000213E0000060000000700000000000000&MessageId=000000004A4E0000020000000800000000000001″><visual><binding template=”ToastText02″><text id=”1″>Voicemail Access</text><text id=”2″>Pls call 321, You have 5 New VoiceMail messages</text></binding></visual><audio src=”ms-winsoundevent:legacy-notification.sms”/><backgroundColor>#0</backgroundColor></toast>
Unlike Windows 10 for PC, there was no “TimestampWhenSeen” stored in P26:\Windows\system32\config\SOFTWARE (ie when Notification Center was viewed).
Thanks to Boss Rob for patiently helping/waiting for this monkey to obtain/analyse the various phone dumps and allowing us to share our findings with the forensic community.
There is lot of potential geolocation data stored on a Windows Phone 8.10 device but it will depend on the main Location setting being ON and in certain situations, on the app’s required capabilities.
The P27:/pagefile.sys is probably the best place to look for textually encoded latitude/longitude data. However, Internet Explorer cache, app logs, device camera picture/video files and the Registry can also store location data.
It is suspected that other Windows Phone 8.1 makes/models will contain the same geolocation artifacts but this should be tested/verified by the analyst.
For future testing purposes, it is noteworthy that the 530 can be upgraded to Windows 10 for Mobile devices (whenever it officially comes out, under whatever name they decide on).
If you would like to share your thoughts/suggestions or any geolocation artifacts, please leave a comment.
|
| Monkey, just keep swimming through the WinPhone data … ya clown! |
UPDATE 6OCT2015: Edited FindMyPhone and Multimedia sections + added suspected main Location setting Registry location.
A couple of recent cases had this monkey investigating how Windows Phone 8.10 stores geolocation data on a Nokia Lumia 530.
There does not appear much forensic documentation regarding this, so this post is going to be a pretty voluminous / potentially narcoleptic episode of squirrel chasing (without any neat scripts to run at the end either). Despite the length of this post, monkey gets the sneaking suspicion that there is more to be discovered. I guess we have to start somewhere …
Carrier-locked versions of the 530 can be picked up for as little as $50 in Monkeytown so they could be more popular than you’d initially suspect. They also come bundled with Windows Phone 8.10 by default.
Downloading of the 4 GB capacity devices was done via eMMC read using the Z3X-Pro flasher box and took approximately 90 minutes per device. Note: The soldering points for these are not for the banana fisted. The points are so tiny that this monkey needed his big boy soldering pants AND special adult assistance (Thanks Boss Rob!).
For the 530, there are 3 potential storage areas for geolocation data – the Partition 26 (P26) “MainOS” NTFS partition, the Partition 27 (P27) “Data” NTFS partition and the removable SD Card.
The test data came from 2 well used 530 devices (Devices A and B), a factory fresh 530 (Device C) and a simulated test device (Device D). While all four were 8.10 (MajorVersion.MinorVersion) devices, their SYSTEM hive’s \Versions\BuildNumber values were not all the same (probably due to being configured for different service providers).
An X-Ways Forensics (XWF) “simultaneous search” for likely geolocation keywords was initially performed (eg “latitude”, “lat”, “GPS”, “GNSS”, “degree”). Subsequently, a regex search was also performed using some likely latitude regular expressions (eg1 “-1[2-5].” for “-12.” to “-15.”. eg2 “-1[2-5]°” for “-12°” to “-15°”).
Tip: To type the degree symbol, you hold down the Alt key as you type 248 on the numeric keypad (with numlock ON).
For accuracy purposes, it might also help to know that 1 nautical mile (approximately 1852 m) is 1 minute of a degree (there are 60 minutes to a degree).
Thanks to a Brian Moran (@brianjmoran) tip, we found some information on commonly used latitude/longitude formats here.
To simplify the number of searches, it was also assumed that any textual latitudes will have the corresponding longitude close by. Ideally, there will also be an associated timestamp so we can say that at a certain time, the device was at location X. The XWF regex search technique should find any plain text (UTF8, UTF16-LE) strings which contain relevant latitude information. However, it will not find any latitudes stored as binary data (ie floats/doubles).
The main Location setting (for this phone model) is suspected to be at:
P26:\Windows\system32\config\SOFTWARE\OEM\Nokia\GPS\LocationService which was set to 1 when the main Location setting was enabled and set to 0 when disabled. We’re not sure if this is the direct cause or a secondary result of the Location setting. Presumably, this location will vary with non-Nokia devices.
The proliferation of web based location/map services and the availability/storage capacity of P27:/pagefile.sys (which contains the swapped out contents of RAM) has resulted in a large number of readable lat/long pairs. Connecting a lat/long pair to specific phone functionality and/or proving a user’s direct knowledge was/remains a challenge.
To assist with this we have organized the lat/long information in this post into the following categories:
– ObservationLogWP8 (crowd sourced location logs)
– FindMyPhone (location tracking of device)
– Default Internet Explorer Browser
– Cortana (personal assistant)
– Multimedia metadata (from device pictures/video)
– WP8 Application data
– Registry
This appears to be related to Microsoft’s crowd-sourcing efforts to survey/report WiFi and cell tower information for device location (see here and here). Various UTF8 and UTF16-LE encoded XML fields belonging to a parent “ObservationLogWP8” XML element were found in Device A’s P27:/pagefile.sys. These fields included a timestamp, location, WiFi and Cell Tower signal information. Not all instances of these had latitude/longitude information, some only had timestamped WiFi and cell information (they may have been related to requests for location).
The string “ObservationLogWP8” was also found in a LocationCrowdsource.dll. The LocationCrowdsource.dll also existed in a Nokia 520 running Windows Phone 8.0 suggesting this functionality is not new to Windows Phone 8.10.
From the dates found in test data, it is suspected the initial phone setup is one event that triggers this data being recorded. According to the FAQ mentioned previously, enabled apps can also request the device location which could result in ObservationLogWP8 data being generated.
One of the more complete “ObservationLogWP8” XML elements (from P27:\pagefile.sys) looked like:
<Env Version=”1.0″><Body Type=”ObservationLogWP8″><LocationData><RequestHeader><Timestamp>2015-12-31T01:23:45.678+12:34</Timestamp><Authorization /><TrackingId>378130cb-e97f-4558-a3ac-123456789ABC </TrackingId><ApplicationId>d002970e-345b-409f-9e22-b360eb83f641</ApplicationId><DeviceProfile ExtendedDeviceInfo=”NOKIA/Lumia 530″ OSVersion=”8.10.14234.WPB_CXE_R1(wpbldlab).20150123-1722″ LFVersion=”2.0″ Platform=”” ClientGuid=”00000000-0000-0000-0000-000000000000″ DeviceType=”WP8″ DeviceId=”d002970e-345b-409f-9e22-123456789ABC” /></RequestHeader><LocationStamps><LocationStamp ts=”2015-12-31T01:23:45.678+12:34″><Loc la=”-XX.12345″ lo=”YYY.12345″ al=”12.00000″ spd=”5.25000″ hed=”180.50000″ hacc=”3″ hdop=”0.80000″ vdop=”0.80000″ herralong=”2″ haxis=”2″ /><CellTowers ts=”2015-12-31T01:23:45.678+12:34″><Umts7 mcc=”505″ mnc=”1″ lac=”12345″ ucid=”123456789″ uarfcn=”1234″ psc=”12″ rscp=”-100″ ecno=”-11″ /></CellTowers><WifiPoints ts=”2015-12-31T01:23:45.678+12:34″><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-86″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /> /></WifiPoints></LocationStamp></LocationStamps></LocationData></Body></Env>
Note1: The mcc = country id and mnc = carrier id.
Note2: Note the ApplicationId GUID field in the data which could potentially connect an app to this location data.
For privacy reasons, the above example had the following information modified:
– Timestamps
– Various GUIDs (except ApplicationId and ClientGuid)
– bssid (MAC address of WiFi access points)
– CellTowers
– Location/Movement information
If the main Location setting is OFF, ObservationLogWP8 data should not be written (in theory). This was possibly observed when we found that some devices contained hits for “ObservationLogWP8” in LocationCrowdsource.dll but no ObservationLogWP8 XML elements. Also, if an individual application does not have it’s Location capability enabled, the ObservationLogWP8 data should not be present for that app.
From the Microsoft “Personal Wi-Fi Access Point Opt-Out” section here:
“If you have a Wi-Fi access point or router and you wish to exclude it from Microsoft’s location positioning database … you can submit the MAC address to Microsoft’s block list”
This means by default (with a Location enabled device), the device gets to snoop around and map any/all WiFi access points it can. So you’d expect to see more of these ObservationLogWP8 XML instances, the longer a phone is used (assuming the phone moves around).
Windows Phone 8.10 has the capability to ring/lock/erase/locate a registered device from this website. This capability is not enabled by default and requires the user register their device and phone number with their Microsoft account. The FindMyPhone settings menu has a checkbox for “Save my phone’s location periodically and before the battery runs out to make it easier to find”. This is OFF by default. According to the (March 2014) Windows Phone 8 Privacy Statement:
“the location of your phone will be sent periodically to your online account at the My Windows Phone page”. It “only stores the last known location of your phone. When a new location is sent, it replaces the previously stored location”.
There were various FindMyPhone P26:\Windows\system32\config\SOFTWARE registry entries, FindMyPhone DLL libraries and a FindMyPhone executable present in our devices. The FindMyPhoneRuntimeDll.dll contains what appears to be a print format string for a “MyPhoneOperation” data element. Searching for “MyPhoneOperation” returned hits in Device A at
P27: \Users\WPNETWORK\APPDATA\Local\dcpsvc\StagingFiles\CssV1_1\*FOLDER_GUID*\*FILENAME_GUID*.csd – which contained a timestamp, Latitude, Longitude and possibly Altitude information stored in a .csd file. We are unsure of the significance of the GUIDs in the directory and file names as they varied between phones. For Device A (with FindMyPhone enabled), there were multiple directories and .csd files with two .csd files containing geolocation information. For Device D (with FindMyPhone enabled), there were multiple directories and .csd files but only one .csd contained geolocation information.
Devices B and C did not store this information potentially indicating that the FindMyPhone functionality was not enabled on those devices. The found XML string looked like:
<MyPhoneOperation> <UpdateLocation> <Location>(2015-12-31 01:23:45Z) -XX.123456,YYY.1234,ZZ.000000</Location> </UpdateLocation> </MyPhoneOperation>
Where XX is latitude and YYY is longitude. ZZ is suspected to be altitude. For Device A, the lat/long listed was about 400m W of the suspected location so the third parameter is probably not accuracy. Note the differences in precision (decimal places) between latitude and longitude. So if your device does contain a FindMyPhone location, the accuracy of the position can vary.
Two configurable FindMyPhone Registry settings are located at:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\LocationSyncEnabled
(which was set to 1 when “Save my phone’s location periodically and before the battery runs out to make it easier to find” is checked. 0 if unchecked (by default)) and
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\MpnEnabled
(which was set to 1 when “Always use push notifications (not SMS) to send commands and apps to my phone” is checked. 0 if unchecked (by default)).
There were also multiple hits for “FindMyPhone” in various GUID named sub-keys under:
P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID1*}
which suggests the regular running of a process/processes to report back the device’s current location. For example, the “Schedule” entry value under the GUID sub-key contains the strings “ProcessFindMyPhoneCommand”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe ProcessFindMyPhoneCommand”. This was also present on a factory fresh install.
There was also a “Schedule” entry under P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID2*} which contained the strings “FMPLastLocationSyncSchedule”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe SyncLocation”. This one was NOT present on a factory fresh install with FindMyPhone disabled.
The default Internet Explorer browser provides some potential geolocation data via cookies, webcache and the “GetLocationUsingFingerprintResponse” browser function. The P26:\Windows\system32\config\SOFTWARE\Microsoft\Internet Explorer\Version registry entry value was set to 11.0.0.0 for all test devices.
The browser also has an “Allow access to my location” setting which should affect how much location information is stored/accessed.
Cookies which contained (URL/percent encoded) textual latitude and longitude information were located in randomly named .txt files in P27: \Users\DefApps\APPDATA\INTERNETEXPLORER\INetCookies. The availability and format will vary depending on the website requesting the user’s location and the device’s Location settings. Using ESEDatabaseview from NirSoft to view the P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\WebCacheV01.dat tables (eg table “Container_21”) can help link a URL to the randomly named cookie file.
URLs with latitude/longitude information were also found in Webcache log files such as P27: \Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\V01tmp.log
For example, a (redacted) GoogleMaps directions URL:
http://maps.googleapis.com/maps/api/directions/json?origin=-XX.1234567891234,YYY.123456789123&waypoints=&destination=-XX.1234,YYY.123&mode=d&units=metric&language=en&sensor=true
Note1: XX = latitude and YYY = longitude.
Note2: Notice the precision (number of decimal places) of the latitude differs from the longitude. Similar entries were also observed in WebcacheV01.dat which makes sense if the .log files are being used as transaction logs for the WebcacheV01.dat ESE database.
The “GetLocationUsingFingerprintResponse” browser function appears to be used by Internet Explorer to submit various values (eg cell tower/WiFi signal strengths) to a web based service. The service then sends back the (estimated) device location. Various hits for “GetLocationUsingFingerprintResponse” with close by Latitude, Longitude, Altitude, ServerUtcTime and RadialUncertainty were found in P27:\pagefile.sys.
For example:
<GetLocationUsingFingerprintResponse xmlns=”http://inference.location.live.com” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”><GetLocationUsingFingerprintResult><ResponseStatus>Success</ResponseStatus><LocationResult><ResolverStatus Status=”Success” Source=”Internal”/><ResolvedPosition Latitude=”-XX.123456″ Longitude=”YYY.123456″ Altitude=”0″/><RadialUncertainty>2246</RadialUncertainty><TileResult/><TrackingId>7e8381e9-106c-45f2-8af9-123456789ABC</TrackingId></LocationResult><ExtendedV21Result CrowdSourcingLevel=”High” ServerUtcTime=”2015-12-31T01:23:45.1234567Z” CollectionType=”Wifi|Cell” InferenceType=”Wifi|Cell”/></GetLocationUsingFingerprintResult></GetLocationUsingFingerprintResponse>
For further information on “GetLocationUsingFingerprintResponse”, see the “Post Script” section in Rudy Huyn’s blog post (in French but Chrome translates it OK-ish).
Also see Chad Tilbury’s (@chadtilbury) series of posts on browser geolocation forensics here.
The Alpha version of Cortana comes installed with the 530. Search for “What does the fox say?” or “Who is Siri?” and prepare to be semi-amused. It appears Cortana requires an active Internet connection so it may not always be enabled by the user if they’re on a cheap pre-paid plan. If not enabled, searches are supposed to use Bing instead. Cortana can be voice activated and location aware so you can set it to remind you “When I get home, remind me to spank the monkey”. Such behaviour (the reminding, not the spanking) means there could be a register of locations which may help prove the user had prior knowledge of a location.
Most of the information in this section was sourced from Brent Muir’s (@bsmuir) recent Windows 10 forensics post here. Not all of the functionality mentioned in that post was applicable to Windows Phone 8.10 but it was still a great resource to have (Thanks to Brent for sharing!).
P27:\Users\WPNETWORK\APPDATA\Local\Graph\WP8LoggedInUser\Me\00000000.ttl
contained various Latitude and Longitude strings (preceded by the string “place.”). According to Brent, these types of file contain searched/favourite locations. Two other data sets had .ttl files but they did not contain any latitude/longitude data. It is likely that the recorded position data is dependent on the main Location setting being ON.
An example 00000000.ttl entry looked like:
p:me/place.-XX.123456_YYY.123456 <http://platform.bing.com/dateAccessed> “1601-01-01T00:00:00.000Z”^^s:Date ;
a s:Place ;
b:preferences/favorites.businessType “” ;
b:preferences/favorites.entityId “-XX.123456_YYY.123456” ;
b:preferences/favorites.entityType “http://schema.org/Place” ;
b:preferences/favorites.entityUrl “local_vdpid:\”-7995539123\”” ;
b:preferences/favorites.isBusiness false ;
b:preferences/favorites.originalName “Some Place Banana-ish” ;
s:ShowOnMap true ;
s:address p:me/postalAddress.-XX.123456_YYY.123456 ;
s:dateModified “2015-12-31T01:23:45.123Z”^^s:Date ;
s:displayCoordinates “Point(-XX.123456 YYY.123456)”^^geo:wktLiteral ;
s:geo “Point(0.000000 0.000000)”^^geo:wktLiteral ;
s:mapZoomLevel 18 ;
s:name “Some Place Banana-ish” ;
s:phone “” .
Note: The “dateAccessed” value above has NOT been modified from the original value.
There were other instances of latitude/longitude recorded in this .ttl file but they did not have a timestamp. For example:
p:me/list.recent. -XX.123456_YYY.123456 a rdf:List ;
rdf:first p:me/place.-XX.123456_YYY.123456 ;
s:displayOrder 25 ;
s:memberOf p:me/geoAnnotationCollection.recent .
which appears to be a recent search location.
Similarly, there were also latitude/longitude pairs observed in P27:/pagefile.sys preceded by “place.”. For example:
<http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456>
It is unknown if/how this example can be correlated to the previous Cortana .ttl examples but they do look similar.
Grammar files are used by speech recognition to define input speech words/phrases. They could also be used to indicate prior knowledge of a location. For more information, refer to the MSDN reference on “Grammars for Windows Phone 8” here.
Location data was found in Device A grammar files located at P27:\SharedData\Speech\Grammars\0809\PointsOfInterestGrammar.cfp.txt and P27:\SharedData\Speech\Grammars\0809\PointsOfInterest2Grammar.cfp.txt
These grammar files did not exist in Device C (factory fresh phone).
The grammar files contained entries like:
“Monkeytown, BananaState”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456”
“home”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456
which was followed by a timestamp in the format:
31/12/2015 1:05:45 PM
This timestamp matched the file system File Created date (in UTC) for the parent .txt file.
Unlike Windows 10 for PC, there was no IndexedDB.edb or CortanaCoreDb.dat (geofence) databases found in our test data. However, this may be due to our test data not being setup with any geofences.
Our device created multimedia’s file location, naming convention and metadata content was consistent with Det. Cindy Murphy et al’s SANS whitepaper on Windows Phone 8. That is, camera created media was found in the phone’s internal memory at P27:\Users\Public\Pictures\Camera Roll.
Additionally, under Device A’s SD Card’s \Pictures\Camera Roll\ directory there were various .mp4 videos whose filename started with WP and a datestamp (eg WP_20150101_001.mp4). Upon further inspection in XWF, there was “Xtra” metadata embedded in each video file which included an ISO timestamp (eg 2015-01-01T01:02:03Z) and location (eg -XX.3456+YYY.4567). This information was also visible using Phil Harvey’s ExifTool.
Also stored under the SD card’s \Pictures\Camera Roll\ were various .jpg files whose filename started with WP and a datestamp (eg WP_20150101_002.jpg). Upon further inspection in XWF, there was “EXIF” metadata embedded in each file which included the Phone model (eg “Lumia 530”), Date Original & Date Digitized timestamps (eg 2015:01:01 01:02:03), Latitude (eg 12° 34’ 5.678” S) and Longitude (eg 123° 45’ 5.678” E).
Photos from a different 530 device (media stored in internal phone memory), had similar EXIF data but did not contain GPS Latitude/Longitude information. This is possibly because the user did not enable the main Location setting and/or they did not enable the “Use Location info” in the “Photos” settings.
The following SOFTWARE hive entry value is suspected of configuring camera pictures/video with embedded location data:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Photos\Shared\CameraSettings\EmbedLocation
This entry value was set to 2 for device multimedia files with embedded GPS metadata and it was set to 1 when the “Photos” … “Use location info” setting was unchecked (no embedded GPS metadata). Presumably, the GPS data in EXIF also requires the main Location setting being enabled.
According to Microsoft, there are two location API libraries that Windows Phone 8.1 developers can use – the .NET Location API (for Windows Phone 7.1 and 8) and the Windows Phone Runtime Location API (new to Windows Phone 8 and 8.1).
The .NET Location API uses the System.Device.dll so whenever you see “System.Device.Location” you know the app was using the .NET Location API. See here for further details.
Alternatively, the MSDN Windows Phone Runtime uses the “Windows.Devices.Geolocation” namespace so if you see that string near latitude/longitude information, the Windows Phone Location API is potentially being used.
Both of these libraries are designed so the app can call a “Get Location” function and let the library calculate a position from the available resources (eg Cell, WiFi, GPS). As the library and results of the call are loaded into RAM, pagefile.sys can also potentially contain these app location artifacts.
The Facebook application comes bundled with the 530. Device A was the only data set that had Facebook user data. Various Facebook related location data was found in
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\LocalState\Log.txt
This file did not exist in Device C (factory fresh) which suggests that Facebook was not used on that device.
Anyway, here’s what the Facebook location data looked like:
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:45: POST: places.setLastLocation?coords{“accuracy”:0.0,”altitude”:0.0,”altitudeAccuracy”:0.0,”heading”:0.0,”latitude”:-XX.12345,”longitude”:YYY.12345,”speed”:0.0}
[Type: Navigation] [Severity: Low] 2015-12-31T01:23:45: Navigated to: Facebook.Views.Places
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:48: MULTIQUERY GET: Places:SELECT page_id, name, description, latitude, longitude, checkin_count, display_subtext, pic_square, distance(latitude, longitude, “-XX.12345”, “YYY.12345”) FROM place WHERE distance(latitude, longitude, “-XX.12345”, “YYY.12345”) < 750 LIMIT 25|Pages:SELECT page_id, name, fan_count, were_here_count, location FROM page WHERE page_id IN (SELECT page_id from #Places)
A potential Facebook “Last login” location was also found at:
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat and P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat.LOG1
Both setting files contained a string similar to:
“AllowLocationAccess”:true,”CacheExpirationInMinutes”:10,”ConfirmExit”:true,”CurrentUserName”:”Randy Monkey”,”CurrentUserProfilePicUri”:”https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xfa1/v/t1.0-1/p200x200/12345678_123456789ABCDEF12_123456789ABCDEF1234_n.jpg?oh=9b1356725bdbc1f30cb193068343123&oe=564DE360&__gda__=1438678992_c2802dc1e45c7998ca39c6f5dcf67484″,”GetHereNowEnabled”:true,”IsVerfified”:false,”HasLoggedIn”:true,”LastLatitude”:-XX.123456789012345,”LastLocationDate”:”\/Date(1430562061234)\/”,”LastLongitude”:YYY.12345678901234,”LockScreenState”:1,
For Device A, it also appears that the Windows Store app “GPS Voice Navigation” was installed, run and then uninstalled. There were location artifacts left in P27:\pagefile.sys such as:
app://8E116909-CF87-4176-894F-F54434EFB01E/_default#/Protocol?encodedLaunchUri=ms-drive-to%3A%3Fdestination.latitude%3D-XX.12345%26destination.longitude%3DYYY.123456%26destination.name%3DMonkey%2520Central%2520Headquarters
The GUID 8E116909-CF87-4176-894F-F54434EFB01E listed above is an alias for the GPS Voice Navigation app. This can be confirmed by visiting:
windowsphone.com/s?appId=8E116909-CF87-4176-894F-F54434EFB01E
Searching for “ms-drive-to” (as above) and “ms-walk-to” keywords can lead to further location data. According to this, these keywords can be used by an app to request walking/driving directions. So while it may not confirm a device’s actual location, it can prove a user looked up directions from/to specific places.
For the “GPS Voice Navigation” app, various location data was found with references to the System.Device.Location namespace. As mentioned previously, this is a .NET Framework library for calculating location via GPS, WiFi, Cell Tower triangulation. Any location strings found near a “System.Device.Location” string could be potential device locations.
So in P27:\pagefile.sys, we found:
<Latitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>-XX.1234</Latitude><Longitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>YYY.123</Longitude> <Speed xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>NaN</Speed>
Also found in Device A P27:\pagefile.sys was this more comprehensive gem:
<KeyValueOfstringanyType><Key>CurrentPosition</Key><Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/System.Device.Location” i:type=”d3p1:GeoPositionOfGeoCoordinate8rbsckdZ”><d3p1:Location><d3p1:Altitude>45</d3p1:Altitude><d3p1:Course>188.3</d3p1:Course><d3p1:HorizontalAccuracy>3</d3p1:HorizontalAccuracy><d3p1:Latitude>-XX.123456789012345</d3p1:Latitude><d3p1:Longitude>YYY.1234567890123</d3p1:Longitude><d3p1:Speed>3.72</d3p1:Speed><d3p1:VerticalAccuracy>3</d3p1:VerticalAccuracy></d3p1:Location><d3p1:Timestamp xmlns:d4p1=”http://schemas.datacontract.org/2004/07/System”><d4p1:DateTime>2015-12-31T01:23:45.1234567Z</d4p1:DateTime><d4p1:OffsetMinutes>600</d4p1:OffsetMinutes></d3p1:Timestamp></Value></KeyValueOfstringanyType>
As this only appeared in Device A, it is probably related to the “GPS Voice Navigation” app. This is potentially confirmed by nearby XML elements such as:
<Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/GPS_VN_BL_WP8″ i:type=”d3p1:Locales”>English</Value>
Also observed in Device A P27:/pagefile.sys, was an “EndLocation” keyword used by the “GPS Voice Navigation” app which showed the destination address details. So searching for that keyword could also reveal destinations entered into the app.
A basic app permission analysis was also performed on selected devices using the WP8_AppPerms.py script (see this previous post).
In Device A, There were 7 applications which required the ID_CAP_LOCATION capability (which provides access to device location):
WhatsApp
Facebook Messenger
*Facebook
*Skype
*XBox Video
*LumiaHelpTips_4?
*Nokia Music WP8 client
The apps that we preceded with an asterisk seem to be default apps that are pre-installed with the phone. Notice how even chat apps can require access to the device location. For example, Skype allows the user to “share location” from a chat. Similarly, WhatsApp can also send its location (as an attachment) in a chat.
Other permissions which a location aware app might need include:
ID_CAP_NETWORKING which would be required for accessing network services that can provide location information (eg “GetLocationUsingFingerprintResponse” data for Internet Explorer location queries).
ID_CAP_MAP which allows an app to display a map.
ID_CAP_CELL_API_LOCATION which seems to allow for/help location via Cellular position information.
ID_CAP_SENSORS which provides access to the phone’s accelerometer, compass, gyroscope.
According to XWF, Device A’s “Free space” (unallocated space) contained some UTF16-LE lat/long hits and a timestamp close to a “LastFoundAt” (ASCII) string.
For example, in close proximity to:
“lat=-XX.123456###long=YYY.123456###time=22/12/2015 01:23:45”
was an “hbin” string and a “LastFoundAt” string. The “hbin” signature suggests that the surrounding data belongs to a registry hive cell. Searching the P26:\Windows\system32\config\SOFTWARE hive resulted in a hit at \OEM\Nokia\NokiaAccessories\Devices\*FF:FF:FF:FF:FF:FF* (Hex string has been redacted) which contained an entry for “LastFoundAt” equal to the lat/long/time string observed.
However, this subkey did not exist in all test devices so this registry value may not always be available for providing a position.
P26:\Windows\system32\config\SOFTWARE\Microsoft\BingSuggests can have PreviousLatitude, PreviousLongitude entry values along with QueryAttemptTime, SuccessfulQueryTime and CacheUpdateTime entry values. It is unclear what the significance is of the Position information relative to Bing. Times appear to be LE 64 bit Number of 100 ns since 1 JAN 1601. The CacheUpdateTime was slightly later than the QueryAttemptTime (which equalled the SuccessfulQueryTime). The Registry Key’s “LastWrittenTime” occured AFTER the various timestamp values. The Timestamp values were zeroes for a new phone.
While squirrel chasing through the data, we noticed a few non-location related but interesting nuggets … (as if this post wasn’t already long enough!)
P27: \SharedData\Store\PurchaseHistory.xml
contains the purchased App GUID, the app name and the purchase date. If entering the app GUID to the “windowsphone.com/s?appId=” URL does not reveal the app name, try checking this file.
Calendar Reminders are stored in P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*} entry values. For example, SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*}
could contain a “Schedule” entry with value string containing the strings: “Reminder”, “Monkey’s New Year” and “All day event 01/01/2015”.
As mentioned by Brent Muir, notification messages are archived in a .dat file. For our test devices, this appears to be located at:
P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\Notifications\appdb.dat
This file was 24 MB in size but sparsely populated.
An example data string from the file looks something like:
<toast launch=”app://5B04B775-356B-4AA0-AAF8-6491FFEA5610/Chat?EntryId=00000000213E0000060000000700000000000000&MessageId=000000004A4E0000020000000800000000000001″><visual><binding template=”ToastText02″><text id=”1″>Voicemail Access</text><text id=”2″>Pls call 321, You have 5 New VoiceMail messages</text></binding></visual><audio src=”ms-winsoundevent:legacy-notification.sms”/><backgroundColor>#0</backgroundColor></toast>
Unlike Windows 10 for PC, there was no “TimestampWhenSeen” stored in P26:\Windows\system32\config\SOFTWARE (ie when Notification Center was viewed).
Thanks to Boss Rob for patiently helping/waiting for this monkey to obtain/analyse the various phone dumps and allowing us to share our findings with the forensic community.
There is lot of potential geolocation data stored on a Windows Phone 8.10 device but it will depend on the main Location setting being ON and in certain situations, on the app’s required capabilities.
The P27:/pagefile.sys is probably the best place to look for textually encoded latitude/longitude data. However, Internet Explorer cache, app logs, device camera picture/video files and the Registry can also store location data.
It is suspected that other Windows Phone 8.1 makes/models will contain the same geolocation artifacts but this should be tested/verified by the analyst.
For future testing purposes, it is noteworthy that the 530 can be upgraded to Windows 10 for Mobile devices (whenever it officially comes out, under whatever name they decide on).
If you would like to share your thoughts/suggestions or any geolocation artifacts, please leave a comment.
|
| Monkey, just keep swimming through the WinPhone data … ya clown! |
UPDATE 6OCT2015: Edited FindMyPhone and Multimedia sections + added suspected main Location setting Registry location.
A couple of recent cases had this monkey investigating how Windows Phone 8.10 stores geolocation data on a Nokia Lumia 530.
There does not appear much forensic documentation regarding this, so this post is going to be a pretty voluminous / potentially narcoleptic episode of squirrel chasing (without any neat scripts to run at the end either). Despite the length of this post, monkey gets the sneaking suspicion that there is more to be discovered. I guess we have to start somewhere …
Carrier-locked versions of the 530 can be picked up for as little as $50 in Monkeytown so they could be more popular than you’d initially suspect. They also come bundled with Windows Phone 8.10 by default.
Downloading of the 4 GB capacity devices was done via eMMC read using the Z3X-Pro flasher box and took approximately 90 minutes per device. Note: The soldering points for these are not for the banana fisted. The points are so tiny that this monkey needed his big boy soldering pants AND special adult assistance (Thanks Boss Rob!).
For the 530, there are 3 potential storage areas for geolocation data – the Partition 26 (P26) “MainOS” NTFS partition, the Partition 27 (P27) “Data” NTFS partition and the removable SD Card.
The test data came from 2 well used 530 devices (Devices A and B), a factory fresh 530 (Device C) and a simulated test device (Device D). While all four were 8.10 (MajorVersion.MinorVersion) devices, their SYSTEM hive’s \Versions\BuildNumber values were not all the same (probably due to being configured for different service providers).
An X-Ways Forensics (XWF) “simultaneous search” for likely geolocation keywords was initially performed (eg “latitude”, “lat”, “GPS”, “GNSS”, “degree”). Subsequently, a regex search was also performed using some likely latitude regular expressions (eg1 “-1[2-5].” for “-12.” to “-15.”. eg2 “-1[2-5]°” for “-12°” to “-15°”).
Tip: To type the degree symbol, you hold down the Alt key as you type 248 on the numeric keypad (with numlock ON).
For accuracy purposes, it might also help to know that 1 nautical mile (approximately 1852 m) is 1 minute of a degree (there are 60 minutes to a degree).
Thanks to a Brian Moran (@brianjmoran) tip, we found some information on commonly used latitude/longitude formats here.
To simplify the number of searches, it was also assumed that any textual latitudes will have the corresponding longitude close by. Ideally, there will also be an associated timestamp so we can say that at a certain time, the device was at location X. The XWF regex search technique should find any plain text (UTF8, UTF16-LE) strings which contain relevant latitude information. However, it will not find any latitudes stored as binary data (ie floats/doubles).
The main Location setting (for this phone model) is suspected to be at:
P26:\Windows\system32\config\SOFTWARE\OEM\Nokia\GPS\LocationService which was set to 1 when the main Location setting was enabled and set to 0 when disabled. We’re not sure if this is the direct cause or a secondary result of the Location setting. Presumably, this location will vary with non-Nokia devices.
The proliferation of web based location/map services and the availability/storage capacity of P27:/pagefile.sys (which contains the swapped out contents of RAM) has resulted in a large number of readable lat/long pairs. Connecting a lat/long pair to specific phone functionality and/or proving a user’s direct knowledge was/remains a challenge.
To assist with this we have organized the lat/long information in this post into the following categories:
– ObservationLogWP8 (crowd sourced location logs)
– FindMyPhone (location tracking of device)
– Default Internet Explorer Browser
– Cortana (personal assistant)
– Multimedia metadata (from device pictures/video)
– WP8 Application data
– Registry
This appears to be related to Microsoft’s crowd-sourcing efforts to survey/report WiFi and cell tower information for device location (see here and here). Various UTF8 and UTF16-LE encoded XML fields belonging to a parent “ObservationLogWP8” XML element were found in Device A’s P27:/pagefile.sys. These fields included a timestamp, location, WiFi and Cell Tower signal information. Not all instances of these had latitude/longitude information, some only had timestamped WiFi and cell information (they may have been related to requests for location).
The string “ObservationLogWP8” was also found in a LocationCrowdsource.dll. The LocationCrowdsource.dll also existed in a Nokia 520 running Windows Phone 8.0 suggesting this functionality is not new to Windows Phone 8.10.
From the dates found in test data, it is suspected the initial phone setup is one event that triggers this data being recorded. According to the FAQ mentioned previously, enabled apps can also request the device location which could result in ObservationLogWP8 data being generated.
One of the more complete “ObservationLogWP8” XML elements (from P27:\pagefile.sys) looked like:
<Env Version=”1.0″><Body Type=”ObservationLogWP8″><LocationData><RequestHeader><Timestamp>2015-12-31T01:23:45.678+12:34</Timestamp><Authorization /><TrackingId>378130cb-e97f-4558-a3ac-123456789ABC </TrackingId><ApplicationId>d002970e-345b-409f-9e22-b360eb83f641</ApplicationId><DeviceProfile ExtendedDeviceInfo=”NOKIA/Lumia 530″ OSVersion=”8.10.14234.WPB_CXE_R1(wpbldlab).20150123-1722″ LFVersion=”2.0″ Platform=”” ClientGuid=”00000000-0000-0000-0000-000000000000″ DeviceType=”WP8″ DeviceId=”d002970e-345b-409f-9e22-123456789ABC” /></RequestHeader><LocationStamps><LocationStamp ts=”2015-12-31T01:23:45.678+12:34″><Loc la=”-XX.12345″ lo=”YYY.12345″ al=”12.00000″ spd=”5.25000″ hed=”180.50000″ hacc=”3″ hdop=”0.80000″ vdop=”0.80000″ herralong=”2″ haxis=”2″ /><CellTowers ts=”2015-12-31T01:23:45.678+12:34″><Umts7 mcc=”505″ mnc=”1″ lac=”12345″ ucid=”123456789″ uarfcn=”1234″ psc=”12″ rscp=”-100″ ecno=”-11″ /></CellTowers><WifiPoints ts=”2015-12-31T01:23:45.678+12:34″><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-86″ /><Wifi7 bssid=”AA:BB:CC:11:22:33″ rssi=”-95″ /> /></WifiPoints></LocationStamp></LocationStamps></LocationData></Body></Env>
Note1: The mcc = country id and mnc = carrier id.
Note2: Note the ApplicationId GUID field in the data which could potentially connect an app to this location data.
For privacy reasons, the above example had the following information modified:
– Timestamps
– Various GUIDs (except ApplicationId and ClientGuid)
– bssid (MAC address of WiFi access points)
– CellTowers
– Location/Movement information
If the main Location setting is OFF, ObservationLogWP8 data should not be written (in theory). This was possibly observed when we found that some devices contained hits for “ObservationLogWP8” in LocationCrowdsource.dll but no ObservationLogWP8 XML elements. Also, if an individual application does not have it’s Location capability enabled, the ObservationLogWP8 data should not be present for that app.
From the Microsoft “Personal Wi-Fi Access Point Opt-Out” section here:
“If you have a Wi-Fi access point or router and you wish to exclude it from Microsoft’s location positioning database … you can submit the MAC address to Microsoft’s block list”
This means by default (with a Location enabled device), the device gets to snoop around and map any/all WiFi access points it can. So you’d expect to see more of these ObservationLogWP8 XML instances, the longer a phone is used (assuming the phone moves around).
Windows Phone 8.10 has the capability to ring/lock/erase/locate a registered device from this website. This capability is not enabled by default and requires the user register their device and phone number with their Microsoft account. The FindMyPhone settings menu has a checkbox for “Save my phone’s location periodically and before the battery runs out to make it easier to find”. This is OFF by default. According to the (March 2014) Windows Phone 8 Privacy Statement:
“the location of your phone will be sent periodically to your online account at the My Windows Phone page”. It “only stores the last known location of your phone. When a new location is sent, it replaces the previously stored location”.
There were various FindMyPhone P26:\Windows\system32\config\SOFTWARE registry entries, FindMyPhone DLL libraries and a FindMyPhone executable present in our devices. The FindMyPhoneRuntimeDll.dll contains what appears to be a print format string for a “MyPhoneOperation” data element. Searching for “MyPhoneOperation” returned hits in Device A at
P27: \Users\WPNETWORK\APPDATA\Local\dcpsvc\StagingFiles\CssV1_1\*FOLDER_GUID*\*FILENAME_GUID*.csd – which contained a timestamp, Latitude, Longitude and possibly Altitude information stored in a .csd file. We are unsure of the significance of the GUIDs in the directory and file names as they varied between phones. For Device A (with FindMyPhone enabled), there were multiple directories and .csd files with two .csd files containing geolocation information. For Device D (with FindMyPhone enabled), there were multiple directories and .csd files but only one .csd contained geolocation information.
Devices B and C did not store this information potentially indicating that the FindMyPhone functionality was not enabled on those devices. The found XML string looked like:
<MyPhoneOperation> <UpdateLocation> <Location>(2015-12-31 01:23:45Z) -XX.123456,YYY.1234,ZZ.000000</Location> </UpdateLocation> </MyPhoneOperation>
Where XX is latitude and YYY is longitude. ZZ is suspected to be altitude. For Device A, the lat/long listed was about 400m W of the suspected location so the third parameter is probably not accuracy. Note the differences in precision (decimal places) between latitude and longitude. So if your device does contain a FindMyPhone location, the accuracy of the position can vary.
Two configurable FindMyPhone Registry settings are located at:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\LocationSyncEnabled
(which was set to 1 when “Save my phone’s location periodically and before the battery runs out to make it easier to find” is checked. 0 if unchecked (by default)) and
P26:\Windows\system32\config\SOFTWARE\Microsoft\Settings\FindMyPhone\MpnEnabled
(which was set to 1 when “Always use push notifications (not SMS) to send commands and apps to my phone” is checked. 0 if unchecked (by default)).
There were also multiple hits for “FindMyPhone” in various GUID named sub-keys under:
P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID1*}
which suggests the regular running of a process/processes to report back the device’s current location. For example, the “Schedule” entry value under the GUID sub-key contains the strings “ProcessFindMyPhoneCommand”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe ProcessFindMyPhoneCommand”. This was also present on a factory fresh install.
There was also a “Schedule” entry under P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID2*} which contained the strings “FMPLastLocationSyncSchedule”, “c:\Programs\FindMyPhone\ShellCommandDispatcher.exe SyncLocation”. This one was NOT present on a factory fresh install with FindMyPhone disabled.
The default Internet Explorer browser provides some potential geolocation data via cookies, webcache and the “GetLocationUsingFingerprintResponse” browser function. The P26:\Windows\system32\config\SOFTWARE\Microsoft\Internet Explorer\Version registry entry value was set to 11.0.0.0 for all test devices.
The browser also has an “Allow access to my location” setting which should affect how much location information is stored/accessed.
Cookies which contained (URL/percent encoded) textual latitude and longitude information were located in randomly named .txt files in P27: \Users\DefApps\APPDATA\INTERNETEXPLORER\INetCookies. The availability and format will vary depending on the website requesting the user’s location and the device’s Location settings. Using ESEDatabaseview from NirSoft to view the P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\WebCacheV01.dat tables (eg table “Container_21”) can help link a URL to the randomly named cookie file.
URLs with latitude/longitude information were also found in Webcache log files such as P27: \Users\DefApps\APPDATA\Local\Microsoft\Windows\WebCache\V01tmp.log
For example, a (redacted) GoogleMaps directions URL:
http://maps.googleapis.com/maps/api/directions/json?origin=-XX.1234567891234,YYY.123456789123&waypoints=&destination=-XX.1234,YYY.123&mode=d&units=metric&language=en&sensor=true
Note1: XX = latitude and YYY = longitude.
Note2: Notice the precision (number of decimal places) of the latitude differs from the longitude. Similar entries were also observed in WebcacheV01.dat which makes sense if the .log files are being used as transaction logs for the WebcacheV01.dat ESE database.
The “GetLocationUsingFingerprintResponse” browser function appears to be used by Internet Explorer to submit various values (eg cell tower/WiFi signal strengths) to a web based service. The service then sends back the (estimated) device location. Various hits for “GetLocationUsingFingerprintResponse” with close by Latitude, Longitude, Altitude, ServerUtcTime and RadialUncertainty were found in P27:\pagefile.sys.
For example:
<GetLocationUsingFingerprintResponse xmlns=”http://inference.location.live.com” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”><GetLocationUsingFingerprintResult><ResponseStatus>Success</ResponseStatus><LocationResult><ResolverStatus Status=”Success” Source=”Internal”/><ResolvedPosition Latitude=”-XX.123456″ Longitude=”YYY.123456″ Altitude=”0″/><RadialUncertainty>2246</RadialUncertainty><TileResult/><TrackingId>7e8381e9-106c-45f2-8af9-123456789ABC</TrackingId></LocationResult><ExtendedV21Result CrowdSourcingLevel=”High” ServerUtcTime=”2015-12-31T01:23:45.1234567Z” CollectionType=”Wifi|Cell” InferenceType=”Wifi|Cell”/></GetLocationUsingFingerprintResult></GetLocationUsingFingerprintResponse>
For further information on “GetLocationUsingFingerprintResponse”, see the “Post Script” section in Rudy Huyn’s blog post (in French but Chrome translates it OK-ish).
Also see Chad Tilbury’s (@chadtilbury) series of posts on browser geolocation forensics here.
The Alpha version of Cortana comes installed with the 530. Search for “What does the fox say?” or “Who is Siri?” and prepare to be semi-amused. It appears Cortana requires an active Internet connection so it may not always be enabled by the user if they’re on a cheap pre-paid plan. If not enabled, searches are supposed to use Bing instead. Cortana can be voice activated and location aware so you can set it to remind you “When I get home, remind me to spank the monkey”. Such behaviour (the reminding, not the spanking) means there could be a register of locations which may help prove the user had prior knowledge of a location.
Most of the information in this section was sourced from Brent Muir’s (@bsmuir) recent Windows 10 forensics post here. Not all of the functionality mentioned in that post was applicable to Windows Phone 8.10 but it was still a great resource to have (Thanks to Brent for sharing!).
P27:\Users\WPNETWORK\APPDATA\Local\Graph\WP8LoggedInUser\Me\00000000.ttl
contained various Latitude and Longitude strings (preceded by the string “place.”). According to Brent, these types of file contain searched/favourite locations. Two other data sets had .ttl files but they did not contain any latitude/longitude data. It is likely that the recorded position data is dependent on the main Location setting being ON.
An example 00000000.ttl entry looked like:
p:me/place.-XX.123456_YYY.123456 <http://platform.bing.com/dateAccessed> “1601-01-01T00:00:00.000Z”^^s:Date ;
a s:Place ;
b:preferences/favorites.businessType “” ;
b:preferences/favorites.entityId “-XX.123456_YYY.123456” ;
b:preferences/favorites.entityType “http://schema.org/Place” ;
b:preferences/favorites.entityUrl “local_vdpid:\”-7995539123\”” ;
b:preferences/favorites.isBusiness false ;
b:preferences/favorites.originalName “Some Place Banana-ish” ;
s:ShowOnMap true ;
s:address p:me/postalAddress.-XX.123456_YYY.123456 ;
s:dateModified “2015-12-31T01:23:45.123Z”^^s:Date ;
s:displayCoordinates “Point(-XX.123456 YYY.123456)”^^geo:wktLiteral ;
s:geo “Point(0.000000 0.000000)”^^geo:wktLiteral ;
s:mapZoomLevel 18 ;
s:name “Some Place Banana-ish” ;
s:phone “” .
Note: The “dateAccessed” value above has NOT been modified from the original value.
There were other instances of latitude/longitude recorded in this .ttl file but they did not have a timestamp. For example:
p:me/list.recent. -XX.123456_YYY.123456 a rdf:List ;
rdf:first p:me/place.-XX.123456_YYY.123456 ;
s:displayOrder 25 ;
s:memberOf p:me/geoAnnotationCollection.recent .
which appears to be a recent search location.
Similarly, there were also latitude/longitude pairs observed in P27:/pagefile.sys preceded by “place.”. For example:
<http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456>
It is unknown if/how this example can be correlated to the previous Cortana .ttl examples but they do look similar.
Grammar files are used by speech recognition to define input speech words/phrases. They could also be used to indicate prior knowledge of a location. For more information, refer to the MSDN reference on “Grammars for Windows Phone 8” here.
Location data was found in Device A grammar files located at P27:\SharedData\Speech\Grammars\0809\PointsOfInterestGrammar.cfp.txt and P27:\SharedData\Speech\Grammars\0809\PointsOfInterest2Grammar.cfp.txt
These grammar files did not exist in Device C (factory fresh phone).
The grammar files contained entries like:
“Monkeytown, BananaState”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456”
“home”:, http://platform.bing.com/persons/me/place. -XX.123456 YYY.123456
which was followed by a timestamp in the format:
31/12/2015 1:05:45 PM
This timestamp matched the file system File Created date (in UTC) for the parent .txt file.
Unlike Windows 10 for PC, there was no IndexedDB.edb or CortanaCoreDb.dat (geofence) databases found in our test data. However, this may be due to our test data not being setup with any geofences.
Our device created multimedia’s file location, naming convention and metadata content was consistent with Det. Cindy Murphy et al’s SANS whitepaper on Windows Phone 8. That is, camera created media was found in the phone’s internal memory at P27:\Users\Public\Pictures\Camera Roll.
Additionally, under Device A’s SD Card’s \Pictures\Camera Roll\ directory there were various .mp4 videos whose filename started with WP and a datestamp (eg WP_20150101_001.mp4). Upon further inspection in XWF, there was “Xtra” metadata embedded in each video file which included an ISO timestamp (eg 2015-01-01T01:02:03Z) and location (eg -XX.3456+YYY.4567). This information was also visible using Phil Harvey’s ExifTool.
Also stored under the SD card’s \Pictures\Camera Roll\ were various .jpg files whose filename started with WP and a datestamp (eg WP_20150101_002.jpg). Upon further inspection in XWF, there was “EXIF” metadata embedded in each file which included the Phone model (eg “Lumia 530”), Date Original & Date Digitized timestamps (eg 2015:01:01 01:02:03), Latitude (eg 12° 34’ 5.678” S) and Longitude (eg 123° 45’ 5.678” E).
Photos from a different 530 device (media stored in internal phone memory), had similar EXIF data but did not contain GPS Latitude/Longitude information. This is possibly because the user did not enable the main Location setting and/or they did not enable the “Use Location info” in the “Photos” settings.
The following SOFTWARE hive entry value is suspected of configuring camera pictures/video with embedded location data:
P26:\Windows\system32\config\SOFTWARE\Microsoft\Photos\Shared\CameraSettings\EmbedLocation
This entry value was set to 2 for device multimedia files with embedded GPS metadata and it was set to 1 when the “Photos” … “Use location info” setting was unchecked (no embedded GPS metadata). Presumably, the GPS data in EXIF also requires the main Location setting being enabled.
According to Microsoft, there are two location API libraries that Windows Phone 8.1 developers can use – the .NET Location API (for Windows Phone 7.1 and 8) and the Windows Phone Runtime Location API (new to Windows Phone 8 and 8.1).
The .NET Location API uses the System.Device.dll so whenever you see “System.Device.Location” you know the app was using the .NET Location API. See here for further details.
Alternatively, the MSDN Windows Phone Runtime uses the “Windows.Devices.Geolocation” namespace so if you see that string near latitude/longitude information, the Windows Phone Location API is potentially being used.
Both of these libraries are designed so the app can call a “Get Location” function and let the library calculate a position from the available resources (eg Cell, WiFi, GPS). As the library and results of the call are loaded into RAM, pagefile.sys can also potentially contain these app location artifacts.
The Facebook application comes bundled with the 530. Device A was the only data set that had Facebook user data. Various Facebook related location data was found in
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\LocalState\Log.txt
This file did not exist in Device C (factory fresh) which suggests that Facebook was not used on that device.
Anyway, here’s what the Facebook location data looked like:
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:45: POST: places.setLastLocation?coords{“accuracy”:0.0,”altitude”:0.0,”altitudeAccuracy”:0.0,”heading”:0.0,”latitude”:-XX.12345,”longitude”:YYY.12345,”speed”:0.0}
[Type: Navigation] [Severity: Low] 2015-12-31T01:23:45: Navigated to: Facebook.Views.Places
[Type: Miscellaneous] [Severity: Unspecified] 2015-12-31T01:23:48: MULTIQUERY GET: Places:SELECT page_id, name, description, latitude, longitude, checkin_count, display_subtext, pic_square, distance(latitude, longitude, “-XX.12345”, “YYY.12345”) FROM place WHERE distance(latitude, longitude, “-XX.12345”, “YYY.12345”) < 750 LIMIT 25|Pages:SELECT page_id, name, fan_count, were_here_count, location FROM page WHERE page_id IN (SELECT page_id from #Places)
A potential Facebook “Last login” location was also found at:
P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat and P27:\Users\DefApps\APPDATA\Local\Packages\Microsoft.MSFacebook_8wekyb3d8bbwe\Settings\settings.dat.LOG1
Both setting files contained a string similar to:
“AllowLocationAccess”:true,”CacheExpirationInMinutes”:10,”ConfirmExit”:true,”CurrentUserName”:”Randy Monkey”,”CurrentUserProfilePicUri”:”https://fbcdn-profile-a.akamaihd.net/hprofile-ak-xfa1/v/t1.0-1/p200x200/12345678_123456789ABCDEF12_123456789ABCDEF1234_n.jpg?oh=9b1356725bdbc1f30cb193068343123&oe=564DE360&__gda__=1438678992_c2802dc1e45c7998ca39c6f5dcf67484″,”GetHereNowEnabled”:true,”IsVerfified”:false,”HasLoggedIn”:true,”LastLatitude”:-XX.123456789012345,”LastLocationDate”:”\/Date(1430562061234)\/”,”LastLongitude”:YYY.12345678901234,”LockScreenState”:1,
For Device A, it also appears that the Windows Store app “GPS Voice Navigation” was installed, run and then uninstalled. There were location artifacts left in P27:\pagefile.sys such as:
app://8E116909-CF87-4176-894F-F54434EFB01E/_default#/Protocol?encodedLaunchUri=ms-drive-to%3A%3Fdestination.latitude%3D-XX.12345%26destination.longitude%3DYYY.123456%26destination.name%3DMonkey%2520Central%2520Headquarters
The GUID 8E116909-CF87-4176-894F-F54434EFB01E listed above is an alias for the GPS Voice Navigation app. This can be confirmed by visiting:
windowsphone.com/s?appId=8E116909-CF87-4176-894F-F54434EFB01E
Searching for “ms-drive-to” (as above) and “ms-walk-to” keywords can lead to further location data. According to this, these keywords can be used by an app to request walking/driving directions. So while it may not confirm a device’s actual location, it can prove a user looked up directions from/to specific places.
For the “GPS Voice Navigation” app, various location data was found with references to the System.Device.Location namespace. As mentioned previously, this is a .NET Framework library for calculating location via GPS, WiFi, Cell Tower triangulation. Any location strings found near a “System.Device.Location” string could be potential device locations.
So in P27:\pagefile.sys, we found:
<Latitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>-XX.1234</Latitude><Longitude xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>YYY.123</Longitude> <Speed xmlns=”http://schemas.datacontract.org/2004/07/System.Device.Location”>NaN</Speed>
Also found in Device A P27:\pagefile.sys was this more comprehensive gem:
<KeyValueOfstringanyType><Key>CurrentPosition</Key><Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/System.Device.Location” i:type=”d3p1:GeoPositionOfGeoCoordinate8rbsckdZ”><d3p1:Location><d3p1:Altitude>45</d3p1:Altitude><d3p1:Course>188.3</d3p1:Course><d3p1:HorizontalAccuracy>3</d3p1:HorizontalAccuracy><d3p1:Latitude>-XX.123456789012345</d3p1:Latitude><d3p1:Longitude>YYY.1234567890123</d3p1:Longitude><d3p1:Speed>3.72</d3p1:Speed><d3p1:VerticalAccuracy>3</d3p1:VerticalAccuracy></d3p1:Location><d3p1:Timestamp xmlns:d4p1=”http://schemas.datacontract.org/2004/07/System”><d4p1:DateTime>2015-12-31T01:23:45.1234567Z</d4p1:DateTime><d4p1:OffsetMinutes>600</d4p1:OffsetMinutes></d3p1:Timestamp></Value></KeyValueOfstringanyType>
As this only appeared in Device A, it is probably related to the “GPS Voice Navigation” app. This is potentially confirmed by nearby XML elements such as:
<Value xmlns:d3p1=”http://schemas.datacontract.org/2004/07/GPS_VN_BL_WP8″ i:type=”d3p1:Locales”>English</Value>
Also observed in Device A P27:/pagefile.sys, was an “EndLocation” keyword used by the “GPS Voice Navigation” app which showed the destination address details. So searching for that keyword could also reveal destinations entered into the app.
A basic app permission analysis was also performed on selected devices using the WP8_AppPerms.py script (see this previous post).
In Device A, There were 7 applications which required the ID_CAP_LOCATION capability (which provides access to device location):
WhatsApp
Facebook Messenger
*Facebook
*Skype
*XBox Video
*LumiaHelpTips_4?
*Nokia Music WP8 client
The apps that we preceded with an asterisk seem to be default apps that are pre-installed with the phone. Notice how even chat apps can require access to the device location. For example, Skype allows the user to “share location” from a chat. Similarly, WhatsApp can also send its location (as an attachment) in a chat.
Other permissions which a location aware app might need include:
ID_CAP_NETWORKING which would be required for accessing network services that can provide location information (eg “GetLocationUsingFingerprintResponse” data for Internet Explorer location queries).
ID_CAP_MAP which allows an app to display a map.
ID_CAP_CELL_API_LOCATION which seems to allow for/help location via Cellular position information.
ID_CAP_SENSORS which provides access to the phone’s accelerometer, compass, gyroscope.
According to XWF, Device A’s “Free space” (unallocated space) contained some UTF16-LE lat/long hits and a timestamp close to a “LastFoundAt” (ASCII) string.
For example, in close proximity to:
“lat=-XX.123456###long=YYY.123456###time=22/12/2015 01:23:45”
was an “hbin” string and a “LastFoundAt” string. The “hbin” signature suggests that the surrounding data belongs to a registry hive cell. Searching the P26:\Windows\system32\config\SOFTWARE hive resulted in a hit at \OEM\Nokia\NokiaAccessories\Devices\*FF:FF:FF:FF:FF:FF* (Hex string has been redacted) which contained an entry for “LastFoundAt” equal to the lat/long/time string observed.
However, this subkey did not exist in all test devices so this registry value may not always be available for providing a position.
P26:\Windows\system32\config\SOFTWARE\Microsoft\BingSuggests can have PreviousLatitude, PreviousLongitude entry values along with QueryAttemptTime, SuccessfulQueryTime and CacheUpdateTime entry values. It is unclear what the significance is of the Position information relative to Bing. Times appear to be LE 64 bit Number of 100 ns since 1 JAN 1601. The CacheUpdateTime was slightly later than the QueryAttemptTime (which equalled the SuccessfulQueryTime). The Registry Key’s “LastWrittenTime” occured AFTER the various timestamp values. The Timestamp values were zeroes for a new phone.
While squirrel chasing through the data, we noticed a few non-location related but interesting nuggets … (as if this post wasn’t already long enough!)
P27: \SharedData\Store\PurchaseHistory.xml
contains the purchased App GUID, the app name and the purchase date. If entering the app GUID to the “windowsphone.com/s?appId=” URL does not reveal the app name, try checking this file.
Calendar Reminders are stored in P26:\Windows\system32\config\SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*} entry values. For example, SOFTWARE\Microsoft\WPTaskScheduler\{*GUID*}
could contain a “Schedule” entry with value string containing the strings: “Reminder”, “Monkey’s New Year” and “All day event 01/01/2015”.
As mentioned by Brent Muir, notification messages are archived in a .dat file. For our test devices, this appears to be located at:
P27:\Users\DefApps\APPDATA\Local\Microsoft\Windows\Notifications\appdb.dat
This file was 24 MB in size but sparsely populated.
An example data string from the file looks something like:
<toast launch=”app://5B04B775-356B-4AA0-AAF8-6491FFEA5610/Chat?EntryId=00000000213E0000060000000700000000000000&MessageId=000000004A4E0000020000000800000000000001″><visual><binding template=”ToastText02″><text id=”1″>Voicemail Access</text><text id=”2″>Pls call 321, You have 5 New VoiceMail messages</text></binding></visual><audio src=”ms-winsoundevent:legacy-notification.sms”/><backgroundColor>#0</backgroundColor></toast>
Unlike Windows 10 for PC, there was no “TimestampWhenSeen” stored in P26:\Windows\system32\config\SOFTWARE (ie when Notification Center was viewed).
Thanks to Boss Rob for patiently helping/waiting for this monkey to obtain/analyse the various phone dumps and allowing us to share our findings with the forensic community.
There is lot of potential geolocation data stored on a Windows Phone 8.10 device but it will depend on the main Location setting being ON and in certain situations, on the app’s required capabilities.
The P27:/pagefile.sys is probably the best place to look for textually encoded latitude/longitude data. However, Internet Explorer cache, app logs, device camera picture/video files and the Registry can also store location data.
It is suspected that other Windows Phone 8.1 makes/models will contain the same geolocation artifacts but this should be tested/verified by the analyst.
For future testing purposes, it is noteworthy that the 530 can be upgraded to Windows 10 for Mobile devices (whenever it officially comes out, under whatever name they decide on).
If you would like to share your thoughts/suggestions or any geolocation artifacts, please leave a comment.