第26章安全与加固

课程目录第26章安全与加固

第26章安全与加固：给APP穿上“防弹衣”

说实话，安全这块内容，很多初学者会觉得“离我挺远的”。我刚入行那会儿也这么想——一个简单的记账APP，谁会来攻击我？直到有一次，我负责的一个企业应用因为没做基本的代码混淆，被竞争对手直接反编译抄走了核心逻辑……嗯，从那以后，我再也不敢小看安全加固了。

这一章，我会把Android安全里最实用的几个点串起来讲。你不需要成为安全专家，但掌握这些，至少能让你的APP不那么“裸奔”。

本章核心脉络：从代码保护（混淆）→ 身份验证（签名）→ 通信安全（网络安全配置）→ 数据保护（加密）→ 环境检测（Root检测），层层递进，构建APP的基础防御体系。

1. 代码混淆：让反编译的人“怀疑人生”

代码混淆，说白了就是把你的类名、方法名、变量名改成a、b、c这种无意义的短名字。同时还会删除无用的代码、优化指令。目的不是让代码“不能看”，而是让看了的人“看不懂”。

我个人的习惯是，从项目一开始就开启混淆。别等到上线前再开，那时候一堆报错能让你改到崩溃。

💡 我的经验：混淆不是万能的。字符串常量依然会暴露。比如API的URL、加密的Key，如果硬编码在代码里，混淆后依然明文可见。所以敏感信息一定要放到native层或者使用密钥服务。

在Android Studio中，我们使用ProGuard或R8（新版本默认R8）。配置在 build.gradle 里：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

这里要注意，proguard-android-optimize.txt 是Android SDK自带的通用规则。而 proguard-rules.pro 是你自己写的。我曾经因为忘记添加 -keep 规则，导致Gson解析的Bean类被混淆，运行时直接崩溃。嗯，那是一个加班的夜晚。

常用的 proguard-rules.pro 规则示例：

# 保留实体类（Gson、FastJson等）
-keep class com.example.app.model.** { *; }

# 保留JNI方法
-keepclasseswithmembernames class * {
    native <methods>;
}

# 保留枚举
-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

⚠️ 避坑指南：千万不要混淆第三方库！除非你非常清楚它的内部逻辑。我一般会把所有第三方库的包名都 -keep 掉。否则，你可能会遇到“ClassNotFoundException”这种让人抓狂的问题。

2. 签名与打包：APP的“身份证”

每个Android APP都必须有一个数字签名。它就像你的身份证，用来证明这个APP是你发布的。系统通过签名来确认APP的归属，防止被篡改。

签名有两种方式：

签名方式	说明	适用场景
V1 (JAR签名)	传统方式，只对未压缩的文件签名	兼容Android 7.0以下
V2 (APK签名方案)	对APK整个文件进行签名，更安全	Android 7.0及以上
V3 (APK签名方案)	支持密钥轮换，可以更换签名密钥	Android 9.0及以上

我个人建议，在 build.gradle 中同时开启V1和V2：

android {
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "password"
            keyAlias "my-alias"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            // 同时开启V1和V2签名
            v1SigningEnabled true
            v2SigningEnabled true
        }
    }
}

💡 小技巧：签名文件（.jks）一定要妥善保管！我见过有人把签名文件传到GitHub上，结果被人下载后签名了恶意版本。建议把签名文件放在项目外的安全目录，并在 .gitignore 中忽略它。

3. 网络安全配置：明文流量？不存在的

从Android 9（API 28）开始，系统默认禁止明文HTTP流量。如果你的APP还在用HTTP，那就会直接报错。这时候就需要 Network Security Config 来“开绿灯”。

但我的建议是：能上HTTPS就上HTTPS。明文传输就像在明信片上写密码，谁都能看。

配置方法很简单，在 res/xml 下创建一个 network_security_config.xml：

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">10.0.2.2</domain> <!-- 模拟器本地调试 -->
        <domain includeSubdomains="true">192.168.1.100</domain> <!-- 内网测试 -->
    </domain-config>
</network-security-config>

然后在 AndroidManifest.xml 中引用：

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ... >

⚠️ 注意：发布版本一定要把 cleartextTrafficPermitted 设为 false。我曾经在调试时为了方便，允许了所有明文流量，结果上线前忘了改回来……嗯，被安全团队打回来了。

4. 数据加密：AES与RSA的“双剑合璧”

数据加密这块，我常用的套路是：对称加密（AES）加密数据，非对称加密（RSA）加密AES的密钥。这样既保证了速度，又保证了安全性。

你想想看，如果直接用RSA加密大文件，那速度慢得让人崩溃。而AES加密速度快，但密钥怎么安全传输？用RSA加密AES密钥，完美解决。

下面是一个简单的AES加密工具类片段：

public class AESUtil {
    private static final String ALGORITHM = "AES/GCM/NoPadding";
    private static final int GCM_IV_LENGTH = 12;
    private static final int GCM_TAG_LENGTH = 128;

    public static byte[] encrypt(byte[] plaintext, SecretKey key) throws Exception {
        byte[] iv = new byte[GCM_IV_LENGTH];
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.ENCRYPT_MODE, key, spec);
        byte[] ciphertext = cipher.doFinal(plaintext);
        // 将IV和密文拼接返回
        ByteBuffer buffer = ByteBuffer.allocate(iv.length + ciphertext.length);
        buffer.put(iv);
        buffer.put(ciphertext);
        return buffer.array();
    }
}

RSA的使用场景更多是“签名”和“加密小数据”。比如，客户端用服务器的公钥加密一个AES密钥，服务器用私钥解密。这样即使数据被截获，没有私钥也解不开。

💡 我的习惯：密钥不要硬编码在Java代码里。我会把它放在 BuildConfig 中，或者通过JNI从native层读取。甚至可以用 Android KeyStore 来存储密钥，这样系统会帮你做硬件级别的保护。

5. Root检测与防篡改：别让APP跑在“裸奔”的手机上

Root过的手机，就像一扇没锁的门。任何进程都可以读取你的数据、Hook你的方法。所以，对于金融、支付类APP，Root检测是必须的。

检测Root的方法有很多，我常用的几个：

检测可执行文件：检查 /system/bin/su、/system/xbin/su 等是否存在。
检测Build标签：检查 Build.TAGS 是否包含 test-keys。
检测危险应用：检查是否安装了SuperSU、Magisk Manager等。

代码示例：

public static boolean isDeviceRooted() {
    String[] paths = {
        "/system/bin/su",
        "/system/xbin/su",
        "/sbin/su",
        "/system/sd/xbin/su",
        "/system/bin/failsafe/su",
        "/data/local/su"
    };
    for (String path : paths) {
        if (new File(path).exists()) {
            return true;
        }
    }
    return false;
}

⚠️ 避坑指南：Root检测不是万无一失的。Magisk可以隐藏Root，让检测失效。所以，我一般会结合“完整性校验”一起做。比如，在启动时计算APK的签名哈希值，如果和服务器下发的值不一致，说明APP被篡改了。

防篡改的另一个常见做法是“签名校验”。在代码中获取当前APK的签名，与预埋的签名做对比。如果不一样，直接退出。

public static boolean checkSignature(Context context, String expectedSignature) {
    try {
        PackageInfo info = context.getPackageManager().getPackageInfo(
            context.getPackageName(), PackageManager.GET_SIGNATURES);
        Signature[] signatures = info.signatures;
        // 计算签名哈希
        MessageDigest md = MessageDigest.getInstance("SHA-256");
        byte[] digest = md.digest(signatures[0].toByteArray());
        String currentSignature = bytesToHex(digest);
        return expectedSignature.equals(currentSignature);
    } catch (Exception e) {
        return false;
    }
}

嗯，到这里，安全加固的几个核心点就讲完了。你可能会觉得“东西有点多”，但没关系，安全本身就是个持续对抗的过程。没有绝对的安全，只有不断升级的防御。

记住一句话：让攻击者的成本高于收益，你的APP就安全了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录