简介腾讯乐加固工具包是一套面向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.xmlApplication节点被替换成了壳的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层这些措施叠起来才能真正把“被扒”的概率降下来。现在我们的发版流程已经稳定跑了大半年中间升级过几次加固工具版本基本没再出现二次打包的问题。如果你也被盗版包、被注入广告、被抄代码折磨建议把加固尽早纳入发版流程。第一次配置需要花半天但之后每次发版都省心。本文还有配套的精品资源点击获取 Android APK加固实战：腾讯乐固接入与构建流程指南
简介腾讯乐加固工具包是一套面向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.xmlApplication节点被替换成了壳的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层这些措施叠起来才能真正把“被扒”的概率降下来。现在我们的发版流程已经稳定跑了大半年中间升级过几次加固工具版本基本没再出现二次打包的问题。如果你也被盗版包、被注入广告、被抄代码折磨建议把加固尽早纳入发版流程。第一次配置需要花半天但之后每次发版都省心。本文还有配套的精品资源点击获取