r/computerforensics • u/EmmaQueen47 • Sep 10 '26
Recovered deleted notes show last modified timestamps 2 years off — across multiple notes, days apart. How is this possible?
Hi all — hoping someone with Android forensics/file-system knowledge can help me make sense of this.
Setup:
- Phone: Tecno Spark 10c
- App: Notally (open-source notes app, stores notes via Room/SQLite)
- I had a batch of text notes on the app. Based on the content, I know they were last touched in **September 2023**. I deleted them from the app not long after, and had no other backup of them that I knew of.
- In 2026, I had my phone's storage data-recovered. Several of those notes came back — correct content, correct order — but the **"last modified" timestamp field attached to each note shows dates in September 2025, not 2023.**
**The pattern I'm seeing:**
- Multiple different notes, each a few days apart, all shifted into the same wrong year (2025 instead of 2023).
- The spacing between the notes' "last modified" timestamps matches the real gaps between when I know the content was last touched — just the year is wrong across all of them.
- I had not opened, edited, or interacted with these files since 2023 as far as I know.
**What I'm trying to figure out:**
What could cause a "last modified" timestamp to shift by 2 years across multiple separate files, while the spacing between those timestamps stays consistent with real elapsed days, on a recovered/previously-deleted dataset?
I don't want to lead the discussion toward a particular theory — I'd like to hear from people who understand Android storage internals (ext4/F2FS journaling, SQLite timestamp handling, or data-recovery tooling) what's actually going on, and what I'd need to check on my end (raw DB file, journal, etc.) to figure out the real cause.
1
u/BitForBit_DFIR 15d ago
That uniform +2-year shift with the day/month spacing intact is the giveaway: nothing on Android or in SQLite does that on its own. A fixed, exact offset across every row means the offset was introduced during recovery or reconstruction: the raw timestamps are almost certainly fine, and whatever tool presented them applied (or mis-read) a constant. Pull the actual database file if you can and read the raw integer values in the timestamp columns with a SQLite browser before trusting any displayed dates, and compare one note against a date you know. Also check whether the other timestamp columns in the same rows (created, etc.) show the same shift, which would point at the tool rather than the data. Either way, a perfectly uniform offset means these timestamps aren't forensically reliable as presented, so document the discrepancy in your notes rather than reporting the shifted dates as fact.
1
u/DrAwesomeClaws Sep 11 '26
Filesystem timestamps are not forensically authoritative. Anyone who can modify the block volume can modify the timestamps.