01Session plan
| Minutes | Block | What happens |
|---|---|---|
| 0–15 | Brief, rules and integrity (Q01) | Read export-metadata.txt aloud and write the three time notations on the board with one conversion each. |
| 15–50 | The message and the call (Q02–Q06) | Convert one epoch value by hand, then place the call against the message on one UTC line. |
| 50–95 | Where, and how sure (Q07–Q09) | Plot the fixes of the evening with their radii; filter on accuracy before distance; discuss the cell fix. |
| 95–130 | Use of the phone (Q10–Q14) | Read the usage events around the message and count the unlocks; follow the phone home. |
| 130–150 | The statement and the sentence (Q15–Q16) | Test the owner's statement part by part, then write the signed sentence and compare it with b. |
Materials: the pack files on each trainee's machine, a printed worksheet from the pack page, and an examination log form. Pack page →
02Answer key
Q011 point
On a copy of sms.csv, compute the SHA-256 value, compare it with manifest.txt, and enter the first 8 hex characters.
Answer565d9572
The prefix matches the manifest line. A spreadsheet turns the 13-digit epoch values into rounded scientific notation if the file is saved again; hash it as exported.
- Where
- manifest.txt, the sms.csv line.
- Usual mistake
- Hashing a copy saved again by a spreadsheet.
Hash calculatorF-04 Examination logSOP-02 Evidence intake and registration
Q022 points
When was the message 'Bu iş burada bitmedi…' written to the phone's SMS table as sent? UTC.
Answer2026-10-03 20:47:31
Row _id 1858: address +905550193344, type 2 (sent), date 1791060451000. Epoch milliseconds are UTC: 2026-10-03 20:47:31, which is 23:47:31 local, the minute the complaint gives. The tool's date_utc column agrees; check one row by hand before you rely on a column.
- Where
- sms.csv, row _id 1858, date and date_utc.
- Usual mistake
- Reading 20:47 as local time and concluding that the message left three hours before the complaint says.
Q032 points
How many messages did the phone send to +905550193344 in the export window?
Answer3
Three type 2 rows: 29 September 'Konuşmamız lazım.', 1 October 'Son kez söylüyorum, ara beni.' and the 3 October message. Two type 1 rows are replies from that number: 'Lütfen bana yazma' on 29 September and 'Polise gidiyorum' at 20:52:05 UTC on 3 October.
- Where
- sms.csv, address +905550193344, type.
- Usual mistake
- Counting all five rows of the thread.
Q042 points
The call log shows an outgoing call to 'Ece' at 03.10.2026 23:41:12. How does it stand against the message?
AnswerB — Six minutes and nineteen seconds before it: the call log is device local time, 20:41:12 UTC, and the message is 20:47:31 UTC.
export-metadata.txt says the Turkish report renders the call log in the device's time zone. Subtract three hours: 20:41:12 UTC. The phone was used for a 62-second call to the friend it was supposedly left with, six minutes before the message.
- Where
- call-log.csv, the 'Ece' row of 3 October; export-metadata.txt, Export 2.
- Usual mistake
- Comparing a local time with a UTC time as written.
Q052 points
When did that outgoing call to Ece start? UTC.
Answer2026-10-03 20:41:12
03.10.2026 23:41:12 local minus three hours. The dialer comes to the foreground at 20:40:58 UTC in the usage events, which agrees.
- Where
- call-log.csv, date_local of the row.
- Usual mistake
- Entering 23:41:12.
Q061 point
How long did that call last, in seconds?
Answer62
duration_s 62, type 2 (outgoing). A call that connects has a duration; an unanswered outgoing call is logged with 0. At 00:02:40 local Ece's number calls this phone and the call is missed (type 3).
- Where
- call-log.csv, duration_s.
- Usual mistake
- Reading the duration of the missed call that follows.
Q072 points
When did the location history first place the phone within 200 m of the complainant's building, counting only fixes with an accuracy of 100 m or better? UTC.
Answer2026-10-03 19:51:40
The building is at 41.0452, 29.0049 (acquisition-log.txt). The first fix inside 200 m with accuracy ≤100 m is stamped 2026-10-03T22:51:40+03:00, 19:51:40 UTC, after a run of GPS fixes moving from Uskudar over the bridge. The fixes stay there until 20:58:22 UTC.
- Where
- Timeline.json, rawSignals[].position; acquisition-log.txt, the building's coordinates.
- Usual mistake
- Copying 22:51:40 without subtracting the +03:00 offset.
Q082 points
At 23:30:07 local one fix has source CELL, accuracy 1,500 m, and a centre about 870 m from the building. What does it show?
AnswerB — Nothing that contradicts the Wi-Fi and GPS fixes around it: the building lies well inside its 1,500 m circle.
A cell fix is placed by the serving cell and is wide. 870 m from a centre with a 1,500 m radius is inside the circle. The neighbouring Wi-Fi and GPS fixes at a few tens of metres decide the position; the cell fix only fails to contradict them. The owner's home is over 6 km away.
- Where
- Timeline.json, the CELL fix and the fixes before and after it.
- Usual mistake
- Reading the centre of a wide fix as the phone's position.
Q092 points
How many fixes with accuracy ≤100 m fall within 200 m of the building between 23:00 and 00:00 local time on 3 October?
Answer12
Between 20:00 and 21:00 UTC there are twelve such fixes, Wi-Fi and GPS, every three to six minutes; the nearest to the message, at 20:48:09 UTC, is 47 m from the building with a 20 m radius. The CELL fix is excluded by the accuracy filter.
- Where
- Timeline.json, rawSignals[].position, timestamp and accuracyMeters.
- Usual mistake
- Filtering 23:00 to 00:00 on the UTC clock.
Q102 points
At 20:46:51 UTC the usage events record KEYGUARD_HIDDEN, then Messages to the foreground at 20:46:58 and to the background at 20:47:40. What can be said?
AnswerC — The lock screen was dismissed and Messages was in the foreground when the sent row was written at 20:47:31: the phone was unlocked and in use. By whom, and by PIN or fingerprint, is not recorded.
KEYGUARD_HIDDEN means the lock screen went away, which on a PIN-locked phone requires the PIN or the enrolled finger. The foreground window brackets the sent row. Nothing in usagestats names the person; the report must stop at the device.
- Where
- usage-events.csv, rows around time_ms 1791060451000; export-metadata.txt, Export 3.
- Usual mistake
- Writing that the owner sent the message.
Q112 points
Which package was in the foreground when the SMS row was written?
Answercom.google.android.apps.messaging
The last MOVE_TO_FOREGROUND before 1791060451000 without a matching MOVE_TO_BACKGROUND is com.google.android.apps.messaging (Google Messages). Its own database, bugle_db, was not part of this extraction.
- Where
- usage-events.csv, event_type 1 and 2 before the SMS time.
- Usual mistake
- Entering the dialer, which went to the background at 20:42.
Q122 points
How many times was the lock screen dismissed (KEYGUARD_HIDDEN) between 23:00 and 00:00 local time on 3 October?
Answer5
Five unlocks: 23:12 (Maps), 23:40 (the dialer, the call to Ece), 23:46 (Messages, the SMS), 23:52 (Messages, after the reply arrived at 23:52:05) and 23:56 (Maps). The phone was handled repeatedly during the hour it was near the building.
- Where
- usage-events.csv, event_type 18, time_local 2026-10-03 23:xx.
- Usual mistake
- Counting SCREEN_INTERACTIVE rows, or using the time_ms values as local time.
Q132 points
Which statement about the time bases is right?
AnswerB — Epoch values (sms date, usage time_ms) are UTC; the call log report is device local; Timeline times carry +03:00; the device clock was 2 s ahead at seizure.
Android stores epoch milliseconds; how they are shown depends on the tool. Here the tool rendered SMS in UTC and the call log in device local time, and the Timeline export writes the offset into each time. A two-second clock difference does not change any finding but belongs in the report.
- Where
- export-metadata.txt; device-info.txt, clock at seizure.
- Usual mistake
- Assuming one tool renders every table on one basis.
Q142 points
When did the location history first place the phone within 150 m of the owner's home after it left the building? UTC, fixes with accuracy ≤100 m.
Answer2026-10-03 21:36:47
The last fix near the building is at 20:58:22 UTC; GPS fixes then cross back over the bridge to Kadikoy, and the first within 150 m of 40.9869, 29.0261 is stamped 2026-10-04T00:36:47+03:00, 21:36:47 UTC on 3 October. The phone then stays at the home until the seizure. It is never back at Ece's building.
- Where
- Timeline.json, rawSignals after 20:58 UTC.
- Usual mistake
- Writing the date 2026-10-04 because the local stamp is after midnight.
Q152 points
The owner says he left the phone at Ece's in Uskudar at about 21:30 and collected it the next morning. What do the records show?
AnswerB — They contradict the second half: the phone left Ece's building at 22:24 local, was near the complainant's building from 22:51 to 23:58, was unlocked five times there, called Ece's number, sent the message, and went to the owner's home at 00:36; it was never back at Ece's before the seizure.
The first half (dinner at Ece's) fits: fixes at her building from 19:18 to 22:24 local. The rest does not: the phone moved, was used and went home that night. Whoever carried it, the device was not at Ece's in the morning. Ece's missed call to the phone at 00:02 also sits badly with the phone being in her house.
- Where
- Timeline.json; call-log.csv; usage-events.csv; acquisition-log.txt, the statement.
- Usual mistake
- Accepting or rejecting the whole statement instead of testing each part.
Q162 points
Which sentence can the examiner sign?
AnswerB — The phone +905550127788 recorded as sent, at 20:47:31 UTC on 3 October, the message to +905550193344; at that minute it was unlocked with Google Messages in the foreground, and its location history places it 47 m from the complainant's building (radius 20 m). The records do not show who was holding it.
Sentence b names the device, the time with its basis, the state of the phone and the location with its radius, and stops at the person. a and d turn the device into the person; c reads a UTC time as local. Whether the statement is false is for the court to weigh with the other evidence.
- Where
- All exports; README.txt, rule 4.
- Usual mistake
- Writing a conclusion about the person or the truth of the statement.
03Reconstructed timeline
The timeline as the correct answers build it. Local time is UTC+3.
| UTC | Local | Event | Source |
|---|---|---|---|
| 19:24:16 | 22:24:16 | Last fix at Ece's building in Uskudar (22:24:16 local). | Timeline.json |
| 19:51:40 | 22:51:40 | First fix within 200 m of the complainant's building. | Timeline.json |
| 20:41:12 | 23:41:12 | Outgoing call to Ece, 62 s (written 23:41:12 local). | call-log.csv |
| 20:46:51 | 23:46:51 | Lock screen dismissed; Google Messages to the foreground. | usage-events.csv |
| 20:47:31 | 23:47:31 | Message to +905550193344 written as sent. | sms.csv |
| 20:52:05 | 23:52:05 | Reply received: 'Kimsin sen? Polise gidiyorum.' | sms.csv |
| 20:58:22 | 23:58:22 | Last fix near the building. | Timeline.json |
| 21:36:47 | 00:36:47 | First fix at the owner's home in Kadikoy (00:36:47 local on 4 October). | Timeline.json |
04Scoring
Questions 1–11 carry one point each and question 12 carries three: 30 points in all. The finding paragraph is not scored by points; mark it against the four criteria below and discuss it in the debrief.
| Points | Next step |
|---|---|
| 27–30 | Sound. Move on to a supervised review of a full file system extraction, including bugle_db and the operator's records. |
| 15–26 | Review each missed question with its explanation, then rebuild the evening in the workbench with every source on UTC. |
| 0–14 | Work through VP-02 first, then repeat this pack converting every time by hand before using the workbench. |
Finding paragraph: criteria
- Every time carries its basis; epoch, local and offset times are each converted correctly.
- Every location is given with its accuracy radius, and wide fixes are not read as points.
- The use of the phone (unlocks, foreground app) is placed around the message on one UTC line.
- The owner's statement is tested part by part.
- The report speaks of the phone, not the person, and lists what was not examined.
05Debrief
- Android keeps epoch milliseconds; every tool chooses how to show them. Read the export notes before the numbers.
- An ISO time with its offset is the kindest time an examiner can be given. Keep the offset when you copy it.
- Location answers 'how close' only together with 'how sure'.
- Unlock events show a hand on the phone, never whose.
06Model finding
The SMS table of the phone with SIM number +905550127788 records a message to +905550193344, 'Bu iş burada bitmedi. Şu an neredesin biliyorum.', as sent at 20:47:31 UTC on 3 October 2026 (epoch 1791060451000; 23:47:31 local; sms.csv). It was the third message to that number in the window. At 20:46:51 UTC the lock screen was dismissed and Google Messages came to the foreground until 20:47:40 (usage-events.csv); between 23:00 and 00:00 local the phone was unlocked five times. Six minutes before the message, at 20:41:12 UTC (23:41:12 in the local-time call log), the phone made a 62-second call to the number saved as Ece (call-log.csv). The on-device location history places the phone at Ece's building in Uskudar until 19:24:16 UTC, within 200 m of the complainant's building from 19:51:40 to 20:58:22 UTC in twelve Wi-Fi and GPS fixes of ≤100 m accuracy in the hour of the message, the nearest 47 m away with a 20 m radius at 20:48:09 UTC, and at the owner's home in Kadikoy from 21:36:47 UTC until the seizure (Timeline.json, times written with +03:00). The owner's account that the phone stayed at Ece's until the next morning is not consistent with these records. Limits: the records describe the phone; they do not show who carried or used it. The complainant's phone, the operator's records and the Messages database were not examined. The device clock was 2 s ahead at seizure.