檢測 iOS 重置並清除所有內容後所遺留的數位痕跡

2022-12-9 by 高田鑑識修訂

我們最常被問的問題之一 「如何辨別 iOS 裝置被清除、重置時間?」清除資料是常見的一種銷毀證據的方法。多年來,我們觀察到許多試圖掩飾清除動作、防止被檢測的手段。常見手段如下:

  1. 預先好幾個禮拜前先清除裝置,並正常使用製造數位「雜訊」,讓它看起來像是 「使用過」。
  2. 清除裝置並將舊的備份資料還原回去,讓它看起來像是 「使用過」。
  3. 清除裝置並將其他使用者的數據還原回去,讓它看起來像是 「使用過」。

本文旨在協助您快速確認 iOS 裝置是否曾經被清除。請留意,裝置被清除並不代表一定有發生違法行為,仍有很多重置裝置的正當理由。我們只是協助您確認清除的時間點,至於清除裝置的背後原因,需由您自行調查發現。

檢視的數位檔案

Ruth 的測試裝置 – iPhone X

  • 測試裝置使用的是 Cellebrite CTF 活動成員 Ruth Langmore 的 iPhone X,並在 2020 年 7 月 27 日 7:08 PM UTC 清除裝置。
  • 對應 Ruth 實際的所在地並加上日光節約時間後(GMT-4),以當地時間計算,清除的時間點是 3:08 PM。

與往常一樣,我們會在多個裝置上驗證檢查的內容與方式,包括 iPhone SE (iOS 版本 13.7) 和 iPhone 6S (iOS 版本 14.2)。

鑑識人員通常使用鑑識工具進行日期解析,或根據數位痕跡(Artifact)上顯示的日期判別。但開始之前,我們列舉一個比較不可靠的數位資料日期。

com.apple.purplebuddy.plist

該 plist 檔案的資料夾路徑如下:

開啟該檔案後請先檢視 SetupLastExit 項目。

SetupLastExit 日期並非清除裝置時間的最佳證據,有很多因素可影響此時間戳記的正確性。當你啟用一台未設定的 iPhone 時,可以跳過 Wallet 和其他設定。當之後重新設定這些項目時,此時間戳記會被更新。如果在一段時間後更改 Apple Pay 的信用卡資訊,該時間戳記會再次被更新。因此,它反映的是裝置使用者最近一次在 「設定」 內更改內容的時間點。

當用該測試裝置驗證,雖然清除時間的日期是正確的,仍舊可以發現 SetupLastExit 的時間是 09:32 PM ,是在清除裝置後的幾個小時(清除時間 7:08 PM UTC),這對應了Ruth 在「設定」內更新 Apple Pay 的時間。

如果您近期清除裝置並進行設定,可以看到 「Finish Setting Up Your iPhone (完成您的 iPhone 設定)”」紅色警示。

總之,SetupLastExit 記錄著裝置最後一次的設定時間。你可能會發現一些裝置在清除後立即設定,這十分正常,但您可能會遇到一些長達數天或數月未完全設定的裝置,面對這種情形,我們建議忽略 SetupLastExit 值。

在清除 iOS 裝置時,您會發現有幾個檔案的日期時間是正確的,我們也將在此分享我們多年來最信賴的檢測清除日期方法。

第一個同樣是在 com.apple.purplebuddy.plist 檔案內,其中包含許多有用的日期並且可以使用大多數 iOS 提取方式取得,包括 iTunes 備份一直到完整檔案系統提取。

在 com.apple.purplebuddy.plist 中,我們可以看到 GuessedCountry(建議的國家或地區)的時間戳記顯示 2020 年 7 月 27 日 7:13:13 PM,大約是清除 iOS 裝置重啟並進入設定的時間。

您必須考慮到: 當使用者按下「Erase All Content and Settings (清除所有內容和設定)”」並繼續時,清除的動作完成後直到裝置重新開機並進入設定畫面,可能會有幾分鐘的時間間隔。使用者將看到的第一個畫面是 「Select Your Country or Origin (選擇您的國家或地區)」,該值在 plist 檔中代表 GuessedCountry

若要採用這個時間做為證據,請確保 SetupState SetupUsingAssistant,假如是 RestoredFromiCloudBackup,該日期代表的是上一次「清除」後進入「使用設定輔助程式」的時間點,而不是這次採用 iCloud 復原後的時間點。因為採用 iCloud 復原後不會進入到設定全新裝置的引導畫面。關於 iCloud 復原,我們建議使用完整檔案提取,並依本文章後段提及的數位痕跡檢視方式。如果無法執行,便只能使用手動檢查裝置的啟用日期和使用情形。

總之,com.apple.purplebuddy.plist 內有很多日期資料可供查看,即便使用 iTunes 備份也可以使用。我們建議您檢查該 plist 檔案中的 GuessedCountry,該時間代表在清除後初次成功啟動進入設定畫面時顯示的國家/地區 (本文案例顯示美國)。

請留意,如果裝置是從 iCloud 備份檔復原,您得查看 GuessedCountry 以外的內容,因該時間代表著較舊的清除日期。如果想了解更多關於清除裝置後的使用者設定操作 (iCloud 復原、全新設定、iTunes 復原),請參考 Heather Mahalik 發布的 DFIR Review 部落格

containermanager

第二個須注意的檔案需透過完整檔案系統提取才可取得,儲存所有 logs 檔案的資料夾路徑如下:

複製

containermanager 是一系列系統日誌 (logs) 檔案,在裝置啟動時紀錄啟動過程。資料夾內的檔案副檔名為 .log,較舊的 log 會用數字排序。因此,你會發現 containermanager.log.0、containermanagerd.log.1 和 containermanagerd.log.2。請留意,數字越大,檔案越舊 — containermanager.log.0 是最新檔案。

由於我們想要了解裝置清除的日期,該資訊儲存在最舊的檔案中,我們需要查看數值最大的檔案,我們最關心的紀錄是裝置啟動過程,啟動的時候,裝置會檢查最近是否有更新:

該筆紀錄說明: 在啟動時發現作業系統版本為 17C54,與上次啟動時相同,因此並沒有升級。

此紀錄顯示作業系統正從 build 17C54 升級到 build 17D50。

但是在清除後初次啟動裝置時,並無裝置資訊,如以下紀錄:

這些紀錄每一筆都在前面加上了紀錄的日期和時間,時間戳記是根據裝置所在時區的紀錄建立時間點。請留意,首次啟動時,裝置預設為美國太平洋時間 (UTC-8),正確的時間會在設定過程中更新。

意味著無論裝置在清除之前的設定如何,前幾條紀錄 (我們感興趣的紀錄) 都以 UTC-8 顯示。如果我們檢查 Ruth 的裝置查看描述的紀錄,可發現時間戳記是 2020年7月27日 12:11:38 PM

正確的 UTC 時間需要加上 7  小時 (因西岸日光節約時間差一小時)才能轉換成 UTC 時間,變成 7:11 PM — 約裝置清除後的 3 分鐘。因為裝置可能需要幾分鐘才能完成清除和重新啟動。

以上情形看似有些異常,我們需要做進一步的測試。

第二台裝置 — 驗證:

該測試裝置在 16:32 UTC 時清除,在 17:00 UTC 時設定,並在 17:07 UTC 時重新啟動。但是,MobileContainerManager 資訊顯示 08:33。由於清除重啟後裝置是在太平洋標準時間 (UTC-8),我們必須加上 8 小時轉換成 16:33 UTC,與上述時間相近

logd.0.log

在此研究期間, Ian 在 logd.0.log 發現,其中包含關機和時區更改的資訊。該檔案位置在以下資料夾:

複製

如果您還記得,該裝置的設定時間是 05:00 PM UTC,我們查看 logd.0.log 檔案可以發現第一行代表的是時區的更改。

設定完成後,時區便會更改並自動加上日光節約時間,這裡顯示時間戳記為 10:01:49 UTC-0700,對於裝置執行設定時間點以及我的時區來說都是正確的。第二個項目是在裝置關機時產生的,與我重新啟動裝置的時間 — 5:07 PM UTC 相同。

最後,我們回到最開始的地方,可以看到 containermanagerd 的時間戳記以當地時間顯示。

值得注意的是,該檔案似乎有保存期限,不能保證每次開啟提取時都可取得。有趣的是,Ian 在他的個人裝置上發現一則購買前三個月的紀錄,這並非 EPOCH 日期,可以猜測這是裝置在工廠測試時啟動的紀錄。

Ruth 裝置再次驗證

為了再次確認,我們使用 Ian 開發的 ArtEx 工具檢驗 Ruth 的數據。下面我們可以看到 containermanagerd 和我們在 Physical Analyzer 中看到的一致,時間戳記顯示 07/27/2020 12:11:38。(Heather 所在地區為東部時區,因此需加上 3 小時才符合她的當地時間)。如同我們之前所述,這是正確的。

在檢查 containermanagerd.log.0 的 Metadata 時,可以看到建立時間 (UTC) 符合裝置清除時間。

因此,檢查 containermanagerd.log.0 中的建立日期是最簡單的方法,但還需了解其中的內容和意義,才不會在裝置清除時誤判。如先前所述,還有其他檔案的建立日期可以用來辨別 iOS 裝置清除之後的啟動時間。如下圖所述,您可以看到 Ruth iPhone 中的其它檔案。

AddressBook.sqlitedb

複製

AddressBook.sqlitedb — 建立時間 7/27/2020 7:11 PM UTC修改日期與清除日期沒有任何關聯。

CallHistory.storedata

複製

CallHistory.storedata — 建立時間 7/27/2020 7:12 PM UTC

.obliterated

複製

辨別裝置清除的常用檔案是 .obliterated,這是在裝置清除後,啟動時建立的 0 byte 檔案。

我們如果查看 Ruth 裝置上的 .obliterated 檔案,可以看到它的建立時間是 3:11:25PM (東部夏令時間),既  7:11:25PM UTC

將它的時間戳記與其他時間進行比較,我們可以發現該檔案建立的時間,是在 containermanagerd 顯示時間約 14 秒之前。

.obliterated 需要藉由完整檔案系統提取才能獲得,並且不一定每次提取中都能看到。然而,它是其中一個裝置清除時間的重要參考指標。

總結

您可以查到有關 iOS 裝置清除的確切證據,如果您只有 iTunes 備份或進階邏輯提取,只需比對 com.apple.purplebuddy.plist 之中的 GuessedCountry。如果想要調查更多與其他數位痕跡的關聯性,可將此日期與 Addressbook.sqlitedb 和 Call_History.storedata 的建立時間進行比對,這些是裝置被清除重新啟動後隨之產生的檔案。對於其他檔案也可行,我們需要檢查的是時間的一致性。

如果您有完整檔案系統提取,請從 containermanagerd 建立時間開始檢查、查看其內容並確保轉換為所在時區。然後查看 logd.0.log 以確定裝置時區是否有轉換 (除非您的所在時區就是太平洋時區)。另外也可前往 com.apple.purplebuddy.plist 進行複驗,來確保裝置清除的時間點是正確無誤的

.obliterated

複製

辨別裝置清除的常用檔案是 .obliterated,這是在裝置清除後,啟動時建立的 0 byte 檔案。

我們如果查看 Ruth 裝置上的 .obliterated 檔案,可以看到它的建立時間是 3:11:25PM (東部夏令時間),既  7:11:25PM UTC

將它的時間戳記與其他時間進行比較,我們可以發現該檔案建立的時間,是在 containermanagerd 顯示時間約 14 秒之前。

.obliterated 需要藉由完整檔案系統提取才能獲得,並且不一定每次提取中都能看到。然而,它是其中一個裝置清除時間的重要參考指標。

總結

您可以查到有關 iOS 裝置清除的確切證據,如果您只有 iTunes 備份或進階邏輯提取,只需比對 com.apple.purplebuddy.plist 內的 GuessedCountry。如果想要調查更多與其他數位痕跡的關聯性,可將此日期與 Addressbook.sqlitedb 和 Call_History.storedata 的檔案建立時間進行比對,這些是裝置被清除重新啟動後隨之產生的檔案。對於其他檔案也可行,我們需要檢查的是時間的一致性。

如果您有完整檔案系統提取,請從 containermanagerd 建立時間開始檢查、查看其內容並確保轉換為所在時區。然後查看 logd.0.log 以確定裝置時區是否有轉換 (除非您的所在時區就是太平洋時區)。另外也可前往 com.apple.purplebuddy.plist 進行複驗,來確保裝置清除的時間點是正確無誤的。