今天这个CM估计是XP2000以前的老东西了,在很久以前的lstrlenA函数可能和现在的不一样~那里不一样?现在的会影响除了eax之外的寄存器,或者说在我的机器上会发生这种影响(已知我从来没有修改过kernel32.dll ),如果你也遇到过这种问题的话…
总之在我的机器上调用strlenA返回值除了eax==ASCII`s Len之外 还有一点就是ecx==addr strlenA+SZIE(strlenA的函数代码宽度)
由于这点问题直接导致了我今天的困扰 所幸现在已经解决~这也就是今天这个CM的关键所在~
首先看这个CM的DASM原版:
在红色代码处 函数返回后 发现eax==Len ecx==0x7C80BE56+0X30==0X7C80BE86
其中0x30是在我机子上strlenA的执行代码长度,0x7C80BE56是strlenA的地址~
这段代码是属于今天这个CM的算法之内 起初我还以为作者取API函数地址加入CM算法 实在高明 后来写逆算法的时候发现 完全不是这么回事~
再翻翻作者给出的答案 发现其实上面那句 xor ecx,ecx才是作者意图
附近中有原版和加入补丁后的正确版本~注册机针对修改后版本…
而跟踪一边lstrlenA的运行会发现…一下三句:
pop ecx
…..
push ecx
retn
这说明啥 说明函数把ecx当作保存返回地址的寄存器了…所以返回后ecx才会等于 addr lstrlenA+他的运行长度
一组可用Key:
shadowkong
C81+6>
CM隐藏控件属性:Name输入必须是字母!
DownMe KeyGen