Lý thuyết
Giới thiệu về mã độc file Helper
Đây là mã độc được giả dạng trông như một ứng dụng trợ giúp tệp hợp pháp, quản lý tệp và các tài nguyên khác được lưu trữ trên điện thoại Android của bạn.
Mã độc được phát hiện hoạt động trên các dòng máy android từ bản 4.1.x đến 5.x chạy trên nền kiến trúc ARM
Tổng quan về Rootkit
Mã độc thuộc rootnik, một dạng mã độc (malware) nhắm vào hệ điều hành Android. Rootnik được phân loại là một loại rootkit, cho phép kẻ tấn công kiểm soát hoàn toàn thiết bị bị nhiễm. Ngoài ra nó có khả năng xâm nhập vào hệ thống và cấp quyền truy cập root mà không cần sự cho phép của người dùng
Các đặc điểm chính của Rootkit:
Quyền truy cập root: Rootkit khai thác các lỗ hổng bảo mật để có được quyền truy cập root trên thiết bị, cho phép nó cài đặt các ứng dụng khác mà không cần sự cho phép của người dùng.
Khả năng ẩn mình: Rootnik có khả năng ẩn mình khỏi các công cụ bảo mật và quản lý, làm cho việc phát hiện và loại bỏ nó trở nên khó khăn hơn.
Chức năng đa dạng: Có thể thực hiện nhiều hành động khác nhau như ghi lại các hoạt động của người dùng, đánh cắp thông tin cá nhân, tải xuống và cài đặt các ứng dụng độc hại khác, và gửi dữ liệu nhạy cảm đến máy chủ điều khiển của kẻ tấn công.
Phát tán thông qua ứng dụng giả mạo: Thường được phát tán thông qua các ứng dụng giả mạo hoặc các file APK không rõ nguồn gốc. Người dùng có thể vô tình tải và cài đặt nó khi nghĩ rằng đó là ứng dụng hợp pháp.
→ Mã độc file Helper chứa tất cả các đặc điểm trên khi thực hiện cài mã độc trên máy ảo
Luồng hoạt động chính
Luồng hoạt động của mã độc được miêu tả trong ảnh sau:
Nhìn vào sơ đồ ta có thể tóm gọn chu trình hoạt động gồm 3 hoạt động chính:
Đầu tìn chạy file .dex đầu tiên load file .so (file share objects binary) để lấy ra một file .dex thứ hai thực hiện
File .dex thứ hai thực hiện parse file KK.bin để lấy ra các file .dex, .apk , các file ELF
Phân tích từ các file được tải về từ remote server, tạo một file .js để thực hiện các command trong máy tạo 1 file .apk trong system/priv-app để thực hiện cac mục tiêu cuối
Đoạn cuối sau khi cài thêm file BSetting.apk nữa thì máy nạn nhân sẽ các “triệu chứng” sau:
Máy bị tạo nhiều screen shortcut trên màn hình
Các quảng cáo xuất hiện kèm theo là nhiều thông báo từ các apps lạ
Download nhiều file khác nhau cho lên máy nạn nhân
Phân tích file apk đầu vào
Kết cấu file mã độc
Đầu tiên sử dụng apktool giải mã file mã độc ta sẽ có cây thư mục của mã độc như sau:
Đối với phân tich mã độc trên Android thì đầu tiên chúng ta cần phải đọc tệp cấu hình AndroidManifest.xml. Đây là tệp tin cấu hình chính của ứng dụng Android và chứa các thông tin quan trọng như thành phần ứng dụng, quyền ứng dụng yêu cầu, ….
Dòng đầu tiên cho chúng ta thấy package name cho mã độc xuât hiện trong máy sẽ là com.web.sdlife , thuộc tính standalone="no": Chỉ ra rằng tài liệu này phụ thuộc vào các thực thể bên ngoài (external entities). Các phiên bản platform chỉ ra phiên bản mà mã độc được build lên
Bên dưới là các quyền mà mã độc yêu cầu để được sử dụng để hoạt động đúng cách. Mã độc đã yêu cầu hơn 50 quyền khác nhau cho hoạt động của mình
Đọc xuống bên dưới sẽ cung cấp thêm thông tin về cách hoạt động của mã độc
Chi tiết đoạn này đã khai báo application có chứa một lớp java có tên là com.secshell.shellwrapper.SecAppWrapper nhằm mục đích lớp này sẽ là lớp được chạy đầu tiên trước khi lớp mà hệ thống Android khởi tạo
Bên dưới là lớp Java định nghĩa action.main là com.sd.clip.activity.FileManagerActivity , nhưng ta không thể tìm được lớp Java này, bên cạnh đó là các lớp java Service class or Broadcast class trong lớp class.dex chính của mã độc
→ Mã độc sẽ tải một file .dex khác và thực thi nó
Giờ chúng ta đã biết đầu tiên chúng ta cần phải làm tìm hiểu lớp com.secshell.shellwrapper.SecAppWrapper trong class.dex
Phân tích tĩnh class.dex
→ Tóm lại luồng cơ bản của class này sẽ là:
Static code block (Load SecShell)-> attachBaseContext -> onCreate
Ngoài ra mã độc còn dùng multidex scheme để thực hiện tải file .dex thứ hai về từ thư viện native được thể hiện qua class DexInstall
Trong class này chỉ có 2 lớp chính như trên nên tiếp theo ta sẽ đi sâu vào phân tích thư viên native SecShell
Phân tích tĩnh thư viện native
Đọc luồng thực thi trong native code
Khi bắt đầu nhìn vào đoạn code Assembly của phần hàm JNI_Onload()
- Thư viện viết theo kiến trúc ARM
Kiến trúc ARM sử dụng kiến trúc RISC (Reduced Instruction Set Computing), có nghĩa là nó sử dụng một tập lệnh đơn giản và tối ưu hóa để thực hiện các tác vụ nhanh chóng và hiệu quả. Điếm khác biệt lớn ngoài hiệu năng và thời gian so với Intel đó là phần thanh ghi của ARM có nhiều hơn so với Intel nhưng số lượng instruction thì không bằng
→ Hàm p7E7056598F77DFCC42AE68DF7F0151CA() sẽ thực hiện chức năng anti-debugging
Anti-Debug là các kỹ thuật được sử dụng để vô hiệu hóa các Debugger, nhằm mục đích gây khó khăn cho công việc Reverse, làm tiêu tốn nhiều thời gian hơn khi thực hiện phân tích một mẫu
Kĩ thuật anti-hooking là các kỹ thuật và các chiến lược được sử dụng để ngăn chặn các kĩ thuật hooking trong phần mềm. Hooking là một kỹ thuật phổ biến được sử dụng trong lập trình máy tính để thay đổi hoặc mở rộng hành vi của các hàm, phương thức, hoặc sự kiện của một ứng dụng mà không cần thay đổi mã nguồn gốc của ứng dụng đó. Dễ hiểu hơn thì hook sẽ nhắm vào khoảng thời gian trước khi hệ thống đọc được dữ liệu thành công. Thư viện hook sẽ khiến cho hệ thống đọc sai địa chỉ lưu dữ liệu và các chỉ thị của hàm, từ đó khiến cho chương trình hoạt động sai so với thiết kế
Thực hiện bypass anti-debugging
Theo như chúng ta đã phân tích, điều cần làm là tránh cho chương trình chạy đến hàm p7E7056598F77DFCC42AE68DF7F0151CA() để thực thi hàm check có đang được debug hay không, do đó ta đi đến instruction trước khi gọi đến hàm Loc_F924 . Vì vậy:
Như trên ảnh thay vì để instruction “SUBS R1, R0, #0” tại địa chỉ 0xF828 , với instructions trước R1 chứa kết quả của R0 - 0 lưu vào R1 và vì BNE là lệnh "Branch if Not Equal", nghĩa là nhảy đến địa chỉ đích nếu kết quả của lệnh trước đó không bằng 0 (dựa trên cờ Zero). có 2 kết quả sau:
Qua đó đến khi debug ta sẽ thực hiện thay đổi giá trị thanh ghi R1
Ta có thấy địa chỉ thay đổi do phân tích tĩnh ta đang xem gọi là địa chỉ ảo còn khi thực hiện thì chúng ta sẽ thấy gọi là địa chỉ vật lý khi hệ điều hành ánh xạ các địa chỉ ảo này sang địa chỉ vật lý thực tế trong không gian địa chỉ của quá trình. Để thực hiện điều này thì cờ Address Space Layout Randomization (ASLR) cần được bật
Sau đó sẽ nhảy đến local_75178834
Sau khi bypass khỏi hàm anti-debugging, ta tiếp tục theo luồng và gặp một hàm load vào memory
Tiếp tục theo sau đó ta sẽ thu được một vùng memory khác chứa chữ ký khác
Chữ ký PK tượng trưng cho đây là file .zip. Do đó ta sẽ thực hiện dump memory này ra để chương trình đã lấy điều gì qua script của IDA
Bên dưới ta sẽ có thể thấy một hàm như install file .dex qua lời gọi của JNI
Phân tích file class.dex thứ hai
Sau khi thực hiện dump memory ta sẽ có file decrypt.dump như sau:
Vì là file .zip nên thực hiện decompress, sau đó ta sẽ có file .dex:
Dùng jd-gui phân tích thì trong cây thư mục ta sẽ có các class đã nói ở phần một:
Xem xét hàm OnCreate() trong class FileManagerActivity()
Giờ chúng ta sẽ đi sâu vào class PG
readDex()
Như trên ảnh thì đầu tiên lấy string là KK.bin ra biến V9 (KK.bin chính là file nằm trong cây thư mục gốc của file )
v10 sẽ lấy tên KK.bin đọc file đó trong thư mục assets (Vì KK.bin nằm trong thư mục KK.bin)
Đến phần cuối thì nó sẽ đọc trong file KK.bin thành các chuỗi ngắt nhau bằng dấu xuống dòng. Ta xem
Cuối là gọi hàm getAppid() của class Pls
→ Cuối cùng ta thu được một list các tên app trong Pls sau khi decode Base64
Pls.Kbin: wddex.jar
Pls.OI: xdt
Pls.PL: com.svq.cvo.Rtow
Pls.Jr: getDex
Pls.Wv: sgdex
Pls.as: dos.jar
Pls.NQ: KK.bin
dxFile()
DexClassLoader()
Lớp này có cấu trúc như sau:
Đây là một lớp trong Android thuộc gói dalvik.system, được sử dụng để tải các lớp từ các tệp .jar và .apk, mà có chứa mã bytecode Java và cho phép bạn tải và sử dụng các lớp từ các tệp mà không cần phải biên dịch chúng vào APK chính của ứng dụng
Với dexpath là file muốn tải, OptimizedDirectory là nơi chứa thì có thể biết được đối số muốn load là /data/data/com.web.sdfile/app_sgdex/dos.jar và đầu ra sẽ là /data/data/com.web.sdfile/app_xdt .
Phân tích file .dex từ dos.jar
Phân tích class com.svq.cvo.Rtow
Cấu trúc của hàmsilentInstall() có dạng như sau:
Phân tích file wsh.dex
Cấu trúc của file như sau:
Nội dung của class getDex():
Thực hiện nếu trong thư mục system không xuất hiện các apk trên sẽ thực hiện hàm GetActive() là được sử dụng để thu thập thông tin thiết bị và gửi nó đến máy chủ từ xa. URL của máy chủ từ xa là [`http://grs[.]gowdsy.]com:8092/active.do`
Kiểm tra xem một số tệp có tồn tại trong thư mục /data/data/com.web.sdfile/files/ hay không và thêm tên tệp của chúng vào danh sách mảng mà mã độc đang chuẩn bị cho bước tiếp theo là root thiết bị.
Thực thi rooting trên thiết bị.
Theo hàm run() trong class MTKRoot(), ta sẽ xem xét hàm HandleRoot():
Bắt đầu với copyRootFile()
FileUtil.dxfile() được sử dụng để giải mã tệp /data/data/com.web.sdfile/files/png.ico và lưu nó dưới dạng tệp /data/data/com.web.sdfile/app_dex/.do.
FileUtil.UnZip() được sử dụng để giải nén tệp /data/data/com.web.sdfile/app_dex/.do vào thư mục /data/data/com.web.sdfile/.rtt, là thư mục hệ thống ẩn chứa sáu tệp thực thi ELF, như được hiển thị bên dưới. Nó bao gồm bốn khai thác root r1,r2,r3,r4.
Nó xóa các công cụ root đã được giải mã /data/data/com.web.sdfile/app_dex/.do và thư mục /data/data/com.web.sdfile/app_dex
Sau đó, nó tạo một tệp mới, psneuter.js, trong thư mục /data/data/com.web.sdfile/files/. Nội dung của nó được hiển thị dưới đây.
Tiếp trong hàm executeRootAct() thì sẽ thực hiện với nội dung sau:
→ như vậy các thành phần từ r1 đến r4 sẽ thực hiện root được thiết bị còn thành phần psneuter.js sẽ thực hiện với quyền cao nhất tải các tệp thực thi vào /system/priv-app
Phân tích file apk trong system
Phân tích code
Sau khi file abc.apk chuyển tên thành BSetting.apk và được install vào máy nạn nhân nên ta sẽ thực hiện phân tích file abc.apk.
Xem xét cấu trúc của file abc.apk sau:
File AndroidManifest.xml:
class đầu tiên ta phân tích là com.sfy.oyr.R:
Vì gọi đến class D hàm a() nên ta phân tích
Mở đầu là một loạt khai báo các kiểu string
Chuyển mã Ascii sẽ là:
public static String d = "testdex.jar";
public static String e = "temp";
public static String f = "com.android.sync.ADSservice";
public static String g = "getDex";
public static String h = "com.android.sync.ADBoot";
public static String i = "getBDex";
public static String j = "sdex";
public static String k = "do.jar";
public static String l = "jif.png";
public static String m = "doSo";
public static String n = "/system/app";
public static String o = "intent.action.file.deleted";
public static String p = "/system/priv-app";
Hàm a():
Dựa vào kí tự đã giải mã thì đây là yêu cầu thực hiện hàm doSO() trong class com.android.sync.ADBoot
Còn thành phần onStart() của class D sẽ thực hiện decrypt file jif.png thành một file class.dex mới
Phân tích file class.dex từ jif.png
Ta có cấu trúc của file class.dex:
Sau khi xem xét 2 class này ta sẽ thấy trong class ADService sẽ thực hiện fetch đến 2 domain là grs[.]gowdsy[.]com và grs[.]rogsob[.]com.
Ở đây ta sẽ thấy các hành vi cuối cùng của mã độc như:
Thực hiện push nhiều thông báo trên thiết bị:
Tổng kết
Từ phân tích trên, chúng ta có thể thấy rằng phần mềm độc hại rootnik đã sử dụng các kỹ thuật Anti-debug và Anti-hooking để ngăn chặn kỹ thuật đảo ngược và các loại mã hóa khác nhau cho tệp và chuỗi. Ngoài ra, nó cũng sử dụng một lMultidex scheme để tải và cài đặt động tệp dex thứ cấp là logic chính của phần mềm độc hại này. Phần mềm độc hại sử dụng một số công cụ khai thác gốc Android nguồn mở. Sau khi giành được quyền root thành công trên thiết bị, phần mềm độc hại rootnik có thể thực hiện nhiều hành vi độc hại, bao gồm quảng cáo ứng dụng và quảng cáo, tạo shorcut trên màn hình chính, cài đặt ứng dụng âm thầm và đẩy thông báo, v.v.
C&C Server
gt[.]rogsob[.]com
grs[.]gowdsy[.]com
alog[.]umeng[.]com
![[CVE-2026-48731] AI-Assisted Discovery of Command Injection in Warp Terminal](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F699fec8cc9015c37f6e5364f%2Fe7817cef-a8af-45ec-b931-4e08225edeb6.png&w=3840&q=75)
