(并非)奇怪的搭档——三星Rubin与数字健康功能

又一個夏天飛逝而過。假期、法庭（是的！）、課程（同樣，是的！），當然還有會議行程，今年都在全力進行中。事情稍微緩和下來，我終於有機會動手寫一些一直在進行的事情。如今要找到時間坐下來寫作越來越困難。不過，我希望能改變這種趨勢。

首先從三星開始。具體來說，是三星定制服務（又名Rubin）和數字健康（DWB）。有相當多的人直接或通過工作聯繫我，詢問有關這兩者的問題以及它們表現出的一些奇怪行為，我認為「奇怪」可能是最好的形容方式。畢竟這是三星，在Android方面，他們喜歡以自己獨特的方式做事。這讓取證人員保持警覺，並為Android增添了一些多樣性。因為Android取證缺乏多樣性，對吧？

在測試期間，我必須應對三星的SPL和一般更新，這使得獲取提取變得棘手和令人沮喪。有時我會獲得Rubin所需的關鍵材料，有時則不會。這完全取決於我進行提取時的運氣。無論如何，S22得到了很好的鍛煉。它運行的是Android 15（OneUI 7），並具有2024年12月和2025年4月的SPL。我知道有一個7月的SPL，但由於我已經在手機上遇到困難，我選擇保留現有的內容。

如果您還沒有閱讀過三星實施DWB的相關資料，可以在[這裡]閱讀。如果您不熟悉三星Rubin，Cellebrite有一些資源，您都可以在[這裡]找到。

這將是我迄今為止最短的文章，但很重要，因為它關係到可能被遺漏的數據。

鎖定與解鎖——更好的搭配

標題真的說明了一切。如果取證人員遇到同時使用Rubin和DWB的手機，這兩個項目需要一起檢查，以便最全面地了解設備上發生的情況。原因是，當啟用時，傳統上由DWB保留的一項信息被轉移到了Rubin：設備解鎖。參見圖1。

圖1. dwbCommon中沒有一個解鎖事件。

上面是dwbCommon.db中usageEvents表的摘錄。上面截圖涵蓋的時間段應該有兩個解鎖事件（eventType=18），但卻沒有。為了再次確認，我手動檢查了usageEvents表，發現根本沒有eventType=18的值，這引出了一個問題：手機如何知道我在這段時間內解鎖了兩次？結果發現，Rubin擁有這些數據。參見圖2。

圖2. 屏幕解鎖和鎖定。

inferenceengine_logging.db中的screen_state_log表包含設備解鎖和鎖定的信息。為了確定哪些記錄代表哪個操作，需要一起使用列screen_state、user_present、use_keyguard和time（我使用這個是因為我喜歡UTC）或time_string（事件發生時設備的本地時間）。此表還會告訴您屏幕何時被點亮。我觀察到以下組合：

• 解鎖（生物識別或密碼） screen_state = 1 user_present = 1 use_keyguard = 0

• 通過側邊按鈕鎖定 screen_state = 0 user_present = 0 use_keyguard = 1

• 通過達到屏幕超時閾值鎖定 screen_state = 0 user_present = 0 use_keyguard = 0

• 屏幕點亮，但未發生解鎖 screen_state = 1 user_present = 0 use_keyguard = 1

再次強調，這些解鎖事件沒有記錄在dwbCommon.db（或其-WAL）中。但有趣的是，一些鎖定事件（eventType=17）被記錄在usageEvents（dwbCommon.db）中，但並非全部，而且它們與screen_state_log（inferenceengine_logging.db）中記錄的相同操作時間大致接近。

這裡還有一個額外的說明：如果用戶關閉Rubin，上述行為仍然適用。解鎖仍然會記錄到Rubin，並且不會顯示在DWB中。

延遲寫入與完成的啟動

三星決定實施他們自己版本的DWB，這是根據Google的移動服務合同允許的。因此，他們實施並使用了一個名為Logging的表在dwbCommon.db中，正如其名稱所示，它正在記錄一些事情，其中一些從取證人員的角度來看可能很有用。第一項是設備啟動，雖然我們從一開始就能在usageEvents表中看到這一點，但這次探索性研究使我們對什麼實際上構成「啟動」的理解更加清晰。這是我發現一些奇怪行為的地方。參見圖3和圖4。

圖3. 完成的啟動和Logging表中的最後條目。

圖4. usageEvents表中的最後記錄。

圖3和圖4真正揭示了這種奇怪的行為，因為我在測試期間多次遇到這種情況。圖3有Logging表中的最後兩條記錄，其中有兩個「BOOT_COMPLETED」條目。這些條目的有趣之處在於它們與usageEvents表中最後四個條目的關係：它們的時間比後者晚了超過12小時！這很有趣，因為在此手機上發生的活動（包括兩次啟動操作）本應在8月4日記錄信息到usageEvents中，但它們卻不在usageEvents中。然而，在幾小時後進行了幾次更多提取後，記錄終於出現了。

我們這裡遇到的是一個延遲寫入的實例。我的意思是，使用數據既不存在於主數據庫中，也不存在於關聯的-WAL文件中，並且在相當長的一段時間內都沒有記錄到其中任何一個。在測試中，我多次觀察到這種行為，並且其他聯繫我的從業者也描述了相同的行為。我看到記錄需要從1小時到超過12小時不等的時間寫入數據庫或-WAL（我有幾次實例記錄花了超過一天才出現）。我已經仔細檢查了S22的提取內容，但找不到這些數據在記錄之前被保存在哪裡。我最初懷疑是RAM，但重啟設備似乎並沒有強制寫入。觸發寫入的原因對我來說仍然是一個謎，但取證人員應該知道，有可能存在尚未寫入的記錄，特別是如果他們檢查Logging表並看到像圖3中那樣比usageEvents中最後條目時間晚很多的條目。

這一發現還揭示了另一件事：Logging表中的「BOOT_COMPLETED」條目並不像它們看起來那樣是一個清晰的陳述。在測試期間，S22重啟了多次，但有時與BOOT_COMPLETED記錄相關的時間戳遠遠晚於設備實際重啟的時間。考慮一下：用戶重啟了他們的手機，但沒有立即解鎖手機，而是讓它閒置了一段時間。最終，用戶解鎖手機以便開始使用它。圖5下面顯示了一個例子。

圖5. 兩次重啟。

上面有兩個重啟事件。第一次發生在2025-08-04 09:26（UTC -0400），但手機直到09:27（UTC -0400）才被解鎖。第二次重啟發生在2025-08-04 19:20（UTC -0400），但手機直到2025-08-05 08:29（UTC -0400）才被解鎖。如上所示，BOOT_COMPLETED條目與手機首次解鎖的時間一致。為了確認我在這裡看到的情況，我查看了文件eRR.p（USERDATA/system/users/service/data/）。下面的圖6顯示了相關的時間範圍，相應的重啟以各自的顏色編碼標示。

圖6. eRR.p中的重啟。

那麼發生了（正在發生）什麼？當S22在重啟後首次被解鎖時，在我輸入PIN後，屏幕顯示「手機正在啟動…」。直到此時，手機處於BFU狀態；它可以做一些事情，但不是所有它能做的事情。一旦我輸入了PIN，手機就「完成」了其啟動過程並進入AFU狀態。看來，就DWB而言，啟動過程直到手機進入AFU狀態才完成。

請注意，手機在之前的提取過程中崩潰了，這解釋了在圖6第292行看到的KP事件（可能是內核恐慌）。

沒有Rubin？沒問題。

到目前為止，討論圍繞著Rubin和DWB共存於手機上的情況。但是當用戶不使用Rubin時會發生什麼？為了測試這一點，我重置了S22，但沒有登錄我的三星帳戶。我將提前說明，我仍然觀察到以與之前相同的方式延遲寫入記錄到數據庫的情況。但當談到DWB時，情況略有不同。參見圖7。

圖7. 這看起來好多了。

在未啟用Rubin的情況下，解鎖事件（eventType=18）回到了usageEvents表中。並且，和以前一樣，設備啟動記錄（eventType=27）仍然指示著手機在啟動/重啟後首次被解鎖的時間。圖8顯示了Logging表，其中突出顯示了一個BOOT_COMPLETED記錄。請注意其時間與圖7中看到的記錄855（DEVICE_STARTUP）大致接近。

圖8. BOOT_COMPLETED（無Rubin）。

真快啊

雖然這是我最短的文章…就像有史以來最短…但我認為單獨強調這一點很重要。不僅Rubin+DWB設置會導致問題，而且它可能導致取證工具錯過重要的數據。這些是取證人員在過去五年中逐漸依賴的數據。此外，這種不立即寫入記錄的習慣可能會在並非所有內容都已寫入時給取證人員一種錯誤的安全感。記錄可能正在等待寫入而不可用（我仍然認為這些東西在某處的磁盤上——我會繼續尋找），取證人員可能由於缺乏數據而得出錯誤的結論，因此理解這種行為的存在非常重要。