ZecOps 對 AliExpress 平臺購買的 Android 手機取證分析,發現該手機將系統 Android 6 偽造欺騙成...

語言: CN / TW / HK

ZecOps 對 AliExpress 平臺購買的 Android 手機取證分析,發現該手機將系統 Android 6 偽造欺騙成 Android 10。我們會在本文介紹攻擊者如何“偽造”iOS 上的關機螢幕以實現永續性,以及裝置偽造者如何將舊的 Android 裝置作為新裝置出售,偽造的規格包括偽造 CPU 速度、Android 版本、補丁級別、記憶體,甚至螢幕解析度。

我們能夠在全球速賣通上找到下面的手機。

這款手機看起來很棒,而且非常便宜。

在使用 ZecOps for Mobile 檢查了這款手機後這款裝置聲稱的Android 10其實是Android 6。

我們做的第一件事是轉到設定→關於手機。如下所示:

如上所示,該裝置顯示它是具有 10 個處理器核心的 Android 10。然後我們使用了一個名為“CPU-Z”的已知軟體。此應用程式用於檢查硬體屬性。

我們檢查了核心版本和裝置屬性:

由輸出可知核心版本為3.18.19,Android版本為6.0。設定應用程式,以及CPU-Z,試圖欺騙終端使用者。

讓我們檢查一下處理器:

我們看到了 MT6753。該處理器有 8 個核心,而不是“設定”應用程式中顯示的 10 個核心。

讓我們檢查一下API版本:

該API版本與Android 6一致。

此外,我們對這款手機的使用者介面做了一些觀察,它與我們之前使用的Android 6版本類似。

Android 偽造過程

設定應用程式和CPU-Z應用程式報告了相同的假硬體細節。為了瞭解Android 偽造過程,讓我們應關注 各個Android 版本並檢查所有其他應用程式是否確實看到與 CPU-Z 相同的裝置屬性,讓我們以 CPU-Z 或設定應用程式的方式進行操作。

首先,讓我們檢查一下這個 fake 是否是全域性的,這將幫助我們猜測發生偽造的正確元件。我們已經知道,使用 ADB 可以獲取正確的 OS 版本號,這與 SDK 版本和核心版本都是一致的。

讓我們從一個簡單的檢查開始,並建立一個起點:編寫我們自己的程式來檢查預編譯框架載入的實際版本。

程式碼(放置在基本專案模板的 onCreate 中):

輸出:

因此,這裡的所有內容都正確地顯示出來,並且與adb輸出一致。接下來我們需要檢查設定應用程式。

對應apk的提取和apktool'ing給了我們android版本字串資源id的id,它是“firmware_version”,但是裡面沒有classes.dex。沒關係,這是設定應用程式的常見情況。

使用 baksmali 進行 deodexing /system/priv-app/Settings/oat/arm/Settings.odex並獲取程式碼後,我們可以對其進行 grep 獲取 firmware_version 常量,並檢視它獲取os.android.Build.VERSION的內容。

在 DeviceInfoSettings.smali 中,我們會看到如下內容:

這對應於https://android.googlesource.com/platform/packages/apps/Settings/+/refs/tags/android-6.0.1_r55/src/com/android/settings/DeviceInfoSettings.java中的onCreate程式碼。

但是除錯資訊中的行號與確切的行不對應,只在所需的程式碼周圍。

將程式碼反編譯回java後,我們終於可以看到更有趣的內容了:

現在一切都清楚了,與原始實現類似的程式碼從未實際發生,因為“persyst.sys.hdf.androidsdk”在這款手機上的實際值為1。

這裡有一些有趣的細微差別,包括從 2018 年到 2019 年安全補丁級別的更換!

現在我們知道了虛假的 Android 版本是怎麼出現的了。它來自 HdfUtil.GetHrfAndroidString,以及許多其他虛假屬性。

讓我們進一步研究一下虛假Android版本是如何配置的:

正如我們在 onCreate 函式的開頭看到的那樣,呼叫了 SystemProperties.getInt(“persyst.sys.hdf.androidsdk”, 0)。

我們可以使用 getprop 實用程式驗證這個值,並看到返回值為 1,因此將顯示為 android 版本的值來自 HdfUtil.getHrfAndroidString 。

下面是這個函式的原始碼:

這個函式實際上是根據從 SystemProperties.getInt(“persist.sys.hdf.androidv”, 0) 返回的實際值返回值“10.0”,可以用 getprop 工具檢查,等於 7。

對於所有其他引數也會發生類似的操作。

DeviceInfoSettings 類的幾乎所有 onCreate 函式都引用了這個類,而不是像原來的 Android 源所說的那樣(主要是指 os.android.Build.VERSION 類,見下文)。

所有的硬體偽造都發生在 HdfUtil.java 中。這個檔案沒有被混淆。

當我們瞭解其中到底發生了什麼時,我們就可以將這臺裝置的真實硬體屬性與我們的設定應用程式所顯示的進行比較。

綜上所述,偽造的原因如下:

1.偽造者對現有 Android 6 環境的來源進行了更改。

2.他們從 Java 原始碼編譯了它,我們看到它是因為 smali 程式碼中存在有效的除錯資訊。

3.他們添加了一些我們可以在 /system/build.prop 中看到的構建引數和通過 adb 的輸出,這些引數定義了自定義設定應用程式應該向使用者顯示的確切內容。原始引數保持不變,因此所有未觸及的框架都可以正常工作。

4.HdfUtil.java 中的硬體變體數量表明該框架也可能用於偽造其他手機。

我們可以看到,這足以欺騙小白級的使用者,或是貪小便宜的人。

但還有三個謎團需要解決:

1.他們究竟是如何欺騙 CPU-Z 應用程式的,該應用程式在出現時並未安裝在手機上?

2.還有其他類似的手機?誰負責偽造規格,我們可以自動找到這些手機嗎?

3.手機上是否還有其他惡意軟體允許賣家遠端訪問裝置?

欺騙 CPU-Z 應用程式

在花了一些時間調查 android.os.Build.VERSION 的工作原理、root 裝置(mtk-su 完美執行)、反轉框架及其本機部分之後,我們主要專注於他們如何顯示虛假資料,而不是如何獲取版本號和字串。

看起來他們只是簡單地改變了類android.widget.TextView的程式碼,使其在特定的應用程式中顯示所需的虛假值。有時候,事情比看上去要簡單得多。

為了驗證我們應該從裝置中提取的 boot.oat,使用 oat2dex 實用程式將其轉換為 dex 檔案,然後反編譯生成的 dex 檔案。

看起來如下(以下程式碼來自 public final void setText(CharSequence var1) ):

其背後的主要思想如下:如果包的名稱是 com.cpuid.cpu_z (對應於 CPU-Z 包名稱)並且之前用 function 設定的字串是偽造的引數之一,則文字基於可以使用 getprop 檢查的相同構建引數,神奇地更改為以類似於設定應用程式中使用的方式編碼的值。

與以下包相關的類似程式碼片段也可以在此程式碼中找到:

com.antutu.ABenchMark
com.mediatek.camera
com.mediatek.filemanager
com.qiku.android.filebrowser
com.finalwire.aida64
com.ludashi.benchmark
ru.andr7e.deviceinfohw

這不僅增加了CPU-Z被欺騙的嫌疑,也增加了檢查裝置規格/裝置基準測試的其他常見應用程式的嫌疑。

在進一步分析了各種有趣的程式碼片段之後,我們反編譯了所有的框架,並且令人驚訝地發現了另一個有趣的發現,它分享了偽造者如何處理其他基準測試/規範應用程式的資訊。在規範偽造框架的其他類中似乎存在一些可疑活動,特別是在包管理器中。

在反轉包管理器之後,似乎除了欺騙這些應用程式之外,規範偽造者還用一種有趣的方法欺騙了包管理器:他們沒有安裝從 Google Play 下載的 APK,而是使用預先儲存和篡改的副本 /系統/資料。 經過簡要分析,我們得出結論,這些 APK 並不是惡意的。這一改變是為了確保他們正在處理的假冒應用程式版本經過了適當的測試,並顯示了虛假值。

最後,偽造人員在活動管理器中遮蔽了 Google Play 保護的崩潰報告,並根據 ro.hdf.shutdown.ani 引數修改了關機動畫。

至於預裝的惡意軟體及其作用我們將下一篇文章中介紹。