To further illustrate the previous example, the Locations category was selected using Physical Analyzer. This script will locate applications on the device THAT HAVE BEEN PARSED that appear to contain geolocation data. While the script is very useful at quickly identifying applications containing locational data, it cannot be used as the only method for reporting geolocation data.

In this particular example, a third-party application contained addresses and GPS coordinates and was parsed by the tool. The only coordinates that were parsed for this particular application were the favorites. Given the nature of how mapping and navigation applications use this category, we should not assume that it means that an individual has actually been in either one of these locations. At this point, it is best to use the pointer provided by your tool to access the application directory to look for additional data of interest.

It is important to note, however, that if the application is not parsed automatically by the tool, then this location data is not available unless it is retrieved from the databases manually. This does not mean the data doesn’t exist.

Upon a closer inspection of the raw database, those coordinates that were pulled together for this particular application can be confirmed in both the FAVORITES and the PLACES tables.

If an application wasn’t automatically parsed by a tool, locate geo data by looking for:

•  obvious addresses within the database.

•  column headings referencing latitude/longitude, position, location, directions, street, city, state, etc.

•  references to image files that could be a shared map.

•  map tiles contained in application sub-directories.

•  images embedded within the database.

Bottom line: Investigate each application thoroughly, or you could be missing important data!