可执行文件自修改?(200分)

  • 主题发起人 主题发起人 lintel
  • 开始时间 开始时间
L

lintel

Unregistered / Unconfirmed
GUEST, unregistred user!
如何实现可执行程序自修改本身?(利用delphi实现)
 
可以呀,程序员大本影上有一个例子,
 
麻烦把链接告诉我?我这里上网很忙,不方便查询
 
是一张比较老的光盘,好象是2000年的,
 
那我更找不到了
多谢
 
要是修改了不存盘的话就很容易。
 
我记的是该EXE里的资源文件
 
当然要保存了
 
那也不难,自己的程序运行后复制一个副本,然后运行副本,关闭本身,
然后再用副本修改本身就是了。
 
方法不是很好
 
查以前的帖子...
http://www.delphibbs.com/delphibbs/dispq.asp?lid=643213
 
可执行程序运行后,磁盘上的映像属性是不可写的。要修改,就要修改属性值。
不过我感觉很难实现,可能要比较深入。
如果用临时文件什么的方法,那就没有一点技术含量了。
 
我以前也提过类似的问题,可是没人回答.但我坚信是可以实现的,因为我见过这样的程序.
 
Readbook好像就可以自修改
 
to lgxyy:
你确信不是通过临时文件什么的实现得吗?
是什么程序?我可以反汇编看看。
 
我把readbook用ultraedit打开随便改了一些
结果启动时就报被修改,问是否改回来
 
readbook如果没有副本的话,他怎么知道你改了那些?
他可以通过CRC校验,知道文件被改过,但是不可能知道改了那些。
我跟踪了一下,发现ReadBook是通过c:/windows/temp目录下的readbook.ex0文件来
实现修改自己的。那个文件其实就是readbook.exe。我试着把temp目录清空,然后修
改readbook.exe,马上出现非法操作。
 
没有仔细研究过
to:薄荷
你有什么好的意见吗?
 
我原来以为只能通过临时文件的方法来修改,后来我感觉不能修改自己,是因为系统
占用了句柄。这个问题和删除自身,有点类似,对于删除自身(我们不讨论使用bat
文件的方法),是先FreeLibrary自身,解除系统对自身的映像,然后就可以删除了。
当然这些操作必须把操作步骤入栈,由系统来操作。
所以,我们可能同样可以通过先把修改步骤入栈,然后把freeLibrary入栈,出栈
的时候就先free了自身,然后修改磁盘上的映像。
具体的呢,就是在运行的过程里修改内存里的映像,然后在close的时候入栈。
这是我个人的一点看法,希望大家指正。
 
同意楼上的, 需要先解除映象, 然后关闭句柄.
参考
program Project1;

uses
Windows;

procedure DeleteSelf;

var
hModule: THandle;

buff: array[0..255] of Char;

hKernel32: THandle;

pExitProcess, pDeleteFileA, pUnmapViewOfFile: Pointer;

begin

hModule := GetModuleHandle(nil);

GetModuleFileName(hModule, buff, sizeof(buff));

CloseHandle(THandle(4));

hKernel32 := GetModuleHandle('KERNEL32');

pExitProcess := GetProcAddress(hKernel32, 'ExitProcess');

pDeleteFileA := GetProcAddress(hKernel32, 'DeleteFileA');

pUnmapViewOfFile := GetProcAddress(hKernel32, 'UnmapViewOfFile');

asm
LEA EAX, buff
PUSH 0
PUSH 0
PUSH EAX
PUSH pExitProcess
PUSH hModule
PUSH pDeleteFileA
PUSH pUnmapViewOfFile
RET
end;

end;

begin

DeleteSelf;

end.


现在有一点比较古怪,那就是必须把代码放在一个Procedure里,
直接放在begin
... end.
中间是不行的。也许是全局变量不能使用
的缘故,但为什么不能使用,还是不是很清楚。
还有,不GetProcAddress,直接如下写:
PUSH OFFSET UnmapViewOfFile
trace的结果是执行进入了KERNEL32.UnmapViewOfFile的,只是在
函数内RET $4出就出错了,跳到了一个莫名其妙的地方。为什么会
这样?难道是Delphi的编译器的问题吗?
另外,Borland论坛上RE的代码不是上面的,不过效果跟我写的一样
。但是FreeLibrary(p)跟UnmapViewOfFile(hModule)效果一样吗?
代码如下:

program Project1;

uses
windows;

procedure DeleteSelf;

var
module : HMODULE;

buf : array [ 0 .. MAX_PATH - 1 ] of char;

p : ULONG;

hKrnl32 : HMODULE;

pExitProcess, pDeleteFile, pFreeLibrary : pointer;

begin

module := GetModuleHandle ( nil );

GetModuleFileName ( module, buf, sizeof ( buf ) );

CloseHandle ( THandle ( 4 ) );

p := ULONG ( module ) + 1;

//上面这一句什么意思?

hKrnl32 := GetModuleHandle ( 'kernel32' );

pExitProcess := GetProcAddress ( hKrnl32, 'ExitProcess' );

pDeleteFile := GetProcAddress ( hKrnl32, 'DeleteFileA' );

pFreeLibrary := GetProcAddress ( hKrnl32, 'FreeLibrary' );

asm
lea eax, buf
push 0
push 0
push eax
push pExitProcess
push p
push pDeleteFile
push pFreeLibrary
ret
end;

end;



下面的代码由Gary Nebbett写就.Gary Nebbett乃是WINDOWS NT/2000 NATIVE API REFERENCE的作者.乃NT系统一等一的高手.下面就分析一些他的这段代码.
这段代码在PROCESS没有结束前就将启动PROCESS的EXE文件删除了.
int main(int argc, char *argv[])
{
HMODULE module = GetModuleHandle(0);
CHAR buf[MAX_PATH];
GetModuleFileName(module, buf, sizeof buf);
CloseHandle(HANDLE(4));
__asm {
lea eax, buf
push 0
push 0
push eax
push ExitProcess
push module
push DeleteFile
push UnmapViewOfFile
ret
}
return 0;
}
现在,我们先看一下堆栈中的东西
偏移 内容
24 0
20 0
16 offset buf
12 address of ExitProcess
8 module
4 address of DeleteFile
0 address of UnmapViewOfFile
调用RET返回到了UnmapViewOfFile,也就是栈里的偏移0所指的地方.当进入UnmapViewOfFile的流程时,栈里见到的是返回地址DeleteFile和HMODUL module.也就是说调用完毕后返回到了DeleteFile的入口地址.当返回到DeleteFile时,看到了ExitProcess的地址,也就是返回地址.和参数EAX,而EAX则是buffer.buffer存的是EXE的文件名.由GetModuleFileName(module, buf, sizeof buf)返回得到.执行了DeleteFile后,就返回到了ExitProcess的函数入口.并且参数为0而返回地址也是0.0是个非法地址.如果返回到地址0则会出错.而调用ExitProcess则应该不会返回.
这段代码的精妙之处在于:
1.如果有文件的HANDLE打开,文件删除就会失败,所以,CloseHandle(HANDLE(4));是十分巧妙的一手.HANDLE4是OS的硬编码,对应于EXE的IMAGE.在缺省情况下,OS假定没有任何调用会关闭IMAGE SECTION的HANDLE,而现在,该HANDLE被关闭了.删除文件就解除了文件对应的一个句柄.
2.由于UnmapViewOfFile解除了另外一个对应IMAGE的HANDLE,而且解除了IMAGE在内存的映射.所以,后面的任何代码都不可以引用IMAGE映射地址内的任何代码.否则就OS会报错.而现在的代码在UnmapViewOfFile后则刚好没有引用到任何IMAGE内的代码.
3.在ExitProcess之前,EXE文件就被删除了.也就是说,进程尚在,而主线程所在的EXE文件已经没了.(WINNT/9X都保护这些被映射到内存的WIN32 IMAGE不被删除.)
Gary Nebbett果然是WIN系列平台的顶尖高手之一.能写出如此代码.独辟蹊径啊:)
 
后退
顶部