对某APK中的骚套路分析。（转录组和代谢组联合分析套路）

在对某个APK逆向中遇到的骚套路，害我搞了半天才明白过来~~~~

先看下Wireshark到的数据流。

从图上的请求头中我们发现Host竟然是内网127.0.0.1地址，在使用Fiddler等代理抓包工具也是显示的是127.0.0.1的地址，这时候我们就能断定APK中内部自带了web容器，然后所有的请求走127.0.0.1的地址，通过APK中的web服务器转发出去（类似NGINX，看到响应头中有NGINX我还真认为他是不是在apk中搞了个nginx来运行？？？）

好吧，不管他怎么走内网，始终还是会把数据包发出去的，所有我是用Wireshark（大白鲨）进行网卡抓包，从以上图片的数据中我们应该会断定他就是简单的HTTP请求嘛，然后把“127.0.0.1:xxx/usere/xxx”换成外网地址“120.xx.xx.xxx:xxx/usere/xxx”进行访问不就解决了？厄 我也是这么想的，看下面图执行结果

“Remote end closed connection without response”

远程端关闭连接没有响应。

也就是连接成功了，但是没有任何响应给客户端，服务端就把连接关闭了。

我第一时间想到的是难道端口错了？IP地址错误？从抓包工具上面看貌似也没啥问题。。。。

看是陷入沉思。

有人肯定会想反编译APK查看源代码~~

我也想，他用的是cocos2d，不俗啊，然后所有的请求相关的我都找了没有任何关键词，资源文件只有被加密的lua文件和js文件。解啊，尝试拖入IDA进行静态分析找秘钥，找不到。。。。

动态调试配置环境太麻烦，不想动。。。。

好吧，只能再次回到数据流上，

咋办，咋办，咋办不成功啊，咋回事呢，求助朋友啊，问啊，交流啊，朋友告诉我用socket5代理，搞上去还是抓不了。

这时候我都想把模拟器当做服务直接请求模拟器上的web了，但是太麻烦了要进行端口映射啥的，而且搞出来的程序不是我用啊，只能继续研究。。。。。

这时候我已经怀疑他就是TCP长连接。我尝试拔网线（让他的TCP连接断开）在APK的操作，最后发现

因为我刚才拔了网线让他TCP断开了服务器，那么我再次进行请求操作他肯定会再次进行连接服务器的，所以我进行了严格抓他的第一个请求包。发现在我们HTTP报文前面有一串乱码~~~

怀疑是认证秘钥吧。（只有在连接成功后才会发一次这个数据，所以认定应该是秘钥吧）

然后模仿他的结构进行TCP数据发送

拿到返回结果了。

所以最终的分析是：

请求---》APKweb服务器----》打包数据成HTTP报文结构---》TCP发送到服务器

PS ：响应的正文上面的“3a”是十六进制转换为十进制就是正文的长度，所以在解析的时候要用到。

骚在他把数据体伪装了HTTP报文结构，导致让我误判他是HTTP~~~