iOS 地理圍欄 – GeoFences

當分析行動裝置資料時， PA 上可呈現不同種類的定位資訊。本篇文章會深入探討 iOS 地理圍欄 – GeoFences 功能，藉由分析存放地理圍欄資訊的 consolidated.db 資料庫 ，讓鑑識人員對於行動裝置上的定位資訊類別有更詳細的了解。

Apple 裝置上的地理圍欄資料庫檔案只能透過 FFS (Full File System) 提取，在 AFU 或 BFU 模式下皆可取得該資料庫檔案，資料庫的路徑為：

APP 要存取 consolidated.db 資料庫需透過 iOS GeoFence API，該資料庫由 iOS 作業系統管理，任何要建立地理圍欄的 APP 皆會將地理資訊存放於此資料庫內。

基本上地理圍欄是由經緯度和半徑等三個資訊定義的圓形範圍位置。行動裝置會持續監測是否抵達或離開地理圍欄的範圍。

圖一、地理圍欄監測示意圖

抵達地理圍欄：當行動裝置是從監控位置的中心點半徑範圍外進入。

離開地理圍欄：當行動裝置是從監控位置的中心點半徑範圍內離開。

表一、Fences Table

在 consolidated.db 資料庫內主要可看到四種類型的位置資訊

想像一下安裝與商店有關的 APP，以 Sephora APP 為例。

在第一次打 APP 時，Sephora 會在裝置上建立地理圍欄，這些地理圍欄包含了行動裝置附近銷售他們化妝品的實體商店。在預設情況下，該 APP 建立了 19 筆地理圍欄（註：Apple 限制每個 APP 的地理圍欄最多為 20 個）。

圖二、Sephora 地理圍欄紀錄

圖三、Sephora 實體商家

當行動裝置靠近 Sephora 所建立的地理圍欄時，Sephora APP 可以主動推播商品資訊或優惠等，來增加商品銷售的誘因。

因次，資料庫上的 GeoFence 的時間戳記是它被建立的時間，而不是裝置抵達或離開該位置的時間。可從圖二上看到有 19 筆 Sephora GeoFences 資料在同一個時間被建立。

若在 consolidated.db 資料庫上看到其他的 APP 的地理圍欄資訊，例如 IKEA 的 APP，在分析過程很容可以將這些位置資料排除。因為 IKEA 的實體商家距離分佈較廣，很明顯行動裝置不可能同時出現在這些點位。但是，如 Sephora 的案例可能會對分析過程產生新的挑戰。因為這些地理圍欄與實際行動裝置的位置非常接近，使得定位資訊看起來像是實際造訪過。

無論如何，藉由 Sephora 或 IKEA 產生的地理圍欄位置不太可能對調查有用，並且在大多數情況下應被排除。

提醒事項的定位資訊主要分兩種型態，請務必知道這兩種型態的差異，避免在偵查上造成誤判。

圖四、提醒事項地理圍欄紀錄

a) 當我抵達 X 位置請提醒我

應用情境可以是「當我靠近 X 位置附近時提醒我做 Y」或「當我到達 X 位置時提醒我打電話給 Z」。

從情境上可以得知，裝置使用者有預計會移動至 X 位置。但請注意，地理圍欄的 X 位置並不是裝置使用者當前所在的位置。他們建立該地理圍欄提醒時可以在地球上的任何地方。

另外在圖四的 Distance 欄位，可以看到半徑的距離可以小到 100 公尺，也可以大到 5 公里或更多。當半徑為 5 公里的情況下，使用者建立的提醒通知為抵達一個行政區或鎮的情境。

b) 當我離開 X 位置時請提醒我

這個地理圍欄的資訊比前一項較為有用，使用情境為「當我離開家 X 位置後提醒我做 Y」之類的事情。

在這個提醒的情境下，裝置使用者至少必須在該地理圍欄的區域內。請注意圖四上的時間戳記為該地理圍欄的建立時間，而不是抵達或離開的時間。但不幸的是一旦裝置使用者離開該地理圍欄位置，此記錄將立即被刪除，因此無法從提取中得知裝置使用者曾經在 X 位置。

但若在這之前先取得行動裝置的 FFS 提取，我們至少可以知道裝置使用者與 X 位置有極大的關聯性。

裝置使用者為專心工作，可設定離開當下位置之前行動裝置為「勿擾模式」。啟用後它會在裝置當下的位置建立一個 100 公尺的地理圍欄，並持續監控裝置是否離開該位置。

圖五、勿擾模式紀錄

從 BundleID 或 Name 欄位可以分辨出該筆紀錄與勿擾模式有關。該設定運作方式與離開地理圍欄雷同，當裝置使用者離開地理圍欄位置後該筆紀錄會立刻被刪除。

圖六、設定勿擾模式

相較於前幾個類別，預測經常造訪地點的地理圍欄資訊對於鑑識工作會有較多幫助，但呈現的資訊也容易令人混淆。這過程行動裝置會預測下個或多個預計抵達的地點，當移動出監測的點位後會再重複預測，這過程會不斷的建立和刪除地理圍欄紀錄。

圖七、經常造訪地點記錄

經常造訪地點的 BundleID 欄位內容為 Routine.bundle，而 Name 欄位內會有以下兩種類別

1. RTVisitMontor.RealTimeHighConfidenceExitFenceForCurrentVisit (離開預測的地方)
2. RTVisitMonitor.RealTimeEntryFenceForNextPredicted (預測抵達的地方)

因此，預測經常造訪地點的「離開地理圍欄」資訊比較有意義，因為我們知道該筆地理圍欄紀錄代表使用者實際所在的位置。 抵達地理圍欄則是行動裝置根據使用者過往的行為與紀錄，預測下個可能前往的位置。並且如上投影片所示，可能會做出多個預測。 它可能會猜測使用者要回家或去當地的酒吧。 兩筆記錄將有相同的建立時間，但實際位置可能彼此不相近。

想像一下這樣的場景：

• 嫌疑人造訪了一個他之前去過很多次的案發現場。行動裝置自動建立一筆「離開地理圍欄」 。
• 當在案發現場，嫌疑人決定停用行動裝置的定位服務，以隱藏他在犯罪時身處該地點的事實。
• 當他離開了案發現場， 通常「離開地理圍欄」會自動會觸發，導致記錄被刪除，但由於定位服務被停用，因此記錄未被刪除。

對於調查工作算是幸運地找出嫌疑人與犯罪現場的關聯性，但它也證明了透過「啟用/關閉」定位與 Wi-Fi 服務來操縱數據是多麼容易。

以上已經介紹了不同類型的地理圍欄，現在回到 Fences 資料表中的 NAME 欄位，從該欄位可以看到採 GUID 型態紀錄的資料。GUID 可用於反查請求地理圍欄的 APP。以「提醒事項」APP 為範例，透過 GUID 可以找到哪個提醒事項擁有相對應的地理圍欄。

圖八、地理圍欄資料庫紀錄

圖九、Reminder 資料庫紀錄

圖八為 consolidated.db 地理圍欄資料庫內的紀錄。 圖九為「提醒事項」資料庫的紀錄。 請注意，consolidated.db Name 欄位的 GUID 可以對應「提醒事項」內的 GUID。同樣的比對方式也可能適用於其他類型的地理圍欄，值得花額外時間驗證。

雖然 Consolidated.db 不會是最精準的資料來源，因為有可能會有大量預測造訪地點造成鑑識人員的調查困難度。 然而，該資料庫不應該被忽視，裡面的部分資訊可能會是調查的突破點。