前言
最近忙于招聘，尝试了很多途径。发现某招聘软件效果不错，但是噪声有点大。于是觉得既然是个 APP，那我抓出来 API 后，干点我想干的事情（爬虫、自动化管理），岂不是很好？
抓包分析
配合 Charles 代理，我们可以抓到如下 QueryString
对于同一个事件，多尝试几次之后发现：只有sig和req_time 是变量。而且 V2.0 感觉是写死的字符串，后面的那个怎么看怎么像 MD5
对于这种 MD5 我们不会指望它能在网站上被爆破的。于是摆在眼前的做法，就剩下逆向分析了，然而我手头没有一台越狱的 iPhone，就没法通过擅长的 lldb 断点的方式看到 MD5 加密前的样子，于是我目标改为了 Android
拆包分析 java 源码
apk改名zip，解压拿到classes.dex我们通过
dex2jar轻松拿到了dex包所对应的jar文件。jd-gui拆包jar，倒出对应代码。发现这东西做了混淆，但系统API MD5 肯定无法混淆
尝试着 grep 一下:
grep -r "md5" * -i
在一堆代码中，发现那个 V2.0 似曾相识
return "V2.0" + MD5.convert(new StringBuilder().append(com.package.id.config.c.a(paramString)).append(str1).append(str2).toString());跟到文件中看了一眼：
我们知道了签名是由 config 的一个方法，和经过处理的 参数字典 以及 盐和某个 c.f() 方法构成的。
然而跟了一下 str2 的 c.f() 方法
public static String f()
{ if (!LText.empty(e)) { return e;
} return SP.get().getString("com.package.id.SECRET_KEY", "");
}发现走入了死胡同，要知道 SECRET_KEY 哪来的，仿佛很麻烦的样子。总想放弃治疗，但又觉得可以抢救一下。联想了一下 iOS，于是开始搜索 Android 有没有像 lldb 断点一样的东西。
毕竟，他的 MD5 都是经过一个叫做 MD5.convert 的方法。于是我下个断点岂不是很好？突然想起来 《Android 软件安全与逆向分析》 里面介绍过可以修改 Smali，添加 Log.d 的方法，尝试一下。
反编译修改 Smali 代码
apktool D xxx.apk，结果出了点小插曲，详情见阅读原文吧。
找到那个
MD5.smali
在 convert 方法中给 .locals +1 并插入 Log 对应代码：
.method public static convert(Ljava/lang/String;)Ljava/lang/String; .locals 4 const-string v3, "hack" invoke-static {v3, p0}, Landroid/util/Log;->v(Ljava/lang/String;Ljava/lang/String;)I .prologuev3是我声明的 “hack” 字符串，p0是传入默认参数。apktool b 文件夹名，我这里是：
apktool b app这时在 app/dist/ 中，可以找到我们打包好的 apk 文件了，但这时候是没法用的，我们需要重新签个名。
用 google 提供的
signapk.sh签名 APKadb install -r app.apk
启动，闪退。logcat 提示
java.lang.VerifyError: Rejecting class com.monch.lbase.util.MD5 because it failed compile-time verification
查了一下貌似是 ART 的锅。用模拟器跑了一个 4.4 的 rom，adb logcat | grep hack
于是整个 md5 加密前的东西，暴露无遗。配合爬虫，就能抓到一份属于自己的简历库了！
