最近在学习ARM汇编和逆向方面的基础知识,抽空跟着“无名”大神的逆向数据分析视频学习了一下,以下是本人在学习过程中的一些心得和笔记,还望各位大牛们指正。
PS:本人已对截图做了相应的打码处理,如有侵权或涉及敏感信息,还望告知,我会第一时间做出处理。谢谢!
一、抓包&反编译首先在登录时,抓包,看到相应的登录信息:
通过POST信息可以看到,除了时间戳、手机号码、经过MD5处理的密码以及deviceid外,有一个“sign”的认证信息,故本次逆向分析就是针对“sign”的HASH方式进行分析。
拿出Android killer对该安装包尝试反编译,顺利反编译,发现搜索“sign”关键字后的搜索结果太多,于是换了关键字“pawd”进行搜索后,发现只有两条结果:
根据名称可以基本定位在下方LoginRegisterManager这个方法中。
3.通过反编译后的java代码,顺着pawd向下寻找,于是找到“sign”的代码:
4.通过查看,可以得出sign是通过KeyGenerator的getsign方法操作后获取,于是进入“KeyGenerator”方法,可以查看到这里调用了动态链接库(System.loadLibrary "XX_key"):
二、so静态分析
1.拿出神器IDA,打开apk包lib目录下的libxx_key.so文件,首先下意识的在Exports中搜索关键字“Java”,查看是否有相应方法调用,发现并没有,于是需要通过JNI_Onload中去寻找相应方法,进入JNI_Onload后,F5查看伪C代码,代码相对比较简练,RegisterNatives此处为JNI环境注册Native方法的通用做法:
2.点击gMethods进入查看,这是一个典型的JNINativeMethod methods[]数组,通常是3个参数:
参数1:Java层方法名
参数2:方法的签名以及返回值为Java String类型 (Ljava/lang/String;)Ljava/lang/String;
参数3:为SO库实现的方法名,这里强制转换成了函数指针,会指向SO中的方法(generateKeyByParams)
3.点击第三个参数,进入到generateKeyByParams方法内,同样F5查看伪C代码:
4.发现伪C代码居然将generateKeyByParams的方法只识别了1个传参(上一张截图中可以明显看出该方法是有3个传参的),通过上一张截图可以得知,3个参数的含义:
参数1:Env指针
参数2:Java层类对象
参数3:用户输入的String
5._ZN7_JNIEnv17GetStringUTFCharsEP8_jstringPh ; _JNIEnv::GetStringUTFChars(_jstring ,uchar) 表示将java传入的string转换为C的string格式
6.通过对generateKeyByParams方法的分析,发现它在前面做了一些初始化的工作:
大概有40字节的内存空间初始化,然后调用了generate_key_by_value(v19, v4)这个方法
7.通过以上分析,我们可以初步断定,HASH处理应该就在generate_key_by_value方法内了
三、动态调试手机打开,adb shell运行android_server,运行APP,IDA远程调试连接,选中相应的APP进程
在module中通过查找“libxx_key”,定位到libxx_key.so,然后查找到“generate_key_by_value”,在其开始处下断点,运行
然后在手机上随便填写一个手机号码和12345678的密码,登录,此时IDA会停留在我们的断点处,根据前面所知,generate_key_by_value有两个传参,我们可以通过动态调试的方式查看R0,R1这两个寄存器中的内容,也就是说v19和v4两个参数了:
4.通过查看可以发现R0即为我们提交时的POST封包的一些数据,而R1则为内存初始化的一段空间,此时为00
5.此时记下R1的地址(我的是BEFF34E4,每个人会有所不同),然后在generate_key_by_value方法的结束处下断点,然后运行,IDA会停留在结束处的断点,此时在HEX-View处,按G,输入刚才记下的R1地址,查看R1寄存器中的内容:
可以发现R1的内容已经为HASH后的数据,将该段数据复制出来与抓包的sign数据进行比对:
数据完全吻合,此时可以肯定,generate_key_by_value就是HASH方法关键所在。
四、算法分析
1.为了分析HASH算法,可以在IDA静态分析中继续查看generate_key_by_value的伪C代码,通过查看代码,可以发现是典型的SHA1散列值函数组合生成
其大致的流程为SHA1Init()-->SHAUpdate()-->SHA1Final()
而代码中共调用了4次SHAUpdate():
SHAUpdate(a),SHAUpdate(b),相当于SHAUpdate(a+b),于是我们可以通过代码看到这4次调用,第1次和最后1次,分别有&v15的一串字符串“bi2ipxazqodmw9hoety0h1wwgjvkttng”,推断大致的HASH流程为SHAUpdate(&v15+v6+v8+v10+v12+&v15):
2.为了验证是否正确,再次结合动态调试,在第一处BL SHA1Update处进入到SHA1Update方法中,在开始处下断
3.APP再次登录,IDA会停留到SHA1Update断点处,查看R1寄存器中的内容,发现“bi2ipxazqodmw9hoety0h1wwgjvkttng”字符串:
4.再次运行,IDA会再次停留在下断处,再次查看R1寄存器中的内容,此时变为“deviceid”:
5.继续运行,依次查看R1寄存器中的内容,“mobile”、“pawd”、“timestamp”、“bi2ipxazqodmw9hoety0h1wwgjvkttng”及其相应数据:
6.然后在generate_key_by_valu方法的结束处下断,F9运行,在HEX-View中按G,查看之前记下的R1地址(BEFF34E4),将已HASH后的数据复制出来
7.然后将动态调试时获取到的“bi2ipxazqodmw9hoety0h1wwgjvkttng”、“deviceid”等数据放在一起,保证无空格、无换行,然后通过网上SHA1哈希后与抓包的数据比对,发现完全一致:
故之前推断的HASH流程完全正确。
未完待续,后面会补充SHA1Update()伪C代码分析的学习笔记。
通过两晚的学习,发现还是很有收获的,更加激发了逆向的学习动力,虽然已近不惑,凭着对逆向的热爱兴趣,一直以来都以自学和浏览帖子为主,很少有勇气发帖,希望通过看雪这个平台多与志同道合的朋友们交流,共同进步。