Introduction: The Quest for Hidden Location Data

Proprietary Android applications often store sensitive user data, including location information, in ways that are not immediately accessible to the user or standard forensic tools. This case study details the process of reverse engineering a hypothetical proprietary Android application to extract historical GPS tracking data. Our objective is to demonstrate a systematic approach using static and dynamic analysis techniques, culminating in the successful retrieval of stored GPS coordinates.

This guide is intended for educational and ethical purposes, demonstrating methodologies used in mobile forensics and security research. Always ensure you have appropriate authorization before analyzing any application or device.

Phase 1: Initial Reconnaissance and Setup

Before diving deep, a preliminary understanding of the target application and setting up the analysis environment is crucial.

1.1 Understanding the Target Application

Our target, let’s call it “TrackMeNow,” is a simple Android app that claims to track user location for personal safety. We suspect it stores historical location data locally.

1.2 Essential Tools and Environment

• Android Debug Bridge (ADB): For device interaction.
• APKTool: For decompiling and recompiling APKs.
• Jadx-GUI (or Ghidra/IDA Pro): For converting bytecode to Java source code for static analysis.
• Frida: For dynamic instrumentation and runtime analysis.
• SQLite Browser: For inspecting SQLite databases.
• Rooted Android Device or Emulator: Necessary for accessing `/data/data` directories and using Frida.
• Network Proxy (e.g., Burp Suite): If network communication needs analysis.

Ensure ADB is configured and your device is rooted (e.g., with Magisk) and Frida server is running on the device.

adb rootadb push frida-server /data/local/tmp/frida-serveradb shell "chmod 755 /data/local/tmp/frida-server"adb shell "/data/local/tmp/frida-server &"

Phase 2: Static Analysis – Deconstructing the APK

Static analysis involves examining the app’s code and resources without running it. This helps us identify potential areas of interest.

2.1 Decompiling the APK with APKTool

First, obtain the APK file (e.g., by pulling it from a device using `adb pull /data/app/-…/base.apk` or from an app store). Then, decompile it:

apktool d TrackMeNow.apk -o TrackMeNow_decompiled

This creates a directory `TrackMeNow_decompiled` containing Smali code, resources, and the `AndroidManifest.xml`.

2.2 Analyzing AndroidManifest.xml

Open `AndroidManifest.xml`. Look for permissions related to location, storage, and network access:

• `android.permission.ACCESS_FINE_LOCATION`
• `android.permission.ACCESS_COARSE_LOCATION`
• `android.permission.WRITE_EXTERNAL_STORAGE`
• `android.permission.INTERNET`

Also, identify any declared services, broadcast receivers, or content providers that might handle background location updates or data storage.

2.3 Code Analysis with Jadx-GUI

Open the original APK in Jadx-GUI. This tool provides a more readable Java representation of the Smali code. Our strategy involves searching for key terms:

• Location APIs: `LocationManager`, `LocationProvider`, `GPS`, `Criteria`, `FusedLocationProviderClient`.
• Database Operations: `SQLiteOpenHelper`, `SQLiteDatabase`, `insert`, `query`, `update`, `delete`.
• Data Structures: `latitude`, `longitude`, `lat`, `lon`, `timestamp`, `dateTime`.
• File I/O: `FileOutputStream`, `FileInputStream`, `FileWriter`, `FileReader`.
• SharedPreferences: `SharedPreferences`.

Focus on classes that implement `LocationListener` or contain methods named `onLocationChanged`. Trace how the `Location` object is handled, paying attention to where its data (latitude, longitude, timestamp) is stored.

Phase 3: Dynamic Analysis – Runtime Inspection with Frida

Dynamic analysis involves observing the app’s behavior while it’s running. Frida is an excellent tool for this, allowing us to hook into methods and inspect their arguments and return values.

3.1 Identifying Target Methods for Hooking

Based on static analysis, we’ve identified a hypothetical class `com.trackmenow.LocationService` and a method `saveLocationToDatabase(Location location)`.

3.2 Writing a Frida Script

Create a JavaScript file (e.g., `trackme.js`) to hook into this method:

// trackme.jsJava.perform(function() {    var LocationService = Java.use('com.trackmenow.LocationService');    LocationService.saveLocationToDatabase.implementation = function(location) {        var latitude = location.getLatitude();        var longitude = location.getLongitude();        var timestamp = location.getTime();        console.log("[Frida] Location saved: Latitude=" + latitude + ", Longitude=" + longitude + ", Timestamp=" + timestamp);        // Call the original method        this.saveLocationToDatabase(location);    };    console.log("[Frida] Hooked com.trackmenow.LocationService.saveLocationToDatabase");});

3.3 Running the Frida Script

Execute the script against the running application’s package name:

frida -U -l trackme.js -f com.trackmenow.app --no-pausestarting frida-server... (if not already running)

As you use the app, observe the Frida output in your terminal. This will show the exact location data being processed and stored by the app in real-time.

Phase 4: Data Storage Identification and Extraction

Once we confirm data is being stored, the next step is to locate and extract it.

4.1 Locating Stored Data

Android applications typically store data in their private data directory: `/data/data//`. We can explore this directory using `adb shell`.

adb shellrun-as com.trackmenow.app # Enter the app's context for permissionsls -l databases/ls -l shared_prefs/ls -l files/

Through static analysis (searching for `SQLiteOpenHelper` or `getSharedPreferences`), we likely identified that the app uses an SQLite database named `gps_data.db` within the `databases` directory.

4.2 Pulling the Database

To extract the database file, we need to be in the app’s context to access its private files, then copy it to a world-readable location before pulling it.

adb shell "run-as com.trackmenow.app cp databases/gps_data.db /sdcard/Download/gps_data.db"adb pull /sdcard/Download/gps_data.db .

4.3 Analyzing the Database

Open `gps_data.db` using SQLite Browser (or any SQLite client). Inspect the tables. We’re looking for tables with columns like `latitude`, `longitude`, `timestamp`, `accuracy`, `provider`.

A typical table might look like this:

CREATE TABLE location_history (    _id INTEGER PRIMARY KEY AUTOINCREMENT,    timestamp INTEGER NOT NULL,    latitude REAL NOT NULL,    longitude REAL NOT NULL,    accuracy REAL,    provider TEXT);

4.4 Extracting GPS Data

Once the table and column names are identified, you can write SQL queries to extract the data. For example:

SELECT datetime(timestamp / 1000, 'unixepoch') AS event_time, latitude, longitude, accuracyFROM location_historyORDER BY timestamp ASC;

You can execute this query within SQLite Browser and export the results to CSV or another format. For automated extraction, a Python script using the `sqlite3` module would be ideal:

import sqlite3import pandas as pdconn = sqlite3.connect('gps_data.db')query = """SELECT    datetime(timestamp / 1000, 'unixepoch') AS event_time,    latitude,    longitude,    accuracyFROM location_historyORDER BY timestamp ASC;"""df = pd.read_sql_query(query, conn)df.to_csv('extracted_gps_data.csv', index=False)conn.close()print("GPS data extracted to extracted_gps_data.csv")

Conclusion: Unlocking Hidden Insights

This case study demonstrates a comprehensive approach to reverse engineering a proprietary Android application for GPS data extraction. By combining static analysis (APKTool, Jadx-GUI) to understand the app’s structure and potential data handling mechanisms, with dynamic analysis (Frida) to observe runtime behavior and confirm data flow, we successfully identified, located, and extracted sensitive location information stored within the app’s private SQLite database. This methodology is invaluable in mobile forensics, security auditing, and understanding how applications manage user data, empowering experts to recover critical information.