想看某个 App 到底怎么实现的？先别急着反编译

很多人对 Android 逆向的第一反应是「反编译看源码」。真上手才发现，APK 这东西，远不是把后缀改成 zip 解压那么简单——它外面裹了好几层皮，你得一层层剥，才知道里面长什么样。我习惯在动手前先想清楚：我到底想看什么，静态看还是动态看。

先扒开资源这层皮

APK 本质是个 zip，但里面的 resources.arsc、AndroidManifest.xml 是二进制编译过的，直接解压出来是乱码。所以第一步用 apktool 把资源和清单反编译成可读的：

apktool d app.apk -o out      # 反编译资源+清单+smali
cat out/AndroidManifest.xml   # 看权限、组件、入口

这一步能告诉你很多：它申请了哪些危险权限、有哪些 Activity/Service、SDK 里是不是藏着某家统计或某家加固。光看清单，有时候就能猜出大半架构。我每次都先看 Manifest，再决定往哪深钻。

看逻辑得靠 jadx

apktool 产出的是 smali——一种接近汇编的 Dalvik 中间语言，能读但很累。想看接近 Java 的源码，用 jadx 直接把 dex 反编译成 Java：

jadx -j 4 app.apk -d out_java   # 多线程反编译成 Java

但别指望反出来就是干净的工程代码。混淆过的类名会变成 a/b/c，字符串可能被加密，控制流被扁平化。这时候 jadx 只是起点，真要看懂得结合 smali 和动态分析。我常干的一件事：在 jadx 里定位到疑似逻辑的函数，记下它的 smali 偏移，再去动态环境里下断点验证。

改完想装回去，签名是绕不过的坎

如果你动了代码或资源想重打包，会撞上 Android 的签名校验。改过的 APK 必须用你自己的密钥重新签名，否则安装直接拒：

apktool b out -o mod_unsigned.apk
keytool -genkey -v -keystore my.jks -alias me -keyalg RSA -keysize 2048 -validity 10000
apksigner sign --ks my.jks --out mod.apk mod_unsigned.apk

但注意：很多 App 自己还会做「签名校验」——它运行时检查自身的签名是不是官方的，不是就退出。这种时候光重签名没用，得在 smali 里把校验那段的判断 patch 掉（比如把返回 true 的分支改掉）。这正是静态和动态要结合的地方：你从 jadx 找到校验函数，从 smali 改掉逻辑，再重打包。

还有一道常被低估的墙：加固（梆梆、360、腾讯乐固之类）。它们把真正的 dex 加密藏在 native 层，你 apktool/jadx 看到的只是壳。这种情况静态几乎无解，得先脱壳（通常是运行时把解密后的 dex 从内存 dump 出来），门槛一下高很多。

所以入门 Android 逆向，先把「剥皮—读资源—读 Java—必要时改并签名」这套基本盘练熟，比一上来钻研脱壳实在得多。反编译不是终点，你从里面看到的，永远只是冰山露出的那一点；剩下的，得靠你的假设和下一轮验证去补全。