万字长文-通过Fiddler抓包和jd-gui反编译白嫖某“绅士”APP内的正能量资源（二）

系列文章目录

万字长文-通过Fiddler抓包和jd-gui反编译白嫖某“绅士”APP内的正能量资源

---

---

前言

本系列文章，通过对某“绅士”APP，进行抓包和反编译，白嫖其内部正能量资源。
本系列文章旨在对"移动应用安全"实践中所遇到的，所积累到的一些软件安全方面的问题和分析思路及分析工具的用法进行总结。
作者不赞成也不鼓励任何人对任何软件产品进行恶意反编译及分析。
本文为入门级文章。适合新手，高手请忽略，且本人水平有限如文章有不对的地方，请多多指教，共同讨论。

---

继续深入

书接上回。当你准备用趁手的工具爬虫白嫖时候你发现了一个问题。你不能使用同样的参数，取请求所有的专辑。比如：

比如我用上图的这个参数取请求goods_id是其他值的专辑时，会返回错误信息。我们用postman试一下

并没有我们想要的信息，天啊这是肿么肥事，晴天霹雳呀。同样的现象还出现在了获取专辑列表上。专辑列表默认分页 每页10条数据。

当你只替换page参数进行请求时，返回与上面同样的错误信息。也就是说你连自动翻页也做不了，基于以上两点，那还爬个毛线啊！本文结束。
然而，并没有结束，
（接下来是重点，分析请求参数）
这个问题，一定就是出在了请求参数上，我们来看请求参数。
首先要看哪些参数可以省略。其次要分析参数具体含义，看有没有可能通过顺序增长或者好推算的逻辑进行变更
反复测试发现有些参数省略了，是会返回错误信息的，我们拿了获取专辑列表举例：

反复测试后发现 appid可以省略不要。
那有没有可能按逻辑自增啥的呢！看看这几个参数，appid可以省略，goods_id这个我们能获取到，timstamp时间戳，发现即便不是当前实际一样不影响。sign重点应该是这个，sign英文翻译标志，实际上应该是参数的签名，后端应该是校验此签名来保证请求合法性的。
（以下是重点，关于签名）
我们分析这个sign，典型的32位MD5摘要，那么有哪些参数要参与MD5运算的呢。

对传输中的数据进行签名防止数据被篡改是常见且有效。常见的方式是对关键参数进行编码。比如第一种：进行base64编码。
然后，在通过一个公钥(publicKey)对编码后的参数进行加密生成签名，然后将base54后的参数和加密生成的签名一起传给后端，后端接到后先用私钥解签名，能够得到base64后的参数，然后再对比一同传过来的参数，相同则验证通过。这就是JWT认证的基本概念，当然JWT要比我说的复杂点。这种方式适合对用户信息进行加密传输，比如登录的用户Id 用户名等，这个整个签发过程都应该有服务器来完成。典型场景就是单点登录了。

这个前面分析的东西就没用了，因为appid虽然可以在请求的时候省略，但是不代表不参与MD5运算。
直接说结果，组合试了很多遍，都没有得到和sign相同的MD5。

上活

既然不能蒙出来，那就只能从源码中获得了。反编译之~
将APK解压

提取出classes.dex

上一篇文章忘说了，还需要一个dex2jar这个工具，把classes.dex放到dex2jar文件夹下，并在此文件夹下运行cmd

输入命令

d2j-dex2jar classes.dex

然后会生成

将classes-dex2jar.jar这个jar包拖入jd-gui即可

我们将看到源代码。

分析源码

这么多源码咋看，从哪看
我们ctrl+shift+s 打开搜索，输入MainActivity,找到主Activiry

MainActivity.class

好家伙，代码没混淆！非常好，非常清晰，不看别的，就看以下onCreate()生命周期方法里写的啥。

调用了changeFrament方法，Frament是啥都知道哈！（不知道百度就行，也就是个页面，不过依赖于Activity,）看看changeFrament写啥了

主要就是判断传进来的页面id，然后创建页面，onCreate方法中调用时传入的值是（2131230865），对应的是这个Fragment实例

看这个实例是啥。点击这个类名就能跳转到定义，

首先发现他在fragment包下，并且该包下还有挺多的fragment，也就是挺多的页面。
本CateFragment类下定义的东西不多

这个NOTICE 会在每次onResume声明周期中调用，也就是每次页面出现啊的时候都发送当前用户id，这不是我们想要的。

看下一个

看方法名，初始化cate，初始化分类？
直接说结果，试了几次不是这个。
继续分析，细心的分析发现，这个方法最后调用了doPost

没错，是个发请求的类。那发送请求岂不是要有请求地址。于是。。。

对没错，这就是接口地址了。检验一下

没错FIddler发现了这个接口，同时还发现了上面Notice()方法notice/my_notice_red的接口请求。

那换种思路，是不是可以直接搜索接口，定位我们要找的类。
（下面重要，关于代码分析）
分析这种代码没有固定方法，搜集一切对自己有帮助的信息，然后去代码的海洋里筛选
我们ctrl+shift+s 打开搜索，输入我们获取专辑列表的接口地址。goods_list

啊哈找到了2个，一个是bean,bean一般都是值对象类，另一个是fragment，一探究竟。

我们发现initList发送了请求。没错就是这个方法。往上看

嘿嘿，找到了！看这里有个他在最后追加了个key ，我们不知道这个Key 是怎么也算不出来正确的md5的。

这里还用到了一个方法。stringSort(),跟进一探究竟。

潦草的调用图，先调用sortMapByKey，将参数来了一个按字母排序。

然后就拼装，参数 品装成appid=123&cate=22& 这种形式。

注意最后，返回的时候截掉了最后一个&

最终的形式应该是这样的

验证以下请求自动生成的sign

我们手动生成的sign

一毛一样。大功告成！

爬个虫测试一下

---

总结

本篇继续上篇通过一个APP产品，简单阐述的实践中对产品进行安全分析的方法。
对产品进行反编译，对代码进行审查分析，寻找到了产品生成签名的关键方法。大大降低了产品的安全性。

在“移动应用安全”实践中，我们不仅要保证应用业务逻辑上的安全性
如:把全部的图片地址都发送给前端，由前端判断是不是会员才显示。这样很不安全。
同时也要保证代码的安全性。
如：代码应该混淆，加固等加大破解难度。

自此，整个应用分析完毕。完结撒花~~~
再次说明：作者不赞成也不鼓励任何人对任何软件产品进行恶意反编译及分析。对于本次分析出的源代码及应用内资源已做删除处理。