揰掵佲 发表于 2017-7-15 22:41:07

某WX插件的验证机制的分析


本帖最后由 djcsdjcs 于 2017-4-29 00:14 编辑

首先来个声明: 本文为论文性质,请勿转载;本文仅学习讨论加密解密技术,勿用于其他任何用途,否则与本人无关!为了避免不必要的麻烦,屏蔽相关软件的名字。
    有朋友请我研究一个WX插件的验证机制,一直没找到整块时间,回头想起来这个事花了点时间看了看,很简单,不过插件已经过气了。记录一下逆向过程,开始吧!插件为DEB格式,解压后出现了一个application和三个dylib,安装后会弹出一个UIAlertView,要求输入用户名和验证码,随便输入一个会弹出注册失败。好,就从这个UIAlertView入手,因为它的initWithTitle跟这个DEB包的名字是一样的,根据这个去定位相关函数,把三个dylib和一个application都扔进IDA,查看输入表,找到OBJC_CLASS___UIAlertView的交叉引用,最后确定一个z开头的dylib里负责弹出这个UIAlertView,代码如下:
https://attach.52pojie.cn/forum/201704/29/001303b2wwzwxogvv2isst.jpg
我用的是IDA6.8,里面的Unicode支持不好,使用相关插件后,会自动在注释中标上对应的中文,但是跟心中期望的直显中文还是有所距离,没有6.9也没办法,我凑合用大家凑合看吧。
再去找消息响应函数,代码如下:
https://attach.52pojie.cn/forum/201704/29/001326uwtm9bmncewtv5vw.jpg
我们来看一下dispatch_after的官方解释Enqueue a block for execution at the specified time.
可以理解成在指定的时间执行代码块,至于代码块,IDA已经帮我们分析好了,就是这个block_invoke。IDA为了表述方便吧,他重新定义了一个函数表示这个代码块。那就去看这个block吧!
https://attach.52pojie.cn/forum/201704/29/001341klz9svssyas1v30h.jpg
翻译一下:鑜孮1"就是注册失败,看一下text也挺清楚的,左边成功,右边失败。
https://attach.52pojie.cn/forum/201704/29/001342psfj08asjq0a8zsh.jpg


接下来就是去分析那个V8啥时候为1(注册成功),代码很清楚:checkUID textFieldAtIndex.textencrypt(getuuid())。验证你输入的验证码和一个加密了的uuid。getuuid顾名思义,
https://attach.52pojie.cn/forum/201704/29/001342ewwwnvz12vb2hfod.jpg
接着去看看encrypt
https://attach.52pojie.cn/forum/201704/29/001342a2333fff355ccfgc.jpg
看起来很清晰,uuid先经过utf8编码,然后做MD5,把HASH值打成string再统一大写。这样看下来其实不是加密,编码而已,checkUID的俩参数都搞清楚了,再去看看这个方法
https://attach.52pojie.cn/forum/201704/29/001343ymn9exqcxy0xjwyx.jpg
打开一看有些篇幅,分析分析啊,看字符串的样子,明显是base64编码过的,注意代码中的这行v10 = objc_msgSend(v9, "initWithData:encoding:", v8, 4);这个4其实是

https://attach.52pojie.cn/forum/201704/29/001343ic2q2arlmlq77q6f.jpg
确定是标准的BASE64解码,解码后其实是一个URL地址,就是验证服务器的。接着往下看,向这个地址发起了一个HTTP请求,把那个“加了密”的UUID和我输入的验证码统统发给服务端验证,然后在response里面找code,这个值就是服务器的验证结果。到这里这个验证机制就分析清楚了,这个插件的验证太简单了,方法名没混淆,连个像样的加密算法也没加,严阵以待的LLDB都没用上,就当给刚刚入门的朋友们增加信心吧。On the last,我顺便看了看其他dylib的代码,发现这套验证也是HOOK了其他人的验证,贵圈真乱啊。。。。

阿炮 发表于 2017-11-17 23:31:13

希望多出点IOS相关的帖子
页: [1]
查看完整版本: 某WX插件的验证机制的分析