nishu2402/android-malware-detection-ml

# 🛡️ ANDROID 恶意软件检测 — DREBIN-215

## 👾 作者 ### Nisarg Chasmawala · 昵称: **HEAVEN** ## 📋 目录 - [👾 作者](#authors) - [🧠 项目概述](#project-summary) - [💡 核心思路](#core-idea) - [📦 数据集](#dataset) - [⚙️ 完整流程](#complete-pipeline) - [🔍 降维与特征选择策略](#feature-selection) - [🤖 模型详解](#models-explained) - [📐 评估指标](#metrics) - [🏆 完整性能](#complete-performance) - [🔹 场景 A — 基线（215 个特征）](#scenario-a) - [🔹 场景 B — 卡方检验（前 150 个）](#scenario-b) - [🔹 场景 C — 随机森林重要性](#scenario-c) - [🔹 场景 D — L1 正则化](#scenario-d) - [🥇 为什么 XGBoost 胜出](#why-wins) - [🗂️ 项目结构](#project-structure) - [🚀 安装说明](#installation) - [🔮 未来路线图](#future-roadmap) - [⚠️ 免责声明](#disclaimer) ## 🧠 项目概述

本项目实现了一个**高性能 Android 恶意软件检测系统**，通过对从 APK 清单中提取的 API 调用和权限进行静态分析，在应用**执行之前**将其分类为恶意软件或良性应用，无需任何动态沙箱。 使用了完整的 Drebin-215 数据集，包含 **15,036 条 APK 记录**（5,560 条恶意软件 + 9,476 条良性），以及 **215 个二进制特征**，代表 Android 权限和 API 调用模式。四种特征选择策略和四种 ML 分类算法在 **16 个实验**中进行了系统评估。 ## 💡 核心思路

每个 Android APK 在安装时都会声明其所需的**权限**并调用特定的**API**，在任何代码执行之前。传统杀毒软件依赖于已知的恶意软件签名： - ⏱️ **被动响应** — 只能在威胁被发现后捕获已知威胁 - 🔀 **可被绕过** — 轻易被混淆或重新打包击败 - ❌ **不可扩展** — 每年发布超过 100 万款新 Android 应用 **我们的解决方案：** 从 APK 清单中提取 215 个二进制静态特征，训练 ML 分类器仅通过行为模式检测恶意软件 — 使用 XGBoost 达到 **F1 = 98.47%**，使用随机森林达到 **ROC-AUC = 0.9988**，无需动态执行。 ``` APK Static Analysis ──▶ 215 Binary Features ──▶ Feature Selection (4 strategies) ──▶ ML Classifier ──▶ Malware / Benign Permissions Baseline-215 Chi-Square (150) XGBoost ★ 98.47% F1 API Call Flags 4 Scenarios RF Importance RF 98.37% F1 Manifest Attrs L1 Regularisation KNN 98.19% F1 Logistic Reg. 97.02% F1 ``` ## 📦 数据集

| 属性 | 详情 | |---|---| | **名称** | drebin-215-dataset-5560malware-9476-benign.csv | | **来源** | [Kaggle — Android 恶意软件数据集](https://www.kaggle.com/datasets/shashwatwork/android-malware-dataset-for-machine-learning) | | **总记录数** | 15,036 条 APK 记录 | | **特征** | 215 个二进制属性 | | **目标变量** | `class` — 良性 (B→0) / 恶意软件 (S→1) | | **缺失值** | 无 — 100% 完整 | | **文件大小** | 约 10 MB | ### 📊 类别分布 | 类别 | 标签 | 数量 | 百分比 | |---|---|---|---| | 良性 | B → 0 | 9,476 | 63.0% | | 恶意软件 | S → 1 | 5,560 | 37.0% | ### 📈 特征分类 | 类别 | 数量 | 示例 | |---|---|---| | **Android 权限** | 约 130 个 | `READ_SMS`、`SEND_SMS`、`CAMERA`、`READ_CONTACTS`、`INTERNET` | | **API 调用标志** | 约 85 个 | `getDeviceId()`、`sendTextMessage()`、`execShellCmd()`、`crypto APIs` | | **所有特征** | **215 个** | 二进制（0/1）— 在 APK 清单中的存在/缺失 | ## ⚙️ 完整流程

``` Drebin-215 CSV (15,036 records × 215 binary features) │ ▼ ┌─────────────────────────────┐ │ EDA & Preprocessing │ → class distribution · dtype validation · zero nulls │ Label Encoding │ → B→0, S→1 │ 80 / 20 Stratified Split │ → 12,028 train · 3,008 test · stratified class ratio │ Feature Scaling │ → StandardScaler (for KNN + LR) └─────────────┬───────────────┘ │ ▼ ┌─────────────────────────────┐ │ 4 Feature Selection │ → Baseline · Chi-Square · RF Importance · L1 Lasso │ Scenarios Evaluated │ → 215 · 150 · dynamic · dynamic features retained └─────────────┬───────────────┘ │ ▼ ┌─────────────────────────────┐ │ 4 ML Classifiers │ → KNN · Logistic Regression · Random Forest · XGBoost ★ │ × 4 Scenarios = 16 Runs │ └─────────────┬───────────────┘ │ ▼ Evaluation: Accuracy · Precision · Recall · F1 · ROC-AUC Confusion matrices + ROC curves per scenario All models persisted via joblib (.pkl) ``` ## 🔍 降维与特征选择策略

评估了四种互补的特征选择策略。使用多个独立的范式确保最终特征集是稳健的 — 不会让单一方法的偏差主导选择。 ### 场景 A — 基线（215 个特征）`[无降维]` - **保留特征：** 215 个（所有权限 + API 调用标志） - **XGBoost 结果：** F1 = **98.47%** · ROC-AUC = 0.9988 ⭐ 总体最佳 ### 场景 B — 卡方检验过滤 `[统计过滤]` - **选择：** 按 χ² 分数选取前 **150 个特征** - **降维：** 215 → 150 个特征（减少 30%） - **XGBoost 结果：** F1 = **98.19%** · ROC-AUC = 0.9987 ### 场景 C — 随机森林重要性 `[嵌入式 — 基于树]` - **选择：** 基于重要性分数的动态阈值 - **XGBoost 结果：** F1 = **97.97%** · ROC-AUC = 0.9980 ### 场景 D — L1 正则化（Lasso）`[嵌入式 — 稀疏性]` - **选择：** 仅保留 Lasso 系数非零的特征 - **XGBoost 结果：** F1 = **98.43%** · ROC-AUC = 0.9986 ### ✅ 结论：基线场景胜出 ``` BEST_SCENARIO = "Scenario A — Baseline (215 features)" BEST_MODEL = "XGBoost" BEST_F1 = 98.47 # % — all features, no reduction BEST_ROC_AUC = 0.9988 # 关键洞察：对于二进制APK特征，所有215个都携带信号。 # 激进减少会导致信息丢失而无收敛收益。 # Lasso (D)最接近：F1=98.43%，特征更少——最佳效率权衡。 ``` ## 🤖 模型详解

### 🔵 模型 1 — K 近邻  通过 215 维特征空间中 K 个最近邻的多数投票对每个 APK 进行分类。无训练阶段 — 所有计算发生在推理时。基于距离：由于共享的权限/API 模式，恶意软件 APK 会聚集在一起。 - **算法：** 缩放特征空间中的欧氏距离 · `k=5` **优势：** 无需对数据分布做任何假设 · 自然地捕获恶意软件集群 - **局限：** 在高维二进制数据上推理较慢；对无关特征敏感 - **最佳 F1：** 98.20%（场景 D — L1） ### 🟢 模型 2 — 逻辑回归  线性二分类器，计算 `P(malware) = σ(Σ βᵢxᵢ)`。每个系数 βᵢ 捕获单个权限或 API 调用的边际恶意软件信号。提供完全可解释性 — 哪些特征最能预测恶意软件。 - **算法：** L2 正则化最大似然 · `solver='lbfgs'` - **优势：** 系数完全可解释 · 训练快速 · 概率输出 - **局限：** 线性决策边界 — 无法捕获权限共现模式 - **最佳 F1：** 97.02%（场景 A）— 最低的 ML 结果；线性基函数不足以处理非线性 APK 行为 ### 🟡 模型 3 — 随机森林  100 棵决策树的集成，每棵树在自助采样和随机特征子集上训练。通过多数投票聚合预测。自然地处理二进制特征空间并捕获权限共现模式（例如，`READ_SMS` + `SEND_SMS` + `INTERNET` = 高风险组合）。 - **算法：** 装袋（Bagging），每次分裂使用 `max_features='sqrt'` · `n_estimators=100` - **优势：** 高准确率 · 内置特征重要性 · 对无关特征鲁棒 - **最佳 F1：** 98.37%（场景 A 和 D）· **最佳 ROC-AUC：0.9989**（场景 A）⭐ - **注：** 在场景 A 和 D 的 F1 上与 XGBoost 持平 — 极具竞争力 ### 🔴 模型 4 — XGBoost ⭐ 最佳  带 L1+L2 正则化的梯度提升树、列采样，以及对稀疏二进制特征的内置处理。每棵树纠正集成中之前的残差错误，使用 `scale_pos_weight` 平衡 63/37 的类别分布。在所有 4 个场景中占主导地位的模型。 - **更新规则：** `Fₘ(x) = Fₘ₋₁(x) + η · hₘ(x)`，其中 `hₘ` 最小化正则化二阶损失 - **超参数：** `n_estimators=100`、`learning_rate=0.1`、`max_depth=6`、`scale_pos_weight=1.7` - **优势：** 所有场景中最佳 F1 · 原生处理二进制稀疏特征 · 隐式正则化 - **最佳 F1：** **98.47%**（场景 A）· ROC-AUC = 0.9988 ## 📐 评估指标

所有模型在相同的 **3,008 条记录的分层保留测试集** 上使用五个互补指标进行评估： | 指标 | 公式 | 解释 | |---|---|---| | **准确率** | `(TP+TN)/(TP+TN+FP+FN)` | 总体正确分类率。**越高越好。** | | **精确率** | `TP/(TP+FP)` | 在标记为恶意软件的应用中，实际为恶意软件的百分比。高精确率 = 误报少。**越高越好。** | | **召回率** | `TP/(TP+FN)` | 在实际恶意软件应用中，正确捕获的百分比。高召回率 = 漏报少。**越高越好。** | | **F1 分数** | `2·(P·R)/(P+R)` | 精确率和召回率的调和平均。对于不平衡类别是主要指标。**越高越好。** | | **ROC-AUC** | ROC 曲线下面积 | 模型将随机恶意软件排序高于随机良性应用的概率。AUC=0.9988 → 近乎完美的分离。**越高越好。** | ## 🏆 完整性能

### 🔹 场景 A — 基线（215 个特征） | 模型 | 准确率 | 精确率 | 召回率 | F1 | ROC-AUC | |---|---|---|---|---|---| |  | 98.67 | 98.64 | 97.75 | 98.19 | 0.9971 | |  | 97.81 | 97.29 | 96.76 | 97.02 | 0.9960 | |  | 98.80 | 99.00 | 97.75 | 98.37 | **0.9989** | |  | **98.87** | **98.82** | **98.11** | **98.47** | 0.9988 | ### 🔹 场景 B — 卡方检验（前 150 个特征） | 模型 | 准确率 | 精确率 | 召回率 | F1 | ROC-AUC | |---|---|---|---|---|---| |  | 98.47 | 98.19 | 97.66 | 97.93 | 0.9953 | |  | 97.61 | 97.27 | 96.22 | 96.75 | 0.9958 | |  | 98.64 | 98.73 | 97.57 | 98.15 | 0.9987 | |  | **98.67** | **98.55** | **97.84** | **98.19** | **0.9987** | ### 🔹 场景 C — 随机森林重要性 | 模型 | 准确率 | 精确率 | 召回率 | F1 | ROC-AUC | |---|---|---|---|---|---| |  | 98.54 | 98.28 | 97.75 | 98.02 | 0.9920 | |  | 96.01 | 95.42 | 93.71 | 94.56 | 0.9894 | |  | 98.44 | 98.54 | 97.21 | 97.87 | 0.9975 | |  | **98.50** | **98.11** | **97.84** | **97.97** | **0.9980** | ### 🔹 场景 D — L1 正则化 | 模型 | 准确率 | 精确率 | 召回率 | F1 | ROC-AUC | |---|---|---|---|---|---| |  | 98.67 | 98.46 | 97.93 | 98.20 | 0.9959 | |  | 97.74 | 97.45 | 96.40 | 96.93 | 0.9963 | |  | 98.80 | 99.00 | 97.75 | 98.37 | 0.9985 | |  | **98.84** | **98.47** | **98.38** | **98.43** | **0.9986** | ## 🥇 为什么 XGBoost 胜出

``` Why not Logistic Regression? → F1 = 97.02% (Scenario A) — lowest result of all 4 models. → Linear decision boundary cannot capture permission co-occurrence: e.g. READ_SMS ∧ SEND_SMS ∧ execShellCmd() = near-certain malware, but each feature alone scores low individually. → LR treats all 215 features independently — misses interaction effects. Why not KNN? → F1 = 98.19% (Scenario A) — competitive but 3rd overall. → No training phase: entire 12,028-record train set stored in memory. → High-dimensional binary space degrades Euclidean distance quality. → Cannot generalise beyond nearest training examples. Why not Random Forest? → RF achieves F1 = 98.37% — tied with XGBoost on Scenarios A and D. → But RF ROC-AUC = 0.9989 (highest of all models!) — exceptional separation. → XGBoost edges RF on F1 by +0.10% (98.47 vs 98.37) in the primary scenario. → XGBoost's gradient correction + L1/L2 regularisation prevents the mild overfitting seen in RF's bootstrap aggregation on binary APK features. Why XGBoost wins: ✅ Best F1 score (98.47%) — highest across all 16 runs ✅ Best Accuracy (98.87%) — Scenario A ✅ Best Precision (98.82%) — Scenario A ✅ Best Recall (98.38%) — Scenario D ✅ Consistent dominance — #1 in all 4 scenarios without exception ✅ Handles sparse binary features natively (no scaling required) ✅ L1+L2 regularisation prevents overfitting on 215 correlated binary features ✅ scale_pos_weight balances malware minority class automatically ✅ Captures permission co-occurrence via gradient-corrected tree splits ``` ## 🗂️ 项目结构

``` ANDROID_MALWARE_CLASSIFICATION_PIPELINE/ │ ├── 📓 ANDROID_MALWARE_CLASSIFICATION_PIPELINE.ipynb ← Main notebook (fully documented) ├── 🐍 android_malware_classification_pipeline.py ← Complete standalone Python script ├── 📊 drebin-215-dataset-5560malware-9476-benign.csv ← Drebin-215 dataset (15,036 records) │ └── 💾 saved_models/ ← All trained models + scalers │ ├── 0_MASTER_MODEL/ │ └── Ultimate_Master_Pipeline.pkl ← Best end-to-end pipeline (XGBoost, Scenario A) │ ├── 1_Baseline_Maximum_Performance/ ← Scenario A — all 215 features │ ├── K-Nearest_Neighbors.pkl ← KNN · F1=98.19% │ ├── Logistic_Regression.pkl ← LR · F1=97.02% │ ├── Random_Forest.pkl ← RF · F1=98.37% · ROC=0.9989 │ ├── XGBoost.pkl ← XGB ★ · F1=98.47% · ROC=0.9988 │ ├── scaler.pkl ← StandardScaler (KNN + LR) │ └── selected_features.pkl ← All 215 features list │ ├── 2_Chi_Square_Top150/ ← Scenario B — top 150 by χ² │ ├── [4 model .pkl files] │ ├── scaler.pkl │ └── selected_features.pkl ← 150-feature subset │ ├── 3_RF_Importance/ ← Scenario C — RF-selected features │ ├── [4 model .pkl files] │ ├── scaler.pkl │ └── selected_features.pkl │ └── 4_L1_Regularization/ ← Scenario D — Lasso-selected features ├── [4 model .pkl files] ├── scaler.pkl └── selected_features.pkl ``` ## 🚀 安装说明

### 前置条件 ``` Python 3.9+ pip ``` ### 1. 克隆仓库 ``` git clone https://github.com/nishu2402/android-malware-detection-ml.git cd android-malware-detection-ml ``` ### 2. 安装依赖 ``` pip install pandas numpy matplotlib seaborn scikit-learn xgboost joblib ``` 或一次性安装所有依赖： ``` pip install -r requirements.txt ```

📋 完整的 requirements.txt

``` pandas>=1.5.0 numpy>=1.23.0 matplotlib>=3.6.0 seaborn>=0.12.0 scikit-learn>=1.3.0 xgboost>=1.7.0 joblib>=1.2.0 jupyter>=1.0.0 ```

### 3. 添加数据集 ### 4. 运行笔记本 ``` jupyter notebook ANDROID_MALWARE_CLASSIFICATION_PIPELINE.ipynb ``` ### 5. 加载主模型进行推理 ``` import joblib import numpy as np # ── 加载主管道 (XGBoost, Scenario A) ─────────────────── pipeline = joblib.load("saved_models/0_MASTER_MODEL/Ultimate_Master_Pipeline.pkl") # ── 单个APK推理 ───────────────────────────────────────── # 从APK清单构建215元素二进制特征向量 # 1 = 权限/API存在，0 = 不存在 X_apk = np.zeros((1, 215)) # 示例：具有可疑权限+API调用的高风险APG X_apk[0, [12, 45, 67, 89, 102]] = 1 # READ_SMS, SEND_SMS, execShell, getDeviceId, crypto prediction = pipeline.predict(X_apk) probability = pipeline.predict_proba(X_apk) label = "🚨 MALWARE" if prediction[0] == 1 else "✅ BENIGN" print(f"Classification: {label}") print(f"Malware probability: {probability[0][1]:.4f}") # → 分类：🚨 恶意软件 # → 恶意软件概率：0.9873 # ── 加载单个场景模型 ─────────────────────────────── xgb_baseline = joblib.load("saved_models/1_Baseline_Maximum_Performance/XGBoost.pkl") scaler = joblib.load("saved_models/1_Baseline_Maximum_Performance/scaler.pkl") features = joblib.load("saved_models/1_Baseline_Maximum_Performance/selected_features.pkl") X_scaled = scaler.transform(X_apk) pred = xgb_baseline.predict(X_scaled) ``` ## 🔮 未来路线图

| 优先级 | 改进方向 | 预期影响 | |---|---|---| | 🔴 高 | **混合静态 + 动态分析** — 结合权限标志与运行时系统调用追踪 | 捕获模仿良性静态特征的规避性恶意软件 | | 🔴 高 | **SHAP 可解释性** — 每个预测的特征归因，用于分析师审查 | 实现透明、可辩护的恶意软件分类决策 | | 🟠 中 | **深度学习 — RNN/LSTM** — 建模执行期间的序列 API 调用行为 | 超越静态标志的更丰富时序攻击模式识别 | | 🟠 中 | **对抗性加固** — 针对权限填充规避攻击进行训练 | 缩小特征操纵攻击面 | | 🟠 中 | **Drebin 扩展数据集** — 在更广泛的 APK 语料库上重新训练（2023–2026） | 覆盖 Drebin-215 范围之外的现代 Android 恶意软件家族 | | 🟡 低 | **边缘部署** — 将 XGBoost 量化到 TFLite 用于设备端检测 | 实时恶意软件筛查，无需依赖云端 | | 🟡 低 | **MLOps + 漂移监控** — 持续在新 APK 威胁源上重新训练流水线 | 生产级模型新鲜度，随着恶意软件演进 | | 🟡 低 | **多类别分类** — 从良性/恶意软件扩展到恶意软件家族分类 | 实现针对每个威胁家族的定向事件响应 | ## ⚠️ 免责声明

- 这些模型所做的恶意软件预测**不应**作为专业移动安全评估的替代品。 - 所有 APK 特征数据来源于 Kaggle 上公开可用的 [Drebin-215 数据集](https://www.kaggle.com/datasets/shashwatwork/android-malware-dataset-for-machine-learning)。 - 提供的训练模型文件（`.pkl`）仅用于复现目的。在做出安全决策之前，请始终针对多个分析工具验证模型预测。

⭐ 如果这个项目对您有帮助，请在 GitHub 上给它一个星标！

标签：AMSI绕过, Android APK分析, Android安全, Apex, API调用分析, BSD, Chi-Square特征选择, Drebin数据集, F1分数, Python, ROC-AUC, XGBoost, 二值特征, 二分类, 云安全监控, 威胁检测, 数据挖掘, 无后门, 机器学习, 权限分析, 模型评估, 正则化, 特征选择, 目录枚举, 移动安全, 网络安全, 逆向工具, 随机森林特征重要性, 隐私保护, 静态分析