看雪iOSCrackme破解报告

By xia0

看雪iOSCrackme破解报告

0x01.首先,利用classdump把crackme的头文件导出来,可以看到头文件只有6个,根据屏幕上的check按钮,很容易在控制器中找到如下函数

pic

0x02.然后将可执行文件拉入IDA分析,直接跳到check这个函数。可以猜测这个函数应该就是加密函数。下面重点对这个函数进行详细分析。

pic

0x03.在分析之前,先在手机屏幕上直接点击check,无反应。然后输入一定字符后再点击check,仍然没有反应。没有一点的错误提示,看来只能一步一步看汇编了。在IDA中先大概看下流程图的结构,拉到最底下,发现貌似成功的界面

pic

不管怎样,先试试直接跳转到该地址,看能不能弹出成功的界面?: /

pic

修改为B 0x0000C1AC 然后再屏幕上点击check,成功弹出welcome to kanxue的界面!再接再厉,看看中间都经历了什么步骤。

pic

0x04.下面进入汇编,第一阶段,根据strlen函数很容易知道,这是在对用户输入的字符串进行长度判断,若不满足情况,直接跳到失败代码。name为14位,serialnumber为8位

pic

既然是逆向工程,所以先分析下在弹出这个界面前的代码都在做写些什么,r11为我们输入的serialnumber然后可以发现如果栈中的值和serialnumber8次匹配成功就会弹出成功的界面。

pic

0x05.一段插曲,不知道是程序自身的原因还是手机的问题,在一步步向下调试的时候,发现内存非法访问,为什么会出现这个问题呢?向上找的时候,发现这样一条指令MOV PC, PC按理说,根据arm处理器流水线的处理机制,PC会指向当前的下面两条指令,所以执行这条语句后应该会跳到VDUP.8 Q9, R1指令.

pic

但是实际情况却是把拆成四条指令,并把r0的值变为了0,导致r2变化,从而非法访问了r2地址的内存。

pic
pic

所以为了让r0的值不改变,之前都是通过每次动态修register write $r0的值,导致每次调试都要在那两处下个断点,浪费了很多时间。后来直接把静态修改重新打包安装到手机,lsls r0 r0改为nop代替,同理下面还有一处,作相应的修改。

pic
pic

0x06.回到我们之前的分析,现在开始加密阶段,首先进入的是下面的一个循环

pic

r0的值为栈中的某个地址,d18-d19的值为00-0f,然后循环了16次,每次都对d18-d19加一,所以循环结束后在栈中生成了一个16*16大小的矩阵,且值为00-ff.

pic

0x07.接着往下面分析,又是一个循环。循环了256次,可以猜测应该是对上面的矩阵进行变换,分析可以发现这个循环通过r9(0xaaaaaaab)和r1相乘结果来对矩阵中的值进行交换。

pic

在循环的结束的下一条地址下个断点,打印对应的内存,验证了我们的猜想。

pic

我们之前的分析中好像还没有和我们输入的name和serialnumber有什么联系。接着分析,这个循环终于对name进行了存取操作,通过四次循环把name的前四位取出来与之前的矩阵加密后又放回到name的前四位。

pic

内存图:

pic

下面这一段有点繁琐,各种跳转,但是并不复杂,就是通过判断加密后的name的长度然后复制到栈中地址r8处。

pic

接着又是一个循环,分析可知是对r8即刚才复制加密name后的内存进行每四位反序变换。

pic

内存图:

pic

keep going!这一段不是很复杂,就是把刚才变换后的首地址r8向下的64个字节复制到内存栈中[sp 0x50]处。后来得知从这个地址到r8后的内存就是整个栈变化的结束,后面的四个循环并没有进行栈的存操作,只是将这块内存的值取出来加密。

pic

内存图:

pic

下面的四个循环很相似,都是将那块内存每次提取80个字节进行加密。刚好有80*4=320与内存块的字节数相同。

pic
pic

然后将这之后的寄存器值与对应的值相加spintf按%08x%08x%08x%08x%08x的格式写入栈。

pic

最后对栈进行了5次存储,与后面分析可知这段内存就会与serialnumber进行匹配。

pic

0x07.根据上面的步骤写出代码,注册机为一个命令行程序,运行程序会提示如数14位的字母和数字的字符串,然后根据此就会生成对应的serialnumber。效果图如下:

pic

在手机中输入生成的name和serialnumber弹出成功的界面!

pic