Smali代码补丁入门：不反编译直接改APK逻辑

咨询发布

有时候不想反编译重打包 APK，只想改一小处逻辑。Smali 代码补丁是比 apktool recompile 更轻量的方案。

一、Smali 是什么
APK 里的 classes.dex 反编译后得到 Smali 代码——一种类似汇编的中间语言。每行 Smali 对应一条 Dalvik 字节码。改 Smai 就是改字节码，不需要 Java 源码。

二、最小补丁流程

• 用 apktool d app.apk 反编译，得到 smali/ 目录
  
• 在 smali/ 里找到目标类的 .smali 文件
  
• 直接编辑 Smali 代码改逻辑
  
• apktool b 重新打包
  
• 签名后安装
  

三、常见补丁模式
1. 绕过条件检查
把 if-eqz 改成 if-nez，或者反过来。比如验证逻辑：

1. # 原始
2. if-eqz v0, :cond_fail
3. # 改成
4. if-nez v0, :cond_fail

复制代码

一个字之差，验证从"相等才失败"变成"不等才失败"，直接跳过验证。

2. 强制返回 true
把方法体改成直接返回 true：

1. .method public isVip()Z
2.     const/4 v0, 0x1
3.     return v0
4. .end method

复制代码

不管实际逻辑是什么，isVip 永远返回 true。

3. 替换字符串常量
直接在 Smali 里改字符串。比如把 "trial" 改成 "pro"：

1. const-string v0, "trial"
2. # 改成
3. const-string v0, "pro"

复制代码

注意新字符串长度不能超过原字符串（UTF-8 字节数），否则要改 const-string 指令为 const-string/jumbo。

四、调试技巧

• 在关键方法入口插 log：const-string v0, "ENTER: xxx" 然后 invoke-static 调 Log.i
  
• 用 Frida 动态测试补丁效果，再改 Smali 做静态固化
  
• 多dex应用注意：可能有 classes2.dex、classes3.dex，目标类可能在任一 dex 里
  

五、注意事项

• 改完要重新签名，原签名会失效
  
• 部分 App 有签名校验，需要在 Smali 里禁用 PackageManager 的签名获取
  
• 加固应用（360 加固、腾讯乐固）的 Smali 是脱壳后才能改的，加固壳把真实 dex 隐藏了
  

我只是路过，不发表意见

浅夏不眠

难得看到这么具体的分析，比泛泛而谈强多了。

野渡闻笛

静态分析搞不定的部分，动态跑一遍基本就清楚了。

寒山记事

遇到卡住的地方，换个思路往往比死磕更快。

寒山

这类校验现在很多是服务端下发的，光改本地没用。

榴莲铺子

签名校验放在 Native 层确实麻烦不少，但也不是无解。

溪云记事

这类技术更新的频率很高，老教程参考价值有限。

浅夏笔记

这类壳本质就是给分析加成本，真下定决心还是能扒出来。

沉默长夏

之前分析过类似的，混淆还原完逻辑其实不复杂。