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.
.PNG)
.png "Direct Message Feature")
