What is actually on a phone when it lands on your desk

A typical mid-range Indian Android device, in active daily use, carries data in roughly this shape:

• WhatsApp msgstore.db with messages, contacts, and media references

• Two or three UPI apps (PhonePe, GPay, Paytm, sometimes BHIM) each with its own transaction tables

• Call log and contacts database

• Photos with EXIF metadata plus the Android MediaStore index

• Browser history from system browsers

• Location data scattered across cell tower logs, Wi-Fi BSSIDs, and EXIF GPS tags

• App install and use history

• Notifications cache

  
  

Each one lives in its own format. WhatsApp speaks SQLite. UPI apps each have their own schemas. EXIF is a binary blob inside the JPEG. Browser history is yet another SQLite database with completely different columns. The MediaStore is its own catalogue.

An examiner who tries to read these one app at a time, then mentally stitch them together into a single story, is doing the job a forensic analysis platform is supposed to be doing. The point of Visualizer is to put the fragments on one screen so the examiner can spend time on the case, not on the file plumbing.

An illustrative scenario

Names, UPI IDs, coordinates, and timestamps below are fictional placeholders used to show how the platform behaves on real data shapes. This is not a reconstruction of any actual investigation.

A UPI-related fraud case. A suspect's phone is seized at 08:00 IST. Extractor finishes the file system pull and hashing by 10:00. The examiner loads the case file into Visualizer and opens the timeline view.

The first thing they see is not a list of apps. It is a single chronological stream, every artifact in order, every source labelled. Where there was a pile of databases there is now a sequence of events.

Walking one hour of the timeline

09:47  WhatsApp  group chat "Friends": message "amount ready"
09:50  Call log  outgoing call to +91 98XXX XXXXX (contact: "Rahul")
09:52  PhonePe   UPI debit  ₹49,000  to xyz@paytm
09:58  Camera    photo captured  EXIF GPS: 28.61° N, 77.21° E
10:14  GPay      UPI credit ₹15,000  from abc@okhdfcbank
10:20  Chrome    search "xyz@paytm"  → search "cash out UPI"

Six entries, six different source apps, one screen. The examiner does not have to remember which SQLite file holds the WhatsApp messages or which schema column carries the UPI VPA. The timeline already knows.

Each row is anchored back to the raw artifact. Open the 09:52 entry and you get the actual PhonePe transaction row, with its original database column values, its hash, and a pointer back into the forensic image. The examiner can see the message in its original surface, not just a normalised summary. That source-anchoring is what keeps the evidence trail intact in court.

What Visualizer is actually doing

Visualizer does not replace the investigator. The judgement, the connections, the line of inquiry remain human work. What Visualizer does is remove the parts of the job that have nothing to do with investigation:

One screen, many apps. Instead of opening WhatsApp's database in one viewer, the UPI app's database in another, and EXIF data in a third, the examiner reads them in a single chronological view. Everything carries its source label, so there is no confusion about where any given entry came from.

Bookmark and tag. Mark the artifacts that matter. The tag and the note travel with the artifact through every later view and into the final report.

Source-anchored evidence. Every row in the timeline keeps its link back to the raw data. A bookmarked entry is not a summary of a message; it is a pointer to the exact message in the exact database. That link is what makes the evidence survive cross-examination.

A working surface, not a black box. Visualizer puts the data at the right level of detail in front of the examiner and stays out of the way. The story is the examiner's to build.

From timeline to courtroom

In Indian courts, electronic evidence has to clear Section 63 of the Bharatiya Sakshya Adhiniyam 2023. The compliance certificate that accompanies the evidence has to identify the electronic record, describe how it was produced, give appropriate particulars of the device, and be signed by both the person in charge and an expert. In forensic practice, those particulars typically include identifiers like the IMEI and hash values (commonly MD5 or SHA-256) with the algorithm named.

A timeline that loses its link back to the raw evidence cannot support that certificate. A timeline that keeps every artifact source-anchored and hash-verified can. When the examiner exports the case from Visualizer, the report carries the bookmarked artifacts, the case and examiner metadata, and the hash values needed to support the compliance certificate. The narrative the examiner built on the timeline becomes the document the court reads. The path from a BNSS-mandated 60-day investigation window to a court-ready exhibit runs through that handover.

"I have an extraction" becomes "I have a case"

The acquisition gave the examiner data. Visualizer turns that data into something a prosecutor can put in front of a judge.

If you want to see how this comes together in practice, the UPI forensics walk-through and the WhatsApp deleted-message recovery piece both show the upstream work that produces the data Visualizer then reassembles.

For a demonstration of the timeline view on a representative dataset, request a Secfore demo.