2015年AliCrackMe中第一道题的分析
2019-08-15 20:52:40 Author: bbs.pediy.com(查看原文) 阅读量:160 收藏

[原创]2015年AliCrackMe中第一道题的分析

2天前 245

[原创]2015年AliCrackMe中第一道题的分析

前言

的而且确,对于这个题目的逆向网络上已经有很多案例,逆这个CrackMe难免有照猫画虎的嫌疑。不过新手总要找点什么来验证自己的技术的。

逆向过程

首先拿到这个apk,就上模拟器跑跑看吧。

可以判断是一个验证码类型的CrackMe。

细节的数量还不足以让我们得到验证码,还得获得更多的信息。

解压缩apk文件, 得到下图所示的文件。

发现有一个asset文件夹。以一个只有获取验证码的模块来看,需要额外的资源吗?

当然重点还是dex文件了。打开JEB3.0,把dex文件拖拽进去,看来解析成功了。

首先看看入口函数里apk安排了什么工作:

这里主要的工作是处理按钮的点击事件回调函数,然后在这个函数中处理验证码了。v4和v5根据函数名可以猜测是从图片中得到的数据。点进getTableFromPic: 


流程只有3步:打开资源、从89473位置拷贝一段长度为0x300的数据、编码成utf-8,就返回了。返回值是这段utf-8的数据。

另一个函数getPwdFromPic,功能大同小异,也是打开资源从某个位置读一段数据出来编码成utf-8再返回数据。只是位置和数据的长度不同而已。

返回的Table和Pic,已经被打印出来。可以直接看到。打开虚拟机和cmd,然后在黑框中输入adb logcat | findstr lil。现在还没有数据。运行目标APK,点击一下那个显示着“登录”的按钮,黑框就有内容显示了:

出现这样的乱码并不是命令行的错,只是控制台默认的编码不是utf-8而已。是的,刚刚的两个函数getTableFromPic和getPwdFromPic在返回前已经把返回值编码成了utf-8了。这样的情况下要先CTRL+C停止重定向,然后cls,输入,再次输入adb logcat | findstr lil,重启目标app,点击“登录”按钮,黑框中就有如下内容:

这下得到的信息就比开始的时候丰富得多了。

现在就剩下寻找出图中pw和table的关系了。而这种关系的判断,只能在bytesToAliSmsCode这个函数里了。只有它在获取pw和table后,而又在判断pw和table的关系之前。

不出所料,这里对输入的注册码做了简单的加密,让注册码的每一个字符来做索引,用于在byte类型的数组中取出一个byte,再存到StringBuilder类型的v1中,如此循环。最后返回v1的toString()函数的返回值,也就是String。

这个函数返回后,就在命令行中打印出来了,标识符是“enPassword”。

上图中的v2是加密后的用户的注册码,那根据下图的代码,注册码要和函数getPwdFromPic的返回值v4来做比较。

在if的条件语句块中可以看出v4使用equals函数与v2做比较,比较的结果不用说,肯定是相同则显示成功,不同表示失败了。

根据现在得到的所有信息,足以说明解密的要素了:

1.      上图中倒数第二行的“义弓么丸广之”就是正确的验证码加密后显示的信息,它的每一个字都是从它正上方那个超大数组中索引出来的,

2.      而用来索引的下标就是用户的验证码的所有字符的ASCII码。

3.      所以只要根据数组元素和下标反过来算出对应的下标就是正确的验证码了,如下图所示:

“义”字在表中是唯一的,它在表中的位置是54,根据ASCII表可知他对应的ASCII码是6,以此类推可以得到结果692137。启动目标apk,在其输入框中输入:

也许是数组下标应是从0开始,所以重算了注册码,得到581026。


[招聘]欢迎市场人员加入看雪学院团队!


文章来源: https://bbs.pediy.com/thread-253834.htm
如有侵权请联系:admin#unsafe.sh