Android模擬器檢測體系梳理

轉自:https://www.wireghost.cn/2018/05/10/Android模擬器檢測體系梳理/

模擬器做爲一種虛擬機，配合改機工具，可以以較低成本實現設備多開，所以而備受黑灰產的青睞。如何準確識別模擬器成爲App開發中的一個重要模塊，目前也有專門的公司提供相應的SDK供開發者識別模擬器。經過前段時間對模擬器檢測技術的調研，但願能總結出一套特徵挖掘的體系化方案。

模擬器概述

定義

安卓模擬器是一種能夠運行在電腦上的虛擬設備，經過它能夠實現應用的跨平臺操做，讓移動端APP無需任何改動便可在PC上執行。

特性

優點

隨着技術的不斷髮展，目前模擬器基本已經可以完成手機90%以上的功能。此外，因爲在PC端工做，與傳統手機相比，具備如下幾點優點：

• 更炫：支持大屏幕、提供更炫酷的視覺效果，從而可以自然的將一些移動端因爲適配成客戶端應用；
• 易上手：支持鼠標、鍵盤、手柄、攝像頭等衆多硬件外設，將操做方式從手指運動中解放出來，發揮外設的優點；
• 更強的性能：經過模擬器可自定義配置性能參數，發揮PC硬件性能優點，跑分數據遠超手機，使得高配遊戲運行再也不卡頓；
• 更好的操控性：經過虛擬按鍵功能，可以將任意點觸操做、震動、搖搖等手機獨有操做映射到鍵盤的自定義按鍵，更加簡易、便捷；
• 使用PC工具：利用PC端其餘輔助工具完成對移動端應用的支持，如經過按鍵精靈完成自動掛機等操做，解放雙手；
• 模擬多人操做：經過模擬器多開功能，零成本體驗同時多部手機、多個帳戶開小黑屋，實現刷單的快感；
• 更便捷的虛擬定位功能：經過模擬器虛擬定位，讓你輕鬆落腳五湖四海；
• 不再用擔憂電池電量、手機流量了…

問題

此外，Android模擬器鑑於自身技術瓶頸，也存在如下廣泛問題：

• 性能：運行時廣泛須要佔據較大的CPU、內存等資源，致使低配機運行不流暢。此外，即使是高配機，多開也很容易出現卡頓等現象；
• 穩定性：模擬器技術自己的BUG致使的閃退、花屏、無響應等現象；
• 兼容性
  • 硬件兼容性：主要表現爲大部分模擬器對AMD架構PC的不支持；
  • 應用兼容性：好比部分模擬器尚不兼容ARM架構的APP，又或者某些應用對安卓內核、虛擬機的調用方式比較底層，當模擬器對這些接口支持的很差時，表現爲該類程序沒法在模擬器上運行；
  • PC系統兼容性：表現爲模擬器主要適配Windows主流平臺，而能在Mac下運行的不多，且太低、太高版本支持的很差（如XP以前版本、Win 10，市面上某些定製的平板系統等）；
  • 安卓系統兼容性：目前模擬器上的Android系統仍然停留在4.x，部分達到5.1，使得部分對安卓版本有要求的應用或遊戲在模擬器上運行體驗很差。

底層關鍵技術

虛擬化技術

模擬器是用軟件來模擬硬件操做，這就須要用到虛擬化技術。廣義的虛擬化，是指將網絡、CPU、內存及存儲等各類實體資源，予以抽象、轉換後呈現出來，進而打破實體結構間不可切割的障礙，使用戶能夠比本來的組態更好的方式來應用這些資源。咱們所熟知的虛擬機就是虛擬化技術中的一種，一般來講它們只是模擬了一套與Host主機相同架構、相同指令集的硬件平臺，不涉及內存和CPU的虛擬化。全部的Android模擬器都在不一樣程度上運用了虛擬化技術，好比雷電、夜神，包括Bluestack模擬器是基於Virtualbox虛擬機，谷歌原生模擬器和紅手指雲模擬器則是應用了Qemu的虛擬化技術。

CPU虛擬化

目前，已知的全部ARM架構的模擬器都是基於Qemu虛擬機。Qemu採用的是純軟件模擬，在物理機的操做系統上建立一個模擬硬件的程序來仿真全部想要的硬件，而後在上面跑ARM運行時。在這種環境下，因爲程序每次執行都須要將其翻譯成宿主機（X86）的指令，致使性能很是低下，這也是原生模擬器不夠流暢的緣由之一。

ARM Translation

當下主流的Android模擬器都是X86架構，基於Virtualbox虛擬機。因爲不須要作CPU虛擬化，少了一層指令集轉換過程，所以在運行支持X86架構的app時，就和普通的虛擬機沒有區別，速度也就明顯提升了不少。
此外，針對ARM架構的兼容性問題，廣泛採用的是半虛擬化，根據二進制翻譯技術將ARM指令動態翻譯成X86指令。

黑產經常使用的模擬器

目前市面上安卓模擬器軟件種類繁多，有5一、mumu、藍疊、夜神、逍遙、海馬玩、雷電等等。經過在黑產彙集論壇、QQ羣等多個渠道進行調研，咱們發現黑產當下經常使用的是夜神、雷電和逍遙模擬器。
能夠注意到，這些模擬器的共通點是都自帶修改設備參數、多開、操做錄製和虛擬定位等功能。

模擬器檢測技術框架

模擬器檢測的本質就是要利用模擬器和真機之間的微小差別，從而判斷當前設備是否爲模擬器，具體檢測技術框架整理以下：

如何挖掘特徵

結合前面梳理出的模擬器檢測框架，後續在作相應的特徵挖掘時，可直接根據該腦圖作進一步的完善和增強。

特徵項	細分點		描述	備註
軟件信息	應用層
	系統庫
無線射頻	WIFI
	GPS
	…
硬件信息	底層硬件	CPU
		電池
		設備參數
	硬件抽象層	圖形
		相機
		藍牙
		輸入
		存儲
		傳感器
文件系統（重點關注Linux內核相關）	檢查/sys硬件驅動信息
	檢查/dev設備節點特徵
	檢查/proc運行時的內核信息映射
	…

此外，基於文件系統差別的特徵挖掘，具體可參考Android根目錄文件結構進行操做，如下是幾個重要的目錄/文件的說明：

• /mnt：掛載點目錄
• /etc：指向 /system/etc ，系統配置文件所在目錄
• /data：存放用戶安裝的應用以及各類數據
• /system：Android系統目錄文件夾
• /dev：設備節點文件存放地
• /sys：用於掛載 sysfs文件系統，在設備模型中，sysfs文件系統用來表示設備的結構，將設備的層次結構形象的反應到用戶空間中
• /proc：這是一個虛擬的文件系統，不佔用實際存儲空間。它以文件系統的方式爲訪問系統內核的操做提供接口，動態從系統內核中讀出所需信息
• init.rc：啓動腳本
• default.prop：系統屬性配置文件

對應的檢測弱點

基於模擬器結構特徵

利用任務調度檢測模擬器

原理

模擬器與真機的本質區別在於運行載體，市面上已知的ARM模擬器都是基於qemu虛擬機。因爲qemu在執行程序時其實是將其翻譯成宿主機的指令，好比將安卓的arm指令翻譯成PC的x86指令。爲了效率上的考慮，qemu在翻譯執行arm指令時並無實時更新模擬的pc寄存器值，只會在一段代碼翻譯執行完以後再更新，而真機中pc寄存器是一直在更新的。根據這一點，能夠設計一段CPU任務調度程序來檢測模擬器。

優缺點

優勢：由於是基於qemu的二進制翻譯技術來作特徵檢測，因此可以很好的識別這類Android模擬器。
缺點：

1. 須要本身設計反應離散程度的算法來統計任務調度的地址分佈狀況，想要實際應用到SDK有些困難
2. 會執行彙編代碼，在不一樣的機器設備上須要考慮穩定性和兼容性等問題

利用cache特性檢測Android模擬器

原理

因爲絕大部分手機都是基於ARM架構，而模擬器幾乎所有是運行在PC的X86架構上。所以，能夠利用ARM與X86的底層緩存行爲差別來判斷是否爲真機。
具體來講，ARM採用的是將指令存儲與數據存儲分開的哈佛架構，L1 Cache（一級緩存）被分紅了平行的兩塊，即I-Cache（指令緩存）和D-Cache（數據緩存），而X86採用的是將指令存儲和數據存儲合併在一塊兒的馮•諾伊曼結構，L1 Cache是連續的一塊緩存。因此，若是咱們經過讀寫地址指令的方式對一段可執行代碼進行動態修改，那麼在執行的時候，X86架構上的指令緩存會被同步修改，而對ARM架構而言，這種數據讀寫操做修改的只是D-Cache中的內容，此時I-Cache中的指令並不會被更新。

優缺點

優勢：可以準確的識別arm和x86架構。
缺點：要執行彙編代碼，在不一樣的機器設備上須要考慮穩定性和兼容性等問題。實測發現容易引發崩潰，須要配合多進程予以解決。

基於Android體系架構

應用層行爲數據

這種檢測方案本質上是對正經常使用戶的行爲模式進行統計分析，它也許不能有效的對真機和模擬器進行區分，但能夠做爲風險設備畫像的一個參考維度。

無線射頻

WIFI

檢查WIFI列表這種方式，目前沒發現明顯缺點。當正常手機接入WIFI的時候，周邊每每有複數的WIFI信號，而模擬器因爲不具有檢索周邊WIFI的能力，其WIFI列表一般爲空或者只有一個WIFI。

GPS

這種檢測手法的原理是基於模擬器沒有真實的GPS模塊，一般沒法獲取到地理位置信息。缺點是部分用戶在實際使用中可能會關閉該權限，致使獲取不到數據。

硬件信息

底層硬件

• CPU
  1. 型號：正常x86手機的cpu型號爲intel atom，arm則是聯發科，高通，麒麟等。缺點是須要大盤作數據分析，另外可能要結合手機型號等其餘維度才能作一個比較好的識別。
  2. 溫度：目前來看應該是比較靠譜的，缺點是須要大量的數據統計作支撐，不排除有誤殺的可能。
• 電池
  須要在後臺屢次採集數據，檢驗電壓、電量是否有實時變化，實際應用起來有些困難。。
• 設備
  經過系統API獲取手機硬件參數，能夠說是很是傳統的模擬器檢測方案了。也正是由於傳統，基本上都知道會獲取哪些信息，因此缺點是很容易遭到篡改。

硬件抽象層

• 相機
  經過提取攝像頭參數信息，能夠有效的識別當前設備是否爲「主流手機」。缺點是考慮到平板、學習機等「冷門設備」的存在，不能直接區分出模擬器，須要結合其餘維度一塊兒使用，且須要接入的APP有打開攝像頭的權限。
• 藍牙
  若想從API層面進行檢測，那就必須先開啓藍牙，而這個須要彈框讓用戶確認。
• 輸入
  缺點是對觸摸事件的處理是在前臺完成的，若是是做爲SDK可能不是很好接入和應用。
• 存儲
  1. 閃存分區
     Android系統的更新以及刷機等方式都有可能致使分區的變化，目前來看，在高版本的機器上檢查mmcblk、dm-x分區並非一個靠譜的特徵，須要配合其它維度一塊兒使用。
  2. /mnt掛載
     這種文件名的檢測手法只能針對性的作特定模擬器檢測、不通用，且很容易經過版本更新、更名等手段進行繞過。
• 傳感器
  除判斷設備有支持哪些傳感器外，若想要作更進一步的驗證，就仍然繞不開屢次採集數據的問題。

文件系統

特色是用於作特徵檢出的目錄文件與底層硬件的關聯性越強，其效果越好，反之越可能失效。建議儘可能提取和虛擬機、硬件驅動相關的文件特徵，缺點是部分特徵可能須要結合大量的機型數據作可靠性驗證。