淺談殼的加載步驟及手動脫殼

現(xiàn)在玩脫殼的人越來越多了，不知道是好事還是壞事。 <BR>現(xiàn)在玩手動脫殼一般三樣工具足矣：loader,ImpREC,TRW2000。也許是這三劍客的功能太強大，因此手動脫殼也變得象流水化作業(yè)。大致以下幾個步驟就搞定了。 <BR>1)loader找OEP.(OEP就是程序原來的入口點，即Original Entry Point) <BR>2)TRW2000來Dump。也就是把內存映象保存為文件。 <BR>3)ImpREC修補Import Table.(也就是修補程序原來的API地址) <BR><BR>不過如果這樣，那么我想手動脫殼也沒有必要了，因為更先進的工具如各種脫殼機會更快捷有效。既然是手動脫殼，當然想對殼有所了解，那么讓我們看看殼是如何工作的吧。 <BR><BR>殼和病毒從某些方面比較類似，都需要比原程序代碼更早的獲得控制權，這是通過在原程序的代碼執(zhí)行前加入自己的一段代碼來實現(xiàn)的。注意我說的這是執(zhí)行時的情況。對于文件中的情況，就是殼修改了原程序的執(zhí)行文件的組織結構，從而達到殼的代碼能夠比原程序的代碼提前獲得控制權，并且不會影響原程序的正常運行，所以從這點上說，殼和病毒很類似。 <BR><BR>現(xiàn)在的執(zhí)行文件一般都是PE格式，如果你對PE格式一無所知，最好還是去看一看相關的資料。我沒有那么地道的專業(yè)知識，也怕誤人子弟。 <BR><BR>相關名詞 <BR>1)Entry Point (入口點) <BR>PE格式的可執(zhí)行文件的執(zhí)行時的入口點，即是PE格式中的Entry Point。 <BR>用PEditor或者LordPE之類的PE查看工具看看NotePad.exe，你就會看到Entry Point的值。 <BR>也就是說NotePad.exe在執(zhí)行時的第一行代碼的地址應該就是這個值。（當然應該加上基地址） <BR><BR>2)Section (節(jié)區(qū)) <BR>PE格式文件是按節(jié)區(qū)進行規(guī)劃組織的，不同的節(jié)區(qū)一般保存的數(shù)據(jù)的作用也不相同。通常使用缺省方式編譯的程序文件，有CODE/DATA/TLS/.text/.data/.tls/.rsrc/.rdata/.edata/.reloc等不同的名稱，有的用于保存程序代碼，如CODE和.text節(jié)區(qū)，有的用于保存程序中的變量的，如DATA/.data節(jié)區(qū)，有的保存重定位信息，如.reloc，有的用于保存資源數(shù)據(jù)，如.rsrc。等等等等， <BR><BR>當然這是缺省情況下編譯器產生的結構。 <BR>而節(jié)區(qū)名稱和節(jié)區(qū)中的數(shù)據(jù)其實沒有必然的聯(lián)系， <BR>節(jié)區(qū)中保存的數(shù)據(jù)也沒有什么硬性的限制。所以你可以在編譯時用開關參數(shù)改變這些情況。 <BR><BR>3)ImageBase (基地址) <BR>不僅程序文件按節(jié)區(qū)規(guī)劃，而且程序文件在運行時Windows系統(tǒng)也是按節(jié)區(qū)加載的。那么每一塊的節(jié)區(qū)的順序如何？起始的地址是什么呢？ <BR>這就由基地址決定。在程序的文件頭部保存了每個節(jié)區(qū)的描述信息，比如有前面提到的節(jié)區(qū)名稱，還有節(jié)區(qū)的大小，以及節(jié)區(qū)的相對虛擬地址(RVA)。 <BR>如果我們把節(jié)區(qū)的相對虛擬地址(RVA)加上基地址(ImageBase)就可以知道節(jié)區(qū)在內存中的虛擬地址(VA)了。Windows系統(tǒng)就是按照這個要求來加載各個節(jié)區(qū)的。這樣Windows系統(tǒng)依次把各個節(jié)區(qū)放到了它相應的虛擬地址空間。 <BR><BR>所以如果我們把相對虛擬地址（RVA)看成是坐標的偏移量的話，那么ImageBase就是原點了。有了這個原點，一切都簡單了。 <BR><BR>好了有了簡要的介紹，我們來看看殼的加載過程吧。注意這里說的是一般情況，不特指某個殼，如果那樣的話，我想那大概是洋洋灑灑幾萬字的了，好象我沒有寫過這么長的。雖然我的五筆練得還不錯。 <BR><BR>1)獲取殼自己所需要使用的API地址 <BR><BR>如果你用PE查看工具看看加殼后的程序文件，會發(fā)現(xiàn)未加殼的程序文件和加殼后的程序文件的Import Table不太一樣， <BR>加殼后的Import Table一般所引入的DLL和API很少，甚至只有Kernel32.dll以及GetProcAddress這個API。 <BR><BR>我想你不會認為殼只用這個API就可以做所有的事吧。 <BR>殼還需要很多其他的API來完成它的工作。 <BR>當然他并不想讓你知道他想用哪個API，所以一般他只是在殼的代碼中動態(tài)加載這些API，而只把一些你嗅不過什么味道的幾個API放在Import Table中。 <BR><BR>當然這其中殼可能會用到一些Anti技術，不過這和本文主旨無關，所以就不說了。 <BR><BR>2)解密原程序的各個節(jié)區(qū)(Section)的數(shù)據(jù) <BR><BR>殼出于保護原程序代碼和數(shù)據(jù)的目的，一般都會加密原程序文件的各個節(jié)區(qū)。既然是加密保存，那么在程序執(zhí)行時你總不能也保持加密狀態(tài)吧，所以解密是殼必做的工作之一。 <BR>一般殼按節(jié)區(qū)加密的，那么在解密時也按節(jié)區(qū)解密，并且把解密的節(jié)區(qū)數(shù)據(jù)按照節(jié)區(qū)的定義放在合適的內存位置。 <BR><BR>如果加殼時用到了壓縮技術，那么在解密之前還有一道工序，當然是解壓縮。 <BR>這也是一些殼的特色之一，比如說原來的程序文件未加殼時1-2M大小，加殼后反而只有幾百K，這種瘦身技術當然會吸引了不少眼球。 <BR><BR>3)重定位 <BR>前面我們提到了ImageBase，即程序的基地址，當然這只是程序文件中聲明的，程序運行時能夠保證系統(tǒng)一定滿足你的要求嗎？ <BR>對于EXE的程序文件來說，Windows系統(tǒng)會盡量滿足你的要求。 <BR>比如一般EXE文件的基地址為0x400000，而運行時Windows系統(tǒng)提供給程序的基地址也同樣是0x400000。在這種情況下就不需要進行地址"重定位"了。 <BR><BR>由于不需要對EXE文件進行"重定位"，所以很多殼在加殼時把原程序文件中用于保存重定位信息的節(jié)區(qū)干脆也去掉了，這樣使得加殼后的文件更加小巧。有些工具提供Wipe Reloc的功能，其實就是這個作用。 <BR><BR>不過對于DLL的動態(tài)鏈接庫文件來說，Windows系統(tǒng)沒有辦法保證每一次DLL運行時提供相同的基地址。這樣"重定位"就很重要了。 <BR><BR>此時殼中也需要提供進行"重定位"的代碼，否則原程序中的代碼是無法正常運行起來的。從這點來說，加殼的DLL比加殼的EXE更難修正。 <BR><BR>4)HOOK-API <BR>我們知道程序文件中的Import Table的作用是讓Windows系統(tǒng)在程序運行時提供API的實際地址給程序使用。 <BR>在程序的第一行代碼執(zhí)行之前，Windows系統(tǒng)就完成了這個工作。 <BR><BR>而殼一般都修改了原程序文件的Import Table，那么原程序文件的Import Table由誰來處理呢？ <BR>這當然由殼來自己處理了，因此殼不得不模仿Windows系統(tǒng)的工作來填充Import Table中相關的數(shù)據(jù)。 <BR>Import Table結構中與實際運行相關的主要是IAT結構， <BR>這個結構中用于保存API的實際地址，因此殼所需要的就是填充這個結構中的數(shù)據(jù)。 <BR>不過殼不是填充這些實際的API地址，而是填充殼中用來HOOK-API的代碼的地址。 <BR><BR>這樣殼中的代碼一旦完成了加載工作，在進入原程序的代碼之后，仍然能夠間接地獲得程序的控制權。 <BR>因為程序總是需要與系統(tǒng)打交道，與系統(tǒng)交道的途徑是API，而API的地址已經替換成了殼的HOOK-API的地址，那么每一次程序與系統(tǒng)打交道，都會讓殼的代碼獲得一次控制權，一來殼可以進行反跟蹤繼續(xù)保護軟件，二來可以完成某些特殊的任務。 <BR>其實這就是所謂HOOK技術。 <BR><BR>5)最后當然是跳轉到程序原入口點。 <BR>這個大家比較熟悉，找的就是它。脫殼時大多數(shù)也是在這個時候。從這個時候起殼要把控制權交還給原程序了。 <BR><BR>以上是一個簡單的總結。這代表了大多數(shù)殼的加載過程，不過特殊的不包括在內，介紹一下讓大家了解一些。 <BR>當然還有一些殼充分利用了PE結構的特點，比如利用TLS加載的特點也挺有趣。。。。。 <BR><BR>一點經驗： <BR>手動脫殼不一定要在程序原入口點。沒有人規(guī)定你一定要在那里動手。只要你能保證脫殼后程序正常執(zhí)行就行了。 <BR>當然我們必需得知道這個原入口點的值，否則我們無法修復程序文件中的Entry Point的值了。 <BR>那么手動脫殼還有比較常用的地方嗎？有 <BR><BR>就是前面所提到的第2步完成后。此時Section數(shù)據(jù)已經解密，而且殼還沒有來得及進行Hook-Api，很多殼圖簡單沒有把原程序的Import Table破壞掉，這個時候正是我們下手的好時機。 <BR>要發(fā)現(xiàn)這個地方也很容易，一般重定位代碼的特征是很明顯的。特別是有些殼有壓縮功能的時候，更是容易發(fā)現(xiàn)。 <BR>這個時候脫出來的文件組織一下可以達到和原程序幾乎相同的大小。而不是通常的內存映象大小。 <BR><BR>抱歉，我寫得很倉促，各種錯誤來不及改正。不知道大家能不能看懂我在說什么。希望大家不要以為我在自言自語。 <BR>&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;永遠支持看雪。 <BR>&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;永遠支持看雪論壇。 <BR>