Android惡意軟件模擬器檢測技術
前言
下面的報告來自SophosLabs實驗室的Android安全專家陳宇，還有來自Android組的成員William Lee, Jagadeesh Chandraiah and Ferenc László Nagy的幫助。
隨著Android惡意軟件的數量的持續增長，它緊隨Windows下的應用采用的用于逃脫模擬器的技術，用來防止被動態分析。在這篇文章中，我們將展示一些用于模擬器檢測的技術。
模擬器是一種可以允許一臺電腦(主機)模擬另外一臺電腦(客戶機)的硬件或軟件。通常，它允許主機系統運行軟件或者使用外部設備來模擬器客戶機系統。在安全方面，用它很容易檢測惡意軟件的行為，這也是為什么惡意軟件的作者很想避免運行于模擬器。
模擬器檢測技術在許多不同的Android惡意軟件家族中均被發現了，最近的一款是在Google Play發現的Android加載廣告的惡意軟件。
于是，下面是SophosLabs實驗室發現的6中常用的模擬器檢測技術：
1. 檢測手機服務信息
所有模擬器檢測的關鍵是確定模擬器和真機設備的運行環境之間的差異。首先，模擬器上面的設備ID、手機號、IMEI號和IMSI號都不同于真機設備。
android.telephony.TelephonyManager類提供了用于獲取設備信息的方法。Android應用程序可以通過該類里面的方法用于檢測手機服務和狀態，訪問一些運行商信息，注冊用于接收手機狀態變化通知的監聽器。例如，你能用getLine1Number方法來獲取卡1上的手機號信息。在模擬器上面，它將是“1555521”后面緊跟模擬器端口數字。例如如果模擬器端口是5554，它將返回15555215554。
Andr/RuSms-AT使用下面這種代碼用于檢測模擬器：
2. 檢測制造商信息
我們發現許多惡意軟件家族通過檢測制造商信息來判斷它是否運行在模擬器中。例如，下面這款銀行類的惡意軟件使用如下的模擬器檢測代碼：
其中的字符串被加密了，解密后的內容如下：
上面的方法是被一個廣播接收器調用的。在這款APP的manifest文件中，這個廣播接收器被定義為用于接收android.intent.action.BOOT_COMPLETED和 android.intent.action.SCREEN_ON事件。這意味著它將在手機啟動時或者被喚醒時調用。這是惡意軟件常用來啟動它們惡意行為的地方。但是，這款惡意軟件在模擬器檢測函數返回true時將什么都不做，如下所示：
3. 檢測系統屬性
另外一種方法是檢測系統屬性。模擬器上面的一些系統屬性和真機上面的不同。例如，設備廠商、硬件和model。下面這張表展示了模擬器上面一些系統屬性的值：
4. 檢測模擬器相關文件
這是另外一種在惡意軟件樣本中使用的技術。它們檢測QEMU (Quick Emulator)或者其他模擬器相關的文件是否存在。例如，下面的代碼片段在Andr/Pornclk變種中發現的。
5. 檢測調試器和安裝器
下面這種方法不是為了檢測模擬器，但是主要目的也是為了阻止動態分析。像下面這款詐騙廣告軟件，它使用Debug.isDebuggerConnected()和Debug.waitingForDebugger()來檢測是否存在調試器。更有趣的是，它同時也通過getInstallerPackageName獲取安裝器來查看它是否是通過Google Play安裝的(com.android.vending)。因此，像大部分的逆向分析者一樣，如果你是通過adb安裝應用程序到設備上的，這個應用程序就不會運行了。
6. 時間炸彈
下面是另外的一種方法，許多惡意軟件/廣告軟件利用這種方法在被動態分析時隱藏它們自身。在安裝后，它們在等待指定的時間后才啟動Activities。例如，某款惡意廣告軟件中發現了下面的配置文件：
- “settings”: {
- “adDelay”: 180000,
- “firstAdDelay”: 86400000,
- “unlockDelay”: 2,
- “bannerDelay”: 180000,
- “bannerPreDelay”: 10000,
- “bannersPerDay”: 25
- ,
firstAdDelay是第一條廣告被投遞到客戶端的毫秒時間，在上面的例子中是24小時。這也可以防止用戶懷疑。
我們相信，android惡意軟件和惡意廣告軟件的作者將會繼續編寫模擬器檢測技術的代碼，同時他們也已經獲得了一定程度的成功。安全公司必須使用較好的檢測方法匹配它們。
