脱壳基础知识入门
脫殼基礎知識入門
現在加解密發展己形成2個分支了，一個就是傳統的算法，另一個就是加密殼。越來越多的軟件采用了密碼學相關算法，現在要做出一個軟件注冊機己不象前幾年那么容易，這就要求解密者必須要有一定的數學功底和密碼學知識，而這些在短時間內是不容易掌握的。除了密碼學的應用，越來越多的軟件加殼了，因此要求解密者必須掌握一些脫殼技術，這就使得殼成了解密必須邁過的一個門檻。殼發展到今天，強度越來越高了，將許多人擋在門外，使得大家望殼興嘆。另外，論壇現在兩極分化比較嚴重，高手討論的脫殼技術新手看不懂，很多人想學脫殼，但看到殼這么難，只好放棄了，造成新手與高手間一個斷檔，為了鼓勵更多新人加入脫殼的行列，很有必要將殼有關知識總結一下。www.pediy.com主頁提供的教學確實有點過時了，己到非更新不可了。相對于密碼學算法，脫殼并不難，只要肯花時間，短期內還是比較容易取得成績的。
第一課?PE格式
要想學脫殼，第一步就得掌握PE格式，PE是Portable?Executable?File?Format（可移植的執行體）簡寫，它是目前Windows平臺上的主流可執行文件格式。
Microsoft?Visual?C++提供的WINNT.H里有PE數據結構的完整定義。
推薦文檔：
??ah007翻譯的“PE文件格式”1.9版??
??qduwg翻譯的PE文件格式???
??Iczelion's?的PE文件格式
??PE結構各字段偏移參考??
?????學習PE格式的方法是自己先準備一個十六進制工具，如HexWorkshop，WinHex，用這些工具打開一個EXE文件對照著學。強烈推薦你用Stud_PE?v.2.2.0.5這款工具輔助學習PE格式。PE格式學習的重點是在輸入表（Import?Table）這塊。Stud_PE工具界面：
PE結構圖：
第二課?SEH技術
結構化異常處理（Structured?Exception?Handling，SEH）是Windows操作系統處理程序錯誤或異常的技術。SEH是Windows操作系統的一種系統機制，與特定的程序設計語言無關。
???外殼程序里大量地使用了SEH，如果不了解SEH，將會使你跟蹤十分困難。
??SEH?in?ASM?研究(一)by?hume???
??SEH?in?ASM?研究(二)by?hume???
??Structured?Exception?Handling???
??加密與解密二版菜鳥學習筆記(2)?-?SEH?結構化異常處理?by?ytcswb???
由于?Ollydbg???對SEH處理異常靈活，因此脫殼用Ollydbg會大大提高效率。
附CONTEXT結構環境：
代碼:
?
typedef?struct?_CONTEXT?{
?
?DWORD???????ContextFlags;
?
?DWORD???????Dr0;
?DWORD???????Dr1;
?DWORD???????Dr2;
?DWORD???????Dr3;
?DWORD???????Dr6;
?DWORD???????Dr7;
?
?FLOATING_SAVE_AREA?FloatSave;
?
?DWORD???????SegGs;
?DWORD???????SegFs;
?DWORD???????SegEs;
?DWORD???????SegDs;
?
?DWORD???????Edi;
?DWORD???????Esi;
?DWORD???????Ebx;
?DWORD???????Edx;
?DWORD???????Ecx;
?DWORD???????Eax;
?
?DWORD???????Ebp;
?DWORD???????Eip;
?DWORD???????SegCs;
?DWORD???????EFlags;
?DWORD???????Esp;
?DWORD???????SegSs;
?
?????BYTE????ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
?
?}?CONTEXT;
?
第三課?認識殼
1.?什么是殼？?
??????在一些計算機軟件里也有一段專門負責保護軟件不被非法修改或反編譯的程序。它們一般都是先于程序運行，拿到控制權，然后完成它們保護軟件的任務。由于這段程序和自然界的殼在功能上有很多相同的地方，基于命名的規則，就把這樣的程序稱為“殼”了。
?推薦文檔：
??一切從“殼”開始???
描述殼的示意圖：
?
2.?殼的加載過程?
???????這里談的加殼工具不是WinZIP、WinRAR等數據壓縮工具，而是談壓縮可執行文件EXE或DLL的工具。加殼過的EXE文件是可執行文件，它可以同正常的EXE文件一樣執行。用戶執行的實際上是外殼程序，這個外殼程序負責把用戶原來的程序在內存中解壓縮，并把控制權交還給解開后的真正程序，這一切工作都是在內存中運行的，整個過程對用戶是透明的。
殼和病毒在某些方面比較類似，都需要比原程序代碼更早的獲得控制權。殼修改了原程序的執行文件的組織結構，從而能夠比原程序的代碼提前獲得控制權，并且不會影響原程序的正常運行。
???這里簡單說說一般殼的裝載過程。（參考了Ljtt以前寫過的一篇文章）
???1）獲取殼自己所需要使用的API地址?
?????如果用PE編輯工具查看加殼后的文件，會發現未加殼的文件和加殼后的文件的輸入表不一樣，加殼后的輸入表一般所引入的DLL和API函數很少，甚至只有Kernel32.dll以及GetProcAddress這個API函數。?
?????殼實際上還需要其他的API函數來完成它的工作，為了隱藏這些API，它一般只在殼的代碼中用顯式鏈接方式動態加載這些API函數:3個脫殼相關的重要函數介紹??
???2）解密原程序的各個區塊(Section)的數據?
???殼出于保護原程序代碼和數據的目的，一般都會加密原程序文件的各個區塊。在程序執行時外殼將會對這些區塊數據解密，以讓程序能正常運行。?殼一般按區塊加密的，那么在解密時也按區塊解密，并且把解密的區塊數據按照區塊的定義放在合適的內存位置。?
???如果加殼時用到了壓縮技術，那么在解密之前還有一道工序，當然是解壓縮。這也是一些殼的特色之一，比如說原來的程序文件未加殼時1～2M大小，加殼后反而只有幾百K。?
???3）重定位?
???文件執行時將被映像到指定內存地址中，這個初始內存地址稱為基地址（ImageBase）。當然這只是程序文件中聲明的，程序運行時能夠保證系統一定滿足其要求嗎？?
???對于EXE的程序文件來說，Windows系統會盡量滿足。例如某EXE文件的基地址為0x400000，而運行時Windows系統提供給程序的基地址也同樣是0x400000。在這種情況下就不需要進行地址“重定位”了。由于不需要對EXE文件進行“重定位”，所以加殼軟件把原程序文件中用于保存重定位信息的區塊干脆也刪除了，這樣使得加殼后的文件更加小巧。有些工具提供“Wipe?Reloc”的功能，其實就是這個作用。?
???不過對于DLL的動態鏈接庫文件來說，Windows系統沒有辦法保證每一次DLL運行時提供相同的基地址。這樣“重定位”就很重要了，此時殼中也需要提供進行“重定位”的代碼，否則原程序中的代碼是無法正常運行起來的。從這點來說，加殼的DLL比加殼的EXE更難修正。?
???4）HOOK-API?
???程序文件中的輸入表的作用是讓Windows系統在程序運行時提供API的實際地址給程序使用。在程序的第一行代碼執行之前，Windows系統就完成了這個工作。?
???殼一般都修改了原程序文件的輸入表，然后自己模仿Windows系統的工作來填充輸入表中相關的數據。在填充過程中，外殼就可填充HOOK-API的代碼的地址，這樣就可間接地獲得程序的控制權。
???5）跳轉到程序原入口點（OEP）?
????從這個時候起殼就把控制權交還給原程序了，一般的殼在這里會有明顯的一個“分界線”。但現在的猛殼己沒這界限了，殼里有肉，肉里有殼。
?
3.?壓縮引擎???
???????各類加殼軟件，其壓縮算法一般不是自己實現的，大多是調用其他的壓縮引擎。目前壓縮引擎種類比較多，不同的壓縮引擎有不同特點，如一些對圖像壓縮效果好，一些對數據壓縮效果好。而加殼軟件選擇壓縮引擎有一個特點，在保證壓縮比的條件下，壓縮速度慢些關系不是太大，但解壓速度一定要快，這樣加了殼的EXE文件運行起來速度才不會受太大的影響。例如下面幾個壓縮引擎就能滿足這要求：
1.?aPLib壓縮引擎?http://www.ibsensoftware.com/，這個庫對于低于64K的文件壓縮效果較好，速度較快。
2.?JCALG1壓縮引擎，相對于aPlib，JCALG1對于大文件效果好些。
3.?LZMA壓縮引擎?http://www.7-zip.org/zh-cn/sdk.html，LZMA?是?7-Zip?程序中?7z?格式?的默認壓縮算法，壓縮率很高。
?
?
第四課?常見壓縮殼與加密殼
加殼軟件按照其加殼目的和作用，可分為兩類：一是壓縮（Packers），二是保護（Protectors）。壓縮這類殼主要目的是減小程序體積，如ASPacK、UPX和PECompact等。另一類是保護程序，用上了各種反跟蹤技術保護程序不被調試、脫殼等，其加殼后的體積大小不是其考慮的主要因素，如ASProtect、Armadillo、EXECryptor等。隨著加殼技術的發展，這兩類軟件之間的界線越來越模糊，很多加殼軟件除具有較強的壓縮性能，同時也有了較強的保護性能。
1.?ASPacK???
主頁：http://www.aspack.com/?
???ASPack是款Win32可執行文件壓縮軟件，可壓縮Windows?32位可執行文件（.exe）以及庫文件（.dll、.ocx），文件壓縮比率高達40%～70%。
?
?
2.?UPX
主頁：http://upx.sourceforge.net/?
???UPX是一個以命令行方式操作的可執行文件經典免費壓縮程序，壓縮算法自己實現，速度極快，壓縮比極高。（開源）
3.?PECompact
主頁：http://www.bitsum.com/
???PECompact同樣也是一款能壓縮可執行文件的工具（支持EXE、DLL、SCR、OCX等文件）。相比同類軟件，PECompact提供了多種壓縮項目的選擇，用戶可以根據需要確定哪些內部資源需要壓縮處理。同時，該軟件還提供了加解密的插件接口功能。
?
4.?ASProtect
主頁：http://www.aspack.com/?
???ASProtect是一款非常強大的Windows?32位保護工具，這4、5年來，其一直在更新進步。其開發者是俄國人Alexey?Solodovnikov。它擁有壓縮、加密、反跟蹤代碼、反-反匯編代碼、CRC校驗和花指令等保護措施。它使用Blowfish、Twofish、TEA等強勁的加密算法，還用RSA1024作為注冊密鑰生成器。它還通過API鉤子（API?hooks，包括Import?hooks（GPA?hook）和Export?hooks）與加殼的程序進行通信。甚至用到了多態變形引擎（Polymorphic?Engine）。反Apihook代碼（Anti-Apihook?Code）和BPE32的多態變形引擎（BPE32的Polymorphic?Engine）。并且ASProtect為軟件開發人員提供SDK，實現加密程序內外結合。
?
更多與殼有關的描述參考：
??縱橫間誰能相抗—論殼與加殼技術?作者:forgot?
常見加密殼官方站點?
ASProtect???????????http://www.aspack.com/??
ACProtect???????????http://www.ultraprotect.com/?
Armadillo???????????http://www.siliconrealms.com/srt-news.shtml?
EXECryptor??????????http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.strongbit.com/?
Obsidium????????????http://www.obsidium.de/??
PESpin??????????????http://pespin.w.interia.pl/??
VMProtect???????????http://www.polytech.ural.ru/??
Xtreme-Protector????http://www.oreans.com/xprotector/?
Themida/WinLicense??http://www.oreans.com/downloads.php
?
第五課?文件類型分析
拿到一個殼，第一步就是用相關工具分析一下是什么殼，然后就可心中有數地跟蹤分析。文件分析工具有PEID，FileInfo等。
1.PEiD
???PEiD的GUI界面操作非常方便直觀。它的原理是利用查特征串搜索來完成識別工作的。各種開發語言都有固定的啟動代碼部分，利用這點就可識別出是何種語言編編譯的。同樣，不同的殼也有其特征碼，利用這點就可識別是被何種殼所加密。PEiD提供了一個擴展接口文件userdb.txt?，用戶可以自定義一些特征碼，這樣就可識別出新的文件類型。
???有些外殼程序為了欺騙PEiD等文件識別軟件，會偽造啟動代碼部分，例如將入口代碼改成與Visual?C++?6.0所編程程序入口處類似代碼，即可達到欺騙目的。所以，文件識別工具所給出的結果只是個參考，文件是否被加殼處理過，還得跟蹤分析程序代碼才可得知。?可參考這個文檔了解如何偽裝：讓偵測工具把殼識別為VC++7.0的源代碼???。目前Hying的殼PE-Armor偽裝能力是最強的：
?
PEiD分析不出類型的文件就報告是“Nothing?found?*”，如出現這情況一般都是未知殼或新版的殼。
下面PEiD識別出這個軟件是用Asprotect?1.2x加的殼。
?
2.FileInfo
?????FileInfo（簡稱Fi）另一款不錯的文件檢測工具。Fi運行時是DOS界面，在DOS窗口中運行程序相當不便，建議采用下面的技巧：
1.用鼠標將文件拖到Fi主文件上。
2.將Fi快捷方放進Windows的SendTo文件夾里.以后要分析某文件，只需右擊“發送到”功能就可打開Fi。???
???FileInfo升級慢，其識別庫不能自定義。而PEiD升級比較頻繁，用戶也可自定義特征碼，因此PEiD用的比較普遍。
???有時，FileInfo和PEID會報“PE?Win?GUI”，Win?GUI就是Windows圖形用戶界面程序統稱，表明程序可能沒加殼。但不排除也有加殼的可能性，下圖是一個ExeCryptor?2.2x的殼，FileInfo報“*PE?Win?GUI?*section*???”，其不能識別出來。識別信息中帶了個問號，表明FI對給出的結果不是太肯定。
?
第六課?尋找OEP??
???一般的壓縮殼，如Aspack等都有專用的脫殼機??。而加密殼（如ASProtect,Armadillo）?一般很少有脫殼機，必須手工脫殼。手工脫殼一般情況是分三步：一是查找程序的真正入口點（OEP）；二是抓取內存映像文件；三是輸入表重建。（當然現在的加密殼復雜些，要考慮更多的東西）
???OEP是Original?Entry?Point縮寫，即程序加殼前的真正的入口點。
???外殼初始化的現場環境（各寄存器值）與原程序的現場環境是相同的。加殼程序初始化時保存各寄存器的值，外殼執行完畢，會恢復各寄存器內容。其代碼形式一般如下：
????PUSHFD?????????;?將標志寄存器入棧保存
????PUSHAD?????????;?push?eax,?ecx,?edx,?ebx,?esp,?ebp,?esi,?edi
????……???????????;?外殼代碼部分
????POPAD??????????;?pop?edi,?esi,?ebp,?esp,?ebx,?edx,?ecx,?eax
????POPFD??????????;?恢復標志寄存器
????JMP?OEP????????;?
OEP:?……??????????;?解壓后的程序原代碼
???為了講述方便，本節用UPX加殼的Win98記事本來演示。首先用PEid查看加殼前的記事本：
?
???PEid顯示Notepad.exe程序是用Microsoft?Visual?C++?6.0編譯的，接下來用UPX來加殼，方法是開個DOS窗口，用命令upx?notepad.exe。如下圖所示：
???這時再用PEid查看加殼的文件，PEid會給出如下信息：UPX?0.89.6?-?1.02?/?1.05?-?1.24?->?Markus?&?Laszlo
???UPX的殼可以用UPX.exe自身來脫，命令是：upx?-d?文件名?。一些變種的UPX殼用UPX.EXE自身脫不了，這時可以試試UPX?ShellEx?這款工具。
?本節實例下載：notepad.upx.rar?
???脫殼前建議用PE工具LordPE打開目標文件查看一下區塊，以盡可能地多了解一些信息，對脫殼有幫助，如下圖：
?
1.根據跨段指令尋找OEP
???推薦用Ollydbg來調試脫殼，比SoftICE和TRW2000方便多了。運行Ollydbg，點擊菜單“選項/調試設置”，將第一次暫停設在WinMain函數上。再用Ollydbg打開實例notepad.upx.exe就可中斷在外殼的入口點處了：
?
上圖相關代碼如下：
0040E8C0?>??60??????????????pushad?????//一開始Ollydbg就會中斷這行，這個就是外殼的入口點,注意這個pushad指令
????絕大多數加殼程序在被加密的程序中加上一個或多個段，所以依據跨段的轉移指令（JMP）就可找到真正的入口點，此時就會有POPAD/POPFD指令出現。UPX?用了一次跨段的轉移指令（JMP），在跳到OEP處會看到虛擬地址的值有一個突變，此時就能確定OEP了。
????UPX殼比較簡單，大家不必要跟蹤去找這個跨段的轉移指令，中斷WinMain后，只需要在Ollydbg里往下翻屏，就會發現這個跨段轉移指令：
?
上圖相關代碼如下：
0040EA0E????61??????????????popad????????????//注意這里的popad指令，和開始的pushad對應?????????????
0040EA0F??-?E9?B826FFFF?????jmp?????004010CC??//這里跳到OEP,將光標移到這，按F4執行到這行
???這一句0040EA0F???jmp??004010CC?就是跳到OEP的指令，執行到這，UPX外殼己將程序解壓完畢，并模擬Windows加載器的將原始程序加載到內存，004010CC?就是映射到內存目標程序的入口點，此時就可抓取內存映像文件了。
2.根據堆棧平衡原理找OEP
???這個堆棧平衡原理其找OEP原理這篇文檔描述的比較詳細：尋找真正的入口（OEP）--廣義ESP定律?作者:Lenus
操作方法：多數殼在運行到OEP的時候ESP=0012FFC4，這就是說程序的第一句是對0012FFC0進行寫入操作，只要在0012FFC0下硬件寫入斷點（命令行里鍵入HW?12FFC0），我們就能停在OEP的第二句處。
???用OllyDBG重新加載實例程序notepad.upx.exe，在命令行下硬件寫斷點：
?
???按F9執行程序，就會中斷在OEP第二行：
?
此時如果將光標向上移，會發現第一句代碼變亂了：
004010C7????000D?0A000055??add?????[5500000A],?cl
004010CD????8BEC???????????mov?????ebp,?esp
這是因為Ollydbg將數據當匯編代碼來分析了，你可以按?Ctrl＋ALT＋向上光標鍵?將當前顯示的代碼向上滾動一個字節就可看到正確的匯編代碼了：
004010CC????55??????????????push????ebp
004010CD????8BEC????????????mov?????ebp,?esp???//中斷在這行
004010CF????83EC?44?????????sub?????esp,?44
004010D2????56??????????????push????esi
004010D3????FF15?E4634000???call????[4063E4]?????????????????????????;?kernel32.GetCommandLineA
中斷后，別忘點擊菜單“調試/硬件斷點/”打開硬件斷點面板，將剛才的硬件斷點刪除。
?
小知識：?硬件斷點的原理?作者:Lenus??
3.根據編譯語言特點找OEP
???各類語言編譯的文件入口點都有一些規律，可以這利用這點來尋找入口點。
1）Delphi程序
執行程序，用LordPE（或Prodump）選dump(full)脫殼，存為dump.exe。接著用Hex?Workshop打開dump.exe，搜索文本“runtime”，搜到后，向前查找離“runtime”最近的十六進制數字“55?8B?EC”，數字所在的地址就是程序的OEP。
2）Visual?C程序
可以利用Visual?C啟動部分的幾個函數GetCommandLineA(W)、GetVersion、GetModuleHandleA(W)、GetStartupInfoA(W)?等來定位程序的OEP。
???常見的各類編譯語言的入口匯編代碼都要熟悉，因為一些加密強殼會偷OEP處的代碼到殼里，一般情況各編譯語言入口代碼都相同，到時只需要直接引用相關程序的入口代碼，這給我們恢復代碼帶來方便。
4.用內存斷點找OEP
Author：Lenus
From:???http://www.popbase.net/?&?http://www.pediy.com/
E-mail：Lenus_M@163.com
--------------------------------------------------
1.前言
???發現論壇中很多兄弟在詢問：什么是二次內存斷點，三次內存斷點。還有很多人對內存斷點的原理不是很明白。其實只要懂得殼是如何解壓代碼的，那么就完全可以按自己的喜歡來下斷。
???
???本文要解決的問題是：
???1.什么是內存斷點？
???2.如何在尋找OEP時使用內存斷點。
???3.內存斷點的局限性。
???
2.內存斷點尋找OEP的原理
??i.首先，在OD中內存斷點，硬件斷點和普通斷點（F2下斷）是有本質區別的。硬件斷點等效與SoftICE命令bpm，他的中斷要用到DR0-DR7的調試寄存器，也就是說OD通過這些DR0-DR7的調試寄存器來判斷是否斷下。
????普通斷點（F2下斷）等效于bpx，他是在所執行的的代碼的當前地址的一個字節修改為CC（int3）。當程序運行到int3的時候就會產生一個異常，而這個異常將交給OD處理，把這個異常的regEIP-1以后就正好停在了需要的中斷的地方（這個根據系統不同會不一樣），同時OD在把上面的int3修改回原來的代碼。
??而內存斷點基本上使用的是對代碼使用的保護屬性來實現中斷。
??內存斷點分為：內存訪問斷點，內存寫入斷點。
??我們知道，在程序運行的時候會有3種基本的狀態產生：讀取，寫入，執行。
004AE242?????A1?00104000???????mov?eax,dword?ptr?ds:[004AE24C]????????????//004AE24C處的內存讀取
004AE247?????A3?00104000???????mov?dword?ptr?ds:[004AE24C],eax????????????//004AE24C處的內存寫入
004AE24C?????83C0?01???????????add?eax,1??????????????????????????????????//004AE24C處的內存執行
??
??那么我們應該如何中斷在上面的幾行呢？
??1.當我們對004AE24C下內存訪問斷點的時候，可以中斷在004AE242也可以中斷在004AE247。
??2.當我們對004AE24C下內存寫入斷點的時候，只能中斷在004AE247。
??3.當我們對004AE24C下內存訪問斷點的時候，能中斷在004AE24C。
??到這里你可能不明白了，為什么內存訪問斷點能中斷在004AE247這一句對004AE24C的寫入，而且還能中斷在004AE24C的執行呢？
??其實很簡單，我們只要仔細體會一下“內存訪問”這四個字的含義遍可以知道，當我們對004AE24C進行讀取的時候需要“訪問”他吧，當我對004AE24C進行寫入的時候也需要“訪問”他吧！！當然我們要執行內存地址004AE24C的代碼的時候也是還是要“訪問”他的！
??所以我們不難得出下面的結論：
??1.內存寫入中斷的地方，一定是也可以用內存訪問中斷。
??2.內存執行的地方，也可以用內存訪問中斷。
??如果這時你認為，那么內存寫入豈不是沒用了。呵呵~那我要告訴你當然不是，如果你想快速的準確的定位到004AE247這一行的時候，那么他就大有作用了！
??總結一下：內存斷點不修改改原代碼，不會像普通斷點那樣因為修改代碼被程序校驗而導致中斷失敗；對于區段的訪問只是區域大了一點，其原理和上面分析的三行代碼是一樣的。
??ii.如何使用內存斷點來尋找OEP呢？
??要回答這個問題首先要回答這一個問題：殼是如何解壓代碼的？
??正如我們知道的，殼如果要把原來加密或壓縮的代碼運行起來就必須要解壓和解密原來的代碼。而這一個過程我們難道不能將他看做是對代碼段（code段）的寫入嗎？好了，解壓完畢了。我們要從殼代碼的區段JMP到原來的代碼段的時候，難道不正是對代碼段（code段）的執行嗎？
??理清了上面的關系就好辦了，那么如果載入OD后，我們直接對code段下內存訪問斷點的時候，一定會中斷在殼對code段的寫入的代碼的上面，就像上面的004AE247的這一行。而如果當他把code段的代碼全部解壓解密完畢了以后，JMP到OEP的時候，我們是不是還可以停在OEP的代碼上面呢？而且每按下F9都會中斷，因為這時code段在執行中哦！
??相信很多人到這里已經明白了，為什么在教程中到達了某一個時候，某一行的時候。牛人們就叫我們對code段下內存訪問斷點了吧。
??而如果你還要繼續問我為什么一定要到那個地方才可以下斷呢？我難道不可以一開始就下斷嗎？
??正入我上面所說的，如果你在前面下斷很可能殼對code段還沒解壓完畢呢，這時如果你不停的按F9，你將會看到OD的下方不斷的在提示你“對401000寫入中斷”?“對401002寫入中斷”“對401004寫入中斷”.......如果你不介意按F9到他把正個code段寫完的話，我除了同情你的“F9”以外，沒什么其他的意見！
??
??那么我們就沒有別更快一點的辦法了嗎？
??有的！那就是我們呼之欲出的兩次內存斷點辦法。
??怎么理解兩次內存斷點呢？
??讓我來做一個假設吧，假設我是一個殼的作者。一個EXE文件的有code段，data段，rsrc段.....依次排列在你的內存空間中，那么我會怎么解碼呢？呵呵~我比較笨一點，我會先將code段解碼，然后再將data段解壓，接著是rsrc段......那么聰明的你不難發現，只要你在data斷或者rsrc段下內存訪問斷點，那么中斷的時候code段就已經解壓完畢了。這時我們再對code段下內存反問斷點，不就可以到達OEP了嗎？
??這里注意上面雖然下了兩次內存訪問斷點，但是本質是不一樣的，目的也是不一樣的。
??1.對data段下內存訪問斷點而中斷是因為內存寫入中斷，目的是斷在對對data段的解壓時，這時殼要對data段寫數據，但是code段已經解壓完畢。
??2.對code段下內存訪問斷點而中斷是因為內存執行中斷，目的當然就是尋找OEP了。
??總結一下：如果我們知道殼在什么地方對code段解壓完畢我們就可以使用內存斷點，找到OEP。如果不知道，那么我們就依靠2次內存斷點去找，如果還不行就用多次內存斷點。總之明白了原理在多次的內存斷點其實都一樣。從這個過程中我們了解的是殼在對區段解碼的順序！
??iii.實戰
??說了這么多，我想大家都越越欲試了吧。
??好吧，來弄一個猛殼怎么樣：
注：本節實例有些難度，不適合新手練習，新手可以跳過這個實例的學習，等找到合適的實例會補充上來的?
?
本節實例下載：unpackme.rar?
??這個殼是一個hying的舊版，我們用他來實驗一下我們內存斷點法。
??
??OD載入以后來到這里
0040D000?u>??56????????????????????push?esi??????????????//這里
0040D001?????52????????????????????push?edx
0040D002?????51????????????????????push?ecx
0040D003?????53????????????????????push?ebx
0040D004?????55????????????????????push?ebp
0040D005?????E8?15010000???????????call?unpackme.0040D11F
??根據跟過一次的經驗我們將先設置，除int3異常以外忽略其他異常，SHIFT+F9
?
003725B1????64:8925?0000000>???????mov?????fs:[0],?esp
003725B8????CC?????????????????????int3
003725B9?????90????????????????????nop????????????????????//到這里
003725BA?????8BCD??????????????????mov?ecx,ebp
??然后再設置除“除零”異常外，忽略其他異常。SHIFT+F9
?
00372660?????F7F3??????????????????div?ebx????????????????//到這里
00372662?????90????????????????????nop
??
??下面是很多的單步異常，太麻煩我們不管他，現在開始用內存斷點的方法（記得將所有異常忽略）。
對code段下內存訪問斷點，希望他已經解壓完畢。方法是按ALT＋M鍵打開內存窗口，在.code段按F2設斷：
?
SHIFT+F9執行：
0040D19D?????A4????????????????????movs?byte?ptr?es:[edi],byte?ptr?ds:[esi]?????????//還沒解完呢
0040D19E?????B3?02?????????????????mov?bl,2
對data段下內存“寫入”斷點，試試看他是不是要寫data段。
00372712?????F3:A4?????????????????rep?movs?byte?ptr?es:[edi],byte?ptr?ds:[esi]??????//斷到這里
00372714?????5E????????????????????pop?esi
下面再對code段下內存訪問斷點。F9
00372855?????8907??????????????????mov?dword?ptr?ds:[edi],eax?????????????????????????;?SHELL32.DragFinish??//這里是對IAT加密
的地方了！！！
00372857?????5A????????????????????pop?edx
00372858?????0FB642?FF?????????????movzx?eax,byte?ptr?ds:[edx-1]
0037285C?????03D0??????????????????add?edx,eax
0037285E?????42????????????????????inc?edx
0037285F?????83C7?04???????????????add?edi,4
00372862?????59????????????????????pop?ecx
00372863???^?E2?A9?????????????????loopd?short?0037280E
00372865???^?E9?63FFFFFF???????????jmp?003727CD
0037286A?????8BB5?93060000?????????mov?esi,dword?ptr?ss:[ebp+693]??????????????????????//到這里下斷F2
現在如果再對data下訪問斷點已經是沒用了。這時應該格外的小心。
我們現在就想既然這一段是對code解碼的，那么我們就繞過他吧！
到0037286A下斷F2，然后清除內存斷點！！！！
F9以后停在這里，繼續對code下內存訪問斷點。
看看左下角還在解碼，哎~真是麻煩！
003728E1????/EB?1D?????????????????jmp?short?00372900
003728E3????|25?FFFFFF7F???????????and?eax,7FFFFFFF
003728E8????|0385?83060000?????????add?eax,dword?ptr?ss:[ebp+683]
003728EE????|2B85?8F060000?????????sub?eax,dword?ptr?ss:[ebp+68F]
003728F4????|8BDE??????????????????mov?ebx,esi
003728F6????|2BD8??????????????????sub?ebx,eax
003728F8????|8958?FC???????????????mov?dword?ptr?ds:[eax-4],ebx?????????????????????//停在這里
003728FB????|83C7?08???????????????add?edi,8
003728FE???^|EB?DB?????????????????jmp?short?003728DB
00372900????\64:FF35?30000000??????push?dword?ptr?fs:[30]??????????????????????????//清除內存斷點以后到這里下斷，F9
又是一段解碼的代碼，再次使用上面的辦法手動跳出去。
現在繼續對code段下內存訪問斷點！！F9以后到達這里。
004010CC?????FFD7??????????????????call?edi???????????????????????????????????????????;?unpackme.004010CE???//OEP哦
004010CE?????58????????????????????pop?eax
004010CF?????83EC?44???????????????sub?esp,44
004010D2?????56????????????????????push?esi
004010D3?????90????????????????????nop
004010D4?????E8?B518F7FF???????????call?0037298E
004010D9?????8BF0??????????????????mov?esi,eax
呵呵~雖然不是我們熟悉的OEP，但是地址是沒錯了，況且根據我們的步驟，我可以很肯定的說這是code段的第一次“執行”中斷！
所以這就是OEP了。
總結一下：當我們在尋找OEP的時候，要多次對code下斷“賭”一“賭”他解壓完畢，如果不是就對別的段試試~如果程序跑飛了，那就沒辦法了，重來唄~其實說起來要賭的是：當data段，idata段，rsrc段擺在你的面前，你會好好“珍惜”那個段，不過還好上天還會給我們從來一次的機會（ctrl+F2?^_^），那么我們會對那個不會跑飛的段說3個字----“先斷你”如果非要在上面加一個次數，我希望是“一次內存斷點就好了”
??vi.下面來討論一下內存斷點的局限性問題。
??是不是什么殼都可以用內存中斷啊？
??不是每個都可以的，一些像UPX和ASPACK就不行。
??為什么？
??呵呵~follew?me！
??情況1.
??我們來看看UPX的殼
??
首先，他的殼代碼在UPX1段。
這里是他要跳到OEP的地方
0040ED4F????/77?11?????????????ja?short?NOTEPAD_.0040ED62????????????
0040ED51????|01C3??????????????add?ebx,eax
0040ED53????|8B03??????????????mov?eax,dword?ptr?ds:[ebx]
0040ED55????|86C4??????????????xchg?ah,al
0040ED57????|C1C0?10???????????rol?eax,10???????????????????????????//在解碼
0040ED5A????|86C4??????????????xchg?ah,al
0040ED5C????|01F0??????????????add?eax,esi
0040ED5E????|8903??????????????mov?dword?ptr?ds:[ebx],eax
0040ED60???^|EB?E2?????????????jmp?short?NOTEPAD_.0040ED44
0040ED62????\24?0F?????????????and?al,0F
0040ED64?????C1E0?10???????????shl?eax,10
0040ED67?????66:8B07???????????mov?ax,word?ptr?ds:[edi]
0040ED6A?????83C7?02???????????add?edi,2
0040ED6D???^?EB?E2?????????????jmp?short?NOTEPAD_.0040ED51????????//回跳解碼
0040ED6F?????61????????????????popad
0040ED70???-?E9?5723FFFF???????jmp?NOTEPAD_.004010CC?????????????//跳到OEP
我們看到他在對code段解壓完畢的時候馬上就JMP到OEP去了，那么我們根本就來不及使用內存斷點的辦法。
你可能說，我可以在
0040ED6F?????61????????????????popad?//這一句下段然后使用啊
呵呵~~當然可以，不過你把花在下內存斷點的時間，多按下幾次F8不更好？！
也就是說當一個殼如果他在JMP?到OEP前的一行代碼仍在都在對code段解壓，那么我們就不能再使用這種辦法了！
或者說我們沒必要使用內存斷點更貼切一點！
??情況2.
??對于一些在OEP處有stolen?code的代碼
??我們來看看一個OEP
0049E2F4?u>??55????????????????push?ebp???????????????????????????????//OEP
0049E2F5?????8BEC??????????????mov?ebp,esp
0049E2F7?????83C4?F4???????????add?esp,-0C
0049E2FA?????B8?BCE04900???????mov?eax,unpack.0049E0BC
0049E2FF?????E8?048CF6FF???????call?unpack.00406F08???????????????????//這里調用子程序
0049E304?????A1?B8FE4900???????mov?eax,dword?ptr?ds:[49FEB8]
0049E309?????50????????????????push?eax
0049E30A?????6A?00?????????????push?0
0049E30C?????68?1F000F00???????push?0F001F
0049E311?????E8?E68EF6FF???????call?<jmp.&kernel32.OpenFileMappingA>??//API
0049E316?????A3?60194A00???????mov?dword?ptr?ds:[4A1960],eax
0049E31B?????833D?60194A00?00??cmp?dword?ptr?ds:[4A1960],0
這個軟件在被PESPIN加殼了以后這些全被偷掉了！
也就是說，殼在模擬OEP代碼的時候必然會執行
0049E2FF?????E8?048CF6FF???????call?unpack.00406F08??//這一步
而這個地方是call向code段的。如果我們使用內存訪問斷點，那么就停在這個子程序的地方
00406F08?????50????????????????push?eax????????????????????????????????????????//會停在這里
00406F09?????6A?00?????????????push?0
00406F0B?????E8?F8FEFFFF???????call?<jmp.&kernel32.GetModuleHandleA>
00406F10?????BA?04F14900???????mov?edx,unpack.0049F104
00406F15?????52????????????????push?edx
這里既不是處理stolen?code的地方，也不是FOEP的地方。這就會對我們的判斷產生誤導。
當然你可以alt+F9返回到殼處理stolen的地方，然后用內存斷點，或者按幾下F8到達FOEP處，但試問如果你拿到一個未知的殼的時候又怎么知道應該這么處理呢？
還有其他一些情況留給大家總結吧！
在下的磚已拋出，各位的玉不久矣。
--------------------------------------------------
3.總結
??????好了說了很多，大家應該對內存斷點的辦法有了全面的了解，如果了解了內存斷點的原理就不難明白他的使用方法，不難明白為什么有寫殼不能使用內存斷點的辦法，其實任何的一種辦法都需要經驗的積累。相信如果大家在回答開篇的3個問題，已經不難了。
??????大家可以結合原理再好好的體會一下《手動脫殼進階第八篇Skvp1.32》這篇文章。
?
第七課?Dump內存映像
外殼程序解壓還原后就會跳到OEP處執行，此時內存映像文件是己解壓的程序。這時就可抓取內存映像文件了（該過程稱為Dump）。當然不一定非要在程序原入口點抓取，只要能保證內存映像文件是己還原的就行了。
????有關Dump技術的原理大家可以參考：淺談脫殼中的Dump技術??作者:Lenus?
????繼續上一個實例notepad.upx.exe，到OEP后就可以Dump取內存映像文件：
004010CC????55?????????????push????ebp
004010CD????8BEC???????????mov?????ebp,?esp
004010CF????83EC?44????????sub?????esp,?44
???運行LordPE.EXE，點擊Options，默認選項如下：
?
默認選上“Full?dump:paste?header?from?disk”，PE頭的信息直接從磁盤文件獲得。設置好后，在LordPE的進程窗口選擇notepad.upx.exe，點擊右鍵，執行“dump?full”菜單命令。如圖：
???將內存抓取的文件另存為dumped.exe，此時程序還不能運行，接下來就是重建輸入表。
第八課?重建輸入表
在脫殼中輸入表處理是很關鍵的一個環節，因此要求脫殼者對PE格式中的輸入表概念非常清楚。在磁盤文件中，PE文件的輸入表結構如下圖所示：
?????????????????????????圖8.1?磁盤文件中的輸入表
???PE文件運行時，Windows系統加載器首先搜索OriginalFirstThunk，如果存在，裝載程序迭代搜索數組中的每個指針，找到每個IMAGE_IMPORT_BY_NAME結構所指向的輸入函數的地址，然后用函數入口地址來替代由FirstThunk指向的?IMAGE_THUNK_DATA?數組里的元素值（即用真實的函數地址填充到IAT里）。因當PE文件裝載內存后準備執行時，上圖己轉換成這種情況了：
?????????????????????????圖8.2?PE文件裝載內存后的輸入表
???此時輸入表中其它部分就不重要了，程序依靠IAT提供的函數地址就可正常運行（圖8.2?紅圈部分）。如果程序加殼了，那殼自己模仿Windows裝載器的工作來填充IAT中相關的數據，此時內存中就一張IAT表，輸入表的其他部分是不存的（當然不是絕對的，也有不少殼，如Aspack等，內存中會出現完整的輸入表結構），如圖8.3所示。
???????????????????????
?????????????圖8.3?外殼加載程序后的內部IAT
???輸入表重建就是根據圖8.3這張IAT恢復整個輸入表的結構（即圖8.1這個結構），ImpREC這款工具就是這個功能。
???一些壓縮殼，填充IAT過程中沒做什么手腳，用ImpREC工具可以直接重建輸入表。而一些加密殼為了防止輸入表被還原，就在IAT加密上大作文章，此時殼填充IAT里的不是實際的API地址，而是填充殼中用來HOOK-API的外殼代碼的地址。這樣殼中的代碼一旦完成了加載工作，在進入原程序的代碼之后，仍然能夠間接地獲得程序的控制權。?因為程序總是需要與系統打交道，與系統交道的途徑是API，而API的地址已經替換成了殼的HOOK-API的地址，那程序每一次與系統打交道，都會讓殼的代碼獲得一次控制權，這樣殼可以進行反跟蹤繼續保護軟件，同時也可完成某些特殊的任務。所以重建輸入表的關鍵是獲得沒加密的IAT?，一般的做法是跟蹤加殼程序對IAT處理過程，修改相關指令，不讓外殼加密IAT。
???UPX、ASPack等加殼保護的殼沒加密IAT，而ASProtect、tElock等加密保護的殼都對IAT進行了加密處理。這篇先來簡單的，即UPX殼。用OD打開上面的notepad.upx.exe實例，運行到OEP。（實際跟蹤過程中，不一定要到OEP，只要外殼處理完IAT就可）然后如下操作：
1)?運行ImportREC，在下拉列表框中選擇notepad.upx.exe進程，如圖：
2)?上面己得知notepad.upx.exe的OEP地址是4010CC，則在左下角OEP處填入OEP的RVA值，這里填上10CC。點擊“IAT?AutoSearch”按鈕，讓其自動檢測IAT偏移和大小，如出現下圖表示ImportREC自己找到IAT的地址與大小了，即IAT地址：000062E0，大小248。
如果ImportREC沒找到IAT偏移，則必須手工填入IAT偏移和大小（IAT偏移手動獲得以后再講述）。
3)?點擊“Get?Import”按鈕，讓其分析IAT結構得到基本信息，如下圖所示：
4)如發現某個DLL顯示"valid?:NO"?，按"Show?Invalids"按鈕將分析所有的無效信息，在Imported?Function?Found欄中點擊鼠標右鍵，選擇"Trace?Level1?(Disasm)"，再按"Show?Invalids"按鈕。如果成功，可以看到所有的DLL都為"valid:YES"字樣；?
5)再次刷新"Show?Invalids"按鈕查看結果，如仍有無效的地址，繼續手動用右鍵的Level?2或3修復；
6)如還是出錯，可以利用"Invalidate?function(s)"、"Delete?thunk(s)"、編輯Import表（雙擊函數）等功能手動修復。
7)開始修復已脫殼的程序。選擇Add?new?section?(缺省是選上的)?來為Dump出來的文件加一個Section(雖然文件比較大，但避免了許多不必要的麻煩)?。
8)單擊"Fix?Dump"按鈕，并選擇剛在前面己Dump出來的文件。如修復的文件名是"Dump.exe"，它將創建一個"Dump_.exe"，此外OEP也被修正。
????經過這些步驟，這個UPX殼己成功脫掉。此時再用PEID查一下脫殼后的程序dumped_.exe，會顯示是“Microsoft?Visual?C++?6.0?SPx?Method?1”，如下圖所示：
再用LordPE查看脫殼后的輸入表：
從上圖可以看出，輸入表己正確修復，此時脫殼后的文件己能成功運行了。
?
?
第九課?手動確定IAT的地址與大小
?????在第八課中講到，點擊ImportREC的“IAT?AutoSearch”按鈕，一般情況下ImportREC可以自動識別出IAT地址與大小。但如果不能自動識別，就必須手動確定IAT地址與大小，然后將IAT的RVA與Size填進ImportREC，點擊“Get?Import”按鈕就可得到輸入表。
????還是用上一節實例演示，用OD打開notepad.upx.exe，來到OEP處：
????隨便找一個API函數調用語句，如：
004010D3????FF15?E4634000???call????[4063E4]??????????;?kernel32.GetCommandLineA
???其中地址4063E4就是IAT中的一部分，在數據窗口下命令：D?4063E4，顯示如下：
??上圖每一組數據都是指向一個API函數，如?8D?2C?81?7C?就是地址：7C812C8D，在OD里按Ctrl＋G，輸入7C812C8D跳到這個地址就會發現是kernel32.GetCommandLineA函數：
???IAT是一塊連續排列的數據，因此在數據窗口向上翻屏，直到出現00數據，尋找IAT起始地址：
然后向下翻屏，尋找IAT結束地址：
為了直觀些，你也可以這樣讓數據窗口直接顯示這些API函數，以確定IAT是否正確，在數據窗口點擊鼠標右鍵：
調整顯示格式后的數據窗口：
這樣就直觀了，IAT中每組數據指向一個API函數，各DLL之間是以000000分開的。
因此IAT范圍：0x4062E4～0x406524?，大小為0x406524-0x4062E4=0x240?
如果IAT加密了，此時IAT中的地址不是指向系統DLL中的API函數了，可能指向外殼。這就十分有必要找到外殼處理IAT的代碼了，前面己說過，外殼加載時，會模擬Windows加載器，向IAT里填充當前操作系統API函數的實際地址。所以，在IAT里設個內存寫斷點，就可中斷到這段代碼處。
重新加載notepad.upx.exe，在IAT某個地址下內存寫斷點，這里選擇0x4062E4這個地址設內存寫斷點，先在數據窗口下命令：D?4062E4
然后選擇一個地址，點擊鼠標右鍵，下“內存寫斷點”。
此時只要有數據寫入4062E4地址處，OD就會中斷，按F9運行OD，會中斷這里：
0040E96D????>?/8A02??????????mov?????al,?[edx]
0040E96F????.?|42????????????inc?????edx
0040E970????.?|8807??????????mov?????[edi],?al
0040E972????.?|47????????????inc?????edi
0040E973????.?|49????????????dec?????ecx
0040E974????.^\75?F7?????????jnz?????short?0040E96D
這段還不是處理IAT，按F9繼續執行程序，會中斷這里：
0040E9E9????>?/8A07??????????mov?????al,?[edi]
0040E9EB????.?|47????????????inc?????edi
0040E9EC????.?|08C0??????????or??????al,?al
0040E9EE????.^|74?DC?????????je??????short?0040E9CC
0040E9F0????.?|89F9??????????mov?????ecx,?edi
0040E9F2????.?|57????????????push????edi????????????????????????//?函數名字符串??
0040E9F3????.?|48????????????dec?????eax
0040E9F4????.??F2:AE?????????repne???scas?byte?ptr?es:[edi]
0040E9F6????.?|55????????????push????ebp????????????????????????//?DLL模塊句柄
0040E9F7????.??FF96?A4EC0000?call????[esi+ECA4]?????????????????;??kernel32.GetProcAddress
0040E9FD????.?|09C0??????????or??????eax,?eax
0040E9FF????.?|74?07?????????je??????short?0040EA08
0040EA01????.?|8903??????????mov?????[ebx],?eax????????????????//?EBX指向IAT,將取得的API地址填充進IAT
0040EA03????.?|83C3?04???????add?????ebx,?4????????????????????//?指向下一個地址
0040EA06????.^\EB?E1?????????jmp?????short?0040E9E9
0040EA08????>??FF96?A8EC0000?call????[esi+ECA8]
上面這段就是UPX外殼填充IAT的全過程，感興趣的，動態跟蹤一下就明白了。這里用GetProcAddress函數獲得函數地址：
FARPROC?GetProcAddress(
??HMODULE?hModule,????//?DLL模塊句柄
??LPCSTR?lpProcName???//?函數名
);
?
?
為了方便大家學習脫猛殼技術，根據我自己的經驗，將一些比較不錯的文章列出：
Obsidium殼：?
Obsidium外殼學習手記??
Obsidium1.2.5.0主程序脫殼記錄點滴??（SDK修復部分）
Armadillo殼：?
試玩armadillo3.50a一點心得??（基礎知識）
Armadillo?COPYMEMEII之DUMP的一個LOADPE小插件??（利用插件Dump取COPYMEMEII保護的程序）
Armadillo?3.6主程序脫殼???（Dump取COPYMEMEII保護的程序另一方法）
Patch?修復?Armadillo?的IAT亂序?（處理IAT亂序）
Armadillo中code?splicing的幾種處理方法?（手工修復Code?Splicing）
Armadillo客戶版Code?Splicing+Import?（利用ArmInline工具修復Code?Splicing）
淺談Armadillo?V.3.75?與?V.3.78的保護??（Nanomites原理概念，即CC保護）
Blaze?Media?Pro5.05脫殼＋基本修復CC(int3)＋破解??（修復CC）
Armadillo?V4.40主程序脫殼??（目前處理CC很好的一個方法）
ASProtect?2.x?SKE殼：?
nspack3.5主程序脫殼分析(Aspr?SKE?2.X)???(輸入表)
Asprotect?SKE?2.2?的Advanced?Import?protection保護技術??(輸入表)
萊鳥脫Aspr2.11?SKE+修復stolen???(Dump法對付stolen?OEP)
ASProtect.SKE.2.11?stolen?code解密??(ASProtect?2.11的stolen與SDK修復技術?)
ASProtect_SKE_2.3Beta_Build0319?stolen?code分析?(ASProtect?2.22/2.23的stolen與SDK修復技術?)
Asprotect?2.XX?SKE?IAT?Fixer?(ASProtect?腳本，功能非常強大！?)
……（ASProtect?2.x部分沒完成）
總結
- 上一篇： android 汉字字母排序,andro
- 下一篇： *16.5 shared_ptr使用场景