王成志，楊哲慜，南雨宏，楊 珉

(復(fù)旦大學(xué) 軟件學(xué)院，上海 201203)

1 引 言

動(dòng)態(tài)分析是在很多領(lǐng)域用到的一種通過(guò)實(shí)時(shí)執(zhí)行程序來(lái)進(jìn)行測(cè)試評(píng)估的方法.現(xiàn)在有很多工作依靠動(dòng)態(tài)分析來(lái)檢測(cè)移動(dòng)應(yīng)用程序的bug或者安全漏洞.常見(jiàn)動(dòng)態(tài)分析方法如TaintDroid[1]、SMV-Hunter[2]和AsDroid[3]等通過(guò)運(yùn)行時(shí)分析來(lái)檢測(cè)移動(dòng)應(yīng)用中的隱私泄露，不正確的SSL使用或者其他惡意行為.

在動(dòng)態(tài)執(zhí)行應(yīng)用的過(guò)程中往往會(huì)遇到應(yīng)用需要用戶(hù)文本輸入的情況.例如，應(yīng)用的登錄界面需要用戶(hù)輸入賬號(hào)和密碼.通常應(yīng)用會(huì)通過(guò)輸入控件來(lái)接收用戶(hù)的文本輸入.缺少或?yàn)閼?yīng)用提供錯(cuò)誤的文本輸入會(huì)導(dǎo)致應(yīng)用中依賴(lài)這些文本輸入的代碼不能被觸發(fā)甚至造成應(yīng)用崩潰.這使得在動(dòng)態(tài)分析中，應(yīng)用只能執(zhí)行少量的代碼，嚴(yán)重影響了動(dòng)態(tài)分析的效率.因此，動(dòng)態(tài)分析技術(shù)面臨著巨大的挑戰(zhàn).

在實(shí)際研究中，由于待分析的應(yīng)用數(shù)目龐大，為了滿(mǎn)足大規(guī)模動(dòng)態(tài)分析的需要，研究者將動(dòng)態(tài)分析方法和自動(dòng)化測(cè)試工具(例如，MonkeyRunner1)相結(jié)合，利用自動(dòng)化測(cè)試工具驅(qū)動(dòng)應(yīng)用執(zhí)行，利用動(dòng)態(tài)分析方法分析應(yīng)用的行為.在大規(guī)模動(dòng)態(tài)分析場(chǎng)景中，為了給應(yīng)用提供相關(guān)的文本輸入，提高自動(dòng)化動(dòng)態(tài)分析的執(zhí)行代碼覆蓋率，研究者需要不斷和應(yīng)用交互.然而，巨大的人工干預(yù)嚴(yán)重降低了自動(dòng)化動(dòng)態(tài)分析的效率.

本文分析了現(xiàn)有的能為應(yīng)用產(chǎn)生輸入的工具，這些工具能夠?yàn)閼?yīng)用產(chǎn)生輸入，例如UI輸入和系統(tǒng)輸入.這些輸入能GUIPipper[5]、SwiftHand[8]和PUMA[9]等，這類(lèi)工具會(huì)對(duì)應(yīng)用的UI進(jìn)行分析建模，以應(yīng)用的Activity為狀態(tài)建立一個(gè)狀夠驅(qū)動(dòng)應(yīng)用的自動(dòng)化執(zhí)，觸發(fā)應(yīng)用代碼.本文發(fā)現(xiàn)大部分的工具無(wú)法為應(yīng)用在動(dòng)態(tài)執(zhí)行中生成相關(guān)的文本輸入.在這些工具中，有些工具如Dynodroid[4]依賴(lài)人工干預(yù)，需要研究者手動(dòng)輸入相關(guān)文本.其他工具如AppsPlayground[12]和DroidFuzzer[7]采用基于特定啟發(fā)式的規(guī)則或者fuzzing技術(shù)(例如，給應(yīng)用設(shè)置一個(gè)隨機(jī)產(chǎn)生的字符串)來(lái)為應(yīng)用產(chǎn)生文本輸入.然而，通過(guò)上述方式產(chǎn)生的文本輸入往往無(wú)法滿(mǎn)足應(yīng)用的測(cè)試需要.這主要是因?yàn)閼?yīng)用程序中很多用戶(hù)文本輸入具有非結(jié)構(gòu)化、且類(lèi)型特殊的特征，使得測(cè)試環(huán)境難以自動(dòng)生成有效的用戶(hù)輸入.例如，有效的電子郵件地址應(yīng)包含“@”字符，電話號(hào)碼字段只能接受數(shù)字，而隨機(jī)生成的字符串很可能不符合這樣的要求.

為了能夠?yàn)閼?yīng)用自動(dòng)化產(chǎn)生符合其要求的文本輸入，提高動(dòng)態(tài)分析的覆蓋率從而使應(yīng)用中代碼被盡可能多的執(zhí)行到，本文提出了一種名為AutoSim的分析框架，用于在動(dòng)態(tài)分析時(shí)為應(yīng)用產(chǎn)生相關(guān)文本輸入.對(duì)于一個(gè)給定的應(yīng)用，AutoSim從應(yīng)用反編譯得到靜態(tài)資源文件中提取出具有語(yǔ)義信息的文本，然后利用一個(gè)基于機(jī)器學(xué)習(xí)的分類(lèi)器來(lái)識(shí)別UI控件所需要的文本輸入類(lèi)型 (如，電子郵件地址，出生日期和信用卡號(hào)碼等).同時(shí)，AutoSim在應(yīng)用動(dòng)態(tài)執(zhí)行的過(guò)程中，通過(guò)監(jiān)聽(tīng)?wèi)?yīng)用的上下文信息來(lái)攔截需要文本輸入的UI控件，并將符合類(lèi)型的文本注入到該控件中.此外，AutoSim提供了點(diǎn)擊模塊來(lái)觸發(fā)對(duì)應(yīng)的事件，從而保證應(yīng)用順利完成依賴(lài)于各類(lèi)用戶(hù)輸入的測(cè)試場(chǎng)景.

為了驗(yàn)證AutoSim系統(tǒng)的有效性，我們分別測(cè)試了AutoSim識(shí)別應(yīng)用文本輸入類(lèi)型的準(zhǔn)確率以及AutoSim對(duì)需要文本輸入的控件處理效果，即能否正確識(shí)別控件需要的文本輸入類(lèi)型.此外，通過(guò)測(cè)試AutoSim能否在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)幫助增加遍歷UI的數(shù)目來(lái)判斷AutoSim是否能夠提高動(dòng)態(tài)分析的覆蓋率.實(shí)驗(yàn)結(jié)果顯示，AutoSim識(shí)別文本輸入類(lèi)型的準(zhǔn)確率為88.68%，能夠正確處理89.74%的UI控件.對(duì)于需要用戶(hù)文本輸入的應(yīng)用，AutoSim能夠幫助自動(dòng)化測(cè)試工具提高33.7%的界面遍歷覆蓋率.

2 背景與相關(guān)工作

2.1 Android用戶(hù)界面

用戶(hù)界面是用戶(hù)可以在應(yīng)用程序的屏幕上看到并與之交互的所有內(nèi)容.Android提供了豐富多樣的預(yù)置本地UI控件.比較常見(jiàn)的UI控件有輸入框、按鈕、單選框和標(biāo)簽等，這些控件在Android中對(duì)應(yīng)的類(lèi)分別為EditText、Button、CheckBox和TextView.開(kāi)發(fā)者可以通過(guò)這些控件和用戶(hù)進(jìn)行交互，并且為這些控件定義不同的屬性以展示不同的內(nèi)容.除了Android框架提供的原生UI控件之外，Android允許開(kāi)發(fā)人員設(shè)計(jì)自定義UI控件.這些自定義小部件通常繼承于Android原生控件，添加微小的修改，使得這些控件可以呈現(xiàn)出不同的外觀.

2.2 Android應(yīng)用文本輸入

Android框架提供了一些可編輯的控件來(lái)接收用戶(hù)的文本輸入，例如EditText、AutoCompleteTextView和MultiAutoCompleteTextView等.用戶(hù)可以在這些控件中進(jìn)行文本編輯，

將相應(yīng)的文本內(nèi)容傳遞給應(yīng)用.應(yīng)用根據(jù)接收到的文本輸入，為用戶(hù)提供精準(zhǔn)的信息或者服務(wù).

圖1(a)展示了需要用戶(hù)輸入的UI.用戶(hù)通過(guò)圖 1(a)所示用戶(hù)界面的一些輸入框來(lái)接收用戶(hù)的個(gè)人信息，如email、first name、last name、birthday和phone等，在用戶(hù)填入這些信息之后，通過(guò)點(diǎn)擊“Sign Up”按鈕完成對(duì)應(yīng)用的注冊(cè).這些文本輸入是非常結(jié)構(gòu)化的，類(lèi)型特定，例如電子郵箱地址、生日和手機(jī)號(hào)碼都是具有特定格式的.當(dāng)這些UI中的輸入框沒(méi)有被填入內(nèi)容或者填入錯(cuò)誤的內(nèi)容時(shí)，會(huì)導(dǎo)致該應(yīng)用的核心功能以及大量的用戶(hù)界面無(wú)法被訪問(wèn)到.

(a) (b)

2.3 Android用戶(hù)界面布局

在Android應(yīng)用開(kāi)發(fā)中，開(kāi)發(fā)者可以通過(guò)兩種方式來(lái)聲明UI布局：在XML布局文件中聲明UI元素和在運(yùn)行時(shí)實(shí)例化布局元素.在XML中聲明UI的方式可以更好地將應(yīng)用的外觀與控制應(yīng)用的行為分離，被絕大部分開(kāi)發(fā)者采用.因此本文只考慮基于XML布局的應(yīng)用.

圖1(b)展示了圖1(a)中UI界面對(duì)應(yīng)的XML布局文件的部分內(nèi)容.圖1(b)中的EditText元素對(duì)應(yīng)圖1(a)中的email輸入框.開(kāi)發(fā)者通過(guò)在UI布局文件中定義控件的屬性來(lái)控制控件的顯示，例如，圖1(b)中EditText的屬性android：hint =“@string/create-email”(第4行和第5行)指示當(dāng)輸入框的內(nèi)容為空時(shí)，應(yīng)在UI中顯示的提示文本.這個(gè)EditText的inputType屬性(第6行)也表明該輸入框需要接收email類(lèi)型的用戶(hù)輸入.從控件布局屬性中提取的內(nèi)容是語(yǔ)義相關(guān)的，UIPicker[6]利用這些內(nèi)容判斷控件接收的文本輸入是否為隱私相關(guān)，本文通過(guò)分析這些內(nèi)容來(lái)判斷UI控件需要文本輸入的類(lèi)型.

2.4 Android代碼注入框架

Xposed2是一個(gè)可以在不修改應(yīng)用程序情況下更改系統(tǒng)和應(yīng)用程序行為的框架.Xposed可以通過(guò)hook一些關(guān)鍵函數(shù)來(lái)實(shí)現(xiàn)對(duì)系統(tǒng)或者應(yīng)用功能的修改.在Android中，所有的應(yīng)用進(jìn)程都是通過(guò)zygote進(jìn)程創(chuàng)建，zygote進(jìn)程是運(yùn)行的app-process，app-process在frameworks/base/cmds/app-process/下.Xposed將自己定制的app-process替換掉目標(biāo)設(shè)

2http://repo.xposed.info/

備中的app-process從而修改zygote進(jìn)程達(dá)到hook應(yīng)用目的.Xposed會(huì)將需要hook的方法先指向XposedBridge.jar中的xposedCallHandler方法，然后調(diào)用beforeHookMethod和afterHooked-Method方法，這兩個(gè)方法分別在被hook的方法執(zhí)行前和執(zhí)行后被調(diào)用.開(kāi)發(fā)者可以自定義beforeHookMethod和afterHookedMethod方法中的行為.在本文中，AutoSim利用Xposed攔截正在加載的UI中所有控件.

2.5 相關(guān)工作

在自動(dòng)化分析方面，Choudhary[7]等人認(rèn)為目前能驅(qū)動(dòng)Android應(yīng)用自動(dòng)化執(zhí)行的自動(dòng)化工具根據(jù)其采用的對(duì)應(yīng)用采取策略主要分為三類(lèi)：隨機(jī)探索策略類(lèi)自動(dòng)化工具，基于模型的探索策略類(lèi)自動(dòng)化工具和系統(tǒng)探索策略類(lèi)自動(dòng)化工具.采用隨機(jī)探索策略的自動(dòng)化工具有Dynodroid[4]，這類(lèi)工具為應(yīng)用產(chǎn)生隨機(jī)的事件，例如，隨機(jī)點(diǎn)擊UI上某個(gè)位置，來(lái)驅(qū)動(dòng)應(yīng)用執(zhí)行以及UI的跳轉(zhuǎn).基于模型的自動(dòng)化工具主要有態(tài)機(jī)來(lái)指導(dǎo)應(yīng)用的自動(dòng)化執(zhí)行以及UI跳轉(zhuǎn).而系統(tǒng)類(lèi)的自動(dòng)化工具則采用較為復(fù)雜的技術(shù)，如進(jìn)化算法[10]來(lái)不斷改變輸入驅(qū)使應(yīng)用自動(dòng)化執(zhí)行.

這些自動(dòng)化工具均無(wú)法有效應(yīng)對(duì)需要用戶(hù)文本輸入的UI.在遇到需要文本輸入的UI時(shí)，有的工具會(huì)為需要文本輸入的控件產(chǎn)生隨機(jī)化的文本，如MonkeyRunner、PUMA[9]和Vanar Sena[11]等，有些則直接忽略掉需要文本輸入的UI，如Dynodroid[4]等.還有一些如AppsPlayground[12]采用極為簡(jiǎn)易的基于關(guān)鍵字的方法來(lái)為識(shí)別控件需要的文本輸入類(lèi)型，并且無(wú)法有效處理如開(kāi)發(fā)者自定義控件等情況，效率較為低下.Peng[13]等人采用深度學(xué)習(xí)的方法為應(yīng)用生成相關(guān)的文本，但是他們的方法無(wú)法有效生成結(jié)構(gòu)化特定類(lèi)型的文本輸入.相比于這些工具，AutoSim能夠有效的識(shí)別應(yīng)用需要的文本輸入的類(lèi)型，并能夠在動(dòng)態(tài)執(zhí)行過(guò)程中高效的將相關(guān)的文本注入到應(yīng)用中.

3 AutoSim的基本框架

圖2描述了AutoSim的基本框架.如圖2所示，AutoSim自動(dòng)化生成文本內(nèi)容的過(guò)程主要包括兩個(gè)階段：靜態(tài)UI解析

圖2 AutoSim框架示意圖Fig.2 System overview of AutoSim

階段和動(dòng)態(tài)UI驅(qū)動(dòng)階段.在靜態(tài)UI解析階段，AutoSim使用靜態(tài)分析的方法來(lái)分析應(yīng)用程序中需要文本輸入的UI控件所對(duì)應(yīng)的文本類(lèi)型.在動(dòng)態(tài)UI驅(qū)動(dòng)階段，AutoSim在應(yīng)用執(zhí)行的過(guò)程中將準(zhǔn)備好的符合UI要求類(lèi)型的文本注入到UI控件中.靜態(tài)UI解析階段產(chǎn)生的配置文件將指導(dǎo)動(dòng)態(tài)UI驅(qū)動(dòng)器在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)的注入操作.

3.1 靜態(tài)UI解析階段

在靜態(tài)UI解析階段，AutoSim首先反編譯Android應(yīng)用，獲取到應(yīng)用的資源文件.從資源文件中提取出UI控件的語(yǔ)義相關(guān)的描述信息，通過(guò)分析這些語(yǔ)義相關(guān)的描述信息來(lái)判斷控件需要的文本輸入類(lèi)型.為了能夠精確的識(shí)別UI控件所需要的文本輸入的類(lèi)型，AutoSim采用機(jī)器學(xué)習(xí)的方法，利用從應(yīng)用中提取出來(lái)的語(yǔ)義相關(guān)的描述信息訓(xùn)練出一個(gè)分類(lèi)器.該分類(lèi)器將從應(yīng)用中提取出的UI控件的語(yǔ)義相關(guān)的信息作為輸入，輸出該控件所需文本輸入的類(lèi)型.

3.2 動(dòng)態(tài)UI驅(qū)動(dòng)階段

在動(dòng)態(tài)UI驅(qū)動(dòng)階段，AutoSim會(huì)在應(yīng)用實(shí)際執(zhí)行時(shí)監(jiān)視應(yīng)用運(yùn)行的上下文.該階段主要包含三個(gè)模塊：基于Xposed的Android框架攔截模塊，輸入模塊和點(diǎn)擊模塊.攔截模塊在應(yīng)用加載UI的過(guò)程中通過(guò)Hook的方式攔截即將加載到當(dāng)前屏幕的所有UI控件，并根據(jù)生成的應(yīng)用的配置文件來(lái)檢索需要文本輸入的UI控件.輸入模塊會(huì)依據(jù)配置文件上記錄的UI控件所需文本類(lèi)型的信息將符合該類(lèi)型的有效文本注入到該控件中.在實(shí)現(xiàn)動(dòng)態(tài)UI驅(qū)動(dòng)階段中，利用Xposed工具在Android框架層攔截UI控件不需要對(duì)應(yīng)用做出任何修改.

4 AutoSim的設(shè)計(jì)與實(shí)現(xiàn)

4.1 語(yǔ)義信息的提取

AutoSim首先利用apktool3工具對(duì)Android應(yīng)用進(jìn)行反編譯，提取應(yīng)用的資源文件，從反編譯的APK程序包中的界面布局文件中提取出控件的UI文本和UI描述文本來(lái)獲取有價(jià)值的語(yǔ)義信息進(jìn)行分析.

UI文本是在應(yīng)用屏幕中向用戶(hù)顯示的文本，例如Button的標(biāo)簽，輸入框內(nèi)部用于提示用戶(hù)的文字.在反編譯應(yīng)用中，大多數(shù)UI文本位于/res/values/strings.xml文件中，在控件的屬性中由語(yǔ)法@String/[identifier]來(lái)定義和引用，此外有些UI文本會(huì)直接寫(xiě)在界面布局文件中，如android：hint=“password”.這些語(yǔ)義相關(guān)的UI文本能夠有效提示和指導(dǎo)用戶(hù)的操作.本文通過(guò)提取UI布局文件中控件的hint屬性和text屬性的值來(lái)獲取UI文本.

控件的UI描述文本是僅位于/res/layout/的UI布局文件中，用于描述控件的內(nèi)容，主要包含控件的id、位置和大小等信息.本文通過(guò)提取UI控件的id屬性和inputType屬性的值來(lái)獲取語(yǔ)義相關(guān)的UI描述文本.表1描述了提取的UI文本和UI描述文本內(nèi)容樣例.

表1 從圖1(a)所示UI中提取出的部分資源Table 1 Part of extracted resources from UI shown in Figure 1(a)

AutoSim主要從能夠接受用戶(hù)文本輸入的UI控件中提取語(yǔ)義相關(guān)的內(nèi)容進(jìn)行分析.表2展示了本文中主要關(guān)注的能夠接受用戶(hù)輸入的UI控件.從表2中可以看出，本文不僅分析能夠接受用戶(hù)文本輸入的控件，如EditText，還分析了一些需要點(diǎn)擊的控件，如RadioButton和Checkbox等.這主要是因?yàn)樵赨I界面中需要用戶(hù)交互的不只是輸入文本，還需要一些點(diǎn)擊選擇操作，例如通過(guò)點(diǎn)擊CheckBox同意相關(guān)的協(xié)議，通過(guò)RadioButton選擇性別.此外，本文提供相應(yīng)的機(jī)制來(lái)幫助觸發(fā)點(diǎn)擊控件上對(duì)應(yīng)的事件，例如在填寫(xiě)個(gè)人信息后，自動(dòng)點(diǎn)擊注冊(cè)頁(yè)面上的注冊(cè)按鈕來(lái)完成應(yīng)用自動(dòng)注冊(cè).

3https://ibotpeaches.github.io/Apktool/

表2 十種常見(jiàn)的需要用戶(hù)輸入的控件Table 2 Top ten widgets that require user input

表2中的UI控件均為Android系統(tǒng)提供的原生控件，除了這些原生控件外，本文還分析了開(kāi)發(fā)者自定義的UI控件.開(kāi)發(fā)者在Android系統(tǒng)提供的原生控件基礎(chǔ)上進(jìn)行定義和開(kāi)發(fā)新的UI控件，這自定義控件的源碼包含在應(yīng)用中.對(duì)于這些控件，本文通過(guò)分析反編譯應(yīng)用獲得的這些控件的smali文件得到這些控件繼承的Android原生控件.在本文中，我們認(rèn)為這些自定義的控件和這些自定義控件所繼承的原生組件是等同的，這是因?yàn)樵趹?yīng)用動(dòng)態(tài)執(zhí)行中使用攔截原生控件的方法同樣可以攔截到繼承該原生控件的自定義控件.

4.2 基于SVM的分類(lèi)器

為了能夠精確的識(shí)別UI控件所需要的文本輸入的類(lèi)型，本文利用標(biāo)準(zhǔn)支持向量機(jī)(SVM)和從UI控件中提取出的語(yǔ)義信息訓(xùn)練一個(gè)能夠精確識(shí)別文本輸入類(lèi)型的分類(lèi)器.標(biāo)準(zhǔn)支持向量機(jī)是一種廣泛使用的監(jiān)督式學(xué)習(xí)模型，能夠高效的對(duì)數(shù)據(jù)分類(lèi).然而SVM實(shí)質(zhì)是一個(gè)二元分類(lèi)器，而控件需要文本的類(lèi)型的種類(lèi)多于兩種，因此本文采用一對(duì)多(one-versus-rest)的分類(lèi)策略來(lái)實(shí)現(xiàn)支持多分類(lèi)的分類(lèi)器.在實(shí)現(xiàn)時(shí)，我們使用了scikit-learn包中的LinearSVC來(lái)訓(xùn)練支持多分類(lèi)分類(lèi)器.

在訓(xùn)練分類(lèi)器之前，我們需要確定用戶(hù)文本輸入的種類(lèi).由于Android應(yīng)用的多樣性和實(shí)際需求，應(yīng)用會(huì)要求用戶(hù)輸入各種各樣的信息，導(dǎo)致文本輸入的種類(lèi)數(shù)目龐大.在本文中，AutoSim選取最常用的文本輸入種類(lèi).本文分析了超過(guò)1000個(gè)從Google Play上下載的應(yīng)用，收集需要用戶(hù)輸入的控件，人工識(shí)別這些控件需要的文本類(lèi)型，統(tǒng)計(jì)各種文本輸入類(lèi)型的數(shù)目，并選取比例最高的14種作為要識(shí)別的分類(lèi).表3顯示了本文選取的進(jìn)行分類(lèi)的用戶(hù)文本輸入種類(lèi)以及所占的比例，從表3可以看出，像email、phone、credit card number、birthday和zipcode這些文本輸入都是格式化的，隨機(jī)的內(nèi)容無(wú)法滿(mǎn)足需要這些類(lèi)型輸入的控件.

在訓(xùn)練階段，本文首先分析了超過(guò)2000個(gè)從Google Play上下載的應(yīng)用來(lái)獲取訓(xùn)練樣本.我們從這些應(yīng)用的UI界面中提取出接收用戶(hù)文本輸入控件的語(yǔ)義信息，并且人工標(biāo)注每一個(gè)需要文本輸入控件所需要文本輸入的類(lèi)型，將控件的語(yǔ)義信息和需要文本輸入的類(lèi)型一一對(duì)應(yīng).為了訓(xùn)練分類(lèi)器，AutoSim需要將訓(xùn)練樣本中具有語(yǔ)義信息的原始文本轉(zhuǎn)化成向量.在實(shí)現(xiàn)中，我們從字符層面(Character-level)上對(duì)文本進(jìn)行向量轉(zhuǎn)化.相比于常用的從單詞，短語(yǔ)和句子層面上對(duì)文本進(jìn)行向量轉(zhuǎn)化，字符層面上的向量轉(zhuǎn)化能夠不受文本詞法，語(yǔ)法以及句法結(jié)構(gòu)的影響，并且具有良好的效果.本文選用包含26個(gè)英文小寫(xiě)字母的字典對(duì)訓(xùn)練數(shù)據(jù)中的文本進(jìn)行編碼.從4.1可知，對(duì)于每一個(gè)控件，本文分別提取了控件4種屬性(hint、text、id和inputType)的文本值.在編碼時(shí)，我們將每一個(gè)屬性的文本編碼為長(zhǎng)度為26位的向量.這個(gè)向量上第n位的值表示在字典中偏移量為n的小寫(xiě)英文字母在這個(gè)文本中出現(xiàn)的頻率.對(duì)于每一控件，我們可以得到4個(gè)26位的向量，并且把這4個(gè)向量組合到一起，形成新的104位長(zhǎng)度的向量.SVM將這個(gè)104位長(zhǎng)度的向量和該控件對(duì)應(yīng)的所需文本的類(lèi)型作為輸入進(jìn)行分類(lèi)器的訓(xùn)練.

表3 本文選取的用戶(hù)文本輸入類(lèi)型在統(tǒng)計(jì)樣本中所占比例Table 3 Input types and their corresponding ratio in dataset

4.3 配置文件的生成

在獲得分類(lèi)器后，對(duì)于一個(gè)未知的應(yīng)用，靜態(tài)UI解析會(huì)提取應(yīng)用中需要用戶(hù)文本輸入控件的語(yǔ)義文本信息，按照4.2中所述的方法對(duì)語(yǔ)義文本信息進(jìn)行編碼，用訓(xùn)練好的分類(lèi)器對(duì)編碼好的語(yǔ)義文本進(jìn)行分類(lèi)，判斷控件需要文本的類(lèi)型.AutoSim將應(yīng)用中每一個(gè)需要文本輸入控件的分類(lèi)結(jié)果保存在以該應(yīng)用包名命名的靜態(tài)配置文件中，這些配置文件將會(huì)被保存在待測(cè)設(shè)備中.在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)，動(dòng)態(tài)UI驅(qū)動(dòng)器會(huì)根據(jù)應(yīng)用的包名加載配置文件，根據(jù)配置文件中的信息進(jìn)行操作.

在靜態(tài)文件中，除了識(shí)別出的控件需要的文本輸入類(lèi)型外，本文還記錄了控件的類(lèi)型.控件唯一的十進(jìn)制ID可以被用來(lái)標(biāo)記存儲(chǔ)在配置文件中的該控件的信息(需要的文本輸入類(lèi)型和控件類(lèi)型).Android會(huì)為每一個(gè)在資源文件中定義的控件分配一個(gè)唯一的ID，這些ID以十六進(jìn)制形式存儲(chǔ)在應(yīng)用資源文件的/res/values/public.xml中.在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)，控件ID和保存在public.xml中該控件的ID是一致的，因而AutoSim可以在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)通過(guò)ID來(lái)追蹤控件.并根據(jù)配置文件中保存的控件的信息對(duì)控件進(jìn)行處理.配置文件連接了AutoSim的靜態(tài)分析階段和動(dòng)態(tài)驅(qū)動(dòng)階段，使AutoSim能夠滿(mǎn)足大規(guī)模自動(dòng)測(cè)試分析應(yīng)用的需要.在大規(guī)模自動(dòng)測(cè)試分析應(yīng)用的場(chǎng)景下，研究者可以用靜態(tài)UI解析批量處理待測(cè)應(yīng)用，生成對(duì)應(yīng)的配置文件，并將配置文件存儲(chǔ)在文件中.動(dòng)態(tài)執(zhí)行應(yīng)用時(shí)根據(jù)應(yīng)用的包名加載不同的配置文件進(jìn)行操作.

4.4 基于Xposed的動(dòng)態(tài)UI驅(qū)動(dòng)

在獲得應(yīng)用配置文件之后，動(dòng)態(tài)UI驅(qū)動(dòng)器會(huì)把為應(yīng)用輸入控件準(zhǔn)備好的填寫(xiě)內(nèi)容在應(yīng)用動(dòng)態(tài)執(zhí)行的過(guò)程中注入到控件中.AutoSim利用Xposed工具在android framework層面上進(jìn)行攔截和注入操作，使得UI在加載完成后，UI中所有需要文本輸入的控件都被填寫(xiě)符合類(lèi)型的文本.動(dòng)態(tài)UI驅(qū)動(dòng)器主要由3個(gè)核心部分組成：Android框架攔截模塊，輸入模塊，點(diǎn)擊模塊.

4.4.1 Android 框架攔截模塊

AutoSim利用Xposed工具在Android框架層面上進(jìn)行增強(qiáng)，獲取應(yīng)用執(zhí)行時(shí)的一些信息.在應(yīng)用啟動(dòng)階段，通過(guò)Xposed工具AutoSim可以攔截到當(dāng)前正在被打開(kāi)的應(yīng)用的包名.通過(guò)獲取到的包名，AutoSim可以檢索到存儲(chǔ)配置文件的位置中是否存在與包名相匹配的配置文件.如果存在，則說(shuō)明該應(yīng)用是待測(cè)應(yīng)用，反之則不是.對(duì)于存在配置文件的應(yīng)用，AutoSim會(huì)立即加載配置文件，并開(kāi)始監(jiān)聽(tīng)?wèi)?yīng)用的執(zhí)行情況，并在執(zhí)行時(shí)進(jìn)行自動(dòng)的填寫(xiě)以及點(diǎn)擊操作.不存配置文件的應(yīng)用在執(zhí)行的過(guò)程中將不會(huì)受到AutoSim的影響.

在應(yīng)用執(zhí)行階段，AutoSim通過(guò)對(duì)Android系統(tǒng)框架中的一些API的監(jiān)聽(tīng)來(lái)攔截正在加載UI的控件.由于Android在繪制UI控件過(guò)程中，會(huì)調(diào)用系統(tǒng)框架提供的API，因此可以通過(guò)監(jiān)聽(tīng)這些API的調(diào)用對(duì)象來(lái)攔截正在繪制的控件.例如通過(guò)監(jiān)聽(tīng)這些控件從android.widget.TextView中繼承的的onDraw()方法來(lái)獲取所有正在繪制的TextView類(lèi)型的UI控件.通過(guò)進(jìn)一步的確認(rèn)UI控件的具體類(lèi)型，可以判斷出控件的類(lèi)型是否為MultiAutoCompleteTextView、CheckBox和EditText等.通過(guò)監(jiān)聽(tīng)setOnclickListener()函數(shù)來(lái)攔截需要點(diǎn)擊的控件，如Button，ImageButton等.之后AutoSim根據(jù)控件的類(lèi)型將被攔截到的控件交給輸入模塊和點(diǎn)擊模塊進(jìn)行處理.

4.4.2 輸入模塊

在攔截到當(dāng)前正在加載UI的所有控件后，輸入模塊負(fù)責(zé)將準(zhǔn)備好的內(nèi)容根據(jù)控件需要的輸入類(lèi)型自動(dòng)填寫(xiě)到控件中.對(duì)于攔截到的正在繪制的UI控件，AutoSim通過(guò)這些控件從android.view.View中繼承的getId函數(shù)獲取控件的id.如果應(yīng)用的配置文件中存在這個(gè)id，則表明這個(gè)控件是需要用戶(hù)輸入的控件.通過(guò)id去檢索配置文件中這個(gè)控件需要的輸入類(lèi)型，并獲取符合該類(lèi)型的輸入.本文事先為14個(gè)不同的輸入類(lèi)型各自準(zhǔn)備好符合其類(lèi)型的輸入，這些輸入均為真實(shí)有效的輸入.

AutoSim通過(guò)調(diào)用Android框架提供的API將文本注入到控件中.例如，對(duì)于一個(gè)類(lèi)型為EditText的輸入框，可以在攔截階段獲取到這個(gè)輸入框的實(shí)例對(duì)象.通過(guò)調(diào)用setText()函數(shù)，AutoSim可以將事先準(zhǔn)備好的符合這個(gè)文本框要求類(lèi)型的輸入注入到該文本框中.在當(dāng)前界面加載完后，可以看到被注入的輸入已經(jīng)顯示在屏幕上.

4.4.3 點(diǎn)擊模塊

除了輸入模塊之外，本文也提供了點(diǎn)擊模塊，使得動(dòng)態(tài)UI驅(qū)動(dòng)器能夠自動(dòng)的觸發(fā)相應(yīng)的事件.例如，在一個(gè)登陸注冊(cè)的頁(yè)面，在填寫(xiě)完與注冊(cè)相關(guān)的信息之后，AutoSim能夠自動(dòng)的去點(diǎn)擊注冊(cè)按鈕以提交注冊(cè)信息.同時(shí)點(diǎn)擊模塊也為自動(dòng)的遍歷應(yīng)用內(nèi)所有UI提供了新的思路.在將來(lái)的工作中，我們會(huì)用點(diǎn)擊模塊來(lái)實(shí)現(xiàn)一個(gè)高效的Android應(yīng)用自動(dòng)化遍歷工具，使得更多應(yīng)用的代碼被執(zhí)行.

對(duì)于攔截到的需要點(diǎn)擊的控件，AutoSim通過(guò)調(diào)用這個(gè)控件從android.view.View中繼承的performClick函數(shù)來(lái)實(shí)現(xiàn)自動(dòng)點(diǎn)擊.需要注意的是，我們不能在攔截到需要點(diǎn)擊的UI控件時(shí)立即自動(dòng)點(diǎn)擊該控件，這主要是因?yàn)槠渌枰顚?xiě)的輸入控件還沒(méi)有處理完成.鑒于上述問(wèn)題，本文采用了延時(shí)點(diǎn)擊的策略，即通過(guò)使用Android框架提供的AsyncTask4來(lái)實(shí)現(xiàn)一個(gè)定時(shí)器，在定時(shí)器結(jié)束后AutoSim會(huì)自動(dòng)點(diǎn)擊需要點(diǎn)擊的控件.

5 實(shí)驗(yàn)與效果評(píng)估

在本節(jié)中，本文從三個(gè)方面對(duì)AutoSim進(jìn)行測(cè)試評(píng)估：對(duì)靜態(tài)UI解析部分的評(píng)估，對(duì)動(dòng)態(tài)UI驅(qū)動(dòng)部分的評(píng)估和對(duì)AutoSim對(duì)自動(dòng)化測(cè)試增強(qiáng)效果的評(píng)估.在靜態(tài)UI解析階段，本文將測(cè)試分類(lèi)器的平均準(zhǔn)確率以及對(duì)每一類(lèi)文本輸入類(lèi)型識(shí)別的精確率.在動(dòng)態(tài)UI驅(qū)動(dòng)階段，本文將測(cè)試AutoSim能夠正確處理UI控件的數(shù)目.最后本文將測(cè)試AutoSim在自動(dòng)化測(cè)試Android應(yīng)用的場(chǎng)景下是否能夠有效增大自動(dòng)化測(cè)試框架的UI覆蓋率.

本文靜態(tài)UI解析階段以及分類(lèi)器訓(xùn)練實(shí)驗(yàn)環(huán)境為：具有40核心(Intel Xeon E7-4830，2.20GHz)內(nèi)核版本3.16.0，物理內(nèi)存大小為132G的Linux服務(wù)器.服務(wù)器運(yùn)行的操作系統(tǒng)為64位的Debian，支持python 3.4.2.動(dòng)態(tài)UI驅(qū)動(dòng)階段的實(shí)驗(yàn)環(huán)境為具有2GB RAM，運(yùn)行Android 4.4.4的Nexus 5.

5.1 分類(lèi)器的訓(xùn)練以及識(shí)別效果測(cè)試

為了訓(xùn)練分類(lèi)器，本文從Google Play上隨機(jī)挑選了1000個(gè)應(yīng)用，從這些應(yīng)用中提取出997組需要文本輸入的UI控件的語(yǔ)義信息，對(duì)這些UI控件需要的輸入類(lèi)型進(jìn)行手工標(biāo)注，之后用這些數(shù)據(jù)進(jìn)行訓(xùn)練和測(cè)試分類(lèi)器的效果.本文采用十折交叉驗(yàn)證的方法來(lái)測(cè)試基于SVM分類(lèi)器的平均準(zhǔn)確率和在識(shí)別不同種文本輸入類(lèi)型的精確度，即隨機(jī)將數(shù)據(jù)集分成10份其中9份做訓(xùn)練1份做測(cè)試，并通過(guò)10次十折交叉驗(yàn)證取平均值來(lái)獲取準(zhǔn)確度和精確度.此外本文還將基于SVM的分類(lèi)器與AppsPlayground使用的基于關(guān)鍵詞的分類(lèi)器進(jìn)行對(duì)比.由于AppsPlayground沒(méi)有開(kāi)源，因此我們實(shí)現(xiàn)了簡(jiǎn)易的符合其描述的基于關(guān)鍵詞的分類(lèi)器.

表4是分類(lèi)器的測(cè)試以及對(duì)比結(jié)果，從表4中可以看出基于SVM的分類(lèi)器識(shí)別平均準(zhǔn)確率為88.68%，高于準(zhǔn)確率只有62.7%的基于關(guān)鍵詞的分類(lèi)器.除了平均準(zhǔn)確率以外，基于SVM的分類(lèi)器在識(shí)別單個(gè)文本輸入類(lèi)型的精確率和召回率均超過(guò)基于關(guān)鍵詞的分類(lèi)器.在識(shí)別個(gè)別輸入類(lèi)型，如fullname，birthday時(shí)，基于關(guān)鍵詞的分類(lèi)器的精確率遠(yuǎn)不如基于SVM的分類(lèi)器.這是因?yàn)榛陉P(guān)鍵詞的分類(lèi)主要依賴(lài)于有限的關(guān)鍵詞列表，根據(jù)關(guān)鍵詞列表中的關(guān)鍵詞是否出現(xiàn)在語(yǔ)義信息中來(lái)判斷輸入類(lèi)型.有限的關(guān)鍵詞列表會(huì)造成較多的錯(cuò)誤，例如，“password”這個(gè)詞可以被寫(xiě)成“passwd”、“pwd”或者“passcode”等，因而準(zhǔn)確識(shí)別文本輸入類(lèi)型“password”需要多個(gè)關(guān)鍵詞.為了能夠精確識(shí)別并且區(qū)分所有14種輸入類(lèi)型需要龐大的關(guān)鍵詞列表，而這是不現(xiàn)實(shí)的.因此采用機(jī)器學(xué)習(xí)的方法訓(xùn)練出來(lái)的分類(lèi)器會(huì)更加高效.

4https://developer.android.com/reference/android/os/AsyncTask

5http://appium.io

表4 不同分類(lèi)器的識(shí)別效果對(duì)比Table 4 Classifier comparison result of identifying input types

5.2 動(dòng)態(tài)UI驅(qū)動(dòng)對(duì)單個(gè)控件處理效果測(cè)試

在測(cè)試AutoSim的動(dòng)態(tài)UI驅(qū)動(dòng)部分時(shí)，本文測(cè)試了AutoSim處理單個(gè)控件的效果，通過(guò)統(tǒng)計(jì)AutoSim在應(yīng)用動(dòng)態(tài)執(zhí)行時(shí)能正確處理控件(將正確的文本填入到正確的控件中)的數(shù)目來(lái)測(cè)試AutoSim對(duì)單個(gè)控件的效果.本文從200個(gè)隨機(jī)挑選的應(yīng)用中收集到了234個(gè)需要用戶(hù)文本輸入的控件，其中有60個(gè)控件是開(kāi)發(fā)者自定義的控件.在通過(guò)分類(lèi)器對(duì)控件進(jìn)行輸入類(lèi)型識(shí)別以及生產(chǎn)配置文件后，我們動(dòng)態(tài)執(zhí)行相關(guān)應(yīng)用，并觀察相關(guān)控件是否被填入正確的內(nèi)容.除了測(cè)試AutoSim對(duì)單個(gè)控件的處理效果之外，本文也分別測(cè)試了fuzzing技術(shù)和AppsPlayground對(duì)單個(gè)控件的處理效果，并進(jìn)行對(duì)比.

表5為本次測(cè)試的結(jié)果，由結(jié)果可以看到，AutoSim能夠正確處理210個(gè)輸入控件，包括167個(gè)Android框架提供的原生控件和43個(gè)開(kāi)發(fā)者自定義的控件，分別占比95.98%和71.67%. AutoSim在處理Android原生控件和開(kāi)發(fā)者定義控件上的效果均強(qiáng)于Fuzzing和AppsPlayground.Fuzzing由于采用給控件輸入隨機(jī)的內(nèi)容，導(dǎo)致其能正確處理的控件數(shù)目較少.而AppsPlayground由于采用了基于關(guān)鍵詞的分類(lèi)識(shí)別方法，使得其能夠識(shí)別100個(gè)原生控件，但是由于其在處理開(kāi)發(fā)者自定義的控件時(shí)采用了fuzzing的技術(shù)，沒(méi)有對(duì)自定義控件的輸入類(lèi)型進(jìn)行有效的識(shí)別，因此只能正確處理較少的開(kāi)發(fā)者自定義控件.

表5 針對(duì)單個(gè)控件的不同方法測(cè)試效果對(duì)比Table 5 Effectiveness of testing results by different approaches

5.3 AutoSim對(duì)自動(dòng)化測(cè)試Android應(yīng)用影響的評(píng)估

為了評(píng)估AutoSim是否能夠增大自動(dòng)化測(cè)試框架的UI覆蓋率，本文測(cè)試了AutoSim是否能夠有效增加自動(dòng)化框架在測(cè)試Android應(yīng)用時(shí)遍歷應(yīng)用UI的數(shù)目.這主要是因?yàn)楫?dāng)自動(dòng)化測(cè)試框架遍歷到的UI數(shù)目的增加表明能夠執(zhí)行到的應(yīng)用的代碼的增加.本文從Google Play上隨機(jī)選擇了30個(gè)應(yīng)用進(jìn)行測(cè)試.此外，我們利用Appium5和深度優(yōu)先算法來(lái)點(diǎn)擊UI上的每一個(gè)可以點(diǎn)擊的控件以實(shí)現(xiàn)自動(dòng)遍歷Android應(yīng)用的工具，通過(guò)該工具來(lái)自動(dòng)遍歷安裝在Nexus 5上的Android應(yīng)用，統(tǒng)計(jì)能夠遍歷到的UI的數(shù)目.我們將AutoSim部署在Nexus 5上，分別測(cè)試給需要文本輸入的控件填寫(xiě)隨機(jī)內(nèi)容時(shí)能夠遍歷的UI的數(shù)目和給輸入控件由AutoSim注入的內(nèi)容時(shí)遍歷的UI數(shù)目.我們用基于Appium的自動(dòng)化遍歷工具運(yùn)行測(cè)試應(yīng)用，統(tǒng)計(jì)能夠遍歷的UI數(shù)目.對(duì)于每一個(gè)測(cè)試應(yīng)用，測(cè)試時(shí)間不超過(guò)1個(gè)小時(shí).

表6 AutoSim對(duì)應(yīng)用界面覆蓋率的提示效果Table 6 Improvement of AutoSim on improving UI coverage

測(cè)試結(jié)果表明AutoSim能有效擴(kuò)大33.7%的UI覆蓋率.表6為本次實(shí)驗(yàn)的結(jié)果，在測(cè)試中共有13個(gè)應(yīng)用包含需要用戶(hù)文本輸入的UI，如表6中所示，14個(gè)應(yīng)用不需要用戶(hù)文本輸入，另外3個(gè)在打開(kāi)應(yīng)用時(shí)由于無(wú)法連接服務(wù)器而導(dǎo)致崩潰.從表6中的數(shù)據(jù)可以看出，在13個(gè)需要文本輸入的應(yīng)用中，AutoSim能夠顯著增加其中6個(gè)應(yīng)用遍歷的UI數(shù)目.我們分析另外7個(gè)遍歷UI數(shù)目沒(méi)有增加的應(yīng)用時(shí)發(fā)現(xiàn)，在這些應(yīng)用中，需要用戶(hù)文本輸入的UI并不會(huì)影響應(yīng)用的正常訪問(wèn).例如，包名為“com.protogeo.moves”應(yīng)用中包含有創(chuàng)建應(yīng)用賬號(hào)的功能，但是這個(gè)功能在設(shè)置頁(yè)面中，即使不創(chuàng)建賬號(hào)，我們也基本可以訪問(wèn)到應(yīng)用的所有UI和功能.

6 總 結(jié)

在對(duì)移動(dòng)應(yīng)用自動(dòng)化動(dòng)態(tài)分析過(guò)程中，缺少或者為應(yīng)用提供錯(cuò)誤的文本輸入會(huì)嚴(yán)重的限制自動(dòng)化動(dòng)態(tài)分析效率和覆蓋率.為了解決這個(gè)問(wèn)題，本文提出了AutoSim.AutoSim采用機(jī)器學(xué)習(xí)的方法來(lái)高效的識(shí)別應(yīng)用需要的文本輸入的類(lèi)型，并通過(guò)基于Xposed的技術(shù)將符合需要類(lèi)型的文本，在應(yīng)用動(dòng)態(tài)執(zhí)行的過(guò)程中準(zhǔn)確高效地注入到對(duì)應(yīng)的控件中，使自動(dòng)化動(dòng)態(tài)分析能夠通過(guò)需要用戶(hù)輸入的UI，執(zhí)行更多的代碼.針對(duì)AutoSim的實(shí)驗(yàn)評(píng)測(cè)結(jié)果表明，AutoSim能夠有效識(shí)別應(yīng)用需要輸入的類(lèi)型，并且能夠有效增加在動(dòng)態(tài)分析中遍歷到更多的UI，執(zhí)行更多的代碼.