网络安全——App逆向防护

比较推荐的分层方式是：

• Java层：尽量只保留流程编排、UI、参数整理，避免直接暴露签名算法、密钥片段、风控规则。
• JNI 边界：把敏感输入整理成稳定结构，再交给 native 层，减少 Java 层可搜索的关键字符串。
• SO 层：关键逻辑用 C/C++ 实现，符号隐藏、字符串处理、完整性校验一起上。
• 构建链路：release 包必须经过混淆、裁剪、加密、哈希清单生成、自动检查。
• 服务端：不要完全信任客户端，关键决策必须能在服务端复核。

一个很实用的原则：客户端只做“参与计算”，不要做“最终裁判”。这样即使某一层被拆开，攻击者也很难独立完成整条业务链路。

Java 混淆：先把可读性降下来

Android 项目里最常见的混淆工具是 R8。它能做代码压缩、优化、混淆、资源裁剪。基础配置一般放在 release 构建类型里：

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true

            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

这段配置主要解决三件事：

• minifyEnabled：删除无用代码，并重命名类、方法、字段。
• shrinkResources：删除未被引用的资源，减少静态分析入口。
• proguard-rules.pro：对必须保留的接口做精细控制，避免误删和误改。

混淆规则不要一把梭

很多项目一开始会写一堆 -keep class ** { *; }，结果看起来启用了混淆，实际核心包名、类名、方法名都没有动。更好的方式是只保留必须对外暴露的边界。

# JNI 方法名必须保持稳定，否则 native 绑定会失败
-keepclasseswithmembernames class * {
    native ;
}

# 反射入口只保留必要类，不要保留整个业务包
-keep class com.zoy.app.bridge.NativeBridge {
    public static native byte[] sign(byte[]);
    public static native int verifyEnv(byte[]);
}

# JSON DTO 可以用注解精确保留字段
-keep @com.zoy.app.annotation.KeepForJson class * { *; }
-keepattributes RuntimeVisibleAnnotations, Signature

# 对外 SDK 接口按最小面保留
-keep class com.zoy.app.sdk.PublicApi {
    public ;
}

# 日志与调试信息收敛
-assumenosideeffects class android.util.Log {
    public static int v(...);
    public static int d(...);
    public static int i(...);
}

这里的重点不是“保留更多”，而是“只保留确实不能改名的部分”。一旦把整个包都 keep 住，混淆收益就会大幅下降。

用注解保护必要字段

如果项目里有 Gson、Moshi、Jackson 这类序列化工具，字段名被混淆后可能导致解析失败。可以定义一个轻量注解，只给需要稳定结构的类使用。

package com.zoy.app.annotation;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface KeepForJson {
}

业务模型只在必要处标记：

package com.zoy.app.model;

import com.zoy.app.annotation.KeepForJson;

@KeepForJson
public final class LoginPacket {
    public String deviceId;
    public String nonce;
    public String signature;
}

这样可以避免为了一个 DTO 把整个 model 包都排除在混淆之外。

敏感字符串不要裸奔

混淆只会改变符号名，并不会自动保护字符串常量。下面这种写法很容易被直接搜索到：

public final class ApiConfig {
    public static final String APP_SECRET = "please-do-not-hardcode-secret";
    public static final String SIGN_SALT = "plain-text-salt";
}

更稳的做法是：客户端不保存完整密钥，敏感材料拆分到服务端、Native 层或动态下发流程里，并且本地只保存短期可替换的派生材料。

public final class SecretMaterial {
    private SecretMaterial() {
    }

    public static byte[] buildLocalSeed(byte[] installSeed, byte[] serverSeed) {
        if (installSeed == null || serverSeed == null) {
            throw new IllegalArgumentException("seed missing");
        }

        byte[] out = new byte[installSeed.length + serverSeed.length];
        System.arraycopy(installSeed, 0, out, 0, installSeed.length);
        System.arraycopy(serverSeed, 0, out, installSeed.length, serverSeed.length);
        return out;
    }
}

注意，这里只是演示“不要把完整秘密写死在 Java 层”。真正的签名和密钥派生最好再放到 native 层或服务端协同完成。

JNI 边界：让 Java 层只负责递送

JNI 的价值不是“天然安全”，而是把关键逻辑从易读的 Java 层挪到更难直接理解的 native 层。边界设计要尽量简单：输入清晰、输出稳定、异常可控。

package com.zoy.app.bridge;

import android.content.Context;

public final class NativeBridge {
    static {
        ShieldSoLoader.load();
    }

    private NativeBridge() {
    }

    public static native byte[] sign(byte[] canonicalPayload);

    public static native int verifyEnv(byte[] envDigest);

    public static byte[] signRequest(Context context, byte[] payload) {
        byte[] canonical = RequestCanonicalizer.build(context, payload);
        return sign(canonical);
    }
}

这里有几个设计点：

• Java 层只拼装标准化数据，不直接暴露签名细节。
• Native 方法数量尽量少，方法名和参数稳定，减少 keep 规则范围。
• 返回值使用基础类型或字节数组，避免复杂对象跨层传递导致规则膨胀。
• 异常和错误码要可观测，避免线上问题只能靠猜。

对应的 native 导出也要尽量少：

#include 
#include 

extern "C"
JNIEXPORT jbyteArray JNICALL
Java_com_zoy_app_bridge_NativeBridge_sign(
        JNIEnv *env,
        jclass,
        jbyteArray input) {
    jsize len = env->GetArrayLength(input);
    std::vector buffer(static_cast(len));
    env->GetByteArrayRegion(input, 0, len, reinterpret_cast(buffer.data()));

    std::vector digest = sign_payload(buffer);

    jbyteArray out = env->NewByteArray(static_cast(digest.size()));
    env->SetByteArrayRegion(out, 0, static_cast(digest.size()),
                            reinterpret_cast(digest.data()));
    return out;
}

真实项目里，sign_payload 内部不应该包含可直接复用的明文密钥。更推荐把本地材料、服务端材料、设备状态组合成派生输入，再在服务端做二次校验。

SO 层加密：把 native 库封装起来

SO 加密的核心目标是：不要让 libxxx.so 以清晰形态直接躺在安装包里。一个常见流程是：

• 编译生成 libshield_core.so。
• 对 SO 做 strip，减少符号暴露。
• 使用构建脚本加密 SO，生成封装文件。
• 将封装文件放入应用资源中。
• App 启动后在受控流程中解密、校验、加载。

CMake 侧先收紧符号

在 native 层，先把不必要的符号隐藏掉：

add_library(shield_core SHARED
    src/main/cpp/native_bridge.cpp
    src/main/cpp/signature_engine.cpp
)

target_compile_options(shield_core PRIVATE
    -fvisibility=hidden
    -ffunction-sections
    -fdata-sections
)

target_link_options(shield_core PRIVATE
    -Wl,--gc-sections
    -Wl,--exclude-libs,ALL
)

这样做可以减少导出符号和无用段，让静态分析时可见信息更少。JNI 必须导出的函数保留，其它内部函数尽量不暴露。

Python 加密 SO 包

发布前可以用 Python 对 SO 做加密封装。下面示例使用 AES-GCM，同时输出哈希清单，方便构建后校验。

from __future__ import annotations

import hashlib
import json
import secrets
from pathlib import Path

from cryptography.hazmat.primitives.ciphers.aead import AESGCM


def sha256_hex(data: bytes) -> str:
    return hashlib.sha256(data).hexdigest()


def seal_so(input_so: Path, output_blob: Path, key: bytes) -> dict[str, str]:
    raw = input_so.read_bytes()
    nonce = secrets.token_bytes(12)
    cipher = AESGCM(key)
    encrypted = cipher.encrypt(nonce, raw, input_so.name.encode("utf-8"))

    output_blob.write_bytes(nonce + encrypted)
    return {
        "name": input_so.name,
        "plain_sha256": sha256_hex(raw),
        "blob_sha256": sha256_hex(output_blob.read_bytes()),
    }


def main() -> None:
    root = Path("release-native")
    key = bytes.fromhex(Path("local-seal-key.hex").read_text().strip())

    manifest = seal_so(
        input_so=root / "libshield_core.so",
        output_blob=root / "shield_core.pack",
        key=key,
    )

    Path("release-native/native-manifest.json").write_text(
        json.dumps(manifest, ensure_ascii=False, indent=2),
        encoding="utf-8",
    )


if __name__ == "__main__":
    main()

这段脚本只适合放在构建环境里运行，密钥不要提交到仓库。更推荐使用 CI 密钥管理、临时环境变量或内部密钥服务。

Java 侧安全加载

App 内部加载时要做三件事：读取封装文件、解密写入私有目录、校验后加载。

package com.zoy.app.bridge;

import android.content.Context;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.security.MessageDigest;
import java.util.Arrays;

public final class ShieldSoLoader {
    private static final String LIB_NAME = "shield_core";
    private static volatile boolean loaded;

    private ShieldSoLoader() {
    }

    public static synchronized void load(Context context, byte[] openKey, byte[] expectedHash) {
        if (loaded) {
            return;
        }

        try {
            byte[] sealed = readRaw(context, R.raw.shield_core_pack);
            byte[] soBytes = SoEnvelope.open(sealed, openKey);

            if (!Arrays.equals(sha256(soBytes), expectedHash)) {
                throw new SecurityException("native checksum mismatch");
            }

            File target = new File(context.getCodeCacheDir(), "lib" + LIB_NAME + ".so");
            writeAtomic(target, soBytes);
            System.load(target.getAbsolutePath());
            loaded = true;
        } catch (IOException e) {
            throw new IllegalStateException("native load failed", e);
        }
    }

    private static byte[] readRaw(Context context, int rawId) throws IOException {
        try (InputStream in = context.getResources().openRawResource(rawId)) {
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            byte[] buffer = new byte[8192];
            int read;
            while ((read = in.read(buffer)) != -1) {
                out.write(buffer, 0, read);
            }
            return out.toByteArray();
        }
    }

    private static byte[] sha256(byte[] data) {
        try {
            MessageDigest digest = MessageDigest.getInstance("SHA-256");
            return digest.digest(data);
        } catch (Exception e) {
            throw new IllegalStateException(e);
        }
    }

    private static void writeAtomic(File target, byte[] data) throws IOException {
        File tmp = new File(target.getParentFile(), target.getName() + ".tmp");
        try (FileOutputStream out = new FileOutputStream(tmp)) {
            out.write(data);
            out.flush();
        }
        if (!tmp.renameTo(target)) {
            throw new IOException("native write failed");
        }
    }
}

这里把封装文件放到 res/raw，避免在 Markdown 里出现额外资源字段。实际工程还要补齐 ABI 区分、旧文件清理、加载失败降级等逻辑。

SoEnvelope.open 可以对应 AES-GCM 解密逻辑。示例只展示结构，不建议把完整 key 直接硬编码到客户端。

构建发布：把检查自动化

防护最怕“靠人记”。建议把下面这些检查放进 release 流程：

• 检查 release 是否启用 minifyEnabled 和 shrinkResources。
• 检查 APK/AAB 里是否存在未封装的核心 SO。
• 检查 mapping 文件是否归档到内部安全位置。
• 检查包内是否包含测试接口、调试日志、明文密钥。
• 检查 native 哈希清单是否与产物一致。

下面是一个轻量 Python 检查脚本，用来扫描包内敏感字符串和未封装 SO：

from __future__ import annotations

import sys
import zipfile
from pathlib import Path


SENSITIVE_WORDS = [
    b"APP_SECRET",
    b"plain-text-salt",
    b"debug_api",
    b"test_private_key",
]


def inspect_package(package_path: Path) -> list[str]:
    problems: list[str] = []

    with zipfile.ZipFile(package_path) as zf:
        names = zf.namelist()

        for name in names:
            if name.endswith("libshield_core.so"):
                problems.append(f"core so should be sealed: {name}")

            if name.endswith((".dex", ".so", ".json", ".txt", ".xml")):
                data = zf.read(name)
                for word in SENSITIVE_WORDS:
                    if word in data:
                        problems.append(f"sensitive word {word!r} in {name}")

    return problems


def main() -> int:
    package = Path(sys.argv[1])
    problems = inspect_package(package)

    if problems:
        print("release check failed")
        for item in problems:
            print("-", item)
        return 1

    print("release check passed")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

这个脚本不是完整安全扫描器，但很适合作为 release 门禁：发现硬编码、调试词、明文核心 SO 就直接失败。

运行阶段：完整性校验和风险信号

客户端防护还需要配合运行阶段的校验。建议关注这些信号：

• 安装包签名是否符合预期。
• 核心 dex 和封装 SO 的哈希是否符合清单。
• JNI 返回值是否符合服务端校验规则。
• 同一账号、设备、网络环境的请求特征是否异常。
• 关键接口是否出现重复提交、参数重放、签名异常。

签名校验可以放在 Java 层做第一道筛查，再把摘要交给 native 层参与签名计算。

public final class AppIntegrity {
    private AppIntegrity() {
    }

    public static byte[] digestForSign(Context context) {
        byte[] certDigest = PackageDigest.currentCertSha256(context);
        byte[] packageDigest = PackageDigest.currentPackageSha256(context);

        byte[] out = new byte[certDigest.length + packageDigest.length];
        System.arraycopy(certDigest, 0, out, 0, certDigest.length);
        System.arraycopy(packageDigest, 0, out, certDigest.length, packageDigest.length);
        return out;
    }
}

服务端收到请求后，不要只看一个签名字段。更好的方式是综合校验：

• 签名是否由当前版本算法产生。
• 请求参数是否被规范化处理。
• 设备摘要是否与账号行为匹配。
• 风险分是否超过业务阈值。

这样客户端防护和服务端风控才能形成闭环。

Java 混淆常见坑

反射被混淆导致崩溃

如果代码里使用 Class.forName()、反射调用方法、动态代理，就必须精确保留对应类和成员。

-keep class com.zoy.app.plugin.PaymentPlugin {
    public ();
    public void execute(...);
}

不要为了一个插件入口保留整条业务线，keep 规则越宽，防护收益越低。

序列化字段被改名

解决方案是用注解精确标记，或者给字段加序列化别名。不要因为接口解析失败就关闭整个模块混淆。

public final class OrderPacket {
    @SerializedName("order_id")
    public String orderId;

    @SerializedName("amount")
    public String amount;
}

Native 方法名被改掉

JNI 静态注册依赖方法名，混淆后容易找不到实现。可以保留 native 方法名，或者改用动态注册。

-keepclasseswithmembernames class * {
    native ;
}

如果团队 native 能力比较成熟，动态注册会更灵活，也能减少可见导出。

SO 加密常见坑

把 key 直接写进 Java

这会让 SO 加密变成“换个地方放明文”。key 至少要拆分，核心材料由服务端参与，客户端只保留不可单独复用的片段。

只加密不校验

加密解决“直接查看”，校验解决“被替换”。解密后必须做哈希校验，加载前也要检查目标文件是否来自当前流程。

加载路径不收敛

不要随意从外部可写目录加载 native 库。优先写入 App 私有目录，并且文件名、权限、校验流程都固定。

所有逻辑都塞进 SO

Native 层也会被分析。更好的方式是把核心算法、协议摘要、签名片段放进去，业务决策仍由服务端复核。