昨天我們從 Chrome 的 History 發現,平常看到的瀏覽紀錄,其實是瀏覽器從 SQLite Database 中整理出來的結果。
手機裡也有很多類似的資料。訊息、通話紀錄、聯絡人,甚至許多 App 的使用紀錄,背後都可能存在 Database 中。因此在 Mobile Forensics 裡,除了看手機畫面,更重要的是找到這些資料真正被保存的位置。
Android 和 iOS 的檔案路徑、Database 名稱和 Schema 不會完全一樣,但分析概念很接近。這次實作使用一份公開的 Android Evidence,從檔案系統一路找到 SMS Database,再直接用 SQL 看裡面的訊息紀錄。
這次的測試資料來自 The Evidence Locker。
The Evidence Locker 整理了許多公開的 Digital Forensics Dataset,可以依照作業系統、年份、作者或資料類型找到不同的練習素材,也會提供 Evidence File、檔案大小和 Hash 等資訊。
對剛開始練習數位鑑識的人來說,這類公開 Dataset 很適合練習,因為不需要真的準備一支手機,就可以直接從已經取得完成的 Evidence 開始分析。
這次我使用的是 Android 類別中的 Samsung Galaxy.zip。
下載後附帶的 NOTE.txt 說明,這個 ZIP 本身就是已經取得完成的 Evidence Source,不需要手動解壓縮,而是可以直接載入支援的 Forensic Software。
因此這次的重點不是「怎麼把資料從手機取出來」,而是拿到一份 Mobile Evidence 之後,要怎麼找到真正有價值的資料?
這次使用免費的 Autopsy 進行分析。
會選 Autopsy,是因為它除了可以分析 Disk Image 和一般檔案,也支援部分 Mobile Evidence 的解析。
這次的 Samsung Galaxy.zip 已經是一份完成 Acquisition 的 Android Evidence,所以這次不需要再從手機擷取資料,而是直接把它加入 Autopsy 進行分析。
實際操作流程如下:

Samsung Galaxy.zip 加入 Case。

在左側的 Data Artifacts、Analysis Results 等分類中,就可能看到 Browser、通訊資料、裝置資訊或其他 App Artifact。實際能解析出哪些內容,會依 Evidence 本身包含的資料,以及當時啟用了哪些 Analyzer 而有所不同。

這類自動分析的優點是,可以先快速了解 Evidence 裡有哪些值得注意的資料,而不用一開始就在大量檔案中慢慢翻找。
不過這次不只看 Autopsy 已經整理好的結果,還會再往下追到原始資料本身,看看這些 Artifact 到底是從哪裡來的。
展開 Evidence 後,可以看到像 data、system、storage、cache 等 Android 目錄。

其中很值得注意的是:
/data/data/
這個位置下面會看到大量以 Package Name 命名的資料夾,例如:
com.android.chrome
com.android.bluetooth
com.android.providers.telephony
這些 Package 底下可能包含對應 App 或系統元件使用的 Database、Cache、設定檔和其他資料。
這次選擇 com.android.providers.telephony 當作實作範例,因為它和 Android 的 Telephony 資料有關。
繼續往下可以找到:
/data/data/com.android.providers.telephony/databases/mmssms.db
mmssms.db 是一個 SQLite Database,其中保存和 SMS、MMS 有關的資料。
找到後,不直接修改 Evidence 裡的原始檔案,而是在 Autopsy 中使用 Extract File(s) 匯出一份 Working Copy,再交給 DB Browser for SQLite 分析。

如果同一個目錄還存在 mmssms.db-wal、mmssms.db-shm 或其他 SQLite Sidecar File,也應該一起保留,因為部分較新的 Database 資料可能還存在這些檔案中。
接著用 DB Browser for SQLite 開啟匯出的 mmssms.db。
可以先從 Database Structure (資料庫結構) 看 Database 裡有哪些 Table,再到 Browse Data (瀏覽資料) 直接查看內容。
這份 Database 不只有 SMS,也可能看到像 pdu、part、addr、threads 等和 MMS 或 Conversation 有關的 Table。
在 sms Table 裡,可以看到像 _id、thread_id、address、date、read、type、body 等欄位。
其中 address 可以看到對方的 Address,body 是訊息內容,而 date 和 type 則需要稍微轉換,才比較容易直接閱讀。

直接看原始 Table 時,date 會是一串數字,type 則可能只看到 1、2 等數值。
因此可以利用 SQL 把真正需要的資訊整理出來:
SELECT
_id,
address,
datetime(
date / 1000,
'unixepoch',
'localtime'
) AS message_time,
CASE type
WHEN 1 THEN 'Received'
WHEN 2 THEN 'Sent'
WHEN 3 THEN 'Draft'
WHEN 4 THEN 'Outbox'
WHEN 5 THEN 'Failed'
WHEN 6 THEN 'Queued'
ELSE 'Other'
END AS message_type,
body
FROM sms
ORDER BY date DESC
LIMIT 50;
Android SMS 的 date 是以毫秒記錄,因此先除以 1000,再使用 SQLite 的 unixepoch 轉成一般日期時間;localtime 則會依目前電腦設定的本地時區顯示。
type 也可以直接在 SQL 裡轉成比較容易理解的文字。例如 1 代表收到的訊息,2 代表已送出的訊息。
這樣原本散落在 Database 裡的欄位,就可以整理成比較直覺的資訊:
這時我們看到的才是一筆比較完整的 Message Artifact。

真正的案件通常不會把所有訊息一筆一筆看完,而是依照調查目標縮小範圍。
例如想找內容包含字串 card 的訊息,可以加入:
SELECT
address,
datetime(
date / 1000,
'unixepoch',
'localtime'
) AS message_time,
type,
body
FROM sms
WHERE body LIKE '%card%'
ORDER BY date;
這樣就只會留下符合 Keyword 的 Record。

相同概念也可以用來搜尋網址、檔名、Email、人名或案件中的其他關鍵字。
這次選 mmssms.db 只是因為它很適合拿來示範 Mobile Database 的分析方式,不代表 Mobile Forensics 就只有聊天或簡訊。
同一份 Mobile Evidence 裡,還可能存在:
Android 和 iOS 的實際檔案路徑與 Schema 也不相同,不同 App 保存資料的方法更可能完全不一樣。