171219 JarvisOJ（DebugMe）（1）

1625-5 王子昂 总结《2017年12月19日》 【连续第445天总结】
A. JarvisOJ-DebugMe
B.
JarvisOJ上的题…真是让人痛苦又快乐着，每题都挺难的，但是又能学到不少东西，但是WP难找真让人头疼OTZ强迫自己学习呀这是

拖入IDA反编译，发现是Elf的动态链接库
所以动态调试就比较麻烦了(:з」∠)还要自己写个程序加载它

main函数很直接，要求有2个参数

之后提取了password对其进行了一次异或加密
下面对两个signal绑定了回调函数
信号值查询可得

SIGSEGV 11 Core 段非法错误(内存引用无效)
SIGBUS 10,7,10 Core 总线错误（内存访问错误）

都是内存访问的错误，相当于SEH吧
这个回调函数sub_D90等会儿再说

接下来初始化了v20和v19的空间，通过decrypt1函数解密了unk_213D处的字符串
加密方法是很简单的异或，仿照进行提取和操作即可还原
再往下走，发现取得了ppid后与刚才的字符串组合起来作为文件名打开了
读取其中的内容后

查找其中是否存在v15，即另一个加密字符串，还原出来发现是sh
查资料发现这个地址可以取得该进程的命令行参数
查找其中是否出现了”sh”
若有则对password进行解密

感觉应该是反调试，查看是否是由shell开启的进程……？
如果是调试器开启的话大概命令行里没shell吧…（但完全可以在命令行参数里、文件名里加入sh啊
甚至还可以自己对password进行一次加密，反正异或是很简单的可逆……

这个手段莫名其妙的脆弱啊…

然后是关键函数sub_C14

同样是对字符串进行了加密，虽然解密函数变了，不过原理还是类似的
发现是另外一个文件位置，查询

也是反调试，不过这次的资料表示应该是Android系统下的

无视掉这些会导致return异常的东西，下面对v3，即参数a2进行了switch：

很明显的判断相等，关键在于之后的迭代选项
将v3送入sub_EAC中进行运算，然后以v10赋值过去
这里的v10不知道是哪来的，查找声明表发现是R1寄存器
猜测是刚才的sub_EAC的返回值，将其中的核心计算函数sub_E14完整dump下来进行运算，发现并不能生成8个字符就会跑飞进default

查看汇编发现在sub_EAC中调用完核心函数后又对R1和R0进行了运算

对ARM不够熟悉，所以没追出来栈顶是什么..
于是v10的计算方法到底是什么就不知道了(:з」∠)

另外
刚才的回调函数

也是调用了sub_C14，区别在于它的a2参数为0，而main函数中的sub_C14的a2参数为7
这样的话解密循环开头是不一样的…

而且其中的加密字符串又存在着相同的成功和失败提示，不知道这里是不是真正的出口

原程序中没发现哪里会触发内存访问错误的..

下次考虑下加载库来动态调试吧..
CFF2016太小众了找不到WP好难过啊TAT

C. 明日计划
加密与解密