Reading SIM slot logs and network lookups

Summary

The Android phone app keeps two small databases that record when a SIM slot changed state and which network lookups the radio logged. Neither file had a reader in ALEAPP. This contribution adds four artifacts for them, all reporting values as stored.

• UICC Log (SIM Slot Events) reads the uicclog table of uicc_log.db and splits four line formats into index, state, subscription id and card fields.
• SIM Subscriptions Seen in UICC Log groups the log by phone index and subscription id and adds the matching siminfo row of telephony.db.
• Telephony Network Lookups (trafficstats) reads the trafficstats table of echolocate_system_network_db, and Cells Seen groups it by cell.
• Status: In review. The pull request is open as a draft and no maintainer review has been posted yet.

• 4artifacts added
• 49files changed
• 6,884lines added
• 11synthetic cases

The issue

An examiner is asked which SIM cards a phone held and when the slots changed. ALEAPP already reads the siminfo table of telephony.db, which lists the subscriptions the phone stored. That is a state at extraction. A siminfo row can outlive the SIM it describes, and its display name can be edited after the event. It does not say when a slot reported READY, when a card was absent or how many times the state changed.

The phone app also keeps a plain log of those events, uicc_log.db, and on some builds a table of network lookups with a cell id and a signal reading. Both sat in the extraction and in no report. The examiner would see the subscription list and have to open the databases by hand to see the sequence.

The parser did not read these two files; now it does. Because the meaning of many values is not documented, the artifacts keep each value as stored and say what is not known.

The essence

Four artifacts, two modules, one rule: report what the file stores and name what is not proven. The SIM log is read line by line and the four formats seen are split into fields, with the raw line kept beside them. The subscription view groups those lines and attaches the stored SIM details by matching a subscription id to a siminfo row, an observed match that is labeled as such. The network lookup table is read by column name, because two column orders exist, and a second view groups it by cell.

Two time rules matter. The SIM log time is a device local time with no zone, so it is shown as stored and not converted. The lookup time is a Unix millisecond value and is shown in UTC.

Our methodology

Find the format from the data. No source for these files was found, so the four line formats and the two column orders were read from the databases themselves. The notes say so. They also state what was not established: which component writes each file, and what many values mean.

Recount without our code. On five Samsung Android 16 extractions the SIM log held 123, 223, 387, 423 and 428 rows. Two of them also held the lookup table, with 14,442 and 11,376 rows. An independent script using only sqlite and csv re-derived every artifact row count and every column: all SIM log rows, all lookup rows with all columns, 92 and 48 cell groups whose row sums equal the table, and 3, 1, 1, 1 and 2 subscription groups with their first, last and count values and the stored SIM details. All of it matched.

Look at the output the way a reader would. The repository's output checker flagged a constant Android User column, an empty Carrier Name column and two coincidentally equal columns. These are now named in the notes, and a rerun reports nothing to look at.

Damage the input. Six damaged variants of each of four real database files (truncated at half and at 4 KiB, first page zeroed, header only, empty, random bytes) returned no rows and raised no exception, for both artifacts of the module each time. Unit tests add a missing table, a missing column, timestamps that are not numbers, zero, in seconds or in microseconds, unparsable address text, a second Android user and a table of 60,000 rows.

Build synthetic cases. Eleven synthetic cases with invented values cover both column orders of the lookup table, an older siminfo table lacking several columns, an empty table, a missing telephony.db, two Android users and a data/data layout so that storage views can be re-staged. The run script gave 172 passes against 150 on the base, the difference being 22 new test units, and no failures.

The value

For a case about SIM changes, an examiner can now read the sequence of slot events and see which subscription ids were active, with the stored SIM details beside them. The SIM log is a short trail. Row ids start at 1 on four devices and at 2001 on one, which is consistent with older rows having been removed there, so the table should be treated as a log that can be trimmed. The absence of an event is not evidence that it did not happen.

The network lookup views give a record of cells seen by the radio, with the first and last time and a row count. A cell id on its own does not say where a device was, and nothing is derived from it. The lookup file was present only on the two devices that carried a carrier-branded 'echolocate' application, so it may be specific to builds with that application. Other builds were not tested.

What it does not show. The meaning of the SIM states, the null token, the card fields, the response codes and the -999 signal value is not documented and is reported as stored. The SIM log time is consistent with a local time on two devices but the zone is not proven. Every address item is 32 hexadecimal digits, including failed lookups, so the items are not read as IP addresses. The consumed column is 0 on every row of both devices, so the table does not show data volume, and nothing in it ties a row to a SIM. A SIM state is not by itself proof of who inserted or used a SIM.

What is pending. The pull request is open as a draft with no review yet, and continuous integration had not run when it was written. It lists three open points. There is no sample_data, because none of these files is in the public corpus and a maintainer with a matching image could add counts. There is no Pixel or other-vendor build and no other Android version. The carrier application's own databases and several related files are not covered.

Where this sits in the Lab's research

No Lab report covers this yet; the method above is from the pull request. The approach follows the checks used across this series: an independent recount, damaged and synthetic inputs, and notes that state what is not known. The adjacent merged work on network and telephony sections of bug reports is described in another post.

Sources

Related posts

• Bug report network, Wi-Fi, Bluetooth, NFC, USB and telephony: merged work on the same family of questions from another source.
• App Ops access history databases: another open pull request with an independent recount.
• WhatsApp Business stores: an open pull request that states what real data it lacks.