171227 逆向-JarvisOJ（Shell）

1625-5 王子昂 总结《2017年12月27日》 【连续第453天总结】
A. JarvisOJ-Shell
B.
这个64位的upx+golang真是够折腾人的..

首先查壳，发现PEiD直接罢工了，我还纳闷儿，明明都能运行了咋还不是有效的PE文件捏
然后ExeInfoPE才告诉我这货是64位文件

拖入IDA发现什么都没识别出来
但是通过区段名能看出来是UPX壳

然而掏UPX程序出来却报checksum error
还好UPX手脱难度不大

按照ESP定律轻松找到OEP
接下来就只能一个函数一个函数日了
找到输入函数sub_4643F0，但是一次只能接受8个字符，好像还有一些缓冲区什么的
来回断点调试，发现封装函数sub_464D00，它出来以后内存中就有完整的输入字符串了

对首字符下内存断点，跑起来~

然后就结束了(:з」∠)

难道是之间听说过的Ring0级的内核调用API，所以Ring3的调试器断不到嘛？
不能这么轻易放弃，再思考一下

除了直接校验input内容以外，还有可能进行先行其他校验
比如首尾字符、哈希、长度校验等等

考虑到读取断点没有断到，猜测是长度校验
于是在函数外单步运行调试，观察寄存器中出现的跟测试字符串长度相等的值，注意它被保存到内存的哪里去了

反复改变长度调试以后，最终确定了这里

上面的CreateFileW、GetFileType和ReadFile有点让人在意呢~
WriteConsoleW很明显就是在向控制台输出内容的API了
所以说没事翻翻内存的上下文也挺有好处的233毕竟堆都在一起

言归正传，找到长度以后࿰