企业官网建设流程全解析

简介：腾讯乐加固工具包是一套面向Android开发与安全测试人员的应用加固解决方案，适用于APK防逆向、防篡改及核心代码保护等场景。压缩包共190个文件，包含jar、dll、exe及properties等多种类型，其中jar/dll为加固引擎与依赖库，exe为命令行工具，properties为配置参数，整体约141.54MB，集成度高、开箱即用。内容预览显示其内置JVM运行环境与安全组件（如cacerts、blacklist等），可支持跨平台调用与策略配置。已有323人学习下载，适合需要快速搭建加固流程、评估腾讯乐加固效果的开发者。通过该工具包，读者可获得完整加固工具链、默认策略模板及命令行调用示例，便于直接集成到自己的打包或CI流程中。 你们有没有遇到过这种情况：辛苦写了一个月的Android应用，上线没两天，就在某个论坛上看到有人把APK扒下来，改个包名换一套广告SDK，重新签名又发了出来。我经历过，所以当我拿到那份名为“android版腾讯乐加固工具包-腾讯加固.rar”的压缩包时，第一反应不是怀疑，而是赶紧解压试一圈。这篇文章就把我这段时间用乐固加固APK的完整过程、踩过的坑、以及如何把它接到Android Studio构建流程里的经验整理出来，给同样被扒包问题困扰的Android开发同学一个参考。

1. 一个连反编译都没防住的APK，逼我动了加固的念头

1.1 逆向还原一套UI只需要半天

很多人觉得“我的应用又没价值，谁会来逆向我”，这话我以前也信。直到有一天，我在后台看到一个下载量异常高的渠道包，追踪下来发现包名被改了，启动页换成了别人的广告，里面还多了几个SDK。后来我在本地用jadx打开自己发出去的APK，简直像在逛自己家的仓库：资源文件、AndroidManifest、Activity代码、接口地址，全摊在明面上。说白了，一个APK在没有任何防护的情况下，被还原成可读工程，也就是半天的事。

那之后我学乖了，开始做混淆，Android Studio里开启minifyEnabled，配合R8把类名和方法名缩成a、b、c，发现逆向成本确实高了一些。但R8不是银弹。它解决的是“代码可读性”问题，拦不住别人动态调试、注入、二次打包。真正让二次打包变难的手段，是给APK加一层壳，把原始DEX加密保护起来，在运行时再解开加载——这正是我尝试腾讯乐固的出发点。

1.2 乐固到底在防哪些攻击路径

我理解的加固，核心是解决三条攻击路径：静态分析、动态调试、二次打包。静态分析就是刚才说的拿jadx看源码，加固之后原始DEX被加密，jadx能看到的是壳程序的入口，真正的业务代码不落地，静态层面就很难直接还原。动态调试则需要对抗反调试机制，壳会检测调试器、模拟器、Hook框架，一旦发现异常就拒绝运行。二次打包更典型，攻击者把加固后的安装包重新解包、替换资源、重新签名，加固会通过签名校验和完整性校验把这种篡改拦下来。

腾讯乐固这类方案的另一个价值，是它不要求你改业务代码。你不用像接SDK一样到处加初始化，也不用把核心逻辑改写成native层，编译出Release包后交给工具跑一遍就行。对存量项目尤其友好，我接手的一个老项目连包名都不能乱改，加壳几乎是侵入性最小的安全升级方案。

2. 解压腾讯乐加固工具包，看清里面哪些东西真正有用

2.1 工具包目录里都有什么

我解压“腾讯乐加固工具包-腾讯加固.rar”之后，目录结构大致是这样：

腾讯乐加固/ ├── legu # 加固主程序（Linux/macOS） ├── legu.exe # Windows 下的可执行文件 ├── lib/ # 壳相关的动态库 ├── tools/ │ ├── apksigner.jar # 用于 v2、v3 签名 │ ├── zipalign # 对齐工具 │ └── libwebp.so # 依赖库 └── README.txt # 使用说明

关键在于legu这个命令行程序。它接收一个未签名或已签名的APK，输出加固后的APK，真正干活的是它。lib目录里的so库是壳运行时需要的，加固时会被打进APK里，你不用手动处理。tools里的签名和对齐工具，是因为加固会破坏原有签名，输出包必须重新走一遍“对齐+签名”流程，这也是很多人第一次用的时候最容易卡住的地方。

2.2 为什么加固必须在编译完、签名前这个时间窗口做

先说结论：打包顺序应该是“编译出未签名APK → 加固 → zipalign对齐 → apksigner签名”。加固工具会往APK里追加壳代码、修改DEX和Manifest，这些操作都会让原来的签名失效。如果你把一个已经签好名的APK丢进去加固，输出后的包拿在手里没法直接装，必须重新签名。所以从流程效率上看，用未签名的Release包加固是更省事的选择。

我在Android Studio里通常先关闭签名配置，只打未签名Release包，或者用构建产物里的app-release-unsigned.apk。这个包本质上就是能安装、但没经过正式签名的APK，正好适合拿来喂给加固工具。有些团队觉得“先签名再加固，工具会重新签名”也行，但那样容易混入两个keyStore，后面排查问题会多绕一圈。

3. 命令行实操：从原始APK到加固签名包的全过程

3.1 参数逐个拆解：输入输出、签名、混淆开关

我手头这个版本的乐固命令行，核心参数是这样用的：

./legu \ -in app-release-unsigned.apk \ -out legu_output/ \ -xml \ -so \ -resource

-in指定输入的APK路径，-out指定输出目录。如果-out目录不存在，工具会自己创建。-xml表示对AndroidManifest.xml做加密保护，-so表示对so库做加固，-resource表示对资源文件做混淆或加密。这三个开关我建议全开，除非某个开关导致第三方SDK异常。

如果你希望工具在加固后自动签名，可以追加签名相关参数。但我的习惯是先不传这些参数，让加固包输出后我自己用apksigner控制签名，因为自动签名参数一旦写错，报错信息不够直观。

./legu \ -in app-release-unsigned.apk \ -out legu_output/ \ -sig mykey.jks \ -alias myalias \ -kspass 123456 \ -sigpass 123456

这里-sig是keystore文件路径，-alias是别名，-kspass是keystore密码，-sigpass是key密码。注意密码直接写在命令行里会留在shell历史记录中，我一般是在测试环境才这么干，生产环境建议把密码放到CI的Secret变量里。

3.2 一次完整加固的日志与产物

加固过程跑起来之后，日志输出大概是这样的节奏：先解析原始APK，校验APK是否能被正常解析；然后对DEX做加密替换，把壳的入口写入Manifest；接着处理so库和资源文件；最后重新打包并输出。整个过程根据APK大小不同，几十秒到几分钟不等。我那只包大概40MB，跑完用了两分钟左右。

输出目录里会看到：

legu_output/ ├── app-release-unsigned_legu.apk # 加固后的APK，未签名 └── legu_obfuscation_mapping.txt # 混淆映射（可选）

拿到这个加固后的未签名包，紧接着做对齐和签名：

zipalign -p 4 legu_output/app-release-unsigned_legu.apk app-aligned.apk apksigner sign \ --ks mykey.jks \ --ks-key-alias myalias \ --ks-pass pass:123456 \ --key-pass pass:123456 \ --out app-final.apk \ app-aligned.apk

这里有个细节：先zipalign再apksigner签名。Android官方推荐的顺序是先把未签名APK对齐，再用apksigner签名。如果你用旧的jarsigner，就必须先签名再对齐，两种工具的顺序要求相反。Android 7.0之后建议直接用apksigner，因为jarsigner不支持v2签名。

4. 加固后的验证与兼容性排雷

4.1 用jadx和apktool验证加固效果

加固完不要急着发版，先自己检查一下效果。我习惯把两个APK分别拉出来做对比：一个是加固前的，一个是加固后的。

用jadx打开加固后的APK，入口变成类似com.stub.StubApp这样的壳类，原本的包名Activity不再直接暴露，业务代码的类基本都是加密状态，看不到具体逻辑。再用apktool解包看AndroidManifest.xml，Application节点被替换成了壳的Application，这样才能在App启动时先解密DEX再加载真实代码。

这不是说加固后绝对安全，遇到足够强的人还是可能被脱壳，但普通逆向者看到这种结构基本会放弃。对我们这种担心“源码被抄、包被二次打包”的团队来说，这个防护等级已经够用了。

4.2 常见兼容性坑：反射、so库、v2签名

第一次加固完我踩了好几个坑，最典型的是反射相关。项目里有一个热修复模块，用反射调系统隐藏API，加固后DEX被加密，反射路径被壳改动，启动时直接抛ClassNotFoundException。解决办法是在加固配置里把这些类加入“不加密名单”或者keep规则，让壳在加载时放行这些类。具体配置项因工具版本而异，本质就是给壳提供一份“白名单”。

第二个坑是so库。我们有个核心的native库，之前放在lib/armeabi-v7a下。开-so加固后，System.loadLibrary("core")在部分机型上报UnsatisfiedLinkError。后来我排查发现是壳对so做了抽取保护，某些Android版本的系统加载顺序和原生不太一致。解决方法是把keep名单里加上这个so，或者改用System.load(String path)指定绝对路径，配合applicationContext.getApplicationInfo().nativeLibraryDir。

第三个坑是签名。有个测试同事反馈Android 7以上机型安装时提示“应用未安装”，排查后确认是签名工具没启用v2签名。后来统一用apksigner verify --verbose检查输出包的签名方案，确认包含v2甚至v3再发版。

5. 把加固固化到Android构建流程里

5.1 用Gradle Task串起加固+签名

命令行跑通一次之后，就该考虑固化到构建流程里了。总不能每次发版都手动敲命令。我在项目根目录放了一个build-legu.gradle脚本，定义一个Task挂在assembleRelease后面。

task leguRelease(dependsOn: 'assembleRelease') { doLast { def inputApk = "$buildDir/outputs/apk/release/app-release-unsigned.apk" def outputDir = "$buildDir/legu" def leguBin = "/opt/legu/legu" exec { workingDir '/opt/legu' commandLine leguBin, "-in", inputApk, "-out", outputDir, "-xml", "-so", "-resource" } exec { workingDir '/opt/legu' commandLine "zipalign", "-p", "4", "$outputDir/app-release-unsigned_legu.apk", "$outputDir/app-aligned.apk" } exec { workingDir '/opt/legu' commandLine "apksigner", "sign", "--ks", keystorePath, "--ks-key-alias", keystoreAlias, "--ks-pass", "pass:$keystorePassword", "--key-pass", "pass:$keyPassword", "--out", "$buildDir/outputs/apk/release/app-release-legu.apk", "$outputDir/app-aligned.apk" } } }

keystore密码从gradle.properties里读取，不写死在脚本里。接入之后，每天打Release包都会自动产出加固签名后的APK，直接拿来上架或者发测试。

5.2 我的心得：加固只是其中一道防线

用顺手以后，我觉得该泼一盆冷水：加固不是保险箱，它更多是提高逆向门槛，而不是彻底杜绝逆向。配合代码混淆、混淆规则里的字符串加密、服务端接口校验、防抓包、敏感逻辑下沉到native层，这些措施叠起来，才能真正把“被扒”的概率降下来。

现在我们的发版流程已经稳定跑了大半年，中间升级过几次加固工具版本，基本没再出现二次打包的问题。如果你也被盗版包、被注入广告、被抄代码折磨，建议把加固尽早纳入发版流程。第一次配置需要花半天，但之后每次发版都省心。

本文还有配套的精品资源，点击获取