a）
----------
通过对libdvm.so中dvmUseJNIBridge方法下断点，可以获取check方法动态注册的地址，相对于基地址偏移是0x19c38。在此处下断点，程序运行起来之后使用ida attach上，输入数据并点击按钮后准确断在这里。


b）
----------
b.1 静态分析so基本无法获取信息，动态跟踪时使用了anti-ida的一些技巧，比如将下一条指令的十六进制读取到r1中，然后由于调试器的原因，读到的数据并不是实际的数据，在后面使用时就会出现问题。
b.2 动态调试中出现最多的是花指令，形态类似于一个switch-case结构，处理分支有七条，常用的是第一条，第二条，第四条，第六条，第一条第一条跳出地址偏移好像是0x1f78，第六条跳出地址偏移大约是0x205c。七个地址相邻。每一个分支都会根据输入的一个0-0x200的数据去计算新的pc地址。其中系统调用如strlen，free，strcpy等多是通过第二条分支计算得出。

c）
----------
调试过程中有多处类似调用函数入口的地方。

d）
----------
推测是4位。依据有两个，第一个是程序应该使用的crc32相关的算法；第二个程序中有一段指令是对一个buffer进行循环异或操作（根据实际执行结果得到，实际上是使用了三条指令去完成的）。根据编码后的buffer及后续对buffer的使用，猜测可能是4位，尝试暴力破解，未完成。

e）
----------
运行过程中出现了sigsegment之类的异常。

f）
----------
未关注

g）
----------
不确定

h）
----------
应该是crc32，将程序执行起来之后对so进行dump，可以找到crc32算法所使用的mtable。



i）
----------
程序逻辑：

i.1 通过跟踪可以看出程序运行的一些信息，首先是对输入字符串做了一次copy操作，并在末尾补0。
i.2 调用了sleep、lran48等函数。
i.3 然后是大段的花指令，感觉在计算什么东西，但未看太明白。然后应该是做了一次crc32的计算，太长只在第一次跟进去调试了，输入输出未准确确定。
i.4 再之后准备逆推寻找返回结果来源，发现一段使用输入数据对指定的在栈中的一段数据做异或操作，长度为0x100，之后将输入字符串free，再后来从r6+0x18处取一个数据到r1，该值修改后会显示正确结果，但，分析过程复杂，逻辑无法统一，最终放弃。


手边没工作电脑，以上数据、过程均是临时回忆所写，详尽数据明天上午将会在此提交。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！

上传的附件：

• crc32mtable.png （23.23kb，2次下载）
• encode.png （29.68kb，6次下载）
• check.png （10.50kb，6次下载）