-
-
[原创]全流程使用AI，完成一次APK重打包。改包名、绕过 Native 校验、重建签名并去掉奖励广告的完整复现
-
发表于: 2026-4-2 13:45
-
最近在关注Android应用重打包，自己练手了几个，突发奇想，想试试完全使用AI辅助，能不能完成整个过程。就在google play上随手找了一个小游戏来进行尝试。为了不影响别人的产品，样本和打包成品这里就不提供了。
使用到的工具及环境：apktool、MT管理器、codex cli、jadx、ida
到本文写完为止，已经完成并验证了以下内容：
当前最终测试包：
本次工作目录：
一开始目录中只有样本apks，以及一个agent。这个agent是写的一个根据apktool反编译的目录，来完整修改包名。
核心材料包括：
很多人做 APK 修改时，习惯一上来直接改 AndroidManifest.xml，再零散搜几个字符串，最后编译试错。
这种方式最大的问题不是效率，而是无法形成稳定复现。
因为 APK 改包名真正涉及的不只是一个 package 字段，而是至少要联动处理：
所以我先把“改包名”拆成一份 Agent 文档，把流程固化。
agent.md 的核心目标只有一句话：
改包名不是单点替换，而是一套 Manifest、smali、资源、配置、SDK、Native 联动校验流程。
文档里把整个过程拆成了标准步骤：
后面出现“重打包后卡启动页”的时候，如果没有前面这份 Agent，容易误判成：
但 Agent 里有一条优先级很高的规则：
如果改包名后启动异常，优先排查写死包名、签名校验、自校验和 Native 风险点。
也正是靠这条规则，后面排查时没有在 Java 层盲目来回试错，而是直接把视线转向 libappJni.so。
反编译和修改代码，以及重打包，所有操作均在codex环境中完成。
使用MT管理器，安装xapk安装后成功打开，结果如图：
使用MT管理器，获取样本的apk：
把样本的apk放到当前重打包的目录，然后使用codex，开始进行反编译。
指令：
执行结果：
可以看到，AI已经自动完成了反编译，并且放到了当前目录：PrincessColoring_apks
在反编译出来的目录中找到AndroidManifest.xml,查看一下原包名为：package="art.games.color.princess.coloring"
我准备把包名修改为package="com.pcolor.game.colorings"
指令：
执行完成后，在AndroidManifest.xml中查看修改之后的结果：
现在开始重打包，同样交个codex来完成。
指令:
执行结果：
这里的指令中，我并没有明确指出需要签名，就是想看看AI能不能智能的告诉我，需要签名后才能安装。
结果也是不负所望，它真的告诉我需要签名。
这里就顺着它的回答往下进行，直接告诉它两个字继续，执行结果为：
当前目录中现在就多了2个apk，一个是重打包，未签名的；另一个是重打包，用debug签名的：
使用adb，安装到手机，查看一下结果：
结果失败了：
接下来把错误直接丢给codex，让它自己修复：
执行结果：
测试安装新的apk：
这次成功的安装了，结果是：
点开新安装的app，结果却是卡在了启动界面：
我猜这里很可能是app中做了签名校验，导致进不去。这里，还是把问题抛给codex。
指令：
执行结果：
可以看到，发现了libappJni.so，libclient.so，这与我之前自己在jadx中查找到的结果是一样。
分心完成后，给出了结果：
接下来让它自己修复，结果是：
这里我安装了新的apk，发现还是卡在启动界面，那么继续让它修复。
指令：
这一次很牛逼啊，它自己执行了adb，启动app,并且分析Logcat日志：
跑了2轮，总算是发现了重点了（主动 System.exit(0)，不是崩溃）：
继续分析：
开始下指令，让它绕过校验检测：
指令：
这个时候我电脑突然死机了，很郁闷。但是没办法。 重启电脑后，我们继续分析：
指令：
结果：
指令：
结果：
可以看到，工作目录中已经生成了patch脚本和打包后的apk：
这里我没有进行安装测试，而是让它接着它的建议"2"执行，出标准 v2/v3 签名包：
指令：
结果：
这里我对新生成的签名包进行了测试：
结果很不错，没有再卡启动了，正常打开了app，并进入了主界面：
如图所示，重打包成功了。游戏中的内容需要用金币购买，金币需要看广告。那么这里再让codex试试，能不能跳过广告，直接获取奖励。
说干就干。
指令：
结果:
指令：
结果：
指令：
结果：
指令：
结果：
指令：
结果：
指令：
结果：
指令：
结果：
安装最新的包到手机上进行测试，结果如下：
点击左上角的金币，弹出看广告加金币的弹窗
这里直接点击看广告后，结果如下：
直接点收下。然后就能看到，金币已经增加了，并且没有弹出广告。
到这里，整个操作过程就全部完成了。
这次重打包最重要的不是拿到结果，而是验证是否可用AI来完成整个过程。
agent.md和patch_libappJni_bypass.sh已经放在附件了，过程记录文件就不放了，有兴趣了朋友可以自己操作一次。
我已经获取到了真实的apk文件，名称为PrincessColoring_apks.apk。使用apktool进行反编译，把结果放在当前目录。
很好，现在开始修改apktool反编译出来的文件中的包名。新的包名为：com.pcolor.game.colorings
很好，修改包名已经完成了。接下来把修改之后的文件重打包成新的apk。
adb install PrincessColoring_apks_rebuilt_signed.apk
Performing Streamed Install
adb: failed to install PrincessColoring_apks_rebuilt_signed.apk: Failure [-124: Failed parse during installPackageLI: Targeting R+ (version 30 and above) requires the resces.arsc of installed APKs to be stored uncompressed and aligned on a 4-byte boundary]
› 我使用adb install安装到手机，结果失败了。异常是： adb install PrincessColoring_apks_rebuilt_signed.apk
Performing Streamed Install
adb: failed to install PrincessColoring_apks_rebuilt_signed.apk: Failure [-124: Failed parse during installPackageLI: Targeting R+ (version 30 and above) requires the resces.arsc of installed APKs
to be stored uncompressed and aligned on a 4-byte boundary]
adb install PrincessColoring_apks_rebuilt_aligned_signed.apk
Performing Incremental Install
Serving...
Success
Install command complete in 950 ms
很好。这次安装成功了，我在手机上打开app，却卡在了启动界面。分析出现这个问题的原因。
我安装了新的apk，还是卡在启动界面，说明还没修复完整。继续分析并修复。
继续分析，启动绕过CheckApkSign和so检测绕过。
上次分析 `libappJni.so` 时，电脑死机，没有看到结果。
需要重新分析是否存在包名判断或其他校验，导致重打包后卡启动界面。
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
加油，已经有人复现了 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
codex cli ,gpt5.4 |
|
|
学到了很多，楼主的教程很棒 ，没想到AI已经强大到这种地步了。 windows上复现前期还是有蛮多坑的1.xapk到apk就卡了半小时，试了各种方法，只有MT是最准确的，其他工具有的获取的仍是xapk或者apks仍然是组合包，有的只有apks中的base包... 2.不知道是不是windows的问题，ai对反编译目录直接编译，不是目录权限有问题，就是多了xml.orig配置文件，ai告诉我删不掉，只能重新拷贝一份目录排除掉这个文件重新编译，最后拷贝的反编译资源目录都有18个，哈哈哈，又费时又费token 下面是成果，ai直接帮我把看广告改成了收下，hhh
|
