第27章安全与加固

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

安全与加固：代码混淆、签名打包、网络安全与数据加密

说实话，安全这块内容，很多开发者一开始都不太重视。我早年带团队时，就见过一个App上线三天就被破解的惨案——对方直接反编译拿到了接口密钥，服务器差点被打穿。从那以后，我每次做项目都把安全加固放在跟功能开发同等重要的位置。

今天咱们就把Android安全加固的五个核心模块捋一遍。代码混淆、签名打包、网络安全配置、数据加密、Root检测与防逆向，每个都是实战中绕不开的硬骨头。

1. 代码混淆：ProGuard 与 R8

代码混淆说白了就是给你的源码「穿上马甲」。类名、方法名、变量名全变成a、b、c这种无意义的短名，反编译后根本看不懂逻辑。

我个人的习惯是：新项目直接用R8，老项目如果还在用ProGuard，建议尽快迁移。R8是Google官方推荐的替代方案，混淆+压缩+优化一步到位，打包速度还更快。

核心配置（app/build.gradle）：

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

这里有个坑——混淆后反射会炸。我曾经在项目中用Gson解析一个Bean，混淆后字段名全变了，解析出来全是null。排查了半天才发现是混淆规则没配好。

避坑指南：

所有被反射调用的类，加 -keep 规则
JNI 方法名不能混淆，用 -keepclasseswithmembernames
枚举类、注解类、序列化类都要单独处理

举个例子，如果你用了Retrofit，接口类必须保留：

-keep,allowobfuscation interface * {
    @retrofit2.http.* <methods>;
}

2. 签名与打包

签名是Android应用的「身份证」。没有签名的APK，系统根本不认。我记得刚入行时，有次打包忘了签名，直接adb install报错，折腾了半小时才发现问题。

Android签名经历了三代演变：

签名方案	特点	适用场景
V1 (JAR签名)	基于META-INF，兼容所有版本	Android 7.0以下
V2 (APK签名方案)	全文件签名，更安全	Android 7.0+
V3 (APK签名方案v3)	支持密钥轮换	Android 9.0+

重要提醒：签名密钥一定要备份！我见过不止一个团队，密钥丢了只能换包名重新上架，用户全丢了。建议把.jks文件放在公司内部加密存储，同时保留纸质备份。

打包时建议同时开启V1和V2签名：

android {
    signingConfigs {
        release {
            storeFile file("release.jks")
            storePassword "xxx"
            keyAlias "xxx"
            keyPassword "xxx"
            v1SigningEnabled true
            v2SigningEnabled true
        }
    }
}

3. 网络安全配置

Android 9开始，默认禁止明文HTTP流量。如果你的App还在用HTTP接口，直接崩给你看。解决办法就是配置 network_security_config.xml。

我个人建议：能上HTTPS就全上HTTPS。但有时候开发环境或者第三方SDK确实不支持，那就需要灵活配置。

<?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">192.168.1.100</domain>
    </domain-config>
</network-security-config>

实战经验：调试阶段可以用 android:networkSecurityConfig="@xml/network_security_config" 指向debug配置，release包严格限制。这样既方便开发，又保证线上安全。

4. 数据加密：AES 与 RSA

数据加密这块，我踩过的坑最多。简单说：对称加密用AES，非对称加密用RSA。

AES：加密解密用同一个密钥，速度快，适合加密大量数据。密钥长度建议256位。
RSA：公钥加密私钥解密，速度慢，适合加密小数据（比如AES密钥）。

实际项目中，我常用的方案是「混合加密」：

客户端生成一个随机的AES密钥
用服务器的RSA公钥加密这个AES密钥
把加密后的AES密钥传给服务器
服务器用RSA私钥解密得到AES密钥
后续通信都用AES加密

// AES 加密示例
public static String encryptAES(String data, SecretKey key) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    cipher.init(Cipher.ENCRYPT_MODE, key);
    byte[] iv = cipher.getIV();
    byte[] encrypted = cipher.doFinal(data.getBytes());
    // 返回 IV + 密文 的Base64编码
    return Base64.encodeToString(iv, Base64.NO_WRAP) + ":" + 
           Base64.encodeToString(encrypted, Base64.NO_WRAP);
}

千万别把密钥硬编码在代码里！ 我曾经接手过一个项目，AES密钥直接写在Java文件里，反编译一下就全暴露了。正确的做法是从服务器动态获取，或者用Android Keystore系统存储。

5. Root检测与防逆向

Root检测说白了就是检查手机有没有被越狱。金融类App、支付类App基本都做这个。但说实话，没有100%防不住的逆向，我们能做的只是提高攻击成本。

常见的Root检测手段：

检查 su 文件是否存在（/system/bin/su、/system/xbin/su）
检查Build.TAGS是否包含"test-keys"
尝试执行 which su 命令
检查SuperSU、Magisk等管理应用是否安装

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

防逆向小技巧：

关键逻辑用Native层（C/C++）实现，反编译难度大很多
加壳保护，市面上有360加固、腾讯加固等方案
检测调试器是否附加（android.os.Debug.isDebuggerConnected()）
对关键字符串做加密，运行时再解密

我记得有一次，我们App被某团队逆向后直接改了支付金额。后来我们在Native层加了签名校验，每次启动时验证APK签名是否被篡改，才彻底解决了这个问题。

写在最后

安全加固不是一锤子买卖，而是一个持续对抗的过程。你加固一层，攻击者就多花一层功夫。我们的目标不是让App绝对安全（这不可能），而是让破解成本远大于收益。

嗯，上面这些内容，基本覆盖了Android安全加固的核心要点。每个点展开都能讲一整天，但今天咱们先把框架搭好，后续实战中再慢慢填坑。

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

📚 课程目录

安全与加固：代码混淆、签名打包、网络安全与数据加密

1. 代码混淆：ProGuard 与 R8

2. 签名与打包

3. 网络安全配置

4. 数据加密：AES 与 RSA

5. Root检测与防逆向

写在最后