themida是一款应用在软件加密保护操作上的加壳以及脱壳工具，相较于如今国内混乱的软件行业，许多开发者为了保护自己的软件不被破解使用，采用了许多复杂的加密算法，同时耗费了巨大的精力，而它所能带来的功能就是简化软件加密操作上的繁琐步骤，通过简单的一步式操作便能实现强大的软件加密保护操作，从而有效的防止软件被破解使用，特别是在.net程序上的保护功能尤为突出。
而破解版是旨在帮助使用者更好的应用到软件特有的加密保护功能，另外，软件支持中文语言的转换，极大的方便了初次使用的用户融入功能的操作，它使用SecureEngine的保护技术，能够以最高的优先等级运行而摒弃传统的加密保护模式。本站提供中文绿色破解版下载，有需要的用户可以在本站下载！
注：下载包中有绿色破解版运行程序以及软件集成文件，程序在未使用时请不要轻易删除和更改文件类型。
破解说明
由于软件为绿色版集成文件，软件已提前将破解文件集成在软件运行目录下，所以用户在使用过程中无需破解便可以轻松运行使用，运行程序后点击“关于”按钮查看软件注册激活信息，出现下图表示软件已成功注册激活使用；
功能特色
1、自定的试用计算器来控制你试用版本的有效资源。
2、为试用版本和完全版本制定独立的密码。
3、可以使用外部 Themida DLL 来创建你自己的自动化系统。
4、超过 50 种不同函数的完整 SDK 。
5、为试用版和完全版提供 .NET SDK 支援。
6、使用数据库来安全地储存你所有的软件，客户和注册资料。
7、自定义所有的试用 / 注册讯息，也控制是否要展示特定的试用 / 注册讯息。
8、可以创建用来延长试用版本的有效期的特别码。
9、一个用来储藏试用 状态的 强劲的引擎，以避免任何软件破解者尝试重置有效期。可以为个别开发者的需要创建不同的注册码。
10、针对特定国家的试用锁定和注册码。
11、机器锁定，使程式只运行在特定的电脑上。
脱壳还原教程
大家都知道它的强大保护功能，几乎无人能完整的破解它的VM中的handler（最新进展如何？）。我也试图跟踪过它的几个handler，它为一个简单的入栈操作竟有长达数千行的垃圾代码和无穷的转跳，如果要把它168（？）个handler都清理出来，他一定会疯掉！或累死掉？我曾经下决心不碰它了，不知为什么鬼使神差的我又跟踪了几个
加密软件，竟然还有新的发现！
附件提供的一个程序是用汇编写的PE信息小工具，用它加密，加密选择RISC-64 processor，全选加密可选项，并对部分API函数使用VM加密，入口虚拟系数选择15。应该说对该程序用了较强的加密措施。现在介绍用我的脚本，一步步对它破解(绝不暗中使用对原程序已知的信息)，居然还原了所有的代码，请看下面详细过程。
一、介绍一个万能脚本
1.下面的脚本适用于任何用Themida 1.8.5.5版加密的程序，操作十分简单。
--------------------------------------------------------------
//本脚本适用于Thmida 1.8.5.5版本加密的任何程序
bphwc
bc
jmp Second //第一次运行后,将本行注释掉后保存一次(本)脚本
data:
var mem
var mem1
var temIAT
var temESI
var temAPI
var APIstr
var Addr_0
var Addr_1
var Addr_2
var Addr_3
var Addr_4
var Addr_5
var Rva
Init:
mov Rva,65b970 //用对话框中的值修改该值,并将第一行的jmp Second注释掉
mov Addr_0,Rva-997
mov Addr_1,Rva-809
mov Addr_2,Rva-ea
mov Addr_3,Rva-9d
mov Addr_4,Rva
mov Addr_5,Rva+74c
start:
esto
esto
bphws Addr_0,"x"
esto
bphwc Addr_0
mov [Addr_0],0062e990 //废除监视断点的代码
bp Addr_1
bp Addr_2
bp Addr_3
bp Addr_4
bp Addr_5
First:
run
cmp eip,Addr_1
jz A1
cmp eip,Addr_2
jz A2
cmp eip,Addr_3
jz A3
cmp eip,Addr_4
jz A4
cmp eip,Addr_5
jz A5
jmp First
A1:
mov temAPI,eax //eax 是API函数地址
gn temAPI //显示函数名
log $RESULT
add APIstr," "
add APIstr,$RESULT_2 //恢复API函数名(INT表)
jmp First
A2:
mov temIAT,eax
cmp edx,10000
ja next
xor edx,80000000
mov [eax],edx //修复IAT表(写入序列号)
jmp First
next:
mov [eax],temAPI
jmp First
A3:
mov mem1,eax //eax是内存中呼叫API地址
mov temESI,[esi] //获取转跳标记
jmp First
A4:
cmp temESI,AAAAAAAA
jnz step3
mov [mem1],#FF25# //修复代码中转跳地址
mov [mem1+2],temIAT
jmp First
step3:
mov [mem1],#FF15# //修复代码中呼叫地址
mov [mem1+2],temIAT
jmp First
A5:
bc
pause
Second: //查找写IAT地址的一条指令
var memory
var tmp
var temp
var tmpbp
var Str
gmi eip,CODEBASE
mov memory,$RESULT
find memory,#0000000000000000000000000000000000000000000000#
mov tmp,$RESULT
bphws tmp,"w"
esto
esto
esto
bphwc tmp
sto
find memory,#909090909090909090909090909090909090#
mov temp,$RESULT+2
bphws temp,"w"
mov tmpbp,eip
run
cmp eip,tmpbp+2
jnz next2
run
next2:
itoa eip
mov Str,"请用下列数值："
add Str,$RESULT
add Str," 修改脚本中的Rva."
bphwc
msg Str
pause //（脚本完）
本脚本的使用方法是：用OD打开程序后，如果第一次加载本脚本，则会弹出一个对话框，用对话框中的数据修改脚本中的Rva值（第20行，且只有一处），并一定将第3行的jmp Second注释掉，一定将脚本保存一次！这时脚本就是该程序的专用脚本了。重新用OD加载程序后，可以无须任何更改，直接调用本脚本了！
第2次运行脚本，屏幕快速闪动，一会就出现了神奇的效果了。如果想应用于新的程序，则只须将注释掉的jmp Second恢复即可。
它有很多监视断点的SEH，当时没有采用相应措施，所以被其频频发现。它的“监视”方法很多，用得最多的大约有(1)int 1中断，(2)内存访问异常中断，(3)代码扫描等。对于(1)(2)没有任何办法删除，但脚本的一个循环可与它周旋；对于(3)在我跟踪的代码段中，用脚本将它删除了。所以脚本运行得非常顺利。
(1)脚本中的 mov [Addr_0],0062e990 就是将该地址的“jb”改成了“jmp”，跳过了代码扫描监视。
(2)Thmida不管你是什么类型的断点，很快被发现并单步异常后弹出对话框，然后退出运行。请注意，设置的是单步中断，如果让它自行处理这个中断，就是前面的结果。如果将它拦截下来，自已处理就可以绕过了它的SEH。“拦截”方法就是打开OD“选项--调试设置--异常页”只选“非法访问内存”一项，其余全部不能选取。这样除非法访问内存异常让它自行处理外，其余全部交由OD处理。这样当发现断点后产生的单步异常就被OD拦截了。自行处理的方式就是脚本中“First：”标签部分。(用脚本处理OD拦截下来的中断是非常容易的)
脚本中的First部分(断点循环)就是判断中断地址是不是自己设置的，是则进入相应操作；若不是，则一定是Thmida发现断点后的SEH中断地址(单步中断)，处理方式就是用“run“。OD的这个run，就是让程序在eip中断地址上继续运行，绕过了SEH处理程序(陷阱)。
3.运行脚本后的神奇效果
用OD打开程序后，加载这个脚本，程序运行得很快。当它暂停后它外壳已经被除掉。转到代码段401000，让OD分析代码一次。如果在code段中没有虚拟API函数，则显示在你面前的是一个非常清晰的可读的反汇编程序，各个API函数调用和名称显露无遗。如果你仅仅是想了解原程序的基本结构和思路，这就够了。如果虚拟了部分API，请往下看。如果你一定要dump出来，并去掉垃圾代码，也请往下看。
二、恢复程序的入口代码
如果想进入它的VM(虚拟机)部分，清理它的handler，还原出原代码，我是绝对无能为力了，下决心不碰它了。
那么，我是怎样恢复入口代码的呢？跟踪发现，它对解压出来的代码段并不重视，居然没有设置断点监视？你可以任意设断和修改，我巧妙地利用了它这一弱点。
1.设断技巧（以提供的PeInfo_them.exe为例）
用脚本脱壳后，转到401000代码区，让OD对代码分析一次，来到程序的尾部，API函数都集中在这里(称它为API表)(VC++程序的函数表分散在代码中,相对集中)。
004015FC $- FF25 5820400>jmp dword ptr [402058] ; USER32.wsprintfA
00401602 .- FF25 5420400>jmp dword ptr [402054] ; USER32.DialogBoxParamA <---F2设断
00401608 $- FF25 5020400>jmp dword ptr [402050] ; USER32.EndDialog
0040160E $- FF25 4C20400>jmp dword ptr [40204C] ; USER32.GetDlgItem
00401614 .- FF25 4820400>jmp dword ptr [402048] ; USER32.GetWindowTextLengthA <---F2设断
0040161A $- FF25 4420400>jmp dword ptr [402044] ; USER32.LoadIconA
00401620 .- FF25 4020400>jmp dword ptr [402040] ; USER32.MessageBoxA <---F2设断
00401626 .- FF25 3C20400>jmp dword ptr [40203C] ; USER32.SendMessageA <---F2设断
0040162C $- FF25 3820400>jmp dword ptr [402038] ; USER32.SetWindowTextA
00401632 $- FF25 2420400>jmp dword ptr [402024] ; kernel32.CloseHandle
00401638 $- FF25 2820400>jmp dword ptr [402028] ; kernel32.CreateFileA
0040163E $- FF25 2C20400>jmp dword ptr [40202C] ; kernel32.CreateFileMappingA
00401644 .- FF25 3020400>jmp dword ptr [402030] ; kernel32.ExitProcess <---F2设断
0040164A .- FF25 2020400>jmp dword ptr [402020] ; kernel32.FreeLibrary <---F2设断
00401650 $- FF25 1C20400>jmp dword ptr [40201C] ; kernel32.GetFileSize
00401656 .- FF25 1820400>jmp dword ptr [402018] ; kernel32.GetModuleHandleA <---F2设断
0040165C .- FF25 1420400>jmp dword ptr [402014] ; kernel32.LoadLibraryA <---F2设断
00401662 $- FF25 1020400>jmp dword ptr [402010] ; kernel32.MapViewOfFile
00401668 $- FF25 0C20400>jmp dword ptr [40200C] ; kernel32.UnmapViewOfFile
0040166E $- FF25 0820400>jmp dword ptr [402008] ; kernel32.lstrcpyA
00401674 $- FF25 0020400>jmp dword ptr [402000] ; comdlg32.GetOpenFileNameA
(1)注意到API表中有“$”的地方(如果全都没有,则再分析一次)，$表示程序中有call在呼叫，若没有则表示没有关联(VC++编写的程序有很多无关联的垃圾函数)。在这里没有关联的函数肯定是被虚拟了call代码。在没有“$”的地址上设F2中断。
明眼一看，本例是一个对话框窗口，它只有DialogBoxParamA，没有CreateWindowEx、消息循环等函数。若是Window窗口，则不能在消息循环函数上设断，否则OD将进入假死状态。
(2)在解压后代码段中浏览，发现了一段连续的乱码，用OD分析也无用，它一般就是入口代码段了。本例是4015B6--4015FB这一段(被虚拟了)。
(3)从401000开始寻找跳进006xxxxx段的jmp，这些jmp都是跳到被VM虚拟后的API代码中(代码E9前面都有一个“-”号)，本例中跳进VM中的8个jmp地址如下：
0040100D .- E9 E0532300 jmp 006363F2
00401029 .- E9 408F2300 jmp 00639F6E
0040103E .- E9 95CC2300 jmp 0063DCD8
00401371 .- E9 4A092400 jmp 00641CC0
00401385 .- E9 F0422400 jmp 0064567A
004013C9 .- E9 B2802400 jmp 00649480
004013DD .- E9 61B52400 jmp 0064C943
0040151B .- E9 39F32400 jmp 00650859
在以上的每个地址都用F2设断。
2.操作技巧(以后的操作基本上都是F9或alt-F9，无须shift-F9)
(1)当设置完成后，按F9运行一次，程序中断在
0040165C .- FF25 1420400>jmp dword ptr [402014] ; kernel32.LoadLibraryA
且在堆栈中出现
0013FF90 00654697 /CALL 到 LoadLibraryA
0013FF94 00402060 \FileName = "RichEd20.dll"
0013FF98 004001C0 ASCII " " <--这是应用程序开始的栈顶，dump堆栈平衡时弹出至此
0013FF9C 0013FFE0 指向下一个 SEH 记录的指针
0013FFA0 005E0DB2 SE处理程序
0013FFA4 7C930738 ntdll.7C930738
堆栈中0013FF98是进入应用程序后的栈顶，13FF94的(00402060)是压入的参数，0013FF90的(00654697)是VM中的呼叫地址。
记录下堆栈中的数据，并将4015B6开始的乱码改写为：(它就是解密出来的入口第一组代码)
push 00402060
call 0040165C <---虚拟机中怎样操作不知道，而还原后的代码就是call LoadLibraryA，即call 0040165C。
(2)继续F9一次，中断在
00401656 .- FF25 1820400>jmp dword ptr [402018] ; kernel32.GetModuleHandleA
堆栈中出现
0013FF90 006546A3 /CALL 到 GetModuleHandleA
0013FF94 00000000 \pModule = NULL
这里记下堆栈，接着前面如下修改乱码；
push 0
call 00401656 <---入口的第二组数据
(3)继续一次F9，(记录每一次中断后堆栈中的数据)中断在
00401602 .- FF25 5420400>jmp dword ptr [402054] ; USER32.DialogBoxParamA
堆栈是
0013FF80 006546BB /CALL 到 DialogBoxParamA
0013FF84 00400000 |hInst = 00400000 <--GetModuleHandleA的返回值
0013FF88 000003E8 |pTemplate = 3E8 <--资源ID
0013FF8C 00000000 |hOwner = NULL
0013FF90 00401544 |DlgProc = PeInfo_t.00401544 <--窗口程序地址
0013FF94 00000000 \lParam = NULL
因为程序进入了DialogBoxParamA后，不会退出，但初始化窗口时还会调用其它函数，只有关闭窗口后才退出。
这里将前面3次中断后堆栈中的值，加上必须保存的句柄，将入口处的乱码改写如下：
push 402060
call 0040165C ;LoadLibraryA
mov [xxxxx],eax <---返回RichEdit20A句柄
push 0
call 00401656 ;GetModuleHandleA
mov [xxxxx],eax <---返回GetModuleHandleA句柄
push 0
push 401544
push 0
push 3E8
push [xxxxx] <---它一定是GetModuleHandleA返回的句柄
call 00401602 ;DialogBoxParamA
打开403000全局变量区，每中断一次就会写入一些数据。你会发现LoadLibraryA句柄存入了[403004]，GetModuleHandleA句柄存入了[403000]，这样前面的三个[xxxxx]都解决了(需要一些API函数知识)：即
push 402060 <---查402060是字串RichEd20.dll，原来是装载RichEd20库
call 0040165C ;call LoadLibraryA
mov [403004],eax <---返回RichEdit20A句柄
push 0
call 00401656 ;call GetModuleHandleA
mov [403000],eax <---返回GetModuleHandleA句柄
push 0
push 401544 <--DialogBoxParamA函数的Proc地址
push 0
push 3E8 <--窗口资源ID
push [403000] <---它是GetModuleHandleA返回的句柄
call 00401602 ;call DialogBoxParamA
这就是入口的开局部分。
提问：如果程序中有如：mov eax,12345678； mov ecx,eax；mov [403040],ecx；add eax,ecx等代码，怎么办？
应该说，每种语言编写的程序入口都有一种相对固定的格式，在窗口未建立之前一般不会有mov ecx,eax；add eax,ecx等代码，熟习了各种语言的程序入口代码对破解大有帮助。如果在脚本中设置了bpmw [40x000],ff（[40x000]是数据区），则对找回如:mov [xxxxx],eax等代码有一定的帮助，但断点在VM中，要防止它的监视。退一步说，即使漏掉了一些这样的代码，dump后的程序不能运行，但对程序的结构和思路已经完全掌握了，目的已经达到了。
(4)继续一次F9，中断在地址401371，(窗口初始化调用的函数)
00401371 .- E9 4A092400 jmp 00641CC0
这是code中被虚拟了的API函数，将该地址设置的中断F2关闭(因为程序可能反复调用它，以后每当在前面的8个jmp上中断一次，就关闭该断点)，再F9一次，中断在API表中的
00401626 .- FF25 3C20400>jmp dword ptr [40203C] ; USER32.SendMessageA
堆栈中是
0013FC14 00641CD7 /CALL 到 SendMessageA
0013FC18 004600B2 |hWnd = 4600B2
0013FC1C 00000080 |Message = WM_SETICON
0013FC20 00000001 |wParam = 1
0013FC24 0C1A027D \lParam = C1A027D
原来401371加密前应该是call 401625(即call SendMessageA)，查看地址401371，参数非常清晰，你不必费力去研究它的参数来源，它是装载图标。
注意，这个call SendMessageA不是接在开局的call DialogBoxParamA后面，因为程序还没有退出DialogBoxParamA。
记下00401371地址，将要修改为call 401625(参数修复前不要修改，可能程序会反复调用它)。
……………………………………
这样反复F9，反复记下中断地址和中断函数，(每中断一个jmp的地址，就关闭它的断点(API表中的F2不能关闭)。这样凡是与初始化有关的被虚拟的API都现身了！若发现再F9，老在API表中的SendMessageA(或其它函数)上中断，这是初始化中的调用，运行时总要进入系统领空，可按alt-F9让其返回(在VM中)，再F9回到用户领空。窗口未出现前可以先关闭SendMessageA的F2断点，但窗口出现后一定要恢复其断点。
(5)如果F9后，OD没有反应，但状态栏提示读取[FFFFFFFF]异常，不管它，这时，窗口已经出现了(看桌面状态条），程序进入了DialogBoxParamA中的消息循环。
到此为止，代码段中还有5个断点没有被访问，它们是窗口运行后才要访问的地址。
(6)按普通程序一样运行窗口，让它随便打开一个.exe文件，它立即中断在某jmp虚拟函数上，按前面同样的方法操作，在API函数表中就发现了它调用的API是谁了，这样就一个个地把虚拟的函数清理完了。当代码段中的F2中断地址关闭完后。被VM虚拟的全部函数都现身了。（如何恢复参数，后面再说）
(7)反复运行窗口发现在代码中设置的断点0040151B9(jmp 00650859)始终没有被调用，而API表中的MessageBoxA也没有被调用，可以肯定0040151B9(jmp 00650859)是虚拟了call MessageBoxA。原来它是一个出错对话框，当你打开一个非exe文件时，对话框就出现了。在堆栈中也可以找到它全部参数。
(8)入口的后半部
当清理完代码段中的所有jmp断点后(被虚拟的API)，可以关闭窗口了，按下关闭钮，立即中断在
0040164A .- FF25 2020400>jmp dword ptr [402020] ; kernel32.FreeLibrary
堆栈是
0013FF90 006546CA /CALL 到 FreeLibrary
0013FF94 74D90000 \hLibModule = 74D90000 <--LoadLibraryA的句柄
即：接着call DialogBoxParamA后面，按下面代码修改
push [403004]
call 40164A (call FreeLibrary)
再F9，中断在
0013FF90 004015FC (CALL 到 ExitProcess)
再F9,就退出了。那么，完整的入口代码是：
push 402060
call 0040165C
mov [403004],eax
push 0
call 00401656
mov [403000],eax
push 0
push 00401544
push 0
push 3E8
push [403000]
call 00401602
push [403004]
call 0040164A
push 0
call 004015FC
三、参数的恢复
API参数的设置，需要一些API知识，以本例为例简要说明，回到前面，401000这里有3个被虚拟的函数。前面的操作知道，先中断在一个jmp上，接着中断在API表中对应的API函数上。这样都清楚了它们是call xxxxxx。
00401000 $ 55 push ebp
00401001 . 8BEC mov ebp, esp
00401003 . 83C4 F8 add esp, -8
00401006 . 60 pushad
00401007 . FF35 0C304000 push dword ptr [40300C]
->0040100D .- E9 E0532300 jmp 006363F2 <--应该是call GetWindowTextLengthA
00401012 . D3F4 sal esp, cl
00401014 . 0D B38ACE8D or eax, 8DCE8AB3
00401019 . 45 inc ebp
0040101A . F8 clc
0040101B . 50 push eax
0040101C . 6A 00 push 0
0040101E . 68 37040000 push 437
00401023 . FF35 0C304000 push dword ptr [40300C]
->00401029 .- E9 408F2300 jmp 00639F6E <--应该是call SendMessageA
0040102E . 0B37 or esi, dword ptr [edi]
00401030 . B0 F7 mov al, 0F7
00401032 . F5 cmc
00401033 . 68 C2000000 push 0C2
00401038 . FF35 0C304000 push dword ptr [40300C]
->0040103E .- E9 95CC2300 jmp 0063DCD8 <--应该是call SendMessageA
00401043 . 46 inc esi
00401044 . 6F outs dx, dword ptr es:[edi]
00401045 . C2 0400 retn 4
(1)第一个call GetWindowTextLengthA，参数只有一个push [40300C]，前面已知这是RichEdit20A的句柄，显然它是获取编辑软件RichEdit20A中的字符数，结果应该暂存，eax怎样操作？
(2)第2个是call SendMessageA，消息发往RichEdit20A，堆栈中的表示是：
0013F798 00639F81 /CALL 到 SendMessageA
0013F79C 00450292 |hWnd = 450292
0013F7A0 00000437 |Message = MSG(437)
0013F7A4 00000000 |wParam = 0
0013F7A8 0013F7CC \lParam = 13F7CC <--移动光标或选择范围的操作是该参数指向一个CHARRANGE结构(8字节)
这下难了，必须弄清RichEdit20A是干什么的？原来它是一个大型文本编辑软件，操作十分复杂，这里是大才小用，只用它来显示数据，并不对数据编辑。对RichEdit20A的操作主要是靠SendMessageA发送消息。它操作前，一定要确定光标位，确定光标位消息中的lParam参数指向一个CHARRANGE结构(2个dword)，这两个值相等，其值是光标位置；若不等则表示选择一个区间。
清楚了，GetWindowTextLengthA获取屏幕上字符长度，第1个SendMessageA应该将光标定于尾部，好让第2个SendMessageA向它添加字符。那么第1个SendMessageA的参数13F7CC就一定是指向CHARRANGE结构，从ebp的值知13F7CC是指向[ebp-8]，[ebp-4]即一个CHARRANGE结构，两个dword值应该相等且就是当前的字串长度。
这样，显然应该有：mov [ebp-8],eax；mov [ebp-4],eax。所以，代码应该如下：
call GetWindowTextLengthA
mov [ebp-8],eax
mov [ebp-4],eax
lea eax,[ebp-8]
push eax <---取CHARRANGE结构地址
push 0
push 437
push [40300C]
call SendMessageA
第2个SendMessageA一定是将buffer中的字串添加上去。它的参数lParam应该指向一个buffer。堆栈中参数是
0013F798 0063DCE9 /CALL 到 SendMessageA
0013F79C 00E20202 |hWnd = 450292
0013F7A0 000000C2 |Message = EM_REPLACESEL <-- EM_REPLACESEL=C2
0013F7A4 00000000 |wParam = 0
0013F7A8 0040222F \Text = "--------------------------------------
MSG消息EM_REPLACESEL也表示向RichEdit20A添加字符，参数lParam指向40222F，是直接push 40222F还是由调用程序带来？查调用401000的呼叫，知道它有多个地方调用，它的参数一定得由调用程序带来。
这样，接着的代码是
push [ebp+8] <--唯一的带来参数
push 0
push 0C2 <-- 0C2=EM_REPLACESEL
push [40300C]
call SendMessageA
(4)SendMessageA没有返回值，最后还有乱码46 6f的原码是什么？观察程序，前面有pushad，后面一定要有popad，又汇编程序是堆栈自动平衡方式，最后一般都有leave，最后这个C2 0400 (retn 4)是否是原码呢？应该说是，一般不去惹call ebx、jmp eax、retn等代码，因为它的转跳是不定的，操作起来很复杂。
至此，这段代码被还原了。有的地方说法可能很勉强(因为有原码参考，所以我说得很肯定)，用在其它地方可能就不正确了。不管怎么说，分析起来虽然很困难，但肯定比从VM虚拟代码中还原要容易得多了。
本方法有个致命的弱点是，一些与被虚拟的函数无关的代码，如add eax,6，mov ecx,edi等是永远找不回来的。好在是已经编译过的.exe文件再用它加密，如果不提供原编译文件，则只能对API虚拟了，包含它附近的几个代码。有关API的参数代码相对简单一些，很少有前面说到的那些代码形式，退后一步说，即使有，且被漏掉了，但所有的API都被还原了，关系清楚了，虽然dump后的程序不能运行，但破解的欲望达到了！
四、可能出现的问题
1.如果你用OD打开文件后加载脚本，OD象没有反应一样直接就运行到了窗口出现。
结论：你可能是第1次将脚本用到其它程序上而又忘记了将脚本中的jmp Second恢复过来，或者你忘记了存盘。
2.用脚本第1次弹出对话框没问题，第2次按要求修改也存了盘，但就是不出现任何结果。
结论：版本可能不是1.8.5.5版。或者“调试设置--异常页”的选项选得太多，特别是选择了“忽略特权指令或无效指令”。
3.脚本不能运行到底，弹出警告框后退出。
结论：“调试设置--异常页”的选项选得太多，特别是选择了“忽略单步异常”。
0条评论