動態防護技術
動態防護技術
動態防護技術是面向App運行過程的防護，一方面可以通過App動態加固技術來實現，比如程序數據加解密保護、進程防動態調試保護、運行日志輸出保護、用戶信息輸入保護等;另一方面需要開發者在App實現方案中采用保護技術，如客戶端和服務器端通信過程的保護等。此次僅介紹App動態防護技術的實現思路，不討論具體的實現方案細節。
1.10.1防調試
在對Android App進行逆向破解的過程中，動態調試是最常用也是最有效的方式。動態調試攻擊是指攻擊者利用調試器跟蹤目標程序運行，查看、修改內存代碼和數據，分析程序邏輯，進行攻擊和破解等行為。比如對于金融類app，動態調試可以修改APP業務操作時的賬號、金額等數據。相應的App防調試安全要求在之前章節已有描述，常用的動態調試工具有IDAPro gdb等，開發者通過提高App防調試的能力，能夠增加App的破解難度。
由于Android平臺沒有禁止用于調試的ptrace系統調用，惡意程序在得到ROOT權限后，可以使用系統API對目標進程的內存、寄存器進行修改，達到執行shellcode、注入惡意模塊的目的。在注入惡意模塊后，攻擊者就可以動態獲取內存中的各種敏感信息，例如用戶名、密碼等。除了 ptrace系統調用外，Android 系統中的proc 文件也暴露了大量的程序進程信息，能夠實現對內存的讀寫操作，因此對程序進行反調試的保護是非常有必要的。攻擊者常常利用動態調試工具以及掛鉤系統函數跟蹤程序的執行流程，分析程序執行邏輯，查看并修改內存中的代碼和數據。因此，本節主要介紹防調試和防掛鉤方法的基本思路。
1.防調試方法
在Linux系統中，一個進程只能被附加一次，因此可以讓App進程復制出子進程，然后對自已進行附加，這樣就可以防止調試器在App運行過程中附加到App的進程中。
當一個進程被跟蹤時，對應的進程status文件中的TracerPid字段會發生變化。當進程沒有被跟蹤或者調試時，TracerPid字段的默認值是0;如果進程被跟蹤或者被調試，則該字段的值為跟蹤進程的pid值。通過輪詢/proc/app_pid/status文件，讀取TracerPid的字段值，可以判斷App當前是否被調試跟蹤。以下是檢查TracerPid的示例代碼:
char file [MAX_ _LEN], line[MAX_ _LEN];snprintf (file, MAX_ LEN -1, "/proc/%d/status"，getpid());/*這些地方都需要進行下列檢查
/proc/<pid>/status
/proc/<pid>/task/ <chdpid>/status，
/proc/<pid>/stat
/proc/ <pid>/task/ <chdpid>/stat
/proc/<pid> /wchan
/proc/ <pid>/task/ <chdpid> /wchan
*/FILE *fp = fopen (file, "r");while (fgets (line, MAX _LEN -1，fp)) {if (strncmp (line, "TracerPid:", 10) == 0) { if (0 != atoi (&line[10])) {//進程處于被調試之中
} break;
}
}
fclose (fp);
利用Linux系統的inotify機制監測/proc目錄，利用監聽函數監測/proc目錄是否阻塞在監聽處，一旦有調試進程通過/proc文件系統對App進程內存進行讀寫操作，監聽函數就會停止阻塞， 就可以判定有調試進程正在通過/proc文件系統。以下是inotify 監視/proc文件系統中maps是否被訪問的示例代碼:
bool check_ inotify(){ int ret, i; const int BUF_SIZE = 2048; char buf[BUF_ SIZE]; int fd, wd;
fd_ set readfds;
fd = inotify_init();
sprintf(buf, "/proc/%d/maps", getpid());
wd = inotify_add_watch(fd, buf, IN_ ALL_EVENTS); if(wd>=0){ while (1) {
i= 0; FD_ ZERO(&readfds); FD_ SET(fd, &readfds);
ret = select(fd + 1, &readfds, 0, 0, 0); if (ret == -1) { break;
} if (ret) { while (i < read(fd, buf, BUF _SIZE)) { struct inotify_event *event = (struct inotify_event *) &buf[i];
if ((event->mask & IN_ACCESS) || (event->mask & IN _OPEN)) { // maps被訪問
return true;
}
i+=sizeof(struct notify_event)+event->len;
}
}
}
}
inotify_ rm _watch(fd, wd);
close(fd);
}
2.防掛鉤方法
常用的掛鉤工具有Xposed和CydiaSubstrate。二者的掛鉤原理相似，都要替換系統中的 /system/bin/app_process文件。在系統啟動過程中，init 進程通過app_process文件啟動Zygote進程，從而加載Xposed劫持虛擬機的文件，實現注入Zygote進程的效果。Android系統在運行App時，會通過Zygote進程復制一個進程運行APP，那么APP進程就有了Zygote進程的完整復制， 包括Xposed的相關文件，Xposed 也就完成了App進程注入的工作。
當App進程被Xposed注入，或者運行在一個有被注入風險的移動設備上時，App的進程內存中就應該包含Xposed的相應注入文件。查看/proc/App_pidmmaps 文件，讀取mmaps文件中的信息，判斷App進程中是否加載了Xposed的相關文件，就可以判斷App是否被掛鉤。
本節的App防護措施能夠解決安全測試過程中出現的防調試和防注入問題。
1.10.2 防日志輸出
通過對調試日志輸出的函數進行掛鉤攔截，按照預設的等級允許或者阻止調試日志的輸出，即可實現防日志輸出的效果，統一關閉App、第三方SDK插件和so文件產生的所有調試日志。所有的Android App調試日志輸出最后都會運行liblog.so中的_ android_log_ print/write()函數。函數原型如下:
int _android_log_ print (int prio，const char *tag， const char *fmt, …); int _android_log_write (int prio, const char *tag, const char *text);
prio泰示輸出日志的優先級，tag表示日志的TAG,其他的參數為調試日志輸出的字符串。若對上述函數進行掛鉤，可以根據參數完成過濾，從而統一關閉調試日志。
本節的App防護措施能夠解決安全測試過程中出現的日志泄露問題。在App數據生命周期中的數據處理階段，如果APP發布時沒有及時刪除敏感函數功能的調試日志，就會導致后臺打印日志泄露用戶敏感數據或泄露代碼邏輯。通過加固日志保護處理后，在APP運行期間，后臺將沒有敏感日志同步輸出。
1.10.3安全軟鍵盤
安全軟鍵盤通過白盒加密技術對密鑰進行保護，使用嚴格的加密方式對用戶輸入的信息進行安全處理，架構如圖所示。
加固的實現過程如圖所示。
安全軟鍵盤加固的具體實現流程如下。
1）生成鍵盤方案：初始化鍵盤信息， 隨機分配學符位置。加載字符對應的圖片資源完成鍵盤的演示。
2）加密鍵盤輸入:對通過交互界面輸入的密碼進行動態SM4或AES加密，點擊完成后可以輸出密文發送至后臺解密。
(3)后臺解密:后臺獲取到密文后，調用解密函數對加密數據進行SM4或AES解密，解密返回明文的鍵盤輸入。
本節的App防護措施能夠解決安全測試過程中出現的防系統鍵盤泄露敏感數據、防本地數據存儲安全和防錄屏/截屏的風險問題。
1.10.4防界面劫持
防界面劫持的核心是判斷當前App運行的界面是否被覆蓋。在Android 5.0之前，開發者可以使用ActivityManager中提供的方法操作棧，但是Android5.0之后，谷歌公司出于保護用戶隱私的考慮，弱化了這個接口。ActivityManager只能管理App自身的棧，如果想管理其他App的棧，需要用戶主動授權，而很多手機廠商對這個權限做了進一步限制，只能為系統App等特定的App授權。因此，Android 5.0之后就無法再通過管理棧的方式實現界面防劫持，開發者只能通過App自身的Acticity生命周期管理來達到界面防劫持的效果。
在App運行時，當運行界面發生視圖焦點變化，即當前Activity 變為onPause 狀態時，App應能捕獲當前界面狀態變化并進行相應的分析，提示用戶可能出現的安全風險，同時嘗試對系統輸人入法進行監視，防止惡意程序誘導用戶輸入敏感信息。App防界面劫持的加固實現過程如下。
(1)在受保護的界面啟動時，獲取當前正在運行的系統后臺進程CPU、內存占用信息并存儲，同時啟動后臺服務，在服務中判斷當前界面是否失去焦點。
(2)一旦檢測到當前界面失去焦點，立即獲取當前正在運行的程序信息，如果正在運行的程序是本App，當沒有視圖焦點時，比對之前獲取的系統后臺進程鏡像和現在的系統后臺進程信息，如果存在惡意行為則提示風險。
(3)如果當前運行的程序不是本App，而此時程序界面失去焦點，則獲取當前正在運行的程序，提示風險。
(4)如果當前界面失去焦點，經上述檢測未發現風險，則啟動鍵盤行為檢測；若發現覆蓋界面短時間內出現鍵盤顯示行為，誘導用戶輸入信息，則提示風險。
實現App防界面劫持的示例代碼如下:
public class MyBaseActivity extends Activity { private static Set set = new HashSet(); private boolean b= true;
@override
protected void onCreate(Bundle savedInstanceState) { if (set.size()==0) { try { InputStream is = getAssets(). open( "white. txt”);
BufferedReader br = new BufferedReader(new InputStreanReader(is,"UTF-8"));
while (true){
String write= br.redline();
if (write == null){
break;
}
set . add(write);
}
is.close();
br .close();
}
catch (IOException exp) {
exp. printStackTrace));
}
}
set . add( getPackageName());
super .onCreate( savedInstanceState);
}
protected void onPause() {
if(b){
String packagename=((ActivityManager)getSystemService(Context.ACTIVITY_SERVICE)).getRunningTask(1).get(0).topActivity.getPackageName();
if(!set. contains( packagename)){
String msg=“疑似界面劫持攻擊，請小心使用，并查殺病毒!”;
Toast toast = Toast.makeText(getApplicationContext(), msg，Toast.LENGTH_LONG);
toast.setGravity(17, 0，0);
toast. show();
b = false;
}
}
b = true;
super. onPause();
}
}
本節的App防護措施能夠解決安全測試過程中出現的界面劫持問題。由于Android界面每次只能顯示一個Activty，攻擊者利用這個機制，使用偽造的仿冒界面或透明界面覆蓋在正常界面上，誘騙用戶輸入敏感信息，就會導致信息泄露。通過防界面劫持加固，App一旦發現有其他頁面覆蓋或者程序轉向后臺，將會給出界面被劫持的安全風險提示，讓用戶提高警惕，以免上當受騙。
1.10.5防篡改
App篡改是指這樣一種攻擊過程: 攻擊者通過逆向分析工具對APP 進行反編譯后，在APP程序內添加或修改代碼、替換資源文件、修改配置信息、更換圖標、植入非法代碼，再對篡改后的代碼進行二次打包，生成各種盜版、釣魚APP。尤其對于金融類APP來說，添加攻擊代碼可能導致用戶登錄賬號、支付密碼、短信驗證碼等敏感信息泄露，攻擊者進而實施修改轉賬賬號和金額等犯罪行為，因此非常有必要對APP進行防篡改保護。根據防篡改技術實現方式的不同，App防篡改主要有簽名校驗和完整性校驗兩種實現方式。
1.簽名校驗防篡改
App的數字簽名可用于驗證開發者身份，一旦攻擊者對App進行修改并重新打包，App的數字簽名一定會發生變化。因此，開發者可以獲取App中證書文件的證書指紋MD5并存儲在程序中，當App運行時，讀取證書指紋MD5并與當前apk文件中的證書指紋MD5進行比對。如果比對結果一致，就說明App未被篡改，否則說明App已被篡改。
2.完整性校驗防篡改
我們還可以采用完整性校驗技術對App的安裝文件進行哈希校驗，再對文件內容進行交叉校驗，在App中對校驗數據及校驗代碼做加密保護。
當一個App被防篡改加固保護后，一旦攻擊者對加固后的App 進行任何修改，App 就會在運行時執行校驗代碼，對照存儲的校驗數據檢測App的內容是否被篡改，如果校驗不通過，則表示App被篡改，程序將終止運行。
本節的App防護措施能夠解決安全測試過程中發現的防篡改問題。App完整性校驗技術可以防止攻擊者反編譯App、篡改源代碼、修政改資源文件、添加惡意代碼模塊并二次打包，保護開發者利益。
1.10.6防截屏/錄屏
截屏/錄屏攻擊指的是APP采用系統自帶軟鍵盤或者使用自身定制的軟鍵盤，在用戶使用軟鍵盤進行按鍵過程中出現陰影、放大等特效功能，導致攻擊者通過采用系統自帶的截屏命令或錄屏命令進行多次截屏/錄屏，達到獲取用戶軟鍵盤輸入信息的目的。攻擊者使用的截屏命令和錄屏命令如下所示:
screenshot /data/local/tmp/test.jpg screenrecord -time-limit 4 test. mp4
防截屏/錄屏攻擊的核心是禁止攻擊者進行截屏/錄屏操作，關閉程序的截屏/錄屏功能，方法是在Activity中onCreate()方法的Layout初始化部分加入FLAG _SECURE實現，示例代碼如下所示:
public class FlagSecureTestActivity extends Activity { @Override
public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
getWindow().setFlags(LayoutParams . FLAG_ SECURE， LayoutParams . FLAG_SECURE);
setContentView(R. layout .main);
}
}
本節的App防護措施能夠解決安全測試過程中出現的防截屏/錄屏問題。
1.10.7模擬器檢測
Andoid模擬器本來是用于模擬真機的功能，讓開發者即使在沒有真機的環境中也能調試App的各項功能。但是，真機一般是沒有經過ROOT的環境，而模擬器是已經ROOT的運行環境。因此，攻擊者常常使用模擬器來調試和破解正常的App。
模擬器檢測是指App在運行時結合模擬器的特點，檢測運行環境是否為模擬器，并根據檢測結果判斷是否繼續執行。模擬器的主要檢測方法有以下3種
(1)檢測設備的IMEL、MAC值、Device_Id以及Tlephoy_Sevive中的運營商、國家等信息，判斷運行環境是否為模擬器。但是目前這部分數據不能作為判新的唯一依據，部分模擬器已經可以修改IMEI、設備信息、運營商、手機號等信息，如夜神模擬器、逍遙模擬器等。
2)檢測設備的監牙狀態信息來判斷運行環境是否為模報器。通過系統服務獲取藍牙狀態信息，如果藍牙設備存在，但藍牙的名稱為null,說明當前運行環境不是模擬器環境，反之為模擬器環境，相關示例代碼如下:
Public coolen readBlueTooth(){
BluetoothAdapter readbt = BluetoothAdapter .getDefaultAdapter();
if (readbt == null) {
return true;
} else {
String name = readbt.getName();
if (TextUtils .isEmpty(name)) {
return true;
} else {
return false;
}
}
}
當然，開發者還可以增加對傳感器的檢測，例如檢測光傳感器。不過，溫度、壓力等傳感器不能作為判斷的依據，因為部分設備上不存在溫度和壓力傳感器。
(3)根據模擬器的特征來判斷運行環境是否模擬器，示例代碼如下:
public boolean checkEmu() {
if (Build. FINGERPRINT . startsWith( " Emulator")) return true;
if (Build. MODEL. contains(" Emulator")) return true;
if (Build. SERIAL. equalsIgnoreCase(" android")) return true;
if (Build. BRAND. startsWith("generic")) return true;
return false;
}
由于Android設備的嚴重碎片化，建議組合使用多個規則來判斷運行環境是否為模擬器。
本節的App防護措施能夠解決安全測試過程中出現的模擬器檢測問題。如果發現在模擬器環境中運行，則彈窗提示用戶App在不安全環境下運行，或者禁止在模擬器中安裝或運行。
1.10.8 應用多開檢測
應用多開主要用于游戲類和聊天類App，目的是使游戲玩家能夠同一時間開啟多個終端，實現快速升級。也有同一手機上開啟多個終端，登錄不同的賬戶，實現原理類似。應用多開檢測用于識別在App運行期間是否存在應用多開的情況。下面介紹 5種檢測應用多開的方法。
(1)檢測files目錄路徑
App的私有目錄是“/data/data/包名/”或“data/user/用戶號/包名”，通過Context.getFilesDir()方法可以拿到私有目錄下的files日錄。在多開環境下，獲取到的目錄會變為“/data/data/多開App 的包名/xxxx”或“/data/user/用戶號/多開App的包xxxx。可以通過比對files目錄的數量判斷應用是否多開。
(2)檢測是否能在
/data/data/<package_name>/目錄下創建文件
在Adroid系統中，除了ROOT管理員外，只有APP自身有權限在它沙箱中創建文件，如不能創建文件，則可以判斷為應用多開環境。
(3)ps檢測
原理為UID是系統分配的一個應用標識，每個App對應一個UID,應用虛擬化并未真正安裝App，因此UID必定和宿主一樣通過ps命令查看UID所對應的包名是否為當前App的包名，如不是，則可能為應用雙開環境。通過ps命令加包名過濾得到的結果如下所示:
//正常情況下 u0_ a148 8162 423 1806036 56368 SyS_ epoll+ 0 S com. package //多開環境下 u0_ a155 19752 422 4437612 62752 SyS_ _epoll+ 0 S com.package u0_ a155 19758 422 564234 54356 SyS_ epoll+ 0 S duokaicom. package
(4)應用列表檢測
多開App克隆了原始App，并具有同樣的包名。當使用克隆App時，會檢測到原始App的包名和多開App的包名一樣，因此可以通過獲取系統已安裝的App列表來查看是否有重復的包名，如果有，則為應用多開環境。
(5) maps檢測
原理是通過/proc/self/maps信息進行檢測，如果當前環境為應用多開環境，則系統會加載一些多開的so文件到內存空間，示例代碼如下:
Private boolean checkpkgs(List<String> pkgs){
try{
BufferedReader br =new BufferedReader(new InputStreamreader(new FileInputStream(“/proc/self/maps")));
String line:
While((line = br.readLine())!=null){
for(int I=0;i<pkgs.size();i++){
return line.contains(pkgs.get(i));
}
}
}catch (Exception e){
e.printStackTrace();
}
return false；
}
本節的App防護措施能夠解決安全測試過程中出現的應用多開問題。App運行期間如果發現應用多開的情況，則彈窗提示用戶App已啟動，不要重復運行，進而保護App的安全。
1.10.9ROOT環境檢測
手機ROOT給用戶帶來了非常大的自主權，讓用戶可以刪除系統應用，查看并修改程序的運行信息，但與此同時，也給惡意軟件大開方便之門，給設備信息安全帶來了極大的挑戰。目前許多App在啟動時會進行ROOT環境檢測，防止App在已經ROOT的手機環境中運行，如果發現設備已經被ROOT，會向用戶提示運行環境存在安全風險，終止App的運行。
除了檢測ROOT工具的安裝路徑，包名帶有SU、supersu或superuser等關鍵詞外，下面再介紹3種ROOT環境檢測的方法。
(1)檢查su命令是否存在
通常要獲取ROOT權限，是使用su命令來實現的，因此可以通過檢查這個命令是否存在來判斷運行環境是否ROOT。
(2)檢查Andorid屬性
檢查ro.debuggable、ro.secure這兩個屬性是否為true:
adb shell getprop ro. debugable adb shell getprop ro.secure
如果以上兩個屬性為true,說明ApP所運行的環境很可能是ROOT環境。
(3)檢查特定路徑是否有寫權限
具體的路徑包括:
/system、/system/bin、/system/sbin、/system/xbin、/vendor/bin、/sys、/sbin、 /etc、 /proc、 /dev。
通過mount命令確認對應分區的權限是否為“rw” 。
adb shell mount | grep -w /sysfs on /sys type syfs (rw,seclabel,relatime)
不過值得注意的是，使用上述方法檢測ROOT環境會存在一些誤報， 開發者需要綜合考慮。
本節的App防護措施能夠解決安全測試過程中出現的ROOT環境檢測問題。綜合使用多種方法檢測ROOT環境，如果發現在ROOT環境中運行，則彈窗提示用戶App在不安全環境中運行，或者禁止安裝并運行。
1.10.10掛鉤框架檢測
掛鉤框架檢測指的是防止攻擊者利用開源的掛鉤框架開發自定義的攻擊模塊，對程序進行掛鉤算法破解、敏感API監控、網絡通信過程監控等攻擊。下面介紹4種檢測Xposed的方法。
(1)通過檢測Xposed的特征判定Xposed是否存在，示例代碼如下:
StackTraceElement[] l = new Thread().getStackTrace();
for (int i= 0; i< l.length; i++) {
if (l[i].getClassName(). contains("xposed")) return true;
}
(2)通過classloader檢查系統中是否存在兩個Xposed特征類:
private static final String XPOSED_ HELPERS = "de. robv.a android. xposed. XposedHelpers"; private static final String XPOSED_BRIDGE = "de.robv. android.xposed. XposedBridge";
(3)查看當前進程中是否存在和Xposed相關的動態庫(so 文件):
File file = new File("/system/lib/libxposed_ art.so");
file files = new File("/system/lib64/libxposed_art.so");
(4)查看是否安裝Xposed包。這種方式最簡單，也最容易被繞過:private static final String pkgXposed=” de.robv. android.xposed.installer”;
本節的App防護措施能夠解決安全測試過程中出現的防Xposed 問題。使用多種方法檢測 Xposed 框架，如果發現App運行的設備中已安裝Xposed框架，則彈窗提示用戶App在不安全環境中運行，或者禁止安裝運行。
1.10.11 小結
本章介紹了App的動態防護技術，包括防調試、防日志輸出、安全軟鍵盤、防界面劫持、防篡改、防截屏/錄屏、模擬器檢測、應用多開檢測、ROOT環境檢測、掛鉤框架檢測共10種動態防護技術的基本原理和簡單實現，幫助開發者應對在程序代碼安全、本地交互安全、本地數據安全等安全測試工作中發現的問題。
經過安全加固的App在安全防護能力上有了很大的提 升，但是大量的代碼隱藏、代碼加密、防調試等App安全防護技術也給App 的安全測試工作帶來了很大的挑戰。要對加固后的App開展安全測試工作，還需要開發者和安全測試工程師具備一定的脫殼能力。
文章轉自公眾號： Tide安全團隊
