本發(fā)明涉及一種基于用戶真實(shí)流量數(shù)據(jù)來對(duì)App的Host/Url特征集進(jìn)行補(bǔ)全的方法。具體來說，涉及一種當(dāng)給定某個(gè)App的初始Host/Url特征集后，直接從多個(gè)用戶的真實(shí)流量數(shù)據(jù)中挖掘出歸屬于該App的Host/Url特征，從而對(duì)初始特征集進(jìn)行補(bǔ)全的方法。

背景技術(shù)：

進(jìn)入了后PC時(shí)代，運(yùn)行于各種智能終端的移動(dòng)App已成為互聯(lián)網(wǎng)流量的主要提供者。截止2015年11月，在全球二大主要的App市場(chǎng)中，Google Play中已有120萬+個(gè)App，而Apple Store中的數(shù)量也已達(dá)到112萬+。這些App在為人們提供豐富多彩的網(wǎng)絡(luò)服務(wù)的同時(shí)，也貢獻(xiàn)了海量的互聯(lián)網(wǎng)流量。然而，與App市場(chǎng)繁榮發(fā)展極不相稱的是，運(yùn)營商及網(wǎng)絡(luò)安全部門對(duì)這些來自App的流量的解析能力卻大大的滯后。

這些運(yùn)行于智能終端的App，主要通過HTTP和HTTPS協(xié)議與各自的服務(wù)器進(jìn)行通訊。從數(shù)據(jù)包的外在表征看，這些來自App的HTTP和HTTPS通信數(shù)據(jù)與其他使用同樣協(xié)議的通信數(shù)據(jù)沒有任何本質(zhì)的差別，再加上待識(shí)別App的數(shù)量極為龐大，造成了這一問題解決的不易。

已有學(xué)者開展了從網(wǎng)絡(luò)數(shù)據(jù)中提取App指紋方法的研究，按照所采用特征的不同，可將其歸為以下幾類：

(1)利用HTTP頭(HTTP header)中的User-Agent(UA)信息:HTTP header是HTTP協(xié)議的一部分，是通過HTTP協(xié)議在發(fā)出請(qǐng)求(request)或者應(yīng)答(response)時(shí)封裝在其頭部用來定義HTTP傳輸參數(shù)的一些字段。

在HTTP header中包含多個(gè)域，其中User-Agent(UA)部分是HTTP客戶端向訪問網(wǎng)站提供的所使用瀏覽器類型、操作系統(tǒng)、瀏覽器內(nèi)核等信息的標(biāo)識(shí)。蘋果公司在其iOS開發(fā)者指南中建議在UA中加入有關(guān)App的標(biāo)識(shí)信息。直接從UA中讀取App標(biāo)識(shí)看來是一個(gè)非?？旖萦行У姆椒?，因此有很多方法直接依據(jù)UA中的信息進(jìn)行識(shí)別。然而，盡管iOS做了這樣的建議，但由于并非是強(qiáng)制要求，因而并不是所有開發(fā)者都會(huì)遵循這一建議。安卓則更是連這樣的建議都沒有。我們?cè)趯?shí)際測(cè)試中也發(fā)現(xiàn)，有些App在運(yùn)行時(shí)會(huì)發(fā)出多個(gè)不同UA的HTTP請(qǐng)求，有些甚至將其偽裝成一個(gè)瀏覽器的訪問，有些則是填入一些關(guān)于安卓系統(tǒng)版本等操作系統(tǒng)的信息。因此，基于UA特征的方法在實(shí)際應(yīng)用中具有局限性。

(2)利用Ads或analytics(A&A)輔助服務(wù)提供的App標(biāo)識(shí)：有很多App，尤其是那些免費(fèi)的App，常常會(huì)在提供本身服務(wù)之外加入一些輔助服務(wù)，比如ads或analytics(簡(jiǎn)稱：A&A)。A&A服務(wù)在向服務(wù)器發(fā)送HTTP請(qǐng)求時(shí)，通常會(huì)帶有宿主App的標(biāo)識(shí)。然而，A&A服務(wù)的數(shù)據(jù)流量通常十分稀少，而且可能被用戶所屏蔽(如安裝Adblock等工具)，造成能實(shí)際被檢測(cè)到的概率較低。此外，我們?cè)跍y(cè)試中還發(fā)現(xiàn)，有些App的A&A服務(wù)發(fā)送的宿主App標(biāo)識(shí)并非是App的名稱，而只一個(gè)ID，無法做到直接對(duì)應(yīng)。

(3)利用Host/Url信息：不同的App總是會(huì)和各自的服務(wù)器進(jìn)行聯(lián)系，因而通過用戶流量數(shù)據(jù)中App所訪問的Host/Url信息也能夠?qū)ζ溥M(jìn)行有效識(shí)別。

獲得App的Host/Url特征集是在用戶流量數(shù)據(jù)中對(duì)App進(jìn)行識(shí)別的前提，目前大多采用對(duì)App進(jìn)行自動(dòng)測(cè)試的方法。然而，對(duì)App進(jìn)行的自動(dòng)測(cè)試無法窮盡所有可能的執(zhí)行路徑，因而不能獲得全量的Host/Url特征集。本發(fā)明針對(duì)利用Host/Url特征對(duì)流量數(shù)據(jù)中的App進(jìn)行識(shí)別的問題，如何對(duì)App不完備的Host/Url特征集進(jìn)行補(bǔ)全，提出了一種基于用戶真實(shí)流量數(shù)據(jù)的補(bǔ)全方案。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的在于針對(duì)現(xiàn)有技術(shù)的不足，提出了一種基于用戶真實(shí)流量數(shù)據(jù)補(bǔ)全App的Host/Url特征集的方法。

本發(fā)明的目的是通過以下技術(shù)方案來實(shí)現(xiàn)的：一種基于用戶真實(shí)流量數(shù)據(jù)補(bǔ)全App的Host/Url特征集的方法，該方法包括以下步驟：

(1)從某個(gè)App的初始Host/Url特征集中選取種子特征集，記為{url_seed}。

(2)對(duì)種子特征集{url_seed}中的每個(gè)成員，都在多用戶的真實(shí)流量數(shù)據(jù)中進(jìn)行特征補(bǔ)全。

(3)從補(bǔ)全后的特征集中選取新的種子，構(gòu)成新的種子特征集，迭代地進(jìn)行特征補(bǔ)全，直到不再得到新的種子為止。

進(jìn)一步地，所述的步驟(1)中從某個(gè)App的初始Host/Url特征集中選取種子特征集，具體包括以下步驟：

(1)統(tǒng)計(jì)該App初始特征集中的每個(gè)Host/Url特征出現(xiàn)在不同App的Host/Url特征集中的次數(shù)。只出現(xiàn)在該App中則次數(shù)為1，出現(xiàn)在2個(gè)不同的App中則次數(shù)為2，以此類推。

(2)種子特征集{url_seed}中的成員，將優(yōu)先選取所有出現(xiàn)在不同App的特征集中次數(shù)只有1次的Host/Url特征。如果在初始特征集中沒有出現(xiàn)次數(shù)只有1次的Host/Url特征，則選取出現(xiàn)次數(shù)最少的幾個(gè)Host/Url特征，將其作為種子特征集的唯一成員。

進(jìn)一步地，所述的步驟(2)中對(duì)種子特征集{url_seed}中的每個(gè)種子url_i，都在多用戶的真實(shí)流量數(shù)據(jù)中進(jìn)行特征補(bǔ)全，具體包括以下步驟：

(1)從多個(gè)用戶各自的流量數(shù)據(jù)中提取種子url_i訪問時(shí)刻前后一段時(shí)間范圍內(nèi)的Host/Url特征，構(gòu)成{url_cand}。

(2)對(duì)來自N個(gè)用戶的候選特征集{url_cand}_k(k＝1,2,...,N)進(jìn)行關(guān)聯(lián)分析，得到若干個(gè)頻繁項(xiàng)集。

(3)將得到的頻繁項(xiàng)集中不屬于初始Host/Url特征集的新Host/Url特征提取出來，對(duì)初始特征集進(jìn)行補(bǔ)全。

本發(fā)明的有益效果是：給定App不完備的初始特征集，只需在初始特征集中提取種子，利用種子在多用戶的真實(shí)流量數(shù)據(jù)中將屬于該App的其他Host/Url特征提取出來，從而對(duì)初始特征集進(jìn)行了補(bǔ)全。由于補(bǔ)全特征直接來源于用戶的流量數(shù)據(jù)，本發(fā)明提出的方法不僅實(shí)現(xiàn)較為便捷，還更能貼近用戶的對(duì)App的真實(shí)使用。

附圖說明

圖1為本發(fā)明方法中上位機(jī)控制多臺(tái)安卓終端進(jìn)行批量測(cè)試的示意圖；

圖2為本發(fā)明方法中對(duì)App進(jìn)行批量測(cè)試中具體執(zhí)行進(jìn)程的流程圖；

圖3為本發(fā)明方法中對(duì)HTTPS通信用DNS反向解析獲取App訪問服務(wù)器的域名示意圖；

圖4為本發(fā)明方法中對(duì)某款A(yù)pp的Host/Url初始特征集進(jìn)行補(bǔ)全的方法流程圖；

圖5為本發(fā)明方法中以u(píng)rl_i為種子的特征補(bǔ)全流程圖；

圖6為被發(fā)明方法中由種子url_i在多個(gè)用戶的流量數(shù)據(jù)中得到候選特征集的示意圖。

具體實(shí)施方式

下面結(jié)合附圖和具體實(shí)施方式對(duì)本發(fā)明作進(jìn)一步詳細(xì)描述，本發(fā)明的目的和效果將變得更加明顯。

運(yùn)行于各種智能終端的應(yīng)用(以下簡(jiǎn)稱App)，主要通過HTTP協(xié)議和HTTPS協(xié)議與各自的服務(wù)器進(jìn)行通訊聯(lián)系。這些服務(wù)器的地址通常用域名或IP地址來表示，這里簡(jiǎn)稱為Host。如果在Host基礎(chǔ)上，加上具體的HTTP請(qǐng)求路徑，那就稱之為Url。用Url可以刻畫在同一個(gè)服務(wù)器上的不同類型的訪問。我們把Host和Url統(tǒng)稱為Host/Url特征。一般情況下，一個(gè)App會(huì)向多個(gè)服務(wù)器請(qǐng)求不同類型的網(wǎng)絡(luò)服務(wù)，因而就有多個(gè)Host/Url特征，這些Host/Url特征構(gòu)成了該App的特征集。

另一方面，App所請(qǐng)求的Host/Url會(huì)在網(wǎng)絡(luò)運(yùn)營商端用戶的通信日志(以下簡(jiǎn)稱流量數(shù)據(jù))中會(huì)被記錄下來。如果獲得了某款A(yù)pp的Host/Url特征集，我們就可以在網(wǎng)絡(luò)運(yùn)營商端的用戶流量數(shù)據(jù)中進(jìn)行匹配搜索，以確認(rèn)流量數(shù)據(jù)中是否包含了該款A(yù)pp產(chǎn)生的數(shù)據(jù)流量。

為了采用Host/URL特征進(jìn)行App的識(shí)別，首先要采集App的通信流量數(shù)據(jù)，構(gòu)建一個(gè)Host/URL與App的匹配關(guān)系表。與已有文獻(xiàn)中采用在安卓模擬器中自動(dòng)運(yùn)行安卓App不同的是，本發(fā)明提出了更為高效批處理的方法，如圖1所示。

由一臺(tái)上位機(jī)控制一批安卓智能終端，上位機(jī)和安卓智能終端的連接方式可以是以太網(wǎng)、Wifi或者USB接口。然后當(dāng)接收測(cè)試任務(wù)時(shí)，由上位機(jī)將待測(cè)試的安卓App安裝文件(apk文件)以多進(jìn)程并發(fā)的方式分發(fā)到這些安卓智能終端，每個(gè)進(jìn)程負(fù)責(zé)控制一個(gè)安卓智能終端。每個(gè)進(jìn)程的處理流程如圖2所示，即通過adb命令控制其安裝、運(yùn)行、停止和卸載。并在同時(shí)，在安卓智能終端上啟動(dòng)tcpdump程序開啟對(duì)DNS、HTTP和HTTPS協(xié)議的通信數(shù)據(jù)進(jìn)行捕獲并保存為pcap格式的文件。每個(gè)App測(cè)試完成后，由上位機(jī)將tcpdump程序保存的pcap文件傳回進(jìn)行分析。

有關(guān)adb命令的詳情，參見：https://developer.android.com/studio/command-line/adb.html。

有關(guān)tcpdump程序的詳情，參見：http://www.androidtcpdump.com/。

有關(guān)pcap文件格式的詳情，參見：https://wiki.wireshark.org/Development/LibpcapFileFormat。

由于近年來HTTPS通信量呈逐漸上升趨勢(shì)，而HTTPS是一種加密傳輸?shù)耐ㄐ艆f(xié)議。當(dāng)一個(gè)App試圖與其服務(wù)器建立一個(gè)HTTPS連接時(shí)，它首先會(huì)根據(jù)Host向本地DNS服務(wù)器請(qǐng)求解析，當(dāng)收到DNS回應(yīng)的IP地址后，再去和服務(wù)器建立加密的握手消息并驗(yàn)證成功后，以后所有的請(qǐng)求和應(yīng)答都通過SSL加密通信進(jìn)行，因此無法捕獲到諸如GET、REQUEST以及RESPONSE的任何內(nèi)容，即使是包括具體請(qǐng)求的URL也無法獲得。

由于域名相對(duì)于IP地址來說要穩(wěn)定很多，同一個(gè)域名可由不同的DNS服務(wù)器可以被解析成不同的IP地址。因而，獲得域名而不是IP地址對(duì)于構(gòu)建Host/Url特征十分重要。對(duì)于使用HTTPS協(xié)議的App服務(wù)器而言，用tcpdump程序只能捕獲到服務(wù)器的IP地址，為了獲得它們的域名，我們采用了DNS反向解析的方法，如圖3所示。在對(duì)App進(jìn)行測(cè)試時(shí)，開啟tcpdump時(shí)會(huì)同時(shí)保存此次測(cè)試過程中所有的與DNS服務(wù)器的請(qǐng)求和應(yīng)答記錄，當(dāng)發(fā)現(xiàn)某個(gè)App與其服務(wù)器進(jìn)行HTTPS協(xié)議的通信，我們會(huì)根據(jù)其服務(wù)器的IP地址在DNS記錄尋找其請(qǐng)求的域名，并將此反向解析得到的域名代替IP地址作為該App中基于HTTPS協(xié)議的Host/Url特征。

通過上述對(duì)App進(jìn)行自動(dòng)測(cè)試、用tcpdump進(jìn)行通信數(shù)據(jù)捕獲和對(duì)得到的pcap文件進(jìn)行解析，我們可以獲得App的初始Host/Url特征集{url_init}。

然而，由于App測(cè)試無法窮舉所有可能的執(zhí)行路徑，尤其是那些需要登錄、甚至手機(jī)驗(yàn)證后才能使用的App，所測(cè)得的初始Host/Url特征集是不完備的。

為了對(duì)初始Host/Url特征集進(jìn)行補(bǔ)全，本發(fā)明提出一種基于用戶真實(shí)流量數(shù)據(jù)進(jìn)行補(bǔ)全的方法。具體步驟如下：

如圖4所示，在步驟101中，在某個(gè)App的初始Host/Url特征集{url_init}進(jìn)行篩選，選擇出種子特征集，即有篩選的過程是：

首先統(tǒng)計(jì)初始特征集{url_init}中的每個(gè)特征url_i在不同App的Host/Url特征集中出現(xiàn)的次數(shù)。如果出現(xiàn)次數(shù)只有1次，說明該Host/Url特征只被該App所訪問；而如果在不同App的Host/Url特征集中出現(xiàn)的次數(shù)多，則表明該url_i被多個(gè)不同的App所共同訪問。在種子特征集{url_seed}的成員的篩選過程中，將優(yōu)先選取那些只被該App所訪問的Host/Url，即出現(xiàn)次數(shù)只有1次的特征。

有時(shí)，可能在初始特征集{url_init}找不到出現(xiàn)次數(shù)只有1次的特征。這時(shí)，將選取出現(xiàn)次數(shù)最少的幾個(gè)Host/Url特征，將其的組合作為種子特征集{url_seed}的唯一成員。一般選次數(shù)最少的2個(gè)Host/Url特征即可。

構(gòu)建好種子特征集后，如圖4所示，在步驟102中，對(duì)種子特征集{url_seed}中的每個(gè)成員，都在多用戶的真實(shí)流量數(shù)據(jù)中進(jìn)行特征補(bǔ)全。

假設(shè)url_i是種子特征集中的一員，即url_i∈{url_seed}，則當(dāng)在某個(gè)用戶的真實(shí)流量數(shù)據(jù)中如果在t_p時(shí)刻檢測(cè)到有對(duì)url_i的訪問，則在t_p前后一段時(shí)間范圍[t_p-Δt,t_p+Δt]內(nèi)，屬于該App的其他Host/Url特征被訪問到可能性也很大。假設(shè)這段時(shí)間范圍內(nèi)該用戶所訪問的Host/Url集為{url_cand}，則可從中提取出一個(gè)或多個(gè)url_comp，有url_comp∈{url_cand}且如果經(jīng)過判別是屬于該App，則將它們作為補(bǔ)全數(shù)據(jù)加入到該App的Host/Url特征集。

由于目前手機(jī)操作系統(tǒng)基本都工作在多任務(wù)模式，同一時(shí)刻有多個(gè)App處于運(yùn)行狀態(tài)，在{url_cand}中很容易混入不同App的Host/Url特征?？紤]到不同用戶所使用的App存在差異性，這樣當(dāng)考察從不同用戶得到的{url_cand}構(gòu)成的集合時(shí)，屬于待補(bǔ)全App的Host/Url特征就會(huì)構(gòu)成了頻繁項(xiàng)；而不屬于待補(bǔ)全App的Host/Url特征則由于不同用戶所使用App的差異性，無法構(gòu)成頻繁項(xiàng)；這樣，通過關(guān)聯(lián)分析提取頻繁項(xiàng)的方法就可以有效地將屬于待補(bǔ)全App的Host/Url特征提取出來。具體由種子url_i從提取{url_comp}的過程如下：

如圖5所示，在步驟201中，提取多個(gè)用戶在訪問種子url_i時(shí)刻前后一段時(shí)間范圍內(nèi)所訪問的Host/Url，分別構(gòu)成各自的候選特征集{url_cand}。

假設(shè)某個(gè)用戶的流量數(shù)據(jù)中在t_p時(shí)刻有對(duì)種子url_i的訪問，則將t_p時(shí)刻前后一段時(shí)間范圍[t_p-Δt,t_p+Δt]內(nèi)該用戶訪問的Host/Url提取出來，構(gòu)成候選特征集{url_cand}。通過這種方式，如果在用戶流量數(shù)據(jù)中檢測(cè)到有N個(gè)用戶對(duì)種子url_i的訪問，就可以提取出N個(gè)候選集{url_cand}_k(k＝1,2,...,N)。如圖6所示，提取到這N個(gè)用戶各自對(duì)url_i訪問的時(shí)刻是不必相同的。

如圖5所示，在步驟202中，對(duì)來自N個(gè)用戶的候選集{url_cand}_k(k＝1,2,...,N)進(jìn)行關(guān)聯(lián)分析，得到若干個(gè)頻繁項(xiàng)集：Fp₁＝{url_A,url_B,...}、Fp₂＝{url_C,url_B,...}，…。

有關(guān)關(guān)聯(lián)分析算法的詳情，可參見：Han J,Pei J,Yin Y,et al.Mining frequent patterns without candidate generation:A frequent-pattern tree approach[J].Data mining and knowledge discovery,2004,8(1):53-87.

如圖5所示，在步驟203中，將提取的頻繁項(xiàng)集中不屬于初始特征集{url_init}的新Host/Url特征都提取出來，對(duì)初始特征集進(jìn)行補(bǔ)全。

經(jīng)過上述過程，完成了以u(píng)rl_i為種子對(duì)某款A(yù)pp的Host/Url特征集進(jìn)行擴(kuò)充過程。對(duì)種子特征集{url_init}中所有成員實(shí)施上述過程，即完成了一次對(duì)初始特征集的補(bǔ)全的全過程，即完成了從初始特征集提取種子特征集和基于種子特征集的特征集補(bǔ)全的過程。

為了挖掘出更多的屬于該款A(yù)pp的Host/Url特征，我們?cè)趯?duì)初始特征集進(jìn)行一次補(bǔ)全后，如圖4所示，在步驟103中，從補(bǔ)全后的特征集中選取新的種子，構(gòu)成新的種子特征集，迭代地進(jìn)行特征補(bǔ)全，即重復(fù)步驟101～103的過程，直到不再得到新的種子為止。

上述實(shí)施方式用來解釋說明本發(fā)明，而不是對(duì)本發(fā)明進(jìn)行限制，在本發(fā)明的精神和權(quán)利要求的保護(hù)范圍內(nèi)，對(duì)本發(fā)明做出的任何修改和改變，都落入本發(fā)明的保護(hù)范圍。