原标题:当你写爬虫遇到 APP 的请求有加密参数时该怎么办? [初级篇-秒杀模式]
当你写爬虫遇到 APP 的请求有加密参数时该怎么办? [初级篇-常规模式]
当你写爬虫抓不到 APP 请求包的时候该怎么办? [初级篇]
当你写爬虫抓不到 APP 请求包的时候该怎么办? [中级篇]
当你写爬虫抓不到 APP 请求包的时候该怎么办? [高级篇-混淆导致通用 Hook 工具失效]
觉得文章质量不错的朋友可以关注一下我的公众号,二维码在此:
1
yzkcy 2019-06-19 10:35:36 +08:00
关注了。
|
2
rocketman13 2019-06-19 10:43:50 +08:00
刚刚拿币世界 app 试了一下,真的直接就秒掉了,之前搞了一个星期都没搞出来,大佬牛逼
|
3
David1119 2019-06-19 10:47:23 +08:00
稍微大点的 app 都是 so 加密,需要上 frida+IDA
|
5
locoz OP @rocketman13 #2
|
6
ZeroW 2019-06-19 10:48:10 +08:00 via Android
收藏了
|
9
warcraft1236 2019-06-19 12:19:25 +08:00
有混淆就不太好使了吧
|
10
locoz OP @warcraft1236 #9 标准库好像没有混淆的说法?
|
11
explorerEX 2019-06-19 13:18:14 +08:00
@locoz 请问有哪些无法破解 app 接口的情况
|
12
ghos 2019-06-19 13:28:58 +08:00
额 挺好的 起码有点料 比转来转去的公众号文章强多了
|
13
ColinWei 2019-06-19 14:16:06 +08:00
可以爬手机淘宝的搜索吗
|
14
locoz OP @explorerEX #11 你指的是初级篇无法破的情况?
|
17
akmmmmm 2019-06-19 14:33:34 +08:00 via Android
对这个表示怀疑,现在哪个大公司不是 so 混淆的,逆向领悟的高质量文章也基本都是 so 相关的,不过这个思路不错,可以一试。我也一直有个疑问,能不能有一种通用的做法,自己修改安卓源码然后编译,做到直接调用 app 里面的函数的目的
|
18
ochatokori 2019-06-19 14:39:39 +08:00 via Android
学到了
|
19
locoz OP @akmmmmm #17 首先注意标题,这是初级篇,so 库相关的内容在高级篇中,然后大公司的最新版 APP [通常] 是不属于这 80%以内的,注意通常这两个字,并不是说就是完全安全的,总会有些有遗漏或者是没处理好的地方。然后 Hook 思路挺常见的吧,通常对 so 库逆向的时候也会用上,只不过一般没办法做到这种通杀的效果。
至于你所说的直接调用 APP 里面的函数这种操作,是可以实现的,而且不重新编译系统也可以做到,但是很难达到通用的效果。 |
20
locoz OP @ochatokori #18 感兴趣的话可以关注一下哦
|
21
brotherlegend 2019-06-19 14:45:03 +08:00 via Android
大佬威武 学习
|
22
locoz OP @brotherlegend #21 谢谢~
|
23
slamDunkLINk 2019-06-19 15:33:25 +08:00
关注了
|
24
locoz OP @slamDunkLINk #23
|
25
bridgeca0 2019-06-19 16:28:00 +08:00
公众号和专栏已关注
|
27
zdnyp 2019-06-19 16:43:41 +08:00
提问:
倒数第三段:`看到了吗?直接就得到了它的原文:brand=Xiaomi&device=capricorn&model=MI 5s&ts=1560859682&version=8.1.0 了,轻轻松松地就破解了这个 APP 的 sign 参数,全程只用一分钟!` ‘原文’就是 sign 的生成方法吗? |
28
warcraft1236 2019-06-19 16:47:55 +08:00
@warcraft1236 我是说安卓的代码混淆
|
29
locoz OP @zdnyp #27 你看一下那张图里高亮的那一行,最左侧有个 MD5,说明这个 sign 是使用 MD5 算法处理出来的,也就是 sign 的生成方法,而原文就是字面意思,Hash 前的原始字符串
|
30
locoz OP @warcraft1236 #9
@warcraft1236 #28 这篇文章中所说的方法是对标准库里的方法进行的 Hook,目前还没见到有混淆标准库的,也搜不到相关资料,应该是没办法做的,而 APP 自己的代码里再怎么做混淆,只要它需要调用标准库中已经被 Hook 了的方法,就会被爆出来原文和操作方式,这样解释可以理解吗 |
31
zdnyp 2019-06-19 18:00:09 +08:00
@locoz 不知道是拿哪些参数做的 MD5 计算,比如用`brand=Xiaomi&device=capricorn&model=MI 5s&ts=1560859682&version=8.1.0` 做 MD5 计算,得出 sign
|
34
claysec 2019-06-19 19:10:45 +08:00
准备学习!感谢分享
|
35
mv0x 2019-06-19 19:59:18 +08:00
《网络安全法》了解一下
|
36
mrcn 2019-06-19 20:37:38 +08:00 via Android
有点东西,关注了!
|
37
locoz OP @mv0x #35 了解过,但是我这是破解自己的 APP 哦😁后续也不会写针对某个非我名下的平台的逆向文章
|
40
koodai 2019-06-19 22:08:29 +08:00 via Android
强势!明天就去实测。🍉
|
41
alphatoad 2019-06-20 08:36:55 +08:00 via iPhone
我记得以前扒 b 站的方法就是直接调用 so 的接口
|
43
locoz OP @alphatoad #41 你说的以前是啥时候。。我记得 18 年以前 B 站 APP 的 sign 就是个 md5 ?
|
45
explorerEX 2019-06-20 10:32:39 +08:00
@locoz 就是写接口的改怎么加密才能完全无法破解呢,期待出一篇高级加密的文章。。。
|
46
dahounet 2019-06-20 11:00:28 +08:00 via Android
好东西,收藏了
|
49
locoz OP @explorerEX #45 哦哦,懂你意思了,你是说作为服务方怎么样才能让别人无法破解是吧?
这个问题其实是无解的,只能提高攻击成本,不能做到完全无法被破解。而且这一块跟提供接口的后端没啥关系,主要是在客户端这一块的反破解和在后端前面的风控 /流控层来做。 现在主流手段都是加固、混淆、虚拟机,依靠复杂度极高的代码来掩盖获取的客户端信息,然后依靠客户端信息(比如设备指纹)来做风控,只要发现操作有异常就就直接做限制,最严重的情况就封账号、封 IP 了。 |
51
locoz OP @alphatoad #47 私钥是指?我记得只是有另一个写死的、长得像 md5 的字符串作为盐加进参数字符串里做 md5,出来的就是 sign 了,可能你说的那个版本要更新一些。
|
52
maplejaw 2019-06-20 12:17:13 +08:00 via Android
js 混淆有啥办法么?
|
54
smilev587 2019-06-20 14:09:15 +08:00
大佬知道瑞数加密么
|
56
haohh 2019-06-20 15:14:23 +08:00
扫了一下 我居然早关注了 hhh
|
57
lzvezr 2019-06-20 15:58:38 +08:00 via iPhone
果然是 Inspeckage,建议配合 Android6.0 使用,至少我之前用 7.0 是有一些 bug 的
|
59
locoz OP @lzvezr #57 Inspeckage 这种东西很多人都不知道的,话说我这之前用 7.1 的时候没遇到什么 BUG,8.0 用着倒是 BUG 挺多的,可能跟 Xposed 版本也有关吧
|
60
LanAiFaZuo 2019-06-20 17:16:12 +08:00
楼主有没有微信啊?
|
61
koodai 2019-06-20 22:54:14 +08:00 via Android
大佬,微信上请教您,可能忙的没顾上。
我想问一下,我的目标 APP 签名在 get 参数中,目测是 base64,字符长度 40 个以内(没仔细数,但不长),按照文章中的方法搜索不到结果字符串。日志中有大量 aes/cbc/padding17 之类的信息,IV 也可以看到。加密要素应该是设备 id 之类的。这个 APP 接了 jpush 和 bugly,信息非常杂。 遇到这种情况应该怎么解决?能不能详细写一篇文章 |
62
locoz OP @LanAiFaZuo #60 公众号后台发个消息,我给你发二维码,直接发这里的话加的人太多了
|
63
locoz OP @koodai #61 今晚剪头发去了,没看后台。你的这个我觉得可以先 base64 decode 看一下内容,如果能解出来但是是乱码的话大概率是 AES/DES 之类的对称加密,但是日志里如果很多同类加密的话会比较难区分,建议反编译搜一下参数名找找线索。
|
65
lzvezr 2019-06-21 10:02:55 +08:00 via iPhone
@locoz 折腾过 xposed 的,抓包看到加密第一反应肯定是利用 xposed 进行 hook。没折腾过的以 Android7.0 抓包为关键字也会得 justTrustme 或 sslunpinning,而 sslunpinning 和 Inspeckage 是同一个作者,并且在 sslunpinning 的 GitHub 上也有 Inspeckage 项目的介绍。这种随便网上一搜就有的东西,居然这么多搞逆向搞抓包的人都不知道,看起来我确实高估了大部分人使用搜索引擎的水平
|
66
lzvezr 2019-06-21 10:10:36 +08:00 via iPhone
@lzvezr 想了一下,也不能说的这么过分,毕竟你也是推广的微信公众号,这部分不可能被搜索引擎抓到,下一次再有人搜索 Android7.0 抓包也不能引流过去
|
68
locoz OP @lzvezr #65 很多人其实连 xposed 是干什么的都不知道的,而且你搜一下这方面的东西其实会发现满屏的 [教装抓包工具的证书] 的教程,然后如果搜抓不到包之类的关键词,很多内容也只是说 android 7.0+的原生 ssl pinning,但是对第三方 http client 的部分基本没有,最多说用 justTrustMe 可以解决。然后 sslunpinning 的名气似乎没 justTruseMe 这么大,很少看到这个名字被提起,所以 Inspeckage 不怎么被人知道也挺正常的。
|
69
wtebug6 2019-06-21 15:11:31 +08:00
@locoz 楼主,你好,请教一下,我从一个 APP 抓出了一个请求,直接在 fiddler 里复制发送这个请求会鉴权失败跳转到登录链接,不能返回正确的结果。我又尝试了把 APP 里发出的请求在 fiddler 里打上断点不让它发出,然后复制请求并发送结果仍然鉴权失败。这种情况有没有什么建议思路?
|
70
locoz OP @wtebug6 #69 你这个问题最好是附上截图,要不然只能盲猜。。
根据你的描述我可以猜到三个可能: 1、直接重发请求会返回鉴权失败,原因是 sign 不允许复用,所以第一次正常请求被接收了之后,sign 就失效了。 2、拦截 APP 发送的请求不让他发出,然后“复制请求并发送”,这一步的“复制请求并发送”我不知道你具体是怎么做的。 如果是直接在 Fiddler 中操作重发的话,有可能是因为时间太久了,也就是跟请求中所带的时间参数有关;如果是在自己写的代码里发送的话,时间太久同样有可能,但更可能是你发送的姿势不对,发出去的东西和正常的长得不一样。 3、第一次直接重发请求之后就已经被服务端做了限制,所以第二次才会失败,但是这个概率很低,毕竟容易误伤。 |
71
Bakarua 2019-06-21 15:27:46 +08:00
有点东西
|
72
wtebug6 2019-06-21 16:51:49 +08:00
@locoz 感谢回复,第二点我试了,应该和时间无关,因为我隔了很久在 fiddler 里把断点恢复后,被暂停的请求还是能顺利通过鉴权。我在 fiddler 里比较了请求头,是一模一样的。困扰很久了。
APP 发出的请求和响应: https://i.loli.net/2019/06/21/5d0c970d132cd51915.jpg 我用 fiddler 发出的请求及响应: https://i.loli.net/2019/06/21/5d0c972fa474645799.jpg 请求头: https://i.loli.net/2019/06/21/5d0c9a407ce9036838.png |
73
locoz OP @wtebug6 #72 你的这个截图还是看不出啥哦。。然后你自己用 fiddler 发请求的时候,是用的那个 replay 功能吗?如果是的话不应该会出现返回不一样的情况啊
|
75
yepinf 2019-06-22 09:25:03 +08:00
已经关注公号
哈哈, 大佬多更新点奇淫巧术 |
77
happyhou 2019-06-22 16:54:12 +08:00
精品文章
|
78
happyhou 2019-06-22 16:54:27 +08:00
精品文章 good
|
80
nnnToTnnn 2019-06-24 15:59:00 +08:00
其实我不太明白,爬虫这部分,如果加上一个 reCaptcha 会怎么样? ヾ(=゚・゚=)ノ喵♪
|
83
ColinWei 2019-08-05 15:25:08 +08:00
|