： Mercedes() (2001-8-30 8:41:05) 得0分
前几天才刚刚在Borland的新闻组里看到这个，以下的源代码已经过测试。
运行环境：WIN98+D5
将代码编译好后，把EXE文件拷贝到一张空白的软盘里面，然后从软件里执行这个程序就可以了。
它是用写磁盘绝对位置的方法来修改EXE文件的。
//////////////////////////////
运行时改变自身文件的代码
Here is source code that will create a delphi app that can write to it's own exe file on disk while it runs... win9x only... but you can do the same thing on 95-->xp if you code a different direct sector routine.
It's not magic at all... but it works... Just format a fresh and clean floppy and then compile this code and copy it to the disk... then run it and type in a new DOS stub message in the edit box and press the button... the next time you run the program it will display the DOS stub txt that you entered as it's caption.
This simple minded demo does not look for the sectors that contain your exe because you have placed it on a fresh 1.44 floppy and it know that the dos stub code is in sector 33 :-) but you can code a routine to find all the sectors of an exe on a hd and use the same sort of code to alter all of them...
I worked on a program that downloaded updates from the web and installed them into the running programs exe file... it worked but when I ran it all night doing constant updates on the exe while running a disk defrag it wound up corrupting the hd :-( so I abandoned the scheme in favor of the much safer trick of just appearing to alter an exe's file while it runs....here is the code... I hope the text formats correctly
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ComCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
Edit1: TEdit;
Label1: TLabel;
procedure Button1Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
private
public
end;
var
Form1: TForm1;
const
VWin32_DIOC_DOS_Int25 = 2; // direct read access
VWin32_DIOC_DOS_Int26 = 3; // direct write access
type
TDevIoCtl_Reg = packed Record
Reg_EBX : DWord;
Reg_EDX : DWord;
Reg_ECX : DWord;
Reg_EAX : DWord;
Reg_EDI : DWord;
Reg_ESI : DWord;
Reg_Flags : DWord;
end;
type
TDiskIO = packed record
StartSektor : DWord;
AnzahlSektoren : Word;
PBuffer : DWord;
end;
implementation
{$R *.DFM}
//Demo program that writes new data to the PE
//of a running delphi exe WHILE IT IS RUNNING! :-)
//To use this demo just freshly format a standard
//1.44 mb floppy disk and then copy this exe to it
//run it from the floppy and it can alter itself
//by writting a new DOS stub Message to the exe's file
//on the disk ... the next time the program is run the
//new stub text will be in the caption :-)
//To do this on a HD just discern the location of the
//disk sector that contains the first 512 bytes of this exe
//you can get this from the dir/fat data... this disk code
//only works on fat 16 hd's so you need to recode for fat32
//This is meant to be a demo that proves that contrary to
//popular opinion an exe can write to it's own file while
//running!... but just because something CAN be done does
//not mean that it SHOULD be done! ... you will likely
//wind up destroying data on a HD if you write code to
//locate an exe on the hd and alter it directly...WinDoze
//is totally blind to the fact that you are writing data
//to the sectors directly and will happily move things about
//while you are doing it... and you will wind up overwritting
//the wrong data sooner or later :-(
procedure TForm1.Button1Click(Sender: TObject);
var
x: Integer;
DevIoHandle : THandle;
BytesReturned : DWord;
Reg : TDevIoCtl_Reg;
DiskIO : TDiskIO;
DatenBuffer : Array [0..511] of Byte; // = 512 Bytes
begin
if (length(edit1.text)>35) or (length(edit1.text)=0) then
begin
showmessage('Please enter a new DOS stub text of 1 to 35 chars!');
exit;
end;
with DiskIO do
begin
StartSektor := 33; // from sector 33
AnzahlSektoren := 1; // read 1 sector
PBuffer := DWord(@DatenBuffer);
end;
with Reg do
begin
Reg_EAX := 0; // drive: 0 = A, 1 = B etc.
Reg_EBX := DWord(@DiskIO);
Reg_ECX := $FFFF; // use DiskIO
end;
DevIoHandle := CreateFile(
'\\.\vwin32',
Generic_Read,
File_Share_Read or File_Share_Write,
nil,
Open_Existing,
File_Attribute_Normal,
0);
if DevIoHandle <> Invalid_Handle_Value then
begin
DeviceIoControl(DevIoHandle,
VWin32_DIOC_DOS_Int25,
@Reg,
SizeOf(Reg),
@Reg,
SizeOf(Reg),
BytesReturned,
nil);
for x := 80 to 80 + length(edit1.text) do
begin
DatenBuffer[x] := ord(edit1.text[x-79]);
end;
DeviceIoControl(DevIoHandle,
VWin32_DIOC_DOS_Int26,
@Reg,
SizeOf(Reg),
@Reg,
SizeOf(Reg),
BytesReturned,
nil);
CloseHandle(DevIoHandle);
end;
end;
procedure TForm1.FormCreate(Sender: TObject);
Var x: Byte;
begin
Form1.Caption := '';
For X := 80 to 115 do
begin
Form1.Caption := Form1.Caption +
Char(pointer(Hinstance+X)^);
end;
end;
end.
================
I will zip up a file with all the source files and put it in the attachements group....this will make it easier for anyone that wants to build this silly little demo :-)
p.s.
In the program I wrote to auto-update from the web I was compressing a 500kb delphi app down to 170kb using UPX... then I padded out the compressed file back to the original 500kb using 00H bytes.. this file would then pkzip down to about 160kb because all the 00H's scrunched down
to nearly nothing... this gave me a large space to build out a large update into and let me avoid altering the fat because there was plenty of useable room in the original file...the already allocated sectors were always able to hold a larger updated exe...and all the 00H bytes had no ill effect on the exe before or after an update :-)
--------------------------------------------------------------------------------
***************************************
The Unofficial Newsletter of Delphi Users - by Robert Vivrette
---------------------------------
Self-Modifying Code With Delphi
by Marcus M?nnig - minibbjd@gmx.de
Preface
Lots of people using high-level languages, like Object Pascal, do not know much about what happens with their code when they click compile in Delphi. If you have a basic knowledge about assembler and about the exe file format, the comments in the source code should make everything pretty clear. For everyone else, I will try to explain what's done in the source code.
My own knowledge about assembler and the exe format is limited and I learned most of it while looking for information about piracy protection and how to implement self-modifying code myself. The reason why I did this article is that I found very little information about this issue, so I put everything I found together to share it. Further, english is not my native language, so excuse any spelling and grammatical mistakes.
Self-modifying code with Delphi
What is it? Normally, we modify our code at design time. This usually happens inside Delphi before the code is compiled. Well, we all know this.
Then, sometimes compiled code gets modified, e.g. a patch might be applied to a (non-running) exe file to do changes to the original exe. This is often used when applications are distributed widely and the users want to update to a newer version. To save download time and to prevent that the user has to reinstall the whole application again, only the differences between two versions of an exe file are distributed in a patch file an applied to the old version of the exe. Another example of patch files are "cracks"... little com or exe files that remove built-in limitations (evaluation time limits, etc.) from applications.
These two kinds of code modifications are obviously done before the exe is executed. When an exe file is executed the file gets loaded into memory. The only way to affect the behavior of the program after this point is to modify the memory where the exe now resides.
A program that modifies itself while it is running by doing changes to the memory uses "self-modifying code".
Why is it bad?
Self-modifying code makes debugging harder, since there is a difference in what is in the memory and what the debugger thinks is in the memory.
Self-modifying code also has a bad reputation, especially because the most prominent use for it are viruses, that do all kinds of hide and seek tricks with it. This also means that if you use self-modifying code it's always possible that a virus checker will complain about your application.
Why is it good?
Self-modifying code makes debugging harder. While this is bad if you want to debug your code, it's good to prevent others from debugging your code or at least make it harder for them. This is the reason why self-modifying code can be an effective part of a piracy protection scheme. It won't prevent that an application can be cracked, however a wise use of this technique can make it very hard.
What functions are needed?
In a Windows environment we can make use the following API calls:
ReadProcessMemory(hProcess,lpBaseAddress,lpBuffer,nSize,lpNumberOfBytesRead);
This function is used, well, to read the memory of a process. Since this article is about _self_-modifying code, we will always use this function on our process only.
WriteProcessMemory(hProcess,lpBaseAddress,lpBuffer,nSize,lpNumberOfBytesWritten);
Used for writing data to a process memory.
VirtualProtect(lpAddress,dwSize,flNewProtect,lpflOldProtect);
Used to change the access protection of a region in memory. To learn more about these functions, refer to the Win32 help file that ships with Delphi and take a look how they are used in the sample code.
What does the example code do?
The code that will be modified is inside the CallModifiedCode procedure:
procedure TForm1.CallModifiedCode(Sender: TObject);
var
b:boolean;
c:TColor;
label 1;
begin
c := clgreen;
b := true;
if b then goto 1;
asm
nop
nop
nop
nop
nop
nop
end;
c := clred;
1:
form1.Color := c;
end;
After studying the code you might be puzzled about some things. Obviously, this code sets the color of Form1, but as it is, the color will always be green, since b is always true, so it will always jump to label 1 and c:=clred before never gets called.
However, there is another function in the program that will change the line if b then goto 1; to if NOT(b) then goto 1; while the program is running, so after this modification in memory is done and this function is called again the form will actually be changed to red. Note that we will not change the boolean value of b, but virtually insert a "NOT" into the if statement.
Surely you noticed the six "nop"'s. "nop" is an assembler instruction and means "no operation", so these 6 lines do just nothing. 6 nop's in a row are quite unusual in a compiled exe, so we will use these nops as a marker for the position of the if statement above inside the compiled exe.
To understand how we will modify the code, we need to take a look at what the compiler will make from our pascal code. You can do this by running the project from Delphi, setting a breakpoint on the line with the if statement and (once you called the CallModifiedCode procedure by clicking the button and the debugger stopped the execution) opening the CPU window from Delphi's debug menu. You will see something like this:
807DFB00 cmp byte ptr [ebp-$05],$00
750D jnz TForm1.CallModifiedCode + $2A
90 nop
90 nop
90 nop
90 nop
90 nop
90 nop
Well, we can clearly see the 6 nops we placed in our code. The two lines above are the assembler code of the if statement. The first line compares a value (as we know from the pascal code this has to be the boolean value of b) with $00, the hexadecimal notation of 0, that in the case of a boolean variable means false.
The second line starts with jnz, what means "jump if not equal" (technically, "jump if not zero") and the address to jump to if the compared values from line one are not equal. So, the first two lines mean: "Compare the value of variable b with 0 (false) and if they are not equal jump away."
Note the hexadecimal values to the left of the asm code above. Each assembler instruction has a unique hexadecimal identifier. Obviously, $90 means "nop". $75 means "jnz", which is followed by the address (relative to the current address) to jump to ($0D in this case). $80 means "cmp" followed by some hexadecimal data specifying what and how it it compared. This hexadecimal representation of the assembler instructions is what makes the exe. If you have a hex editor, load the compiled exe and try to search for "909090909090". You will quickly find it and you will notice that the values before will be identical with the values above.
So, coming back to our task, if we want to insert "NOT" into our if statement, we will need to replace "jnz" with "jz". "jz" means "jump if zero" or "jump if equal". Replacing "jnz" with "jz" will reverse the condition in the original if statement, so once this modification is done the jump will not be done and the line c:=clRed; will be executed and the form will get red. As I said, "jnz" is represented by the hexadecimal value $75. The hexadecimal value for "jz" is $74.
Let's summarize what we have to do to change "if b then goto 1;" to "if NOT(b) then goto 1;": Locate $909090909090 in memory. From this position, go back two bytes and replace $75 with $74. If we want to go back to the original code, we do the same, but replace $74 with $75.
This is what is done in procedure TForm1.ModifyCode. I'll not go into further details here, but the source has lots of comments. You can download the sample code for this article by clicking here. After calling ModifyCode by clicking one of the two buttons on the right, click the "Execute code" button again and open the CPU view in Delphi to see that $75 was actually replaced with $74 or vice versa.
Epilog
There are easier ways to set the color of a form depending on which button was clicked ;-), but of course the purpose here is to demonstrate the concept of self-modifying code. Self-modifying code is a powerful technique and the example code might be very useful to implement a piracy protection scheme.
Finally, a small warning: You should take care when using a series of assembler nop's as a marker in real world applications, as these kind of unused code sections can be a nest for some viruses, e.g. the
W95/CIH1003 virus.