一个360CM分析

ollydebug

CM截图。

载入OD，按钮事件到达这里。

一路F8，来到这里，发现是个解密call，是拿我输入的用户名ollydebug hash后的值当成key然后去解密。

而且在解密call中的末端，看到了一段代码，地址为004065C0，看注释好像很重要，所以F2下断。

继续F8，看到一个createthread。


转到00406C90，走过sleep的时候在之前我F2的地方断下了，果然肯定在其中有hook存在（跟上次那个CM很像）。


然后我们开始分析，首先是开辟一些空间，然后readfile读取自身，计算crc32，然后再次当成key解密一段数据。然后继续跟踪，在这个call里，发现了重要的事。

首先开辟一段空间，大小为0x20000，而且反复检测是否开辟成功。然后用这个call来copy一段数据。

然后virtualprotect加上权限。

之后又call eax，来到了一个dll，地址随机。在这个时间，这个地点，谁都知道这肯定是关键call，所以F7进去看看。


F7进去后，发现他在自解密。

那好吧，先让它自解密完毕。然后在代码段开头1000 F2，然后就断下来了，而且还发现了MD5值，所以再次判定这是关键位置。

然后对这个数值下硬件访问断点，F9 F8几次后来到cmp这里。

我靠，竟然是明码比较。原来刚才那个就是密码呀！因为内存是从右到左，所以密码是反着的，所以，得到了一组key。
用户名：ollydebug
密码：8cbb2375ed5fa457f73f
输入进去，Success！

另外，004065C0这个调用位置如下。

这个API是检测调试器的，1为yes，0为no。而下面是关键位置call，只有1才可以进入。所以还是跟上次那个CM一样，只有有调试器才可以进入。
以上就是我的分析，本人菜鸟，有错还请大家多多包涵。另外两次调用解密call分别用hash用户名和crc32解密的数据我也没有跟踪，有时间我还会调试的。

ollydebug

蚯蚓翔龙 发表于 2015-7-1 21:38
不会一看就知道密码是倒着来的吧。。。

内存存储从右到左
假如假玛为1234123412341234，真玛为8765876587658765，在内存里对比为1234对比5678,1234对比5678,以此类推。所以你看到的真玛为5678567856785678，实则不然。就像寄存器显示的那个就是不对的。

蚯蚓翔龙

ollydebug 发表于 2015-7-1 21:51
内存存储从右到左
假如假玛为1234123412341234，真玛为8765876587658765，在内存里对比为1234对比5678,1 ...

大小端存储我知道有这样情况，我只是看堆栈的，对比方向不一定跟存储方式一样吧，会不会正好是反过来比较真码的或者真码存储就是反着来的呢

蚯蚓翔龙

不会一看就知道密码是倒着来的吧。。。

Norton

学习一下

segasonyn64

感谢分享教程，学习！！

monkeyye

看起来不错，感谢分享

ollydebug

蚯蚓翔龙 发表于 2015-7-1 23:33
大小端存储我知道有这样情况，我只是看堆栈的，对比方向不一定跟存储方式一样吧，会不会正好是反过来比较 ...

反正我认为这个CM的对比就是跟存储方式一样的

ollydebug

蚯蚓翔龙 发表于 2015-7-1 23:33
大小端存储我知道有这样情况，我只是看堆栈的，对比方向不一定跟存储方式一样吧，会不会正好是反过来比较 ...

http://www.52pojie.cn/thread-330242-1-1.html 这个CM有些地方和他一样的，比如hook和isdebuggerpresent

Hmily

这个是临时用上次的改吧改吧弄的，把cm传上来吧，总觉得你这分析花挺多时间，为啥帖子写出来总是不够精华的赶脚了？想想怎么详细写写。