Android手機安全軟件的惡意程序檢測靠譜嗎--LBE安全大師、騰訊手機管家、360手機衛士惡意軟件檢測方法研究

轉載請註明出處，謝謝。

 

Android系統開放，各大論壇活躍，應用程序分發渠道普遍，這也就爲惡意軟件的傳播提供了良好的環境。好在手機上安裝了安全軟件，是否能有效的檢測出惡意軟件呢？下邊針對LBE安全大師、騰訊安全管家和360手機衛士作出一系列實驗。

 

1. Android惡意樣本實驗。

      Android Malware Genome Project（http://www.malgenomeproject.org/）收集了2010年8月到2011年10月的涵蓋主要惡意軟件類型的超過1200個惡意程序樣本，樣本有些陳舊，但這是目前手頭上有的，最新的樣本不知如何得到，但願有了解的同窗留言告知。

      從中抽取了涵蓋不一樣類型的100多個樣本進行安裝實驗。結果惡意軟件識別率驚人的高。幾乎所有能夠檢測的到。

                            

      惡意軟件的檢測率如此高，確實很讓我驚訝，那這些安全軟件究竟是如何檢測惡意軟件的呢，實驗的結果更是讓我驚訝，這項實驗纔是重點。

2. Plankton類型的5aff5198c2fe5798bd7f1519dab0cd4ee737d5d2.apk程序測試安全軟件的檢測方式

      起初，我考慮檢測惡意軟件主要是掃描APK的Manifest文件，分析函數調用關係，因此我考慮對樣本進行反向工程，而後本身新建項目去實現，當增長一段代碼安全軟件就斷定爲惡意程序，刪除這一段代碼後就檢測正常時，這段代碼就是惡意軟件的核心特徵。在這樣的考慮下，首先綜合使用apktool、dex2jar和jdgui對apk樣本進行處理。

2.1 樣本反向工程

      5aff5198c2fe5798bd7f1519dab0cd4ee737d5d2.apk樣本爲一款憤怒的小鳥修改器程序，名稱爲Angry Birds Cheater，圖標以下：

                            

      Apktool處理，發現程序結構很簡單，只有res和smali目錄，還有Manifest.xml文件，Manifest文件中只有一個Activity和一個Service，申請的權限很多，我懷疑這些權限是否是一個檢測的點。

      Manifest文件以下：

<?xml version="1.0" encoding="UTF-8"?>
<manifest android:versionCode="3" android:versionName="2.01" package="com.crazyapps.angry.birds.cheater.trainer.helper"
  xmlns:android="http://schemas.android.com/apk/res/android">
    <application android:label="@string/app_name" android:icon="@drawable/icon">
        <activity android:label="@string/app_name" android:name=".AngryBirdsCheater" android:configChanges="keyboardHidden|orientation">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <service android:name="com.plankton.device.android.service.AndroidMDKService" android:enabled="true" />
    </application>
    <uses-sdk android:minSdkVersion="8" />
    <supports-screens android:anyDensity="true" android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="com.android.browser.permission.WRITE_HISTORY_BOOKMARKS" />
    <uses-permission android:name="com.android.browser.permission.READ_HISTORY_BOOKMARKS" />
    <uses-permission android:name="com.android.launcher.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="com.android.launcher.permission.UNINSTALL_SHORTCUT" />
    <uses-permission android:name="com.android.launcher.permission.READ_SETTINGS" />
    <uses-permission android:name="com.android.launcher.permission.WRITE_SETTINGS" />
    <uses-permission android:name="android.permission.READ_LOGS" />
    <uses-permission android:name="com.htc.launcher.permission.READ_SETTINGS" />
    <uses-permission android:name="com.motorola.launcher.permission.READ_SETTINGS" />
    <uses-permission android:name="com.motorola.launcher.permission.WRITE_SETTINGS" />
    <uses-permission android:name="com.motorola.launcher.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="com.motorola.launcher.permission.UNINSTALL_SHORTCUT" />
    <uses-permission android:name="com.lge.launcher.permission.READ_SETTINGS" />
    <uses-permission android:name="com.lge.launcher.permission.WRITE_SETTINGS" />
    <uses-permission android:name="com.lge.launcher.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="com.lge.launcher.permission.UNINSTALL_SHORTCUT" />
</manifest>

       

      Smali代碼看起來比較吃力，因此採用dex2jar和jdgui來查看代碼，代碼的結構以下圖：

                                   

      其中AngryBirdsCheater爲Activity，在onCreate方法裏調用了AndroidMDKService服務的initMDK方法啓動服務，而後向服務器請求攻擊指令，下載jar文件等。

      看雪論壇有對Plankton惡意程序的一篇分析文章：http://bbs.pediy.com/showthread.php?t=176363 。此處很少講了，由於實驗結果出現的太忽然了，根本沒須要深刻理解代碼過程，下邊解釋出現了什麼。

2.2 建立工程實現Plankton惡意程序

      接下來本身建立工程，程序名爲Plankton2，第一個Activity頁面就自動生成的也沒改，而後添加com.plankton.device.android.service包，建立AndroidMDKService類，在Manifest中聲明這個服務，寫到這，先運行下試試吧。

      結果，結果使人震驚：

                           

      什麼，這就報毒了，我還什麼都沒寫呢，MainActivity裏只有onCreate，並且裏邊只setContentView裏，AndroidMDKService裏只有onBind，裏邊仍是空的，Manifest文件裏甚至沒有申請一項權限。這誤報的太明顯了。

      Plankton2代碼結構：

               

 

      MainActivity代碼：

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

}

      AndroidMDKService代碼：

public class AndroidMDKService extends Service {

    @Override
    public IBinder onBind(Intent intent) {
        // TODO Auto-generated method stub
        return null;
    }

}

      Manifest文件：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.shuai.plankton2"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="17" />

    <application
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name" >
        <activity
            android:name="com.shuai.plankton2.MainActivity"
            android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        
        <service 
            android:name="com.plankton.device.android.service.AndroidMDKService">           
        </service>
    </application>
</manifest>

      這樣的結果着實很出乎個人意料。

      還好，360和他們不同，報的是安全的。

                 

      難道僅僅是有了AndroidMDKService類就唬住LBE和手機管家了嗎，如今點到這個類上F2，重命名，去掉MDK的K，從新安全，此時全部檢測均爲安全的了。

      進一步測試發現，必須是com.plankton.device.android.service包名下建立AndroidMDKService類纔會被檢測，看來LBE和手機管家檢測惡意程序是根據惡意類名的方式實現的，這樣的作法致使惡意軟件只要更改包名就能夠繞過檢測。

      360還沒法檢測到惡意，那繼續完善程序，根據反編譯的結果把類補充完整，由於反編譯的結果直接貼到工程中會有很多錯誤，修改了很長時間360仍是一直識別是安全的，我在想是否是由於哪些功能或者特徵沒有實現處理，因此360就不會報毒，讓我認爲360的檢測結果仍是比較靠譜的。

2.3 樣本重簽名，360不認識了

      忽然想到給程序重簽名試試看，重簽名的過程網上能夠搜到，用WinRAR打開APK文件，刪除META-INF目錄，而後在命令行用keytool生成密鑰，用jarsigner簽名。

      這時候再安裝，360報未發現安全風險，和上圖相同，這明明是個惡意程序的，怎麼成安全的了，只是換了個簽名而已，程序的惡意行爲部分又不會影響。

 

總結：

      普通的惡意樣本檢測中，三款安全軟件都表現良好，能準確的檢測出惡意軟件；進一步的分析中發現，LBE和騰訊手機管家識別惡意軟件時經過類的URI（不知道這種叫法是否合理），只要包名和類名符合惡意程序特徵，就會報惡意程序，即便這個程序什麼都不作，這就會形成不少誤報狀況發生，並且惡意程序能夠經過更換包名和類名的方法繞過檢測；360手機衛士是經過簽名來識別惡意程序的，對程序重簽名能夠繞過這種檢測方法。

      總的來講，靜態的基於特徵的檢測總會存在這些問題，這也是在考慮效果和性能狀況下的折中，畢竟在程序安裝時就進行復雜的檢測會帶來過大的系統開銷，可是這就又帶來了一下安全隱患，這種檢測方式還必須及時更新病毒庫，不然最新出現的惡意程序會沒法識別。