Android系統(tǒng)微信數(shù)據(jù)多重融合恢復(fù)方法

朱 兵 蔣烈輝 葛方麗 薛 兵

1(鄭州大學(xué) 河南 鄭州 450000) 2(信息工程大學(xué) 河南 鄭州 450000) 3(鄭州信息工程大學(xué)先進(jìn)技術(shù)研究院 河南 鄭州 450000)

0 引 言

現(xiàn)如今智能手機(jī)的系統(tǒng)多樣，Android系統(tǒng)占據(jù)了中國(guó)甚至全球絕大部分的手機(jī)市場(chǎng)。微信作為最大的獨(dú)立消息傳遞應(yīng)用程序之一，其功能多樣為智能終端用戶提供了免費(fèi)文本和語(yǔ)音通信等服務(wù)[1]。正是由于微信的流行，犯罪分子利用微信進(jìn)行違法犯罪行為越為突出。具有一定反偵察意識(shí)的犯罪分子會(huì)故意刪除微信上的數(shù)據(jù)，恢復(fù)微信數(shù)據(jù)是司法取證的關(guān)鍵，從中獲得犯罪線索或關(guān)鍵證據(jù)會(huì)直接影響案件能否成功偵破。因此，針對(duì)Android手機(jī)微信的數(shù)據(jù)恢復(fù)技術(shù)研究有著普遍且十分重要的意義。

1 國(guó)內(nèi)外研究現(xiàn)狀

童宇等[2]提出了基于SQLite數(shù)據(jù)庫(kù)的空閑頁(yè)鏈表的恢復(fù)方法對(duì)已刪除的微信聊天記錄進(jìn)行了恢復(fù)和提取，但該方法只是從微信數(shù)據(jù)庫(kù)文件“EnMicroMsg.db”中進(jìn)行刪除恢復(fù)，因此可恢復(fù)數(shù)據(jù)源并不完整，實(shí)驗(yàn)驗(yàn)證其恢復(fù)率只能達(dá)到27%。張艷姣[3]提出了基于SQLite數(shù)據(jù)庫(kù)的自由塊鏈表的恢復(fù)方法，該方法也是依賴微信主庫(kù)實(shí)現(xiàn)微信數(shù)據(jù)的恢復(fù)。這兩種傳統(tǒng)微信數(shù)據(jù)恢復(fù)方法恢復(fù)數(shù)據(jù)源并不完整、恢復(fù)率低。文獻(xiàn)[4]分析Whats App的表結(jié)構(gòu)、信息接收與數(shù)據(jù)刪除機(jī)制，認(rèn)為此應(yīng)用不會(huì)從SQLite中直接刪除數(shù)據(jù)，可以提取被邏輯刪除的數(shù)據(jù)，恢復(fù)了SQLite被刪除的數(shù)據(jù)。文獻(xiàn)[5]研究了Firefox中數(shù)據(jù)庫(kù)表格式，從數(shù)據(jù)庫(kù)中存儲(chǔ)的查詢記錄入手，利用回滾日志文件實(shí)現(xiàn)了數(shù)據(jù)庫(kù)已刪除記錄的恢復(fù)。但是此方法局限性較大，僅適用于特定應(yīng)用。文獻(xiàn)[6]針對(duì)Android手機(jī)的存儲(chǔ)技術(shù)進(jìn)行研究，提出了一種基于SQLite存儲(chǔ)結(jié)構(gòu)的數(shù)據(jù)恢復(fù)方法和一種基于SQLite預(yù)寫(xiě)日志的數(shù)據(jù)恢復(fù)方法，解決了預(yù)寫(xiě)日志存儲(chǔ)分片的問(wèn)題，從日志文件的角度對(duì)數(shù)據(jù)進(jìn)行刪除恢復(fù)。該方法并不適用于微信的刪除恢復(fù)，研究發(fā)現(xiàn)微信中涉及恢復(fù)的索引庫(kù)日志文件是回滾日志。文獻(xiàn)[7]用靜態(tài)分析的方法研究了微信的加密方式，在此基礎(chǔ)上提出了MTP協(xié)議下恢復(fù)手機(jī)中被刪除微信數(shù)據(jù)文件的方法,該方法不會(huì)損傷手機(jī)的存儲(chǔ)設(shè)備，但對(duì)微信具體的刪除恢復(fù)效果并未詳述。文獻(xiàn)[8]研究了微信信息的數(shù)據(jù)取證原理，重點(diǎn)對(duì)加密聊天記錄數(shù)據(jù)庫(kù)進(jìn)行了詳細(xì)的解密分析,并給出了在不同取證環(huán)境下的數(shù)據(jù)庫(kù)解密過(guò)程,但是并未詳細(xì)描述解密后的微信數(shù)據(jù)恢復(fù)方法。

從以上研究可以看出，目前傳統(tǒng)的微信取證技術(shù)研究多依賴于主庫(kù)文件，并未對(duì)微信索引庫(kù)文件和日志文件有所研究。但是在我們的研究取證工作中發(fā)現(xiàn)索引庫(kù)和日志文件中有大量可恢復(fù)數(shù)據(jù)。綜上，本文的研究融合了微信主庫(kù)、索引庫(kù)、索引庫(kù)回滾日志文件的數(shù)據(jù)對(duì)微信刪除數(shù)據(jù)進(jìn)行恢復(fù)。解密和脫密數(shù)據(jù)庫(kù)文件和回滾日志文件獲取多重?cái)?shù)據(jù)，提出并詳細(xì)介紹Android系統(tǒng)微信數(shù)據(jù)多重融合恢復(fù)方法的算法流程，最后進(jìn)行對(duì)比實(shí)驗(yàn)驗(yàn)證本文方法的有效性。

2 SQLite數(shù)據(jù)結(jié)構(gòu)分析

2.1 SQLite數(shù)據(jù)庫(kù)文件

微信的主庫(kù)和索引庫(kù)文件都屬于SQLite類型的數(shù)據(jù)庫(kù)文件，在該數(shù)據(jù)庫(kù)中，微信數(shù)據(jù)分別存儲(chǔ)在多個(gè)Btree頁(yè)中，其中表的索引存放在B-tree頁(yè)中，表數(shù)據(jù)存放在B+tree頁(yè)中。而所有表或索引的根頁(yè)編號(hào)都存儲(chǔ)在系統(tǒng)表sqlite_master中，系統(tǒng)表的根頁(yè)為page1。

數(shù)據(jù)庫(kù)中一個(gè)Btree頁(yè)由頁(yè)頭、單元指針數(shù)組、未分配空間和單元內(nèi)容區(qū)四部分組成。Btree頁(yè)內(nèi)部進(jìn)行空間分配和回收是以數(shù)據(jù)單元為基本單位，一個(gè)單元包含一條payload(單元記錄)。頁(yè)內(nèi)所有單元的內(nèi)容都是由頁(yè)的底部向上增長(zhǎng)，稱為單元內(nèi)容區(qū)。由于單元大小可變，所以需要記錄其起始位置，即單元指針。頁(yè)頭之后單元指針數(shù)組中保存著單元指針。單元指針數(shù)組是由上向下增長(zhǎng)，與單元內(nèi)容區(qū)相向增長(zhǎng)。一個(gè)完整的SQLite數(shù)據(jù)庫(kù)文件主要包含文件頭和Btree頁(yè)[9]。SQLite數(shù)據(jù)庫(kù)文件結(jié)構(gòu)如圖1所示。

數(shù)據(jù)庫(kù)文件頁(yè)面中頁(yè)頭的偏移量為1的兩個(gè)字節(jié)代表第一個(gè)自由塊的偏移量，自由塊的前2個(gè)字節(jié)指向下一個(gè)自由塊，形成自由塊鏈表直到自由塊前2個(gè)字節(jié)值為0，表示沒(méi)有下一個(gè)自由塊[4]。文件頭偏移量為32的四個(gè)字節(jié)代表空閑頁(yè)鏈表首指針，空閑頁(yè)有兩種類型：trunk page(主干頁(yè))和leaf page(葉子頁(yè))。文件頭偏移為32處的指針指向空閑鏈表的第一個(gè)主干頁(yè)，每個(gè)主干頁(yè)指向多個(gè)葉子頁(yè)[10]。

2.2 索引庫(kù)回滾日志文件

回滾日志文件始終位于與對(duì)應(yīng)數(shù)據(jù)庫(kù)文件相同的目錄中，并且具有與數(shù)據(jù)庫(kù)文件相同的名稱，但是附加了字符串“-journal”[5]。日志文件的結(jié)構(gòu)主要由日志頭部與一系列回滾日志記錄頁(yè)組成。回滾日志頁(yè)面的前4個(gè)字節(jié)表示數(shù)據(jù)庫(kù)文件的頁(yè)數(shù)，隨后N個(gè)字節(jié)為頁(yè)大小，表示事務(wù)開(kāi)始前數(shù)據(jù)庫(kù)文件中對(duì)應(yīng)頁(yè)的原始數(shù)據(jù)。最后4個(gè)字節(jié)為校驗(yàn)和，用以校驗(yàn)當(dāng)前記錄是否有效[6]?；貪L日志文件存儲(chǔ)結(jié)構(gòu)如圖2所示。

3 解密與脫密數(shù)據(jù)文件

SQLite數(shù)據(jù)庫(kù)被廣泛應(yīng)用于 Android手機(jī)來(lái)保存大量的用戶數(shù)據(jù)，微信應(yīng)用的用戶數(shù)據(jù)會(huì)由SQL存儲(chǔ)引擎存儲(chǔ)和加解密引擎加密存儲(chǔ)到微信本地目錄下的SQLite數(shù)據(jù)庫(kù)中[7]。微信主庫(kù)、索引庫(kù)、索引庫(kù)回滾日志文件都需要解密和脫密之后才能進(jìn)行數(shù)據(jù)分析和恢復(fù)，因此微信數(shù)據(jù)庫(kù)文件和日志文件的解密、脫密是在獲取數(shù)據(jù)之前需要做的重要工作。

3.1 主庫(kù)文件解密與脫密

EnMicroMsg.db(微信主庫(kù))文件的解密密鑰password是IMEI(國(guó)際移動(dòng)設(shè)備身份號(hào)碼)與UIN(用戶信息)拼接后計(jì)算32位 MD5值，然后取前7位。即：

Hash=MD5(IMEI+UIN)

password=Hash[0-6]

微信主庫(kù)脫密密鑰的獲得為：

dec_key=kdf(password,pass_sz,salt,salt_sz,

Kdf_Iter,key_sz)

其中：“pass_sz”是密碼的長(zhǎng)度；“salt”是加密數(shù)據(jù)庫(kù)“EnMicroMsg.db”的前16字節(jié)[8]；“salt_sz”是鹽值的長(zhǎng)度;“Kdf_Iter”是PBKDF2的迭代次數(shù)，默認(rèn)值為4 000，“key_sz”是密鑰的長(zhǎng)度;主庫(kù)的默認(rèn)頁(yè)面大小page_size為1 024。

主庫(kù)獲取脫密密鑰的完整計(jì)算過(guò)程如圖3所示。

3.2 索引庫(kù)及索引庫(kù)回滾日志文件解密與脫密

FTS5IndexMicroMsg_encrypt.db(微信索引庫(kù))文件和FTS5IndexMicroMsg_encrypt.db-journal(微信索引庫(kù)回滾日志)文件的解密和方式相同，本節(jié)僅闡述微信索引庫(kù)解密和脫密過(guò)程。與微信主庫(kù)獲取解密密鑰不同的是，如果UIN是負(fù)值不能直接進(jìn)行MD5拼接，需要把它加上一個(gè)最大無(wú)符號(hào)數(shù)Max之后得到的正數(shù)作為最終的UIN與IMEI進(jìn)行MD5拼接。

FTS5IndexMicroMsg_encrypt.db(加密微信索引庫(kù))文件的解密密鑰password是IMEI、UIN、微信id三者拼接后計(jì)算32位 MD5值，然后取前7位。即：

Hash=MD5(IMEI+UIN+WX_ID) orHash=

MD5(IMEI+(UIN+Max)+WX_ID)

password=Hash[0-6]

索引庫(kù)與主庫(kù)的解密參數(shù)有所不同，迭代次數(shù)kdf_iter為64 000，索引庫(kù)的默認(rèn)頁(yè)面大小page_size為4 096，微信索引庫(kù)脫密密鑰的獲得為：

Salt=ByteCopy(Pages[0][:16])

HMAC_Salt=ByteCopy(Salt)

Key=pbkdf2.Key(password,salt,Kdf_Iter,32,sha1.New)

HMAC_Key=pbkdf2.Key(Key,HMAC_Salt,2,32,sha1.New)

索引庫(kù)獲取脫密密鑰的完整計(jì)算過(guò)程如圖4所示。

4 多重融合恢復(fù)方法

4.1 恢復(fù)方法

通過(guò)對(duì)微信數(shù)據(jù)庫(kù)文件內(nèi)部結(jié)構(gòu)研究發(fā)現(xiàn)，除了微信主庫(kù)中的message表中存儲(chǔ)的有微信消息記錄以外，微信索引庫(kù)的FTS5IdexMessage_content表和FTS5IdexMessage_data表中均存儲(chǔ)有微信消息記錄。前者以明文的形式存儲(chǔ)未被刪除的記錄，后者主要存儲(chǔ)的是被刪除的記錄。Android手機(jī)新版本微信所采用的日志模式為 PERSIST模式，微信索引庫(kù)對(duì)應(yīng)的回滾日志文件并沒(méi)有被刪除，僅清空頭部標(biāo)識(shí)。

上述發(fā)現(xiàn)為本文Android手機(jī)微信數(shù)據(jù)的恢復(fù)帶來(lái)了新的思路，不僅可以在微信主庫(kù)中獲取數(shù)據(jù)，微信索引庫(kù)和索引庫(kù)回滾日志文件中也能獲取數(shù)據(jù)。因此本文提出一種基于Android系統(tǒng)微信數(shù)據(jù)的多重融合恢復(fù)方法，該方法采用基于SQLite數(shù)據(jù)庫(kù)的空閑頁(yè)鏈表或者自由塊鏈表[9]的恢復(fù)技術(shù)融合了微信主庫(kù)、索引庫(kù)、回滾日志文件對(duì)微信刪除數(shù)據(jù)進(jìn)行恢復(fù)。下面詳細(xì)介紹Android系統(tǒng)微信數(shù)據(jù)的多重融合恢復(fù)方法：

1) 主庫(kù)采用傳統(tǒng)恢復(fù)方法進(jìn)行數(shù)據(jù)恢復(fù)，即基于SQLite數(shù)據(jù)庫(kù)的空閑頁(yè)鏈表或者自由塊鏈表的恢復(fù)方法。

2) 根據(jù)數(shù)據(jù)庫(kù)文件內(nèi)部結(jié)構(gòu)直接對(duì)微信索引庫(kù)數(shù)據(jù)進(jìn)行提取和恢復(fù)。

3) 計(jì)算索引庫(kù)回滾日志文件的校驗(yàn)和。

4) 利用校驗(yàn)和對(duì)回滾日志文件頁(yè)記錄進(jìn)行分組恢復(fù)。

5) 主庫(kù)和索引庫(kù)的恢復(fù)數(shù)據(jù)進(jìn)行對(duì)比去重。

6) 回滾日志的恢復(fù)數(shù)據(jù)與步驟5)已經(jīng)對(duì)比去重之后的數(shù)據(jù)再次進(jìn)行對(duì)比去重。

7) 將最終恢復(fù)的數(shù)據(jù)寫(xiě)入數(shù)據(jù)庫(kù)，完成所有數(shù)據(jù)恢復(fù)。

多重融合數(shù)據(jù)恢復(fù)方法如圖5所示。

4.2 索引庫(kù)數(shù)據(jù)恢復(fù)算法

微信索引庫(kù)中FTS5IdexMessage_content表存儲(chǔ)著未被刪除的消息記錄，而FTS5IdexMessage_data表中主要存儲(chǔ)著已經(jīng)被刪除的微信消息記錄，但也會(huì)存在部分沒(méi)有被刪除的消息記錄。所以本文在恢復(fù)時(shí)，需要融合這兩個(gè)表中的數(shù)據(jù)進(jìn)行對(duì)比去重，其恢復(fù)算法為：

Begin:

DataBase Db=OpenDb(“path”);

//打開(kāi)path路徑下的數(shù)據(jù)庫(kù)

//獲取該數(shù)據(jù)庫(kù)中FTS5IdexMessage_content表的根頁(yè)號(hào)

int crpage=getRootPage(“FTS5IdexMessage_content”,Db);

closeDB(Db);

//關(guān)閉數(shù)據(jù)庫(kù)句柄

File file=OpenFile(“r”,“path”);

//將數(shù)據(jù)庫(kù)文件以只讀方式打開(kāi)

//將文件句柄定位到FTS5IdexMessage_content表開(kāi)始位置

feek(file,pageNum*crpage,BEGIN);

String temp=read(file,4,2);

//當(dāng)前第四個(gè)位置開(kāi)始兩個(gè)字節(jié)為本頁(yè)單元內(nèi)容的個(gè)數(shù)

int cNum=int.Parse(temp);

for(int i=0;i

int cSize=getCSzie(file);

//獲取當(dāng)前單元區(qū)內(nèi)容大小

String content=read(file,0,cSize);

//讀取當(dāng)前單元內(nèi)容

write(“newFile1”,content);

//將內(nèi)容寫(xiě)入到newFile1中

}

closeFile(file);

end

//對(duì)FTS5IdexMessage_data也執(zhí)行上述偽代碼邏輯，

//然后存入newFile2中

File file1=OpenFile(“r”,“newFile1”);

File file2=OpenFile(“r”,“newFile2”);

File file=OpenFile(“r”,“newFile”);

//對(duì)文件句柄file1與file2內(nèi)容進(jìn)行去重合并，

//然后寫(xiě)入到file中

mergeOperate(file1,file2,file);

WriteDb(“newDb”,file,type);

//根據(jù)文件中的type標(biāo)記將內(nèi)容寫(xiě)入數(shù)據(jù)庫(kù)中

closeFile(file1,file2,file);

//關(guān)閉文件句柄

4.3 回滾日志恢復(fù)算法

Android 4.1.1版本及之后的微信，每次數(shù)據(jù)庫(kù)事務(wù)結(jié)束后，回滾日志文件仍然保留，文件頭部標(biāo)識(shí)被清空。根據(jù)回滾日志文件結(jié)構(gòu)，日志文件的每個(gè)記錄頁(yè)的最后4個(gè)字節(jié)均為校驗(yàn)和。計(jì)算頁(yè)面數(shù)據(jù)的校驗(yàn)和時(shí),校驗(yàn)和初始值是隨機(jī)生成的,會(huì)寫(xiě)入回滾日志文件頭信息中，所以針對(duì)日志頭被清空的情況，逆向分析計(jì)算校驗(yàn)和，根據(jù)校驗(yàn)和對(duì)日志文件進(jìn)行數(shù)據(jù)分組，提取回滾日志文件中的數(shù)據(jù)。

校驗(yàn)和chkSum是一個(gè)無(wú)符號(hào)的32位整數(shù)，計(jì)算公式如下：

top=size(page)/200

(1)

offset=size(page) mod 200+4

(2)

offset+200(i-1))

(3)

通過(guò)式(1)-式(3)得到rChkSum后截取為 32位無(wú)符號(hào)整數(shù)得到最終校驗(yàn)和chkSum。其中：top表示本頁(yè)記錄選取字節(jié)數(shù)；offset為首字節(jié)偏移量；getVal為取當(dāng)前字節(jié)值[10]；absAddr為記錄頁(yè)面起始位置的指針。微信索引庫(kù)回滾日志文件數(shù)據(jù)恢復(fù)的算法為：

Begin:

File Rj=OpenFile(“r”,“path”);

//打開(kāi)path路徑下的日志文件

chkSum=getChkSum();

//根據(jù)上述公式獲取校驗(yàn)和

String[] contentlist=getContentSplit(Rj,chkSum)

//將日志文件中的內(nèi)容按校驗(yàn)和chkSum分割開(kāi)，

//分割以后存儲(chǔ)在contentlist里

File newFile=OpenDb(“w”,“newPath”);

//打開(kāi)對(duì)應(yīng)路徑下的文件

Write(newFile,contentList);

//將得到的回滾日志數(shù)據(jù)寫(xiě)入新文件中

closeFile(Rj);

//關(guān)閉日志文件句柄

closeFile(newFile);

//關(guān)閉新文件句柄

end

4.4 對(duì)比去重算法

本文方法對(duì)索引庫(kù)中兩個(gè)表恢復(fù)出來(lái)的數(shù)據(jù)進(jìn)行對(duì)比去重，對(duì)主庫(kù)和索引庫(kù)中恢復(fù)出來(lái)的數(shù)據(jù)進(jìn)行融合對(duì)比去重，再與回滾日志文件中的恢復(fù)數(shù)據(jù)進(jìn)行對(duì)比去重?；謴?fù)數(shù)據(jù)對(duì)比去重算法思想為：恢復(fù)的每一條數(shù)據(jù)包含createTime時(shí)間戳(固定6字節(jié))、talker交互方和content聊天內(nèi)容。依據(jù)時(shí)間戳對(duì)恢復(fù)數(shù)據(jù)逐條進(jìn)行插入排序，判斷時(shí)間戳是否相同，逐字節(jié)對(duì)比聊天內(nèi)容，如果不同插入恢復(fù)數(shù)據(jù)庫(kù)，如果相同則刪除重復(fù)記錄。

恢復(fù)數(shù)據(jù)對(duì)比去重具體算法如下：

Begin:

mergeOperate(file1,file2,file):

//獲取文件1和2中的數(shù)據(jù)個(gè)數(shù)

int num1=getDataNum(file1);

int num2=getDataNum(file2);

//創(chuàng)建2個(gè)基本元素結(jié)構(gòu)為DataType的數(shù)組用來(lái)存儲(chǔ)

//2個(gè)文件中數(shù)據(jù)，包括時(shí)間戳以及聊天內(nèi)容等

DataType[] datas1=new DataType[num1];

DataType[] datas2=new DataType[num2];

//分別獲取文件1和文件2中所有的數(shù)據(jù)并存儲(chǔ)到數(shù)組中

getData(file1,datas1);

getData(file2,datas2);

//將數(shù)據(jù)按照時(shí)間戳從小到大排序

sortDataByTimestamp(datas1);

sortDataByTimestamp(datas2);

//創(chuàng)建一個(gè)棧用來(lái)存儲(chǔ)去重后的數(shù)據(jù)

InitStack(datas);

//循環(huán)去重

for(int i=0,j=0;i

//如果兩個(gè)數(shù)據(jù)的時(shí)間戳相等且聊天內(nèi)容相等,將數(shù)據(jù)

//去重后放入棧中

if(equal(datas1[i].timestamp,datas2[j].times tamp&&

equal(datas1[i].content,datas2[j].content){

push(datas,datas1[i]);

}else{

push(datas,datas1[i]);

push(datas,datas2[j]);

}

}

//將剩余數(shù)據(jù)放入棧中

while(i

push(datas,datas1[i]);

i++;

}

while(j

push(datas,datas2[j]);

j++;

}

write(file,datas);

//將去重后的數(shù)據(jù)寫(xiě)入file文件

end

5 實(shí) 驗(yàn)

實(shí)驗(yàn)選用三組不同數(shù)據(jù)量的Android手機(jī)作為實(shí)驗(yàn)對(duì)象。數(shù)據(jù)組1中10部手機(jī)搭載Android9.0，微信版本為7.0.6，微信數(shù)據(jù)量2 560條；數(shù)據(jù)組2中10部手機(jī)搭載Android9.0，微信版本為7.0.3，微信數(shù)據(jù)量4 690條；數(shù)據(jù)組3中10部手機(jī)搭載Android9.0，微信版本為7.0.6，微信數(shù)據(jù)量11 250條。實(shí)驗(yàn)使用工具為WinHex、DB Browser for SQLCipher.exe、Navicat Premium 12等軟件。

5.1 實(shí)驗(yàn)過(guò)程

本實(shí)驗(yàn)采用Android手機(jī)微信多重融合恢復(fù)方法分別對(duì)主庫(kù)、索引庫(kù)、索引庫(kù)回滾日志文件這三部分進(jìn)行數(shù)據(jù)恢復(fù)，再對(duì)恢復(fù)出來(lái)的數(shù)據(jù)進(jìn)行對(duì)比去重。并且與傳統(tǒng)微信數(shù)據(jù)恢復(fù)方法進(jìn)行對(duì)比，驗(yàn)證本文方法的有效性。

選取數(shù)據(jù)組1實(shí)驗(yàn)中一部手機(jī)的數(shù)據(jù)，對(duì)主庫(kù)、索引庫(kù)刪除數(shù)據(jù)恢復(fù)結(jié)果包括聊天時(shí)間、交互方和聊天數(shù)據(jù)，主庫(kù)中恢復(fù)出三條數(shù)據(jù)，索引庫(kù)中恢復(fù)出8條數(shù)據(jù)，如圖6、圖7所示。

在回滾日志中的記錄即為數(shù)據(jù)庫(kù)文件中存儲(chǔ)頁(yè)面內(nèi)容的數(shù)據(jù)副本，所以只需從頭到尾讀取回滾日志分組，并將日志中找到的內(nèi)容寫(xiě)到數(shù)據(jù)庫(kù)文件的適當(dāng)位置?；貪L日志文件提取出一條數(shù)據(jù)如圖8所示。

最后融合從主庫(kù)、索引庫(kù)和索引庫(kù)回滾日志這三個(gè)文件中提取恢復(fù)的數(shù)據(jù)進(jìn)行對(duì)比去重，如圖9所示。

5.2 對(duì)比實(shí)驗(yàn)結(jié)果及分析

本文方法對(duì)比傳統(tǒng)的微信恢復(fù)方法分別對(duì)三組不同數(shù)據(jù)量的微信數(shù)據(jù)進(jìn)行刪除恢復(fù)。實(shí)驗(yàn)結(jié)果分別如表1、表2所示。

表1 傳統(tǒng)恢復(fù)方法實(shí)驗(yàn)結(jié)果

表2 多重?cái)?shù)據(jù)融合恢復(fù)方法實(shí)驗(yàn)結(jié)果

續(xù)表2

從表1實(shí)驗(yàn)結(jié)果數(shù)據(jù)中發(fā)現(xiàn)，傳統(tǒng)恢復(fù)方法的恢復(fù)數(shù)據(jù)源單一，只能從微信主庫(kù)中恢復(fù)數(shù)據(jù)。傳統(tǒng)空閑頁(yè)鏈表法對(duì)數(shù)據(jù)組2恢復(fù)效果最好，恢復(fù)率達(dá)到了18.3%，對(duì)三組數(shù)據(jù)的平均恢復(fù)率為16.8%。傳統(tǒng)自由塊鏈表法對(duì)數(shù)據(jù)組3的恢復(fù)效果最好，恢復(fù)率達(dá)到了17.3%，對(duì)三組數(shù)據(jù)的平均恢復(fù)率為15.4%。

從表2實(shí)驗(yàn)結(jié)果數(shù)據(jù)可以發(fā)現(xiàn)，多重?cái)?shù)據(jù)融合恢復(fù)方法擴(kuò)大了恢復(fù)數(shù)據(jù)源，可以對(duì)主庫(kù)、索引庫(kù)、索引庫(kù)日志文件分別進(jìn)行數(shù)據(jù)恢復(fù)。三組微信數(shù)據(jù)的恢復(fù)中，多重?cái)?shù)據(jù)融合恢復(fù)方法在數(shù)據(jù)組2中的恢復(fù)效果最好，融合對(duì)比去重后恢復(fù)數(shù)據(jù)記錄364條，恢復(fù)率達(dá)到了60.6%，數(shù)據(jù)組3的數(shù)據(jù)量最大，但是恢復(fù)效果卻不是最好的，融合對(duì)比去重后恢復(fù)數(shù)據(jù)記錄711條，只達(dá)到了59.2%。本文方法對(duì)三組數(shù)據(jù)的平均恢復(fù)率達(dá)到了59.5%，對(duì)比傳統(tǒng)的微信數(shù)據(jù)恢復(fù)方法恢復(fù)率顯著提高，進(jìn)一步驗(yàn)證了本文方法的可行性和有效性。

6 結(jié) 語(yǔ)

隨著網(wǎng)絡(luò)時(shí)代的到來(lái)，即時(shí)通信軟件更加受到了人們歡迎，人們常常在生活、辦公中都會(huì)用微信進(jìn)行溝通交流。與此同時(shí)，微信的數(shù)據(jù)恢復(fù)對(duì)于手機(jī)取證也是非常重要的環(huán)節(jié)之一。本文在傳統(tǒng)微信數(shù)據(jù)恢復(fù)方法的基礎(chǔ)上，提出一種Android系統(tǒng)微信數(shù)據(jù)的多重融合恢復(fù)方法對(duì)已刪除的微信聊天記錄從微信主庫(kù)、索引庫(kù)和索引庫(kù)回滾日志文件中進(jìn)行了恢復(fù)和提取，顯著提高了微信數(shù)據(jù)的恢復(fù)率。

此外，由于微信版本的不斷更新，我們?cè)趯?shí)驗(yàn)中發(fā)現(xiàn)數(shù)據(jù)量越大，能夠從索引庫(kù)和回滾日志中恢復(fù)出的數(shù)據(jù)越有限。并且還存在記錄被部分覆蓋和全覆蓋，在這種情況下記錄只能部分恢復(fù)或者無(wú)法恢復(fù)，降低了數(shù)據(jù)恢復(fù)率。這些微信數(shù)據(jù)恢復(fù)中遇到的困難也是今后研究的方向。