Skip to content
DigitalForenSeek home

Usage

Register a PhonePe case, work through the screens, query every index with PPQL, recover deleted records and export a self-contained evidence set.

What you feed it

Section titled “What you feed it”

The PhonePe package data folder from a full-filesystem or rooted extraction. Select the com.phonepe.app folder itself:

Folder Contents
databases/ Room SQLite databases; phonepe_core holds transactions, chat, contacts and the ledger
shared_prefs/ XML key-value files (tokens, device IDs, flags)
files/ DataStore, crash reports, cached blobs
app_webview/ Chromium cookies and local storage

A case is valid as soon as databases/phonepe_core exists. Everything else is optional: missing sources are reported as degraded on the dashboard and the Audit page, never silently skipped.

Screens

Section titled “Screens”

The sidebar groups the screens: overview (dashboard, unified timeline, hunting, suspicious signals, counterparty lookup), identity and authentication, financial (transactions, split and bill ledger, rewards), social (contacts, chat and groups, social graph, push), Android sources (SMS, mini-apps), behaviour, media and recovery (deleted records).

Chat thread with a demo payee: group details, participants with one phone number recovered from a masked value, and the conversation with an inline payment card.
A chat thread. The participants table shows a full number recovered where the chat stored only ******0001, labelled as recovered. View full size: Chat thread with a demo payee: group details, participants with one phone number recovered from a masked value, and the conversation with an inline payment card.

Suspicious-signal findings are heuristics, each with its supporting data. Some are deliberately cautious: a “no deleted records recovered” finding states that this is not evidence nothing was deleted.

PPQL queries

Section titled “PPQL queries”

The Hunting page runs PPQL, a pipeline query language over every index, with CSV export of the results.

transactions | where direction = "OUT" and amount_inr > 5000 | sort amount_inr desc | head 20
chat_messages | where sender_phone_masked like "*9876" | stats count by sender_name
contacts | where on_phonepe = true | top 10 region
timeline | where source = "Chat" | sort when_iso desc
Command Purpose
where COND Filter rows (= != < <= > >=, like, matches, contains, startswith, in [a,b])
sort F [asc|desc] Order results
head N / tail N Limit rows
table F1,F2,… Select columns
stats count by F / stats sum(F) by G Group and aggregate
top N field Most common values
dedup field Remove duplicates
rename F as G Rename a column

Every *_iso field is UTC ISO 8601, so string comparison sorts chronologically; each also has a numeric *_epoch_ms twin.

Hunting page with a PPQL query over transactions, five result rows, and a syntax reference listing operators and pipe commands.
The Hunting page with a query over the demo transactions. View full size: Hunting page with a PPQL query over transactions, five result rows, and a syntax reference listing operators and pipe commands.

Deleted records

Section titled “Deleted records”

The Deleted Records page walks SQLite’s free pages, free blocks, page slack, superseded WAL page versions and rollback journals, and reconstructs rows that match the real table schemas. Rows still present in the live table are excluded, so only genuine deletions are reported, each with its pool, page, byte offset and source file. A record that fits more than one table is flagged ambiguous, and rows whose first field had to be inferred are marked partial.

Audit and exports

Section titled “Audit and exports”
Audit and lifecycle page with the SHA-256 manifest taken before parsing, how each database was opened, and extraction degradations.
Audit and lifecycle: the hash manifest taken before parsing, and how each database was opened. View full size: Audit and lifecycle page with the SHA-256 manifest taken before parsing, how each database was opened, and extraction degradations.

Export Evidence produces a self-contained set: per-module CSV files, a master JSON of everything parsed, a standalone HTML report, and chain_of_custody.json with the SHA-256 manifest and how each database was opened. CSV output neutralises spreadsheet formula injection.

To confirm the evidence folder was not modified, hash it before and after a run and compare:

Terminal window
P=/path/to/com.phonepe.app
find "$P" -type f -exec sha256sum {} \; | sort -k2 > before.sha256
# ...run the tool...
find "$P" -type f -exec sha256sum {} \; | sort -k2 > after.sha256
diff before.sha256 after.sha256 && echo "evidence byte-identical"

Limitations

Section titled “Limitations”
  • Three databases are SQLiteCrypt-encrypted and are recorded as present but not decryptable. Their key is protected by the Android Keystore in the device’s secure hardware, so a static image cannot decrypt them.
  • Deleted-record carving targets a fixed list of tables and takes most of a run’s time.
  • Documents over 8 MB under files/ are indexed but not parsed, and this is reported.
  • “0 schema gaps” does not mean everything was read: many tables are app catalogue data that no module reads; they remain browsable in the raw layer.