【閱后即焚】應用的數據取證分析

隨著智能手機的普遍化以及具備安全通訊功能的手機應用日益增多,人們的通訊內容受到保護的同時為取證分析增加了難度。為此，針對具備閱后即焚特性的手機第三方應用，分析閱后即焚的數據特性，對手機取證分析工作顯得相當重要。

互聯網技術以及移動通訊技術的快速發展、手機的智能化，使得人們對手機的依賴性越來越強。通信、購物、理財、出行等一系列日常行為均可輕鬆的通過手機一鍵完成。手機給人們的生活帶來便利的同時也存在著個人信息泄露、被犯罪分子利用導致生命財產受到威脅等問題。因此，人們的信息安全意識也隨之增強。為了保護用戶的信息安全，各大主流手機第三方應用的開發者們紛紛提出安全通信、私密通信等概念。這在保護用戶信息的同時，對手機取證工作也帶來了一定的困難。

目前對手機第三方應用的取證分析多數集中於針對特定手機系統、特定APP的數據存儲格式進行分析。針對近期較流行的具備閱后即焚特性的手機應用的取證分析較少。本文主要通過分析具備閱后即焚功能的第三方應用軟體的數據特性，總結該類數據的消息銷毀機制及取證分析方法。

具備閱后即焚特性的應用數據取證分析

顧名思義，「閱后即焚」是指信息被賦予了生命周期，其在接收方閱讀後的特定時間內將被自動銷毀。這一概念隨著Snapchat這款照片分享應用的推出而廣受青睞。隨後很多第三方應用開發者們相繼推出了具備閱后即焚的聊天功能。如：支付寶、新浪微博、釘釘、Telegram等應用均具備了閱后即焚的聊天功能。

由於各類手機應用具有多樣性，因此，本文分別選取廣受國內各企業青睞的企業級應用─釘釘和以安全通信為主要特色的Telegram作為分析對象，分別分析其Android版本和iPhone版本的數據存儲格式、消息的」閱后即焚」特性，並總結相應的取證分析方法。本文所採用的設備信息iPhone5 SE iOS 9.3.3 已越獄；Android 酷派 S6 , Android OS 4.3 已root。

1、釘釘取證分析

釘釘是阿里巴巴專為企業推出的一款企業級應用。其主要支持視頻會議、商戶電話、聊天、企業通訊錄以及企業辦公協同等功能。其採用AES加密演算法與第三方加密相結合，來提高用戶數據的安全等級，旨在為企業員工間的交流、協同提供一個安全的環境。

本文所分析的釘釘版本信息分別為：iPhone V2.15.0 （從App Store下載，更新日期:2016年8月13日）；Android V2.15.0（從應用寶下載，更新日期:2016年8月15日）。

1.1 iPhone 釘釘的數據分析

iPhone版本的釘釘用戶數據主要存儲在\Documents\db\<32BitsString>下文件名為db.sqlite的SQLite資料庫文件中，其中：<32BitsString>表示特定ID通過MD5加密演算法加密后的32位密文，該特定ID由每個註冊賬號的系統ID （記為uid）拼接」@dingding」後綴所得的字元串，即uid@dingding。此外，該目錄下含有db.sqlite相應的加密文件(db.sqlite-encrypt)和日誌文件(db.sqlite-shm、db.sqlite-wal)。由於重要的數據文件被加密，因此對釘釘進行取證分析需預先對資料庫文件進行解密。表1為解密后db.sqlite資料庫中部分資料庫表表名及其功能。

由表1可知用戶信息、釘釘好友、企業通訊錄、DING消息等數據均可從相應的資料庫表中獲取到所需數據。聊天內容則需通過WKConversation、WKChat_V32String兩個表關聯查詢。表2、表3分別列出了WKConversation和WKChat_V32String的表結構，其中WKConversation表主要用於存儲會話ID、會話類型等信息；WKChat_V32String表則存儲詳細的聊天記錄包括聊天內容、消息類型、日期、媒體附件信息等主要數據。根據WKConversation表關聯WKChat_V32String主要步驟可描述為：

• STEP1：從WKConversation表中查找conversationId欄位所對應的值，記為VcId標識會話ID，執行STEP2。

• STEP2：根據STEP1所得的會話ID關聯與相應的聊天內容表。即對VcId進行MD5加密得32位的密文，記為VMD5String。即VMD5String = MD5Encode(VcId) ，其中MD5Encode表示MD5加密演算法，執行STEP3。

• STEP3：拼接表名。在STEP2計算所得的32位密文VMD5String，前添加」 WKChat_」前綴后即為所求表名。

根據上述步驟即可關聯到所需的聊天記錄表，且可根據WKConversation表中tag欄位所設置的值進行過濾，從而獲取特定類別的聊天記錄。

1.2 Adnroid 釘釘的數據分析

Android版釘釘的主要資料庫文件存儲在/data/data/com. libaba. android. rimet/ databases目錄下，用戶數據主要存儲在<uid>.db 以及<MD5Encode (uid@ dingding)>.db這兩個資料庫文件中。與iPhone版本相似，Android版本的釘釘主要資料庫文件經過AES加密演算法加密。因此，需預先對其進行解密。表4描述了<uid>.db和<MD5Encode (uid@dingdin g)>.db解密後主要的資料庫表名、相應的功能描述以及存儲位置。

其中，uid表示登陸賬號的系統ID； MD5Encode(id)表示變數id 經過MD5加密演算法加密后的32位密文；tbmsg_Aid_Bid表示Aid與Bid的聊天記錄所在表名。

從解密后的資料庫文件易知，文件名為<uid>.db的資料庫主要存儲登陸賬號、釘釘好友、群組列表等數據；而聊天記錄相關內容則存儲在<MD5Encode(id)>.db的資料庫中。與iPhone版的處理方式相似，聊天記錄均需要通過多表關聯獲取，即tbconversation與tbmsg_Aid_Bid進行關聯。其中tbconversation表存儲會話ID、會話類型等信息；詳細的聊天記錄則存儲在與之相應的tbmsg_Aid_Bid表中。因此，關聯tbmsg_Aid_Bid表可分為三個主要步驟進行：

• STEP1：從tbconversation表中查找cid欄位所對應的值，記為VcId標識會話ID，執行STEP2。
  
  

• STEP2：根據STEP1所得的會話ID獲取當前會話所對應的用戶ID，記Bid，執行STEP3。
  
  

• STEP3：拼接表名。根據STEP2計算所得的Bid，拼接表名，其拼接模式為tbmsg_Aid_Bid，其中Aid為登陸賬號的用戶ID，Bid為與Aid進行會話的用戶ID。因此，當登陸賬號為uid時，其與賬號為Fid的好友聊天記錄表名為tbmsg_uid_Fid。

綜上所述，若要關聯會話ID為1234567:66666666的聊天記錄表，其中登陸賬號的uid為66666666，則與之相應的聊天記錄表名為：tbmsg_66666666_1234567。

1.3 釘釘密聊模式的數據分析

密聊是釘釘的主要特色之一，該模式下不顯示用戶名稱及頭像；聊天消息設置了自動銷毀時間且無法複製及轉發。圖1所示分別為iPhone版本、Android版本密聊的初始會話窗口。

由圖1可看出除了第二條提示信息之外，iPhone版與Android版的密聊初始會話窗口提示語基本相同。其中iPhone端的提示為「消息在服務端不留痕迹」，如圖1(a)所示；而Android端則提示為「消息在各端不留痕迹」，如圖1(b)所示。這說明iPhone版本與Android版本對密聊消息的處理方式存在一定的區別。

下面通過實例來分析iPhone端與Android端對密聊消息的不同處理方式。具體測試方法如下：1）分別在iPhone SE和酷派S6兩部手機上登陸已註冊的兩個釘釘賬號作為密聊消息的接收方，記iPhone端登陸的賬號為A，Android端登陸的賬號為B；2）從另一台設備登陸賬號C，並分別向A和B發起密聊，記消息內容為M；3）分別比較A、B在消息M為未讀和已讀後被銷毀這兩種狀態下資料庫的變化情況。當A與B分別閱讀所接收消息M 30秒后，此部分消息在手機界面被自動銷毀。

根據1.1節、1.2節分別對iPhone版本和Android版本數據的分析方法，可容易關聯到密聊的消息記錄，其中密聊的tag = 4。圖2所示為的C與A的密聊消息在銷毀前後的資料庫對比情況，即iPhone端密聊消息銷毀前後的資料庫變化情況；由圖2可看出，iPhone端數據銷毀后WKChat_V32BitString表中的記錄並未被從資料庫中刪除，與銷毀前一樣content欄位的內容仍是明文顯示，僅修改了unreadCount欄位和isDel欄位相應的值。其中unreadCount欄位表示消息的未讀數，0表示已讀；isDel欄位表示是否刪除，0表示未刪除，1表示已刪除；因此，當消息為未讀狀態時，unreadCount的值大於0且isDel為0；當消息為已讀且被銷毀時，則相應記錄的unreadCount=0且isDel=1。從而進一步說明了服務端不留痕，手機本地資料庫中保留消息記錄的密聊銷毀機制。

對於Android端，當C發送給B的消息M為未讀狀態時可從資料庫表tmsg_Bid_Cid中查看到相關記錄，而當B閱讀消息M 30s之後數據即被銷毀，銷毀后相應記錄也被從tmsg_Bid_Cid表中刪除。說明了對Android端的密聊消息有做到從本地資料庫中刪除記錄的機制。

2、Telegram取證分析

Telegram被稱為是最安全的即時通訊軟體，聊天是Telegram提供的主要功能，支持單聊、群聊、以及Secret Chat，其中Secret Chat是其主要的功能特色。消息端到端加密；不在服務端保留數據；自動銷毀；禁止轉發。Secret Chat模式需雙方同時在線後方可進行通訊，且可自定義自動銷毀時間，一旦會話內容被一方截屏，系統會發送消息通知另一方。Telegram並未對存儲於手機端的相關資料庫文件進行加密處理。因此，對Telegram的取證分析則可省去解密資料庫文件的步驟。

2.1 Telegram的數據分析

本文所分析的Telegram版本信息分別為：iPhone V3.11（從App Store下載，更新日期為2016年8月4日）；Android V3.11.2（從應用寶下載，更新日期為2016年8月16日）。

Android Telegram的主要數據存儲在」/data /data /org. telegram. messenger /files /cache4.db」資料庫文件中；聯繫人信息可從users、user_phones_v6以及use_contacts_v6這三個表中獲取；聊天記錄主要存儲在messages表中，其中，uid表示會話ID（除Secret Chat外，該欄位為好友ID或者群組ID）、date表示消息發送日期、date則存儲詳細的消息內容，該欄位類型為BLOB類型。

iPhone版本的Telegram其主要資料庫文件是Document目錄下的tgdata.db。資料庫文件未被加密，可直觀的查看資料庫中存儲的數據。如：users_v29表中詳細記錄了用戶信息，包括用戶ID、姓名、電話號碼、性別等；contacts_v29表記錄聯繫人列表的用戶ID，相應的詳細信息可通過contacts_v29的uid與users_v29表的uid欄位進行關聯查詢；convesations_v29表記錄會話信息，若為群組會話，則詳細記錄了群組名稱、群成員數以及群成員列表信息等， messages_v29表存儲所有聊天內容信息，其中cid欄位為會話ID、from_id欄位和to_id欄位分別為發送方ID 和接收方ID、 date 欄位表示時間、message欄位為文本類消息內容，media欄位存儲媒體類消息內容，類型為BLOB。

2.2 Telegram Secret Chat的數據分析

根據2.1節分析可知，iPhone版和Android版的聊天記錄分別存儲於Document/tgdata.db的messages_v29表中和org. telegram. messenger/ files/ cache4.db的messages資料庫表中。

iPhone版Secret Chat模式的會話信息同樣存儲於conversations_v29表中，與普通會話的區別在於Secret Chat的會話ID經過特殊處理，表現為以』-』開頭的10位數字形式，相應的chat_version標識為0。雖然普通會話的chat_version欄位同樣設置為0，但其以好友ID作為會話ID。與群組會話不同的是Secret Chat的participants_count欄位值為0，但participants欄位中記錄了參與當前Secret Chat真實的用戶ID信息。圖3為conversations_v29表中Secret Chat、普通會話和群組會話記錄區別。從圖中可看出，當chat_version欄位同為0的情況下，Secret Chat的cid以』-』開頭；當cid均以』-』開頭的情況下，Secret Chat的chat_version欄位的值為0。因此，RecNo為1的記錄表示Secret Chat 會話；RecNo為2的記錄為群組會話；RecNo為3的記錄則表示好友會話。

Android版Telegram的Secret Chat會話信息存儲在dialogs表中，會話ID存儲於did欄位；消息內容存儲於messages表中。通過dialogs表的did欄位與messages表中的uid進行關聯查詢即可獲取到當前會話的聊天記錄。在messages表中除了從會話ID（uid為19位數字形式）以及消息ID（mid以負號開頭）兩方面來區分Secret Chat的消息記錄外，也可從data欄位的前4位元組（用於標識消息的會話類型,此外，不同版該4位元組的數據會相應變化）進行區分（其中0xF9555555表示Secret Chat消息、0xF6A1199E表示系統消息、0x5FE49BC0表示普通會話消息）。

根據上述分析，容易關聯到Secret Chat的消息內容，Telegram的Secret Chat模式支持用戶自定義消息自動銷毀的時間、手動清空歷史記錄以及刪除當前會話。通過採用與2.1.3相同的測試方法分析Telegram對Secret Chat消息的處理方式可知，Telegram iPhone版本和Android版本對Secret Chat模式的消息處理機制基本相似。同樣的，當消息未被銷毀時可從資料庫中獲取到數據，當消息被刪除后則相應的資料庫記錄也會被刪除。從這一層面來講，Telegram對Secret Chat消息的處理機制與Android版釘釘基本相似，均是從手機端本地將相應的消息記錄銷毀。

對釘釘和Telegram的數據分析可看出，不同應用的數據存儲格式不一樣，且同一應用其在不同平台對消息處理機制也可能存在區別。因此，本文以對釘釘、Telegram的分析為基礎，分析具備閱后即焚功能的應用數據特性以及消息處理機制並總結閱后即焚數據的取證分析方法。

閱后即焚數據的特性分析

閱后即焚即為消息被接收閱讀後在特定時間內被銷毀。該銷毀操作包含對存儲於服務端、手機端的數據進行銷毀。根據對釘釘和Telegram的分析可看出，不同應用及平台對數據的銷毀等級不一，如iPhone版釘釘僅對服務端的密聊數據進行銷毀，手機端保留數據；而Android版釘釘和Telegram則將兩端數據同時銷毀。因此，可將閱后即焚的消息處理方式通俗地理解為除服務端不保留數據外，本地資料庫中是否被真正銷毀。

前邊圖2所示的為銷毀后的數據仍保留於手機端的情況。從圖中可看出對手機端數據做保留處理的銷毀機制，其在資料庫表中通過設置特定欄位用於標識記錄是否已被銷毀。記錄為未銷毀狀態時該欄位設置為特定值，當其為銷毀狀態時，則修改該欄位的取值，而其他存儲消息內容等欄位則保持不變。一旦手機端的數據被備份，即可輕而易舉地取到被銷毀的消息內容，因此，認為此類銷毀機制的安全等級較低。

由於數據被刪除后則無法查看到刪除的數據，因此，對於從手機端銷毀數據的情況，從SQLite資料庫存儲原理方面深入分析數據被銷毀前後資料庫文件的變化情況。

圖4所示的為Android釘釘密聊消息記錄被刪除前後，聊天記錄表頁頭的變化對比情況。 圖4 (a) 為數據未銷毀時聊天記錄表tbmsg_Aid_Bid所在頁的頁頭，從中可看出當前頁含有8個單元區、單元區內容的起始地址偏移量為0x0043以及記錄了各單元區內容的地址偏移量。當被銷毀后頁頭的相應區域被相應修改，如圖4 (b)所示，其中記錄單元區數量的兩個位元組被清零，即說明當前頁的所有記錄均被刪除，而記錄單元區內容的起始地址偏移量以及各單元區內容的地址偏移量的相應區域均被修改，且各單元區內容地址偏移量被統一設置為0x0043,即未刪除前的單元區內容起始地址偏移量。

圖5 所示的為Android釘釘密聊消息記錄被刪除前後相應單元區內容的變化對比情況。圖5 (a) 為數據未銷毀時，消息內容分別為「55555555」 和 「66666666」 的記錄所在單元區內容；這兩條記錄被銷毀后，其相應的單元區內容如圖5 (b) 所示，從圖中可看出，記錄被刪除后數據並未真正從資料庫文件中被刪除，且除最後一條記錄的單元區內容前4位元組未被修改外，其他單元區內容的前4位元組均被修改。這說明了數據被刪除后，這部分數據並未被真正刪除，僅是存儲數據的單元區內容頭部被改變。因此，只要該部分區域未被覆蓋，是有可能被恢復的。

圖6、7所示的為Android Telegram Secret Chat消息記錄被刪除前後，messages表頁頭及單元區內容變化對比情況。由圖6可看出，消息記錄被刪除后頁頭的單元區數量以及單元區指針數組均被相應修改。圖7所示的為消息內容分別為」secret chat」、」hi」和」test」三條記錄在單元區內容被刪除前後的對比情況。可看出，當消息記錄被刪除后，資料庫中相應的單元區內容均被清零。因此，該部分記錄一旦被刪除則無法通過刪除恢復技術獲取到。

綜上所述，可認為iPhone釘釘密聊消息的安全級別低於Android釘釘的密聊消息，而Telegram Secret Chat的消息安全級別則相對較高，其數據銷毀后，將被清零。因此，可將銷毀等級理解為是否對手機端保留的數據進行銷毀以及銷毀后數據的可恢復性。銷毀后數據可恢復性越低，則說明銷毀等級越高，相應的數據安全等級也越高。從而，可將閱后即焚的自動銷毀機制分為以下三種情況：1）服務端不留存，手機端保留數據；2）服務端不留存，手機端數據銷毀未清零；3）服務端不留存，手機端數據銷毀且清零。其中第三種情況數據安全等級最高；第二種次之；第一種情況數據安全等級較低。

基於閱后即焚數據的取證方法

由上述對閱后即焚的數據特性分析可知，對上述三種不同銷毀等級的數據相應的取證方法可做適當調整。（1）對於服務端不留存，手機端保留數據的情況。由於資料庫中的數據仍被保留未被銷毀，因此，可與其他普通模式下的聊天記錄的獲取方式一樣，數據可直接從相應資料庫表中查詢獲取。（2）對於服務端不留存，手機端數據銷毀未清零的情況。可通過相應的刪除恢復演算法，恢復到數據。（3）對於服務端不留存，手機端數據被銷毀且清零的情況。若是採用此類銷毀機制，一旦數據被銷毀，則無法恢復獲取。

一般的取證分析方法的可分為以下四個主要步驟：

• STEP1：文件備份及下載。通過手機助手等工具從待取證的手機設備將數據備份到本地。
  
  

• STEP2：數據定位。分析應用數據文件的存儲信息，包括數據包名、用戶信息等重要數據的存儲路徑。

• STEP3：數據分析。主要分析重要的數據文件是否被加密、用戶基本信息、應用功能數據的存儲位置以及數據存儲格式。

• STEP4：數據提取。將STEP3的分析結果，以文檔或報告的方式輸出。
  
  

圖8所示的為具備閱后即焚功能特性的數據取證分析主要流程。從圖中可看出，與一般取證分析流程不同的是，具有閱后即焚功能的數據，需預先分析消息銷毀機制，並針對不同的機制採用與之相適應的取證方法。

總 結：

本文首先分析釘釘和Telegram的數據存儲格式；其次，通過對釘釘的密聊消息、Telegram的Secret Chat消息的銷毀機制的深入分析，總結三種閱后即焚數據的銷毀機制。旨在為取證分析工作提供參考依據。由於手機平台的多樣性以及第三方應用程序的快速更新迭代等因素，本文所分析的取證方法存在一定的局限性。對分析的設備平台方面，本文僅針對已獲取最高許可權的已Root Android手機以及已越獄的iPhone手機作為分析載體，對於其他操作系統平台的應用並未涉及；對應用分析廣度方面，僅選取部分較典型的具備閱后即焚功能特性的第三方應用進行分析，所涉及的應用量廣度不是很全面。因此，分析其他平台的閱后即焚特性以及如何進一步提取規範的取證分析方法有待下一步深入研究。

該文已被中文核心期刊計算機科學收錄，郭舒婷,羅珮允,陳明輝,范潮欽.基於閱后即焚數據的取證分析方法 [J].計算機科學,2016,43（12A）:174-180

第一作者郭舒婷，現為美亞柏科手機取證研發中心研發工程師，自入職以來，一直致力於手機取證方面的研究，在文中以具備閱后即焚功能特性的釘釘、Telegram為例，分析其數據存儲格式，闡述了應用數據取證方法。