Wednesday, April 16, 2014

Final Update and Conclusions



Conclusions and Results.

Over the last four months analyzing Waze has had its successes and failures. After the analysis ended I was successfully able to discover relevant artifacts such as direct messages, GPS coordinates, text messages, and user preference files.  However, it was determined that the majority of relevant artifacts are located on a remote Waze server. This was discovered during the memory analysis. There were numerous http calls to a Waze server proxy protocol buffer and also generic function processes. Ultimately, my goal is for my complete paper to be publicly available soon to serve as an investigator's guide to Waze. 


 
Evidence of Artifacts on Server



Forensic Relevance and Future Implications

Waze continues to add user’s everyday even recently surpassing 20 million users world-wide. With a growing number of users switching to applications that provide social media functionality, Waze will continue to gain popularity on the mobile application markets. Recently Waze also announced an update to their application that will only emphasize the importance of this research.
 Waze announced that they have purchased a dating application known as single-spotter.  Waze intends to allow users set up their profile in a way that allows them to view other singles within the area.

WazeDates
 The user can then begin messaging singles in their area and even drive to them if that option is enabled.  This in-app functionally will without doubt launch Waze’s popularity even more and further create more essential digital forensic artifacts. 

Wednesday, March 12, 2014

Progress Update and Log File Analysis

Brief Update

This blog post will consist of general updates to the progress of my project as well as some interesting artifacts I found in one particular log file.

Over the last 6 weeks my project has emerged and changed pretty significantly.  Due to the fact that I have ran into some large roadblocks along the way in terms of discovering relevant data, I have had to change my course of action to uncover some of the data that just was not where I was expecting it to be.

My project has branched out into three main categories of analysis and examination. The categories are the following:

  • Android memory analysis using LiME and Volatility
  • Python scripting to parse through a log file to pull GPS coordinates
  • Physical image analysis of rooted Android device using Oxygen Forensic Suite.


Perhaps the biggest problem I ran into during this project is that any direct, private messages sent from one Waze user to another was not located in any file or folder even after rooting the device and subsequently gaining access to folders such as /data/data. Ultimately, I had to pull Android Memory which took some time to learn exactly how loadable kernels operate. I am still analyzing the output of the ram dump with Volatility but a quick look at it with a hex editor showed that the direct messages due in fact exist within memory.  *Note these are test messages they do not reflect actual crimes being committed. 

Waze Direct Messages from Memory Dump

Log File Analysis

One of the most crucial files located during analysis of this application is the file named waze_log.txt. The file was located under /sdcard/waze/waze_log.txt. This file logs a large amount of data ranging from errors, to voice commands, to general processes of the Waze App. However, the reason this file is so essential is because it also logs GPS coordinates of all routes driven using the Waze application. This file is broken up by sessions. This means every time the app is opened and then either closed or left, this file will log a new “session” An example of this is shown below. 

Session Logged
As seen in the image above this file logs a time stamp for every occurrence of a process.

Routing Requests 

The waze_log.txt file saves GPS coordinates of drives via what is called a Routing Request. Much like the creation of a new session, every time a user searches for a new address to drive to or even clicks on a saved favorite or previously searched address, this file logs it via a RoutingRequest. The Routing ID which is part of the RoutingRequest is a unique 10 digit number that is incremented sequentially by one every time a new request is initiated.  

An important note which came up a few times throughout this research is even if the device running Waze loses connection during a drive, when the connection is reestablished, the same routing request is used until the drive reaches its destination or is canceled.   After the initial RoutingRequest is given the file also logs the location of the user in two places. Below is an example of a RoutingRequest as well as the log listing the location of the user. 

Unique Routing ID
Logging Devices Current Location

 Below this line in the log file is the RoutingRequest that contains numerous GPS coordinates. The GPS coordinates contained in this line are both the current location of the device and the destination of the drive. Also on this line is the unique routing id seen in the Routing ID screenshot above. The street name is also listed however, not every RoutingRequest line will list the street the device is currently on.


RoutingRequest logging current and destination GPS coordinates

The unfortunate part of this log file is on the line that contains the RoutingRequest and subsequent GPS coordinates there is no logged time. However, within milliseconds above and below this line are logged times. The screenshot below gives an example of logged time above and below the RoutingRequest.  It is important to note that every RoutingRequest logged in this file has a time stamp above and below.


Relevant time stamps in waze_log.txt

The time stamps seen above are only about 2.3 seconds apart from each other, giving the examiner a relatively accurate picture of what time the device logged the coordinates. 

Automating the process

I am currently working on  a python script that will essentially pull out all the above information and put it in a folder structure that is easily maneuverable. The following is a screenshot of the file structure output that I intend to incorporate in the script. 

Script Output File Structure
The Directory is set up as the following folders
  • WazeOutput after script is run
    • The session date and time for each log on session
      • The Unique RoutingID for each drive
        • xls file that contains all the mapped coordinates   
My ultimate goal is to also take each of the GPS coordinates and map out the coordinates using a Google API key in a way that the street names can be exported to the excel file as well.

Next Steps 

The next phase of this project will consist of finishing the analysis of the memory dump using Volatility as well as finishing the python script seen above.  I also will be hopefully posting a tutorial on how to configure and use LiME to pull memory from an Android device as there are not too many tutorials out there that are geared toward non-developers. 


Wednesday, January 22, 2014

Project Introduction

What Waze is

From a first glance, Waze, now owned by Google (isn’t everything?) might look like a typical GPS application. From one perspective it is. It offers your average garden variety GPS features. From favorite locations, to restaurants, to even cheapest gas prices in the area, Waze just seems like another typical GPS app.  However, dive a little deeper and you begin to see that Waze is much more. Waze is an entire community of users.  Waze gives the user the ability to communicate with other “Wazers” through a variety of methods such as direct messages. 



Map Chat Feature 


Here is a list of some of the other features that are available on the Waze App.

  • Native Group Forums
  • Pick Up (allows a user to text or email another Wazer their location to get “picked up”)
  • Save Parking Location  (friends on Waze can see where you parked)
  • Link to Facebook, Twitter, and FourSquare.
  • Drive Sharing (watching other Waze Friends drive to a location)
  • Map Chat and direct messages  
  • Picture Taking (Built in Camera) 

As their motto goes, the goal of Waze it to outsmart traffic together. Users can post where they have seen accidents, slow roads, construction, or even where speed cameras and police are located.

Waze and Forensics

So why is Waze forensically relevant?  All these features, all this data. To an average user
Waze is a great way to combine communication and navigation. But from a forensic perspective it could be a potential goldmine of hidden, critical information. This is where my capstone comes in. Is all this data retrievable? I certainly hope so!

The amount of data, and therefore the amount analysis required for this the App is extensive. To make this project feasible in the amount of time I have, I decided to solely focus on data that I believe could impact a digital forensic investigation. I have broken up the potential artifacts into five main categories
  • Artifacts relating to the GPS functionality.
  • Artifacts relating to unique Waze features found on the device
  • Web Browser History (my Waze profile online)
  • Social Media data (Waze links to FB, Twitter and FourSqaure)
  •  SMS and Email Artifacts relating to Waze.

waze forensics
Direct Message Feature

To  accomplish this I will be generating data using a mobile phone. The mobile phone I have selected is the Android LG Optimus F7 running Jellybean 4.1 which was bought specifically for this project and will only be used when generating Waze evidence.


Questions to be answered

This project will be focused around a few main questions.
  • Can I forensically uncover any data?
  • Is there any recoverable deleted data?
  • Can I create a timeline of events based on GPS coordinates or timestamps?
  • Is there any data stored in memory? (Live routes or shared drives?)


Tools

Although I have not finalized the tools I plan on using to uncover this data, currently I plan at least using the following:
  • Cellebrite UFED touch
  • XRY
  • Volatility
  • Oxygen Forensic Suite

Over the next few weeks I will begin to create the evidence on the mobile device. My plan is to create evidence based on each category and then analyze the data for that category before moving on to the next.

If you would like to read more about Waze in the meantime here is a link to their manual.







Sunday, January 19, 2014

David Storozuk's Waze Forensic Blog


waze, forensics, waze forensics

Hello and welcome to Waze Forensics! 


As a digital forensic senior at Champlain College , my capstone project requires me to choose a topic that has yet to be researched within the digital forensic community. 

As part of this project, I will be blogging about the progress I make uncovering artifacts relating to Waze.To stay up to date on my blog, you can follow me on Google + or Twitter