0. 起因
因工作或生活上的某些原因不得不使用某应用，暂且记为A应用把。可 A 应用设计得实在不人性化，一个操作通常需要点击若干次屏幕，点击一次还要 lodaing ，程序员说：不能忍。
于是开始着手改善软件体验
1. 初步计划
初步分析 A 应用实际上是一个 HTTP 客户端，前端后台之间完全通过 HTTP 协议传输数据。可使用 Fiddler 工具抓取数据包分析。
分析发现之前所有那些繁杂的操作（例如签到打卡（虚构）），其实只需要发送一个 HTTP 请求。于是，完全可以使用一段代码，伪装成 A 应用向后端发请求，完成相应的操作。甚至可以将应用内常用的操作全部提取出来，这样在上班的时候突然想起还没签到打卡，直接跑一段程序就 OK，甚至都不需要打开手机。简直美滋滋，我这样想着。
以签到打卡操作为例
实际应用中并不存在签到打卡操作
2. 分析请求
使用 Fiddler 抓取请求如下：
POST http://api.*****.com/v1/****/****/what
// 请求头
headers = {
"Accept-Encoding": "gzip",
"Accept-Language": "zh_CN",
"User-Agent": "Dalvik/2.1.0 (Linux; U; Android 7.0; MI 5 MIUI/8.1.25)",
"Content-Type": "application/x-www-form-urlencoded",
"Welove-UA": "[Device:MI5][OSV:7.0][CV:Android4.0.2][WWAN:0][zh_CN][platform:tencent][WSP:2]"
}
// 请求体（表单）
form = {
"access_token": "562********358-2****************6",
"app_key": "a*************4",
"timestamp":"1522393966",
"sig":"rTRa2PTiGiwkNVQUnSB0n2l6KrA=",
}
使用 Postman 原样发送请求，操作成功。但一旦更改请求的参数，服务端便会返回：
{
"result": 160,
"error_msg": "sig签名错误"
}
操作失败！
回头看一眼请求体中的sig字段，这个值rTRa2PTiGiwkNVQUnSB0n2l6KrA=一看就是一个用于校验的字符串，A应用在构造完请之后，根据URL和请求参数生成一个sig字段，并附加到请求的参数里面，后台接收到请求之后，通过sig字段来校验请求的合法性。这个设计一定程度上阻碍了我们伪装成A应用发请求。
所以我们修改了请求体中的数据之后，必然导致后台校验sig失败。
如何能愉快的玩耍？关键在于窥探A应用如何生成sig字段。
3. Hack It
思路：
（1）反编译应用，静态分析代码，找出生成sig的规则；
（2）若静态分析又困难，尝试动态调试（运行时打印日志等）。
3.1 反编译得到 smali
（1）下载最新版本的 Apktook
（2）获取A应用安装包，命名为t.apk
（3）使用java -jar apktool.jar d t.apk 反编译应用，得到文件夹t，里面便是A应用的全部
文件夹t的目录结构如下：
其中
smali开头的文件夹里面，是反编译之后的smali代码（类似汇编代码）。