Contents

Android Pentesting

Android Pentesting

Command

adb

// List device
adb devices -l

// Truy cap shell
adb -s <device-name> 

// <Trong shell>
---------------------------
// Lay thong tin phien ban android và API level
getprop ro.build.version.release
getprop ro.build.version.sdk

// Lay thong tin kien truc CPU
getprop ro.product.cpu.abi
----------------------------

// Push file tu Host vao android
adb push </path/to/file/pc> </path/to/file/android> (/data/local/tmp)

// Pull
adb pull	</path/to/file/android>	</path/to/file/pc>

// Cai dat ung dung
adb -s <id-may> install <path/file.apk>

//Log
adb logcat

// Start server adb
adb start-server

// Restart adb voi quyen root
adb 

// list package
adb shell "pm list packages | grep -i <tenapp>"

Decomplie APK

Command-line

apktool

apktool d <file.apk> // src code smali

jadx

jadx -r -d -e <file.apk> 

GUI

apktook-gui, jadx-gui, bytecode-viewer

Procedure

  1. Code -> Compile -> DEX Format
  2. DEX -> Build -> APK
  3. APK -> Signature -> Signed APK
  4. Signed APK -> Google Play -> User Install

Static Analysis

# # Description
1. Decompiling Kiểm tra file APK và Native Libraries - Đổi tên file .apk thành .zip và giải nén (Apktool, Jadx).
- Kiểm tra thư mục lib/ để tìm các native library (file .so).
Decompile - Sử dụng JADX GUI hoặc Apktool (apktool d app.apk -o decompiled) để lấy mã nguồn và file cấu hình.
2. Static Analysis - AndroidManifest.xml App Permissions - Tìm các quyền nguy hiểm (ví dụ: READ_CONTACTS, ACCESS_FINE_LOCATION, CAMERA).
- Đặt câu hỏi: Ứng dụng có thực sự cần các quyền này không?
AllowBackup - Tìm flag <application android:allowBackup="true">.
- Nếu true (hoặc không khai báo, vì mặc định là true), kẻ tấn công có thể dùng adb backup để lấy file nhạy cảm.
- Lệnh test: adb backup -f backup.ab com.example.app
Debuggable Flag - Tìm flag <application android:debuggable="true">.
- Nếu true, kẻ tấn công có thể attach debugger, đọc bộ nhớ và sửa biến runtime. (Mặc định là false nhưng dev có thể quên tắt khi release).
Network Security - Kiểm tra cleartextTrafficPermitted="true" trong thẻ <network-security-config>.
- Nếu có, ứng dụng cho phép HTTP (không mã hóa), dễ bị MITM.
SDK Versions - Kiểm tra minSdkVersiontargetSdkVersion.
- SDK cũ thường thiếu các tính năng bảo mật hiện đại.
Exported Components - Tìm android:exported="true" ở 4 loại components:
+ Activities: Bypass màn hình đăng nhập.
+ Services: Chạy ngầm tác vụ trái phép.
+ Content Providers: Đọc trộm dữ liệu (database, token).
+ Broadcast Receivers: Kích hoạt chức năng ẩn thông qua tin nhắn hệ thống.
3. Static Analysis - Tìm kiếm nâng cao Hardcoded Secret - Tìm passwords, URLs, API keys, tokens, UUIDs bị hardcode.
- Tools: apkurlgrep, lệnh strings, Regex tích hợp trong JADX GUI.
Lỗi cấu hình Firebase - Tìm URL dạng https://xyz.firebaseio.com/ (thường ở res/values/strings.xml).
- Thêm .json vào cuối URL trên trình duyệt.
- Nếu trả về null hoặc JSON data (không phải Permission Denied) -> Đọc được data.
- Test ghi/xóa dữ liệu: Dùng lệnh curl -X PUTcurl -X DELETE để xem có chiếm quyền được database hay không.
Source Code Analysis - Quét các lỗ hổng logic: SSL Pinning, Root detection, Debugger checks, Webview (loadUrl(), evaluateJavascript() -> XSS), Intent/Deeplink handlers.
- Công cụ tự động: Semgrep (rule android-security), MobSF.
4. Kiểm tra Lưu trữ & Tính toàn vẹn Insecure Storage - Kiểm tra thư mục /data/data/com.example.app/.
- Tìm kiếm các file shared_prefs, logs, sqlite db xem có lưu trữ plaintext các thông tin như token, mật khẩu, thông tin thanh toán hay không.
Kiểm tra Chữ ký APK (Janus Vulnerability) - Kiểm tra lỗi CVE-2017-13156 cho phép sửa file APK mà không làm hỏng chữ ký.
- Lệnh: apksigner verify --verbose app.apk
Anti-Tampering Check - Sửa một giá trị bất kỳ (ví dụ đổi true thành false trong manifest).
- Recompile bằng apktool, tự sign bằng key và chạy thử. Nếu app vẫn chạy bình thường -> Lỗi thiếu cơ chế kiểm tra tính toàn vẹn.
5. Dynamic Analysis Kiểm tra & Bypass Root Detection - Dấu hiệu app check root: Tìm RootBeer, check binary su, check app Magisk, SafetyNet, Play Integrity.
- Cách Bypass: Dùng Magisk Hide / Zygisk DenyList, Frida Scripts, Objection, Xposed/LSPosed Modules (Hide My Applist) hoặc Patch APK thủ công.
Kiểm tra & Bypass SSL Pinning - Dấu hiệu app cài SSL Pinning: Dùng Network Security Config, Custom TrustManager, thư viện OkHttp, TrustKit.
- Cách Bypass: Dùng Objection, Frida Scripts, HTTP Toolkit hoặc decompile để xóa code check SSL rồi recompile.
API Testing - Dùng Burp Suite (sau khi bypass SSL) để test các lỗi logic web như IDOR, BOLA, SQLi trên API, bypass thanh toán.
Memory Dumping - Dump bộ nhớ RAM khi app đang chạy để tìm mật khẩu, token, key giải mã chưa kịp xóa. - Công cụ: Fridump, tính năng memory của Objection.
Runtime Hooking - Dùng Frida hook trực tiếp vào các hàm nghi ngờ (tạo OTP, check mã PIN) để thay đổi tham số đầu vào hoặc giá trị trả về (return value) ngay lập tức.
Lỗ hổng Mô tả Checklist
1. SSL Pinning Lỗ hổng SSL Pinning xảy ra khi ứng dụng không xác minh đúng chứng chỉ SSL hoặc public key của máy chủ trong quá trình handshake SSL/TLS. Điều này cho phép kẻ tấn công thực hiện man-in-the-middle để chặn và giải mã giao tiếp của ứng dụng. - Kiểm tra xem SSL Pinning có được triển khai không.
- Objection: Sử dụng lệnh android sslpinning disable.
- Frida: Sử dụng frida-multiple-unpinning -> frida -U --codeshare akabe1/frida-multiple-unpinning -f YOUR_BINARY
- Xposed: Cài đặt module TrustMeAlready hoặc SSLUnpinning.
- Bypass SSL Pinning sử dụng APKLab.
- Kiểm tra xem có thể thao túng mã (code manipulation) không.
2. Root Detection Lỗ hổng Root Detection xảy ra khi ứng dụng không phát hiện và ngăn chặn đúng cách quyền truy cập từ các thiết bị đã root, cho phép người dùng có khả năng giành quyền truy cập trái phép vào dữ liệu hoặc chức năng của app. - Kiểm tra xem Root Detection có được triển khai không.
- Module MagiskHide trong ứng dụng Magisk (= <v23.0).
- Zygisk DenyList trong ứng dụng Magisk (>v23.0).
- Tampering (Chỉnh sửa) mã Smali.
- Frida -> Dùng script fridantiroot.
- Medusa Framework -> Sử dụng module helpers/anti_debug.
- Objection: Dùng dex2jar lấy class file -> Phân tích tìm library check root -> Chạy objection -g com.test.app explore -> Tìm method bằng android hooking list class_methods <class> -> Set lại kết quả android hooking set return_value <method> false. Nếu app vẫn báo root, bấm Back ra ngoài (không kill app) rồi vào lại.
- Đổi tên binaries: Đôi khi chỉ cần đổi tên binary su là đủ để bypass (nhưng cẩn thận hỏng môi trường).
- Unmount /proc để ngăn app đọc danh sách tiến trình.
- Dùng Frida/Xposed hook các API (Java/native) để ẩn file, tiến trình và trả về các giá trị giả (bogus values).
- Hook low-level API bằng kernel modules.
- Patch ứng dụng để xóa bỏ các hàm kiểm tra.
3. Emulator Detection Lỗ hổng Emulator Detection xảy ra khi ứng dụng không phát hiện và ngăn chặn truy cập từ trình giả lập (emulator), cho phép người dùng bypass các kiểm soát bảo mật hoặc truy cập tính năng trái phép. - Kiểm tra xem Emulator Detection có được triển khai không.
- Chỉnh sửa các thuộc tính trong file build.prop.
- Patch chức năng nhận diện: Ghi đè mã bytecode hoặc native code liên quan bằng các lệnh NOP.
- Dùng Frida/Xposed hook các API hệ thống file (Java/native) để trả về các thông số giống máy thật thay vì thông số giả lập. Ví dụ: override hàm TelephonyManager.getDeviceID để trả về một mã IMEI hợp lệ.
4. Sensitive Data in ADB Logcat Logs Lỗ hổng rò rỉ dữ liệu qua ADB Logcat xảy ra khi ứng dụng ghi log các dữ liệu nhạy cảm (mật khẩu, thông tin cá nhân) vào system log, khiến chúng có thể bị lộ cho kẻ tấn công. - Quét Logcat logs tìm dữ liệu nhạy cảm bằng lệnh:
adb logcat | grep "$(adb shell ps | grep <package-name> | awk '{print $2}')"
- Kiểm tra xem logs có thể bị chỉnh bằng Frida/Objection không.
- Tìm các request hoặc dữ liệu dạng unencrypted (không mã hóa) xuất hiện trong log.
5. Sensitive Data Stored in Local Storage Lỗ hổng lưu trữ dữ liệu nội bộ xảy ra khi app lưu thông tin nhạy cảm ở dạng không mã hóa (unencrypted) hoặc không an toàn trong Local Storage của thiết bị. - Kiểm tra cả internalexternal storage tìm các file có dữ liệu nhạy cảm.
- Tìm các file development, backup hoặc file cũ bị sót lại trong bản production.
- Kiểm tra các file SQLite databases (tại /data/data/<package-name>/databases). Nếu có mã hóa, hãy xem password sinh ra thế nào và có được bảo vệ bằng Keystore hay không.
- Kiểm tra Shared Preferences (file XML tại /data/data/<package-name>/shared_prefs). Nếu không dùng thư viện như secure-preferences, dữ liệu mặc định sẽ là plaintext.
- Kiểm tra quyền (permissions) của thư mục data. Chỉ user/group của app (vd: u0_a82) mới được có quyền rwx.
- Ghost Files trong Shared Preferences: Nếu bạn có quyền WRITE vào thư mục shared_prefs (dù không có quyền overwrite file hiện tại), bạn có thể tạo một file .bak chứa setting giả mạo. Ở lần chạy tới, Android sẽ tự đổi tên file .bak đó đè lên file gốc một cách âm thầm.
- Kiểm tra Firebase Real-time databases: Test xem có bị misconfigured bằng cách truy cập https://_firebaseProjectName_.firebaseio.com/.json.
- Kiểm tra Realm database (đuôi .realm, mặc định tên default tại thư mục /files/). Dùng Realm Browser để xem có bị lộ data unencrypted không.
6. Sensitive Data in Application Memory Xảy ra khi ứng dụng lưu trữ thông tin nhạy cảm trong bộ nhớ RAM (Application Memory) ở dạng không an toàn, khiến dữ liệu có thể bị trích xuất nếu kẻ tấn công có quyền truy cập bộ nhớ. - Sử dụng công cụ fridump.py để dump bộ nhớ ứng dụng và phân tích tìm các dữ liệu nhạy cảm (password, token…).
7. Weak Signer Certificate Lỗ hổng xảy ra khi ứng dụng được ký (signed) bằng một chứng chỉ (certificate) yếu hoặc đã bị lộ, cho phép kẻ tấn công chỉnh sửa ứng dụng hoặc mạo danh. - Kiểm tra xem app có dùng thuật toán ký yếu như SHA1withRSA không.
- Kiểm tra lỗ hổng Janus (cho phép sửa APK mà không hỏng chữ ký).
- Kiểm tra xem ứng dụng có đang dùng debug certificate (chứng chỉ test) thay vì chứng chỉ release không.
8. Vulnerable Android Activities Android activities là các thành phần đại diện cho màn hình giao diện. Một Activity có lỗ hổng (do code kém an toàn hoặc dùng thư viện lỗi) có thể bị khai thác để chiếm quyền hoặc bypass logic ứng dụng. - [Authentication Bypass]: Kiểm tra xem có thể gọi trực tiếp các protected activities thông qua ADB mà không cần đăng nhập không.
- [Exported Sensitive Activity]: Đảm bảo các activities được đặt cờ exported đã được phân quyền và kiểm soát chặt chẽ.
- [Task Hijacking]: Kiểm tra khả năng bị chiếm quyền điều khiển luồng activity (hijacking).
- [DOS]: Gửi các payload lỗi để xem activity có gây ra hiện tượng crash app hoặc từ chối dịch vụ (Denial of Service) hay không.
9. WebView Vulnerabilities Android WebView là thành phần cho phép ứng dụng hiển thị nội dung web ngay trong giao diện người dùng. Nó có thể chứa các lỗ hổng do lập trình không an toàn, thiếu kiểm tra dữ liệu đầu vào (improper validation). - Kiểm tra các lỗ hổng Cross-Site Scripting (XSS).
- Kiểm tra các lỗ hổng Local File Inclusion (LFI).
- Kiểm tra xem JavaScript có được bật một cách không an toàn không.
- Kiểm tra Insecure URL Loading qua hàm loadUrl(), cho phép kẻ tấn công inject các URL độc hại.
- Kiểm tra việc sử dụng Javascript Interface: setJavaScriptEnabled(true) cho phép thực thi JavaScript, dẫn đến nguy cơ XSS.
10. Intent Filters Intent redirection là việc sử dụng implicit hoặc explicit Intent để chuyển tiếp từ component này sang component khác. Lỗ hổng xảy ra khi developer không lọc/kiểm tra dữ liệu intent truyền vào (tương tự như Open Redirect trên Web). - Kiểm tra các lỗ hổng Intent Spoofing (giả mạo Intent) và Intent Sniffing (đánh hơi/nghe lén Intent).
11. Broadcast Receivers Broadcast Receiver là thành phần cho phép ứng dụng nhận và phản hồi các sự kiện broadcast của toàn hệ thống (ví dụ: nhận tin nhắn SMS, cắm sạc pin). Cấu hình sai có thể dẫn đến việc bị lợi dụng kích hoạt chức năng ẩn. - Kiểm tra xem các receiver có cờ exported có bị thiếu các quyền (permissions) bảo vệ thích hợp không.
12. Content Provider Security Content Providers dùng để chia sẻ dữ liệu giữa các ứng dụng bằng các hàm insert, update, delete, query qua một URI đặc biệt bắt đầu bằng content://. Nếu không cấu hình bảo mật chuẩn, dữ liệu nội bộ có thể bị rò rỉ. - Kiểm tra lỗ hổng SQL Injection.
- Kiểm tra lỗ hổng Path Traversal.
- Kiểm tra các lỗ hổng truy cập dữ liệu nội bộ.
- Nếu cho phép Insert, hãy test khả năng làm ngập lụt (Flooding) Provider bằng lượng lớn dữ liệu (Infinite Data).
13. Source Code Obfuscation Source code obfuscation (làm rối mã nguồn) là quá trình làm cho mã nguồn khó hiểu và khó bị dịch ngược (reverse engineer), nhằm bảo vệ sở hữu trí tuệ và ngăn chặn chỉnh sửa trái phép. - Kiểm tra xem ProGuard hoặc các công cụ obfuscation khác có được cấu hình không.
- Kiểm tra xem các đoạn mã nhạy cảm có thực sự được làm rối đúng cách chưa.
14. Hardcoded Sensitive Information Lỗ hổng lưu cứng dữ liệu xảy ra khi các thông tin nhạy cảm (như mật khẩu, khóa bảo mật) được viết trực tiếp vào source code của ứng dụng, khiến kẻ tấn công dễ dàng trích xuất sau khi decompile. - Quét source code để tìm các API keys, tokens, passwords hoặc thông tin xác thực (credentials) bị hardcode.
15. Insecure Coding Practices Insecure coding practices là việc sử dụng các kỹ thuật lập trình không bảo vệ đủ tốt cho ứng dụng (ví dụ: dùng mật khẩu yếu, không validate input), khiến hệ thống dễ bị tấn công. - Kiểm tra việc sử dụng các hàm sinh số ngẫu nhiên không an toàn (Insecure random number generators).
- Kiểm tra việc sử dụng các hàm (functions) đã bị cấm/không an toàn.
- Kiểm tra các chuẩn mã hóa yếu (weak cryptography) (Ví dụ: MD5, mã hóa Base64).
- Kiểm tra các điểm yếu về kỹ thuật lập trình khác.
16. Insecure Deeplinks Insecure deeplinks là các link dẫn sâu vào app không được bảo vệ. Nếu không validate và kiểm soát truy cập, kẻ tấn công có thể lợi dụng deeplinks để ép app thực hiện các hành vi nhạy cảm. - Kiểm tra các explicit deeplinks có sử dụng PendingIntent.
- Kiểm tra các implicit deeplinks dẫn đến các khu vực nhạy cảm trong app.
- Kiểm tra lỗ hổng Open Redirect.
- Kiểm tra lỗ hổng lộ lọt file nội bộ (Local File Disclosure).
- Kiểm tra khả năng khai thác các hành động nhạy cảm do ứng dụng thiếu cơ chế xác thực (Authentication bypass).
17. Insecure Services Service là thành phần nhận dữ liệu, xử lý và trả về phản hồi. Nếu ứng dụng export (mở) một số services, cần kiểm tra mã nguồn để hiểu logic và test động (dynamically test) để trích xuất thông tin bảo mật, bypass xác thực. - Kiểm tra sự tồn tại của các services mà không có quyền bảo vệ hợp lý.
- Sử dụng Drozer hoặc Activity Manager (am) để liệt kê và khai thác.
- Lệnh Drozer: run app.service.info -a <package> (Liệt kê) và run app.service.send <package> <service_name> --msg... (Gửi payload).
- Lệnh adb (am): adb shell am startservice -n <package>/.<service_name> --es "key" "malicious_data".
18. Missing Integrity Checks Integrity checks (Kiểm tra tính toàn vẹn) là quá trình xác minh tính xác thực của mã nguồn ứng dụng, đảm bảo nó chưa bị can thiệp (tampered) hay repackage bởi kẻ tấn công. - Thực hiện Decompile (giải mã), chỉnh sửa một vài thông số/logic, recompile (đóng gói lại), tự sign bằng key giả và kiểm tra xem ứng dụng có còn hoạt động bình thường không (Nếu chạy được -> Lỗ hổng).
19. Insecure Android Permissions Ứng dụng Android có nhiều quyền (permissions) và các cờ cấu hình được set trong file AndroidManifest.xml. Nếu không cấu hình chặt chẽ, chúng sẽ mở ra bề mặt tấn công rất lớn. - Kiểm tra xem cleartext traffic có được bật không (cleartextTrafficPermitted="true").
- Kiểm tra xem chế độ debug có đang mở không (android:debuggable="true").
- Kiểm tra xem luật trích xuất dữ liệu (dataExtractionRules) có được định nghĩa an toàn không.
- Kiểm tra tính năng backup mode có bị lợi dụng được không (android:allowBackup="true").
- Rà soát và đánh giá các quyền (permissions) không cần thiết mà app yêu cầu.
20. Background Screen Caching Screen caching là tính năng tối ưu trải nghiệm của hệ điều hành di động (tự động chụp lại ảnh màn hình app khi thu nhỏ). Điều này vô tình gây rò rỉ dữ liệu nhạy cảm hiển thị trên màn hình. - Đẩy ứng dụng xuống chạy ngầm (background), sau đó kiểm tra xem ảnh chụp màn hình (screenshot) lưu trong hệ thống có chứa thông tin nhạy cảm không. Để an toàn, app phải bật cờ FLAG_SECURE.
21. Insecure Firebase Database Firebase Database là cơ sở dữ liệu thời gian thực trên cloud. Việc developer cấu hình sai luồng phân quyền (security rules) là cực kỳ phổ biến. - Thêm .json vào cuối URL của Firebase instance (VD: https://<project>.firebaseio.com/.json) để kiểm tra quyền đọc (read permissions).
- Thay thế firebaseio.com bằng appspot.com/.json để kiểm tra các cấu hình sai liên quan đến CORS.
22. Android Lock/Biometric Authentication Bypass Một số ứng dụng sử dụng màn hình khóa (Screen Lock) hoặc sinh trắc học (Biometric/Fingerprint) của thiết bị để xác thực người dùng trước khi cho phép dùng chức năng nhạy cảm. - Kiểm tra xem cơ chế xác thực này có thể bị bypass bằng cách dùng Frida/Objection (hook vào API sinh trắc học của Android trả về true) hoặc can thiệp trực tiếp vào mã nguồn (code modification) hay không.
23. Key Checks in Dynamic Analysis Các bước kiểm tra trọng tâm trong quá trình Dynamic Analysis (Phân tích động) khi tương tác với API và máy chủ backend của ứng dụng. - Thực hiện kiểm thử bảo mật toàn diện trên API (API security tests).
- Kiểm tra các lỗi kiểm soát truy cập (Broken Access Controls như IDOR, BOLA).
- Test các lỗ hổng Server-side injections (SQLi, Command Injection…).
- Xác định các luồng rò rỉ dữ liệu nhạy cảm từ phía server.
- Thực hiện Fuzz testing để tìm lỗi crash hoặc logic sai từ các input.
24. Other Security Checks Các cấu hình bảo mật nhỏ gọn nhưng quan trọng để tăng cường hardening cho phía Client (UI/UX an toàn). - Kiểm tra xem các khóa mã hóa (cryptographic keys) có bị dùng lại không.
- Kiểm tra bộ nhớ đệm bàn phím (keyboard cache/dictionary) đã bị tắt cho các trường nhạy cảm chưa.
- Kiểm tra xem chức năng Copy/Paste đã bị chặn ở các ô nhập mật khẩu/OTP chưa.
- Kiểm tra xem dữ liệu nhạy cảm có được che giấu (masked) trên UI khi chuyển app không.
- Kiểm tra xem app có chặn bàn phím của bên thứ ba (third-party keyboards) khi nhập liệu quan trọng không.