【作　　者】MulderW
【组　　织】自由人
【日　　期】2005-01-23
【使用工具】flyODBG V1.10正式汉化修改版, C32asm Ver：0.4.12
【平　　台】WinXP sp2
【目标程序】Magic WinMail 4.0（Build 1112）
【下载地址】（忘了）

【正    文】
        软件的作者似乎对自己的注册码验证过程很有信心，并没有对软件进行加壳，这也省了不少事儿。软件安装以后分为管理客户端和服务端，注册码以及可用邮箱数和可用时间期限都在服务端进行验证和计算。破解的过程颇费周折，所以想重点写整个破解过程的经历和思考的过程，作为经验积累，而不是简单的写出最后的结论。
        最开始是对管理客户端因为里面有注册对话框。对管理客户端进行反编译，根据对话框提示信息的字符串在反编译的结果中进行搜索，但是一无所获。上来就吃了闭门羹，这种情况怎么下断点？于是寻找其它办法，尝试利用消息断点，想在注册对话框点击“确定”的时候断下来跟踪，但是因为水平不够，断下来的地方根本就不知道是什么消息断的，往后跟踪也不知道到了哪里，这个方法又被否定了。后来无意中在此查找字符串看到了“MessageBoxA”，怎么在开始的时候没有看到呢？研究半天发现使用工具察看反编译的结果找的模块不对，没有看见这个字符串。结论：反编译工具使用不熟，浪费不少精力！经验总结：学会使用破解工具是很重要的一步，但是使用这些工具的经验是要进行破解练习才能取得的，对没有头绪的情况不能放弃。
        继续跟踪用到这个字符串的函数，也就是“MessageBox”函数，确实在进行注册的对话框被断下来了，而且也得到了结果“Invalid License”，但是跟进了无数的call却没有发现有什么地方是进行注册码验证的。这个过程中看到了这种字符串“<command>111610</command><licensedto>xxx</licensendto><licensevalue>xxx</licensevalue>”。思考：猜测管理端使用类似的命令串发个服务端，又服务端进行命令的验证，然后根据命令进行相应的处理。有这样的想法是因为在客户端可以进行其它的操作，例如添加用户邮箱，添加域等等操作。由管理端对用户的操作编辑成命令串发个服务端，服务端接受命令后，首先验证命令的有效性，随后进行命令要求的操作并在服务端进行相应的设置处理等。这种猜测同时可以解释在跟踪管理端时发现在命令串后跟有的“<cryptkey>”这种段。这个段应该是每次发送命令是都回附有一个，用于对命令的有效性进行验证的。
        接下来对服务端下手。首先使用OD动态的跟踪服务器端的启动过程，也就是从OD打开服务器端的程序一步一步走，这一步步跟进很深层的call，最多一层。然后发现启动过程只是启动了和邮件服务有关的东西，例如smtp、pop3等相关的服务，但是没有进行可用邮箱数、使用期限等等的验证。结论：应该是在管理客户端向服务器端请求连接的时候进行可用邮箱数、使用期限验证的。其过程是管理客户端先向服务端发送连接请求，通过命令验证后服务器端会返回相应的关于邮件服务器的信息，然后在管理客户端的主界面我们就能看到所有的信息。在管理客户端连接服务器后其主界面一般是停在“授权信息”这一项的，可以发现这里已经显示相应的授权信息。也就证明了上面的结论是正确的。经验总结：熟悉软件观察软件的注册行为，考虑每一个环节，要注意软件在运行过程中没有给出交互信息而被隐藏的环节。
        接下来是在对服务器端的反编译结果中寻找进行授权信息验证的地方。C32asm反编译Server端程序，找到了“license”这个字符串。而且是一个压栈，接着后面的是一个call调用，ok，我们有了第一断点！下断跟踪，看call的行为。这里不再写我具体跟踪的过程以及相应的代码分析，写下总结：下这个断点后其时并不知道这里到底是干什么的，就算研究了call也未必能完全弄明白。跟踪的方向不要是只往下进行，应该是多尝试着往上找，找这个断点所在的过程的开始，并在这个开始处下断点，然后运行程序断在开始处记下call到这里的位置。然后去那里下断点查找那个过程的开始，下断跟踪。如此这般的一个递归过程。这种处理的目的是为了搞清程序调用的组织结构，来找到调用的基点，也就是说根据不同的条件走不同的调用处理。如果搞清楚了这种框架结构，我们就能根据不同的情况给给出相应的条件，然后跟踪程序对不同分支情况的相应处理。这样才能更好的理解程序。这里特别提一下我对OD作者的敬意，使用OD进行反编译的结果中有自动的switch…case结构的注释，这种注释是C32asm和W32Dasm都没有的（也可能是我不会使用这两个反编译工具没有打开相应的选项），而实际的汇编代码则是一个减法一个比较然后是跳转。如果没有这种注释我将会在清理这个程序的组织结构时遇到很大的困难，感觉是自己对高级语言的依赖太强，而汇编语言的实际编写经验又是0，所以读汇编语言的困难是可想而知的。
        下面是我对Server端程序的结构总结：
1.004FF00D        call        MailServ.004274C0
        这个被调用的过程中包含一个switch…case（A..F）结构。A的情况应该是由管理客户端向Server端发送注册信息，Server段对注册信息进行验证处理的过程。D与F的情况其具体区别未明，但是它们都会call 00445870，这个过程中对内存填写了“Unregistered”的信息，然后对可用邮箱数和使用期限进行计算。
2.004FF00D的调用所在过程从004F3CD0开始。004F3E33处是一个switch…case（66..82）。
004F3E46        case 66        “service operation…”
004F3E7B        case 76        “advanced operation…”
004F3EB6        case 6C        “smtp operation…”
004F3EF1        case 6D        “filter operation…”
004F3F26        case 6E        “internet operation…”
004F3F5B        case 6F        “schedule operation…”
004F3F90        case 70        “pop3 operation…”
004F3FC5        case 71        “etrn operation…”
004F3FFA        case 74        ；这个case就是包含上面第一部分讲的调用的case
…(省略，不再罗列)
3.00402C55        call MailServ.004F3CD0
        这个调用来到第二部分将的过程。这个call所在过程包括了邮件服务器配置的相应处理，这里不再细述。
        暴力破解小结：
1。使用期限的判断
        005628AD、005628B9、005628C1，这三个地方再日期不符合要求时（例如当前日期在软件安装日期之前、超过使用期限等），让它们nop
2．可用邮箱数以及使用期限的计算
        ebx保存可用邮箱数的计算结果，ebp保存最多使用时间，开始给的初值具体是怎么来的我没有仔细寻找，只是程序开始时这几个地址的内存就保存这3个值。反编译的结果中有对这几个明码地址的修改，其作用我没有研究。不排除有动态计算地址然后赋值的情况。
::005628EE::  8B15 30715C00            MOV EDX,[5C7130] //赋初值5
::005628F4::  A1 2C715C00              MOV EAX,[5C712C] //赋初值2
::005628F9::  8BDA                     MOV EBX,EDX                             
::005628FB::  8B0D 28715C00            MOV ECX,[5C7128] //赋初值1
::00562901::  0FAFD8                   IMUL EBX,EAX                           
::00562904::  8D2C01                   LEA EBP,[ECX+EAX]                       
::00562907::  0FAFD8                   IMUL EBX,EAX                           
::0056290A::  0FAFEA                   IMUL EBP,EDX                           
::0056290D::  0FAFCA                   IMUL ECX,EDX                           
::00562910::  68 0C6F5D00              PUSH 5D6F0C                             
::00562915::  0FAFE8                   IMUL EBP,EAX                           
…        …        …        …
::005629EC::  8BCD                     MOV ECX,EBP //最多使用期限给ecx
::005629EE::  C1FA 10                  SAR EDX,10                              
::005629F1::  8BC2                     MOV EAX,EDX                             
::005629F3::  C1E8 1F                   SHR EAX,1F                              
::005629F6::  03D0                ADD EDX,EAX //edx的计算结果是已经使用的时间
::005629F8::  2BCA                SUB ECX,EDX //ecx的计算结果是还可以使用的时间
3．注册过程的处理
::00427BFC::  E8 8F9C1300   CALL 00561890 //调用注册信息验证过程
::00427C01::  83C4 14        ADD ESP,14                              
::00427C04::  85C0          TEST EAX,EAX //返回结果比较
::00427C06::  0F85 E5000000  JNZ 00427CF1//验证失败跳走，在内存填写“Invalid License”
        有兴趣的朋友可以跟进上面的call去分析验证过程。其中使用了很多大概40多位的可能是某种加密计算结果的字符串进行验证。具体从哪里计算的加密我没有没有仔细寻找。
        上面几处的具体修改步骤就略去不写了。
最后总结：
        这个软件中对字符串的处理都是对内存地址一个一个字节填写相应ASCII码的16进制值，所以在开始反编译的结果中很难用一般方法找到关键的字符串的位置下断点。程序中也没有使用“GetDlgItemText”等取字符串的函数。设想：也可以从SetWindowLong、CallWindowProc、GetWindowLong等函数入手，查找对消息的处理函数开始跟踪。

我写此文仅仅是为了研究，请大家也尊重作者的版权，这个软件好像是美国人写的，但是在国内好像有公司代理销售。
本文仅发表看雪论坛，转载者请注明看雪论坛。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课