The Trigger

A new app showing up in casework starts the clock. Sometimes a senior officer walks into the lab with a seized phone and a frustrated examiner. Sometimes a procurement evaluation finds we cannot decode something the lab needs us to decode. Sometimes our sales team flags that three different agencies asked about the same app in one week.

When the request lands with our decoding team, the first thing we do is decide whether the app is worth a parser at all. Some are not. An app with three thousand users in India is not where engineering hours should go. An app with thirty million users (three crore in India) on devices that show up in cybercrime cases every week is.

The criteria are unsexy: how often does this app appear in real cases, how much investigative value does its data carry, and is this an app a court will care about. If the answers line up, the work starts.

What "Supporting an App" Actually Means

This is the part that gets glossed over in vendor marketing. "Supports tens of thousands of apps" can mean a lot of different things, and most of them are not what an investigator needs.

A real parser does five things:

1. Identifies the app's data on the device, including in places the app does not advertise (cache directories, journal files, attachment folders).

2. Reads the app's storage format, which is usually SQLite but can be protobuf, LevelDB, custom binary, or some combination.

3. Handles encryption at the field, table, or file level, using the right keys for that app and that device state.

4. Reconstructs the user-meaningful content. Messages, transactions, contacts, locations, attachments, deletions, group memberships, the works.

5. Presents the result in a form an investigator can read, search, filter, and export to a report a court will accept.

Anything short of all five is not a real parser. It is a metadata listing. Vendor marketing rarely distinguishes between the two, but lab work does, and so does the defense lawyer at trial. Our blog on Indian OEMs and regional apps covers what this distinction looks like for one specific slice of the Android ecosystem.

What Happens in the Window

Once the work starts, the four weeks roughly look like this. The exact split shifts by app, but the shape holds.

Week 1: Reverse engineering and discovery

The decoding team gets the app on test devices. Real devices, real account activity, not synthetic data. The team uses the app the way actual users do for several days, generating the kinds of data that need to be parsed later. Then we acquire the device with our own Extractor, pull the relevant directories, and start mapping the storage layout.

For an app that uses standard SQLite with no encryption, this is fast. For an app that wraps records in protobuf, encrypts message bodies with a key bound to the device keystore, and scatters attachment metadata across three databases, this is most of the week.

Critical output of week one: a schema map. Which tables hold what, which columns mean what, how relationships are stitched, where deleted records leave traces.

Week 2: Parser draft

Decoder engineers translate the schema map into actual parsing code. This is craft work. The parser has to handle the happy path (a normal message between two users), the edge cases (a deleted message, a forwarded media chain, a group of five hundred), and the failure modes (corrupted records, missing keys, partial writes from a phone that died mid-operation).

Most of week two is making the parser correct on edge cases. The happy path is usually done by Tuesday. Friday is spent finding the records that look right but are not, and fixing the ones that look wrong but are.

Week 3: Decryption and key handling

If the app encrypts data, this is when the team works out where the keys live and how to access them. In some apps decryption work begins in week one because the schema is not even readable until keys are recovered. Sometimes keys live in the OS keystore (Android Keystore or iOS Keychain) and require an unlocked device in AFU state. Sometimes they are derived from a passcode the user set when securing the app. Sometimes the app rotates keys per session and the parser has to follow the chain.

This is also where we decide what we cannot do. Some apps lock data in ways that are not solvable without the user's PIN, or without breaking encryption that no responsible vendor would publish a method for. We mark those clearly in the parser output rather than fail silently.

Week 4: Validation, integration, and release

The parser runs against a battery of test images, including images we have built specifically to break it. We compare the parser's output against the same data viewed through the app's UI on a live device. If a message exists in the app and not in our parser output, we go back. If a message exists in our output and not in the app, we go back further.

Once validation passes, the parser ships in the next Extractor and Visualizer release. Lab heads who asked for it get a note. The supported-apps list grows by one.

Why Most Suites Cannot Do This

Several months at the established vendors is not a question of effort. It is a structural fact about how those companies are built.

A team thousands of kilometres away working on a Vietnamese fintech app needs test devices shipped from Vietnam, account credentials in a script they cannot read, QA staff who can verify outputs against an app whose UI is in a language they need to translate, and a release train that batches new parsers into quarterly builds because that is how shipping at their scale works.

A team in Delhi working on Indian fintech apps like UPI uses the app daily, has accounts already, can read every error string and field name in Hindi or the relevant regional language, runs validation on a device that is on the desk, and ships in the next two-week build because that is how shipping at our scale works. The same model works for any market where our team can get the app, the devices, and the casework signal.

Neither model is wrong. They are sized for different markets, and the lab in Mumbai or Hanoi or Lagos cares which one fits the cases on its desk this quarter.

What We Do Not Promise

A two to four week parser turnaround is not a four-week guarantee for every app. Some apps take six weeks because the encryption is harder. A couple have taken longer because the storage format changed mid-development. We do not promise four weeks. We promise that when a real lab makes a real ask, work starts within a week and ships in the same release cycle as long as the app passes our prioritization criteria.

We also do not pretend a parser ages well by itself. Apps update. Schemas drift. A parser written against version 6.1 starts to break when version 6.4 changes the message table layout. Maintaining a parser is its own ongoing cost, and it is one of the reasons we are deliberate about which apps we add. A parser added today is a parser someone has to keep alive for years.

If you are evaluating mobile forensic tools and the apps that drive your investigations are not on anyone's headline coverage list, this is the conversation worth having with the vendor. Not "which apps do you support today" but "what is your process for adding the next one."

The answer to that question is the answer to whether the tool will work for your lab in twelve months.

Secfore builds mobile forensic tools focused on Indian and adjacent markets. Two to four weeks is the typical turnaround when the app fits our prioritization criteria. If your lab needs an app that is not on our supported list yet, the conversation starts with telling us which app and why.