-
-
[原创]一个简单的压缩自检壳（全部由Delphi编写）
-
发表于: 2008-7-16 21:02
-
很简单的一个压缩自检壳，完全用Delphi编写。原理：将目标程序的压缩流附加到Loader的尾部，加载时还原道内存并执行。
压缩是通过Delphi自带的TCompressionStream压缩流实现的。而自效验部分是自己弄了个Hash函数，移位亦或了一下。没什么特别的东西，所以说是个“很”简单的壳...
作用就很明显了，给常用的几个程序都打上了这个壳后，有病毒感染会因为Hash值不一样而报警，这样就知道该Ghost恢复一下，不用实时装个后台进程一大堆的杀毒软件占资源了。具体的可以看压缩包2里的“说明.doc”。
起因是看到了Anskya的MemRun单元，感觉挺有意思的，于是写了这个压缩壳。由于没有做图标处理，所以加过壳的程序都是Loader的图标。PELoader.res中是一个全白的图标，你可以用资源编辑器改成其它的，比如“烧香的熊猫”，或者“在河边做俯卧撑的人”…… 囧
附件中：
HashShell_Src.rar (63.0 KB) 是源码（Delphi 的）
压缩自检壳.rar (241.8 KB) 编译好的程序，其中Shell.ex_为了减小大小而打了UPX
ps: 最好给Loader程序再打个UPX，这样可以减小加壳后的文件大小，还可以提高脱壳难度（压缩自检壳.rar里那个Shell.ex_就是）。
---------------------------------------------------------------------------
写这个壳只是为了测试一下MemRun的可行性，这个不同于一般的壳是jmp到解压缩后的OEP，手动把PE文件加载到内存更难脱掉。按照传统的脱壳方法跟下去是没用的，因为Loader是通过CreateThread()加载目标，自己完成SetThreadContext()后就僵死在那儿了。
不过仔细想了一下，知道MemRun原理后要脱掉这个壳也相当容易：在ResumeThread()上下断点，然后Attach到该线程中，此时EIP就是入口点，然后就是dump整个程序了
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
收藏，我这里可以正常弹出来
|
|
|
那估计是系统原因了，我SP2（打上最新补丁）和SP3两个系统中都没有弹出对话框或错误提示，不得已，改用了一堆Beep()
另：Loader打上UPX后，脱下来的程序还可以正常执行吗？ 我只试过手脱ASPack 2.12，脱下来的程序可以跑起来： （脱了ASPack后，修改这个就能正常加载） 18216381 /EB 1E JMP SHORT FlowIt_d.182163A1 18216383 -|E9 DCD8FEFF JMP FlowIt_d.18203C64 18216388 |A1 7CEA2118 MOV EAX,DWORD PTR DS:[1821EA7C] 1821638D |E8 E2D4FEFF CALL FlowIt_d.18203874 18216392 |E8 55DBFEFF CALL FlowIt_d.18203EEC 18216397 |E9 99010000 JMP FlowIt_d.18216535 1821639C |E8 4BDBFEFF CALL FlowIt_d.18203EEC 182163A1 \3BDE CMP EBX,ESI 182163A3 0F85 25010000 JNZ FlowIt_d.182164CE ; 判断Hash结果，改JZ 182163A9 A1 7CEA2118 MOV EAX,DWORD PTR DS:[1821EA7C] 182163AE 8B10 MOV EDX,DWORD PTR DS:[EAX] 182164CE 6A 30 PUSH 30 ; Hash出错时跳到这里 182164D0 68 60652118 PUSH FlowIt_d.18216560 ; ASCII "WARNING!" 但UPX 2.02的用UPX -d脱了后，修改jnz -> jz也无法执行，难道是UPX修改了文件尾部的压缩流的数据？ 只手动脱过ASPack，以前遇到UPX都是直接UPX -d来着 
|
|
|
|
|
|
|
|
|
|
|
|
收藏。。。
|
|
|
|
|
|
我这里试过了，卡巴没有报警。
无论是那个PELoader.exe，还是加壳后的程序，都扫描通过了。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
