問(wèn)題描述

Android 市場(chǎng)的開(kāi)放性導(dǎo)致了惡意軟件（Malware）的盛行。據(jù) 360 安全中心報(bào)告，每天都能截獲數(shù)萬(wàn)個(gè) Android 惡意軟件，使得 Android Malware Detection 成為研究人員熱議的話題。傳統(tǒng)的 Android 惡意軟件檢測(cè)方法主要依賴于基于規(guī)則或簽名的檢測(cè)機(jī)制，其中使用 yara 實(shí)現(xiàn)相對(duì)簡(jiǎn)單。但這種基于簽名的檢測(cè)方法是信息密集型的，需要持續(xù)收集新的簽名，而基于規(guī)則的實(shí)現(xiàn)則極為復(fù)雜，極易導(dǎo)致誤報(bào)或讓狡猾的惡意軟件逃過(guò)檢測(cè)。

隨著機(jī)器學(xué)習(xí)的流行，越來(lái)越多的研究人員開(kāi)始嘗試?yán)脵C(jī)器學(xué)習(xí)來(lái)實(shí)現(xiàn)惡意軟件的檢測(cè)。核心思路是從 Android 的 APK 文件中提取信息，用于訓(xùn)練模型，隨后預(yù)測(cè)其他 APK 文件是否為惡意軟件。根據(jù)信息提取方法的不同，主要分為兩類：一類是通過(guò)靜態(tài)分析，從 APK 中提取 permissions、intents、receivers 等組件，以及通過(guò)反編譯提取代碼調(diào)用，利用這些信息進(jìn)行模型訓(xùn)練；另一類是通過(guò)實(shí)際安裝運(yùn)行 APK，攔截網(wǎng)絡(luò)請(qǐng)求和監(jiān)聽(tīng)系統(tǒng) API 調(diào)用來(lái)獲取數(shù)據(jù)，作為模型訓(xùn)練的基礎(chǔ)。

在探討此問(wèn)題時(shí)，由于“Incinerator”項(xiàng)目的動(dòng)態(tài)檢測(cè)功能尚未完全實(shí)現(xiàn)，我們暫時(shí)缺乏研究動(dòng)態(tài)分析的條件，因此選擇采用靜態(tài)分析方法進(jìn)行研究。

當(dāng)前主流方案

基于靜態(tài)分析的機(jī)器學(xué)習(xí)訓(xùn)練方案主要包括以下幾類：

1. 權(quán)限提取訓(xùn)練：

• 從 AndroidManifest.xml 中提取 permissions 信息進(jìn)行模型訓(xùn)練。
• 綜合信息提取訓(xùn)練：

從 AndroidManifest.xml 中提取 permissions、intents、receivers 等信息，并通過(guò)反編譯從 APK 中基于規(guī)則抽取 Android 系統(tǒng) API 調(diào)用等信息進(jìn)行模型訓(xùn)練。

• 整體 APK 訓(xùn)練：

• 將整個(gè) APK 文件作為機(jī)器學(xué)習(xí)訓(xùn)練的輸入，包括將 APK 文件的二進(jìn)制字節(jié)流作為輸入，或通過(guò)反編譯抽取 opcode 作為訓(xùn)練輸入。

據(jù)文獻(xiàn)報(bào)道，這些方案可實(shí)現(xiàn) 90% 以上的準(zhǔn)確率。尤其是方案 3，準(zhǔn)確率在 92%-93% 之間，而方案 1 和 2 在多數(shù)研究中可達(dá)到 95% 以上的準(zhǔn)確率。

我們?cè)噲D重現(xiàn)文獻(xiàn)中的方案，首先著手基于 permissions 的方案進(jìn)行驗(yàn)證。

數(shù)據(jù)源：

• 惡意軟件集合：

a. 來(lái)自威脅情報(bào)公司 abuse.ch 的 Malware APK 集合 2000 個(gè)（簡(jiǎn)稱 MB）

b. VirusShare 2020/2021/2022 的 Malware 集合（簡(jiǎn)稱 VS2020/VS2021/VS2022）

• 良性軟件集合：

a. 從應(yīng)用寶下載的 APK 10000 個(gè)

b. 從 APKPURE 下載的 APK 10000 個(gè)

訓(xùn)練方法

通過(guò)靜態(tài)分析從 APK 的 AndroidManifest.xml 中抽取 AOSP （Android Open Source Project） permissions，并通過(guò) One-hot Encoding 的方式輸入模型進(jìn)行訓(xùn)練。模型選擇采用傳統(tǒng)的機(jī)器學(xué)習(xí)二分類模型如隨機(jī)森林、SVM 等進(jìn)行訓(xùn)練。經(jīng)測(cè)試，隨機(jī)森林的效果最佳，準(zhǔn)確率可達(dá) 98%。

我們選擇應(yīng)用寶的 APK 作為良性樣本，VS2022 作為惡意軟件樣本，進(jìn)行訓(xùn)練。訓(xùn)練數(shù)據(jù)如下：

然后我們對(duì)其他數(shù)據(jù)集進(jìn)行測(cè)試驗(yàn)證：

在進(jìn)行 APKPure 數(shù)據(jù)集的驗(yàn)證時(shí)，發(fā)現(xiàn)模型的假陽(yáng)性率異常高，超過(guò)了 50%，這表明模型在不同數(shù)據(jù)集的交叉驗(yàn)證上表現(xiàn)不佳。同時(shí)，在 MB、VS2020、VS2021 數(shù)據(jù)集上得到的高準(zhǔn)確率由于高假陽(yáng)性率而變得無(wú)意義。

為了深入理解模型的預(yù)測(cè)表現(xiàn)，我們選擇使用 LinearSVM（線性支持向量機(jī)）來(lái)解釋模型的預(yù)測(cè)結(jié)果，并嘗試探討可能出現(xiàn)的問(wèn)題：

在訓(xùn)練過(guò)程中，共有 265 個(gè)權(quán)限被用于訓(xùn)練模型。我們重點(diǎn)分析了對(duì)于 Malware 預(yù)測(cè)結(jié)果影響最大的 30 個(gè)權(quán)限：

0 1.9507425950717683 android.permission.READ_SMS
1 1.6805547441380115 android.permission.SEND_SMS
2 1.5291784053142392 android.permission.RECEIVE_SMS
3 1.281383891333467 android.permission.WRITE_SMS
4 1.1385944832617678 android.permission.GET_DETAILED_TASKS
5 1.0870145778775504 android.permission.MANAGE_USERS
6 0.9822953162458009 android.permission.SET_TIME_ZONE
7 0.9815855293627985 android.permission.REQUEST_DELETE_PACKAGES
8 0.8705538278525148 android.permission.ACCOUNT_MANAGER
9 0.7701851337780519 android.permission.ACCESS_CACHE_FILESYSTEM
10 0.7493889020376178 android.permission.PERSISTENT_ACTIVITY
11 0.742267985802697 android.permission.SET_PREFERRED_APPLICATIONS
12 0.6575763216374741 android.permission.USE_SIP
13 0.6423455602781643 android.permission.MODIFY_PHONE_STATE
14 0.5733719308777389 android.permission.READ_CALL_LOG
15 0.5713221448442122 android.permission.WRITE_SECURE_SETTINGS
16 0.5177117115666185 android.permission.CLEAR_APP_CACHE
17 0.5013751180995185 android.permission.WRITE_SYNC_SETTINGS
18 0.47540432455574055 android.permission.INJECT_EVENTS
19 0.450576746748121 android.permission.BIND_ACCESSIBILITY_SERVICE
20 0.4497437629117625 android.permission.READ_SYNC_STATS
21 0.40721040702182304 com.android.alarm.permission.SET_ALARM
22 0.3958974436391258 android.permission.GET_PACKAGE_SIZE
23 0.35828369132005317 android.permission.TRANSMIT_IR
24 0.3538089622374305 android.permission.CHANGE_COMPONENT_ENABLED_STATE
25 0.3303834311984685 android.permission.STATUS_BAR
26 0.3277728921018696 android.permission.WRITE_USER_DICTIONARY
27 0.31322691738916597 android.permission.SET_DEBUG_APP
28 0.28600828593282673 android.permission.INSTALL_PACKAGES
29 0.27804088205285526 android.permission.SHUTDOWN

導(dǎo)致 Benign 結(jié)果最重要的 30 個(gè)權(quán)限：

1 -1.0280830288092226 android.permission.FORCE_STOP_PACKAGES
2 -1.0244749163270055 android.permission.DELETE_CACHE_FILES
3 -0.9235183435775582 android.permission.READ_PRIVILEGED_PHONE_STATE
4 -0.7975588094210508 android.permission.USE_BIOMETRIC
5 -0.7691538868495551 android.permission.READ_CELL_BROADCASTS
6 -0.7288571523071693 android.permission.REQUEST_INSTALL_PACKAGES
7 -0.7278186994140812 android.permission.WRITE_CALL_LOG
8 -0.7029898754031535 android.permission.READ_SEARCH_INDEXABLES
9 -0.6832562629713737 android.permission.ACCESS_NOTIFICATION_POLICY
10 -0.6442707037030093 android.permission.BIND_NOTIFICATION_LISTENER_SERVICE
11 -0.6229441323892875 android.permission.CAPTURE_AUDIO_OUTPUT
12 -0.5951302503005503 android.permission.REORDER_TASKS
13 -0.552113274404841 android.permission.FACTORY_TEST
14 -0.5512329811397917 android.permission.CAMERA
15 -0.5415431826751977 android.permission.PACKAGE_USAGE_STATS
16 -0.5373788445105623 android.permission.READ_SYNC_SETTINGS
17 -0.5300427083556158 android.permission.ACCESS_WIFI_STATE
18 -0.48952375397337794 android.permission.READ_PHONE_NUMBERS
19 -0.4822239255635727 android.permission.STOP_APP_SWITCHES
20 -0.4525220364959383 android.permission.WRITE_MEDIA_STORAGE
21 -0.4133049145725493 com.android.browser.permission.WRITE_HISTORY_BOOKMARKS
22 -0.3902532535519829 android.permission.CAPTURE_VIDEO_OUTPUT
23 -0.34681147328619505 android.permission.READ_FRAME_BUFFER
24 -0.34134222449779317 android.permission.WRITE_GSERVICES
25 -0.3335042039412585 android.permission.BIND_APPWIDGET
26 -0.3263774109427998 android.permission.AUTHENTICATE_ACCOUNTS
27 -0.3136298914538836 android.permission.NFC
28 -0.3000955825422318 android.permission.READ_EXTERNAL_STORAGE
29 -0.2846046321402758 android.permission.CALL_PRIVILEGED
30 -0.28338090002182315 android.permission.READ_CALENDAR

在表格中，第二列顯示了通過(guò) SVM 計(jì)算得到的權(quán)重值。由于在標(biāo)簽設(shè)定中，Malware 被標(biāo)記為 1，而 Benign 被標(biāo)記為 0，且訓(xùn)練數(shù)據(jù)的格式是 0，1，1，0，...0,1,1,0,...這樣的布爾值，因此，當(dāng)權(quán)重為正時(shí)，該權(quán)重在計(jì)算 Malware 的預(yù)測(cè)結(jié)果時(shí)具有較高的重要性；權(quán)重值越大，其重要性越高。相反，當(dāng)權(quán)重為負(fù)時(shí)，該權(quán)重在計(jì)算 Benign 的預(yù)測(cè)結(jié)果時(shí)具有較高的重要性；權(quán)重值越小，其重要性越高。

通過(guò)分析這些權(quán)限及其功能，我們發(fā)現(xiàn) Malware 相關(guān)的權(quán)限通常比 Benign 相關(guān)的權(quán)限具有更高的危害性。在一定程度上，這種模型的設(shè)計(jì)是合理的。例如，模型成功識(shí)別了與 SMS 相關(guān)的權(quán)限主要與 Malware 相關(guān)，并賦予了較高的權(quán)重，這意味著，基本上，一個(gè) APP 如果包含 SMS 權(quán)限，就非常可疑。實(shí)際上，普通的 APP 不應(yīng)該請(qǐng)求此類權(quán)限，因?yàn)槎绦殴芾硗ǔＪ窍到y(tǒng) APP 的職責(zé)。

然而，這里存在一個(gè)問(wèn)題：權(quán)限的存在是因?yàn)?Android 系統(tǒng)認(rèn)為某些行為可能不妥，需要用戶確認(rèn)。所以，理論上，所有需要請(qǐng)求的權(quán)限都有可能對(duì)用戶造成損害。因此，沒(méi)有請(qǐng)求權(quán)限應(yīng)該被視為一個(gè)加分項(xiàng)。但在二分類機(jī)器學(xué)習(xí)的情境下，模型會(huì)做出區(qū)分，因?yàn)?Benign 類別的存在意味著一定會(huì)有一部分權(quán)限被視為支持 Benign 的證據(jù)。

現(xiàn)在我們來(lái)分析為什么會(huì)出現(xiàn)如此高的假陽(yáng)性率： 我們使用 LinearSVC 來(lái)解釋模型的預(yù)測(cè)結(jié)果，并對(duì)一些具有假陽(yáng)性的權(quán)限信息進(jìn)行分析：

0.1773649887447295 android.permission.WAKE_LOCK
0.01285824377030036 android.permission.INTERNET
-0.1357928094523775 android.permission.ACCESS_NETWORK_STATE

0.43102404170044467 com.android.alarm.permission.SET_ALARM
0.1773649887447295 android.permission.WAKE_LOCK
0.14741402851800423 android.permission.SYSTEM_ALERT_WINDOW
0.02740438240042149 android.permission.FOREGROUND_SERVICE
0.01285824377030036 android.permission.INTERNET
-0.1357928094523775 android.permission.ACCESS_NETWORK_STATE
-0.15043626374678254 android.permission.WRITE_EXTERNAL_STORAGE
-0.1975995718519041 android.permission.CHANGE_WIFI_STATE
-0.20461138790573433 android.permission.VIBRATE
-0.511067438637911 android.permission.ACCESS_WIFI_STATE

0.1773649887447295 android.permission.WAKE_LOCK
0.02740438240042149 android.permission.FOREGROUND_SERVICE
0.01285824377030036 android.permission.INTERNET
-0.1357928094523775 android.permission.ACCESS_NETWORK_STATE
-0.33867385510052594 android.permission.READ_EXTERNAL_STORAGE
-0.511067438637911 android.permission.ACCESS_WIFI_STATE

而真陽(yáng)的權(quán)限信息：

0.32757400447767016 android.permission.INSTALL_PACKAGES
0.2870058866311678 android.permission.READ_PHONE_STATE
0.1773649887447295 android.permission.WAKE_LOCK
0.1545767541451571 android.permission.FLASHLIGHT
0.14613075920332474 android.permission.BLUETOOTH_ADMIN
0.140268653568319 android.permission.GET_ACCOUNTS
0.08641386050999389 android.permission.MOUNT_UNMOUNT_FILESYSTEMS
0.06460516872049353 android.permission.ACCESS_COARSE_LOCATION
0.01285824377030036 android.permission.INTERNET
-0.009804892771664459 android.permission.ACCESS_FINE_LOCATION
-0.12321341834571817 android.permission.READ_LOGS
-0.1357928094523775 android.permission.ACCESS_NETWORK_STATE
-0.15043626374678254 android.permission.WRITE_EXTERNAL_STORAGE
-0.15994619600450963 android.permission.CHANGE_NETWORK_STATE
-0.16005902734200772 android.permission.WRITE_SETTINGS
-0.1975995718519041 android.permission.CHANGE_WIFI_STATE
-0.20461138790573433 android.permission.VIBRATE
-0.23536025455979454 android.permission.CALL_PHONE
-0.24802834827531783 android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
-0.30018060973660377 android.permission.BLUETOOTH
-0.33867385510052594 android.permission.READ_EXTERNAL_STORAGE
-0.511067438637911 android.permission.ACCESS_WIFI_STATE
-0.5625902678304402 android.permission.CAMERA
-0.7242676191415552 android.permission.REQUEST_INSTALL_PACKAGES

通過(guò)分析，我們發(fā)現(xiàn)了一個(gè)模式：擁有較少權(quán)限的 APK 往往會(huì)被誤判，而權(quán)限較多的 APK 基本能得到正確的預(yù)測(cè)。深入探究后，我們理解到這種現(xiàn)象的出現(xiàn)主要是由于 APKPure 樣本中大多數(shù) APK 的權(quán)限數(shù)量較少，而我們的訓(xùn)練模型主要基于權(quán)限較多的應(yīng)用寶 APK 樣本。因此，預(yù)測(cè)誤差的產(chǎn)生在一定程度上是由樣本差異導(dǎo)致的。

為了解決這個(gè)問(wèn)題，一個(gè)直接的方法是將 APKPure 的數(shù)據(jù)也納入訓(xùn)練過(guò)程，以增強(qiáng)模型的泛化能力和預(yù)測(cè)準(zhǔn)確性。

我們采取了以下措施：從 APKPure 樣本中隨機(jī)抽取一半，即 5000 個(gè) APK，同時(shí)從應(yīng)用寶樣本中隨機(jī)抽取一半，約 5000 個(gè) APK，一同用于模型的訓(xùn)練。然后，我們使用這個(gè)新訓(xùn)練得到的模型來(lái)預(yù)測(cè)未參與訓(xùn)練的樣本。結(jié)果顯示，新模型的預(yù)測(cè)準(zhǔn)確率得到了顯著提高。

然后我們對(duì)其他數(shù)據(jù)集進(jìn)行測(cè)試驗(yàn)證：

假陽(yáng)性率已降至可接受的水平。這個(gè)實(shí)驗(yàn)揭示了一個(gè)重要的現(xiàn)象：在訓(xùn)練集上獲得理想的結(jié)果相對(duì)容易，但在現(xiàn)實(shí)世界中準(zhǔn)確預(yù)測(cè)卻可能面臨挑戰(zhàn)。無(wú)人能保證所收集的樣本完美地反映了現(xiàn)實(shí)世界的情況，而我們的目標(biāo)是識(shí)別那些真正與惡意軟件（Malware）相關(guān)的特征。因此，我們決定嘗試探索其他可能的解決方案。

1. 基于 Intents 和 Receivers 的訓(xùn)練

隨后，我們擴(kuò)展了特征集，加入了從 AndroidManifest.xml 中提取的 intents 和 receivers 信息進(jìn)行訓(xùn)練，然而，這并沒(méi)有提高模型的準(zhǔn)確率。

2. 基于系統(tǒng) API 調(diào)用的訓(xùn)練

我們進(jìn)一步嘗試提取 APK 中的所有系統(tǒng) API 調(diào)用，將其轉(zhuǎn)換為適合卷積神經(jīng)網(wǎng)絡(luò)（CNN）的格式，并通過(guò) CNN 來(lái)訓(xùn)練模型。在訓(xùn)練集上，模型達(dá)到了令人滿意的 97% 的準(zhǔn)確率，但在數(shù)據(jù)集交叉驗(yàn)證時(shí)，表現(xiàn)仍然不盡如人意。

在這過(guò)程中，我們遇到了幾個(gè)問(wèn)題：、

• API 調(diào)用頻率的不明顯差異： 最初，我們通過(guò)反編譯提取了所有出現(xiàn)過(guò)的 API 調(diào)用，卻發(fā)現(xiàn)這些 API 的調(diào)用頻率并沒(méi)有明顯差異。例如，我們?cè)菊J(rèn)為 accessibilityservice 的調(diào)用明顯與惡意軟件相關(guān)，卻發(fā)現(xiàn)在良性軟件中也頻繁出現(xiàn)。后來(lái)我們了解到，這主要是因?yàn)榇蠖鄶?shù) APK 都依賴于 android 這個(gè)庫(kù)，而該庫(kù)中包含了大量的系統(tǒng) API 調(diào)用。由于 Malware 和 Benign APK 都依賴于大量的第三方庫(kù)，這些庫(kù)中存在大量的系統(tǒng) API 調(diào)用，使得我們難以從系統(tǒng) API 調(diào)用的統(tǒng)計(jì)結(jié)果中區(qū)分 Malware 和 Benign。即便我們使用了 incinerator 的 SCA 分析功能來(lái)檢測(cè)和剔除這些第三方庫(kù)，結(jié)果仍然不盡如人意。
• 第三方庫(kù)的干擾： 我們發(fā)現(xiàn)，很少有研究考慮到第三方庫(kù)的干擾，并提出剔除第三方庫(kù)的具體方案。如果不剔除這些庫(kù)，基于靜態(tài)分析的方法幾乎毫無(wú)意義，因?yàn)殪o態(tài)抽取會(huì)抽取出大量未被調(diào)用的 API，而這在 Malware 和 Benign APK 中沒(méi)有明顯區(qū)別。
• 反編譯和脫殼問(wèn)題： 由于這種方法涉及從 APK 中抽取系統(tǒng) API 調(diào)用，需要進(jìn)行反編譯。然而，許多 Malware 都加殼處理，而脫殼是一個(gè)復(fù)雜的對(duì)抗技術(shù)。我們查閱的資料中，很少提到這一點(diǎn)。脫殼對(duì)于非專業(yè)團(tuán)隊(duì)來(lái)說(shuō)可能太過(guò)困難，但至少應(yīng)該從數(shù)據(jù)集中篩選出沒(méi)有殼的 APK。如果不進(jìn)行脫殼，直接抽取的話，只能得到極少數(shù)的 dexloader 等系統(tǒng) API 調(diào)用，這大大影響了訓(xùn)練效果。

3. 回歸基于 Permissions 的模型

鑒于前述的嘗試未能取得預(yù)期效果，我們重新回到基于 Permissions 的模型，尋求通過(guò)其他方法提升交叉驗(yàn)證的準(zhǔn)確率。我們進(jìn)行了以下嘗試：

• 通過(guò) Select 模型選擇 Permissions 采用此法的目的是尋找 Malware 實(shí)際所利用的 Permissions。然而，實(shí)際測(cè)試結(jié)果顯示，訓(xùn)練準(zhǔn)確率下降，驗(yàn)證準(zhǔn)確率也下降，且交叉驗(yàn)證的準(zhǔn)確率更是降低。
• 我們的實(shí)驗(yàn)過(guò)程如下： 使用 SelectFromModel 方法，基于 RandomForestClassifier 模型（該模型包含所有參與訓(xùn)練的數(shù)據(jù)）進(jìn)行參數(shù)抽取。我們分別抽取了 100、50、30 個(gè) Permissions 進(jìn)行實(shí)驗(yàn)，并得到了如下數(shù)據(jù)：
• 選取 100 個(gè) Permissions訓(xùn)練數(shù)據(jù)：

• 選取 50 個(gè) Permissions訓(xùn)練數(shù)據(jù)

• 訓(xùn)練 30 個(gè) Permissions訓(xùn)練數(shù)據(jù)

分析及新的嘗試

從前述數(shù)據(jù)中可見(jiàn)，減少 Permissions 的數(shù)量并未能改善假陽(yáng)性率或提高準(zhǔn)確率。

• 利用自編碼器（Auto Encoder）進(jìn)行降維
• 為了進(jìn)一步嘗試改善模型表現(xiàn)，我們轉(zhuǎn)向了自編碼器（Auto Encoder）技術(shù)，期望通過(guò)對(duì) Permissions 的分組和降維來(lái)提高準(zhǔn)確率。自編碼器是一種能夠?qū)W習(xí)數(shù)據(jù)編碼的神經(jīng)網(wǎng)絡(luò)，通常被用于降維或特征學(xué)習(xí)。我們的想法是通過(guò)自編碼器將 Permissions 的高維數(shù)據(jù)轉(zhuǎn)換為低維數(shù)據(jù)，同時(shí)保留與 Malware 識(shí)別相關(guān)的重要信息。
• 然而，盡管我們嘗試了自編碼器的降維方法，交叉驗(yàn)證的結(jié)果仍然不盡如人意，假陽(yáng)性率依然較高。

通過(guò)業(yè)務(wù)邏輯選擇 Permissions

隨后，我們嘗試通過(guò)業(yè)務(wù)規(guī)則來(lái)挑選適當(dāng)?shù)?Permissions。我們的方法是這樣的：

• 我們統(tǒng)計(jì)了所有 Malware 中每個(gè) Permission 的出現(xiàn)頻率 mp 和所有 Benign 中每個(gè) Permission 的出現(xiàn)頻率 bp。
• 然后計(jì)算了 bp/mp

然而，這種方法也未能提高訓(xùn)練準(zhǔn)確率和驗(yàn)證準(zhǔn)確率。例如，android.permission.INTERNET 這樣的權(quán)限在 Malware 和 Benign 中出現(xiàn)的概率非常接近，大約都在 97% 左右，這樣的權(quán)限參與訓(xùn)練并沒(méi)有太大的意義。類似地，android.permission.WAKE_LOCK 在 Malware 和 Benign 中出現(xiàn)的概率也非常接近，大約在 80% 左右。

我們還嘗試了其他研究論文中提到的一些方法。經(jīng)過(guò)測(cè)試，我們發(fā)現(xiàn)無(wú)論采取何種方法來(lái)篩選 Permissions，篩選后的訓(xùn)練準(zhǔn)確率都不如不篩選、直接使用所有 Permissions 進(jìn)行訓(xùn)練的準(zhǔn)確率高。這個(gè)發(fā)現(xiàn)與許多將 Permissions 篩選作為主要研究目的的論文的結(jié)論相左。

結(jié)論

經(jīng)過(guò)多次嘗試，我們暫時(shí)未能訓(xùn)練出一個(gè)在單一數(shù)據(jù)集上訓(xùn)練，而在其他數(shù)據(jù)集上也具有理想準(zhǔn)確率的模型。因此，我們決定將應(yīng)用寶和 APKPure 的數(shù)據(jù)合并作為 Benign APK 的訓(xùn)練集，同時(shí)將其他幾個(gè) Malware 數(shù)據(jù)集也合并作為 Malware APK 的訓(xùn)練集，以提高樣本的平均均衡度。

當(dāng)然，我們也發(fā)現(xiàn)了一些可能的優(yōu)化方向：

• 我們注意到 Malware 和 Benign 的 APK 簽名存在一定的模式，如果能夠驗(yàn)證這些模式，可以將其納入現(xiàn)有模型中。
• 在手動(dòng)分析樣本時(shí)，我們發(fā)現(xiàn)許多 Malware APK 樣本在靜態(tài)分析階段無(wú)法判斷為惡意，因?yàn)樗鼈兊臋?quán)限沒(méi)有任何可疑信息。例如，許多 dropper、downloader 等類型的惡意 APK，在權(quán)限上與 Benign APK 沒(méi)有明顯區(qū)別。因此，人工篩選惡意 APK 可能有助于提高訓(xùn)練準(zhǔn)確率。
• 同時(shí)，將動(dòng)態(tài)檢測(cè)的信息納入訓(xùn)練模型也是一個(gè)值得嘗試的方向。我們計(jì)劃在后續(xù)的研究中加入動(dòng)態(tài)信息以提升模型的表現(xiàn)。

原文鏈接：https://www.liansecurity.com/#/main/news/TfrG0IoBQKl-d7iA6Wuh/detail