modify an EXE file while it's running

[Steve Kobes]

I want my program to modify its own EXE file. I do not want to start
a separate EXE that waits for the first one to quit, then modifies it.
CreateFile fails with a sharing violation when I try to open the EXE
with FILE_WRITE_DATA access. So, we might reasonably conclude that my
task is impossible. BUT...

I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it! After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!

How'd they do that?

[Martijn]

Post by Steve Kobes
I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it! After I hit Save, a file
called ~VC90.tmp appeared in the same folder.

Interesting question. I am not running VC, but I have some questions: How
did you run the program (thru VC or otherwise)? Is it a debug build (don't
know if this may cause some of the behaviour)? Can you edit other running
executables as well?

Curious to see how this turns out...

--
Martijn
http://www.sereneconcepts.nl

[Steve Kobes]

Post by Martijn

Post by Steve Kobes
I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it! After I hit Save, a file
called ~VC90.tmp appeared in the same folder.

Interesting question. I am not running VC, but I have some questions: How
did you run the program (thru VC or otherwise)? Is it a debug build (don't
know if this may cause some of the behaviour)? Can you edit other running
executables as well?

See Dieter's reply... I ran the program outside VC. Seems like it does the
rename-and-copy trick for all types of executables, even system files like
explorer.exe.

[Ritchie]

Post by Steve Kobes
I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it! After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!
How'd they do that?

I can't answer your question, but FWIW..

If I run "Macromedia Dreamweaver MX 2004" and then run sysinternals PROCEXP,
it shows that dreamweaver.exe has two child processes. They are two instances
of "~e5d141.tmp" which is located in the temp directory. A hex editor shows
that it appears to be a regular EXE.

BTW, no I don't have a virus
--
Ritchie, undo for mail

[Dieter Schmeer]

Post by Steve Kobes
I want my program to modify its own EXE file. I do not want to start
a separate EXE that waits for the first one to quit, then modifies it.
CreateFile fails with a sharing violation when I try to open the EXE
with FILE_WRITE_DATA access. So, we might reasonably conclude that my
task is impossible. BUT...
I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it!

That's no problem, VC only opens it for reading and closes it again. Then
you edit the file in memory until you save it.

Post by Steve Kobes
After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!

Well, not really. First, the EXE was renamed to ~VC90.tmp. (Note: You can
rename an EXE while it is running, at least on WinNT/2k/XP). Then your
modified file was saved under the previous name of the EXE file. So, the
system doesn't _think_ your Hello World came from the tmp file, it really
did and therefore you cannot delete this file before the program has ended.

Hope this helps

Dieter

[Steve Kobes]

Post by Dieter Schmeer

Post by Steve Kobes
After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!

Well, not really. First, the EXE was renamed to ~VC90.tmp. (Note: You can
rename an EXE while it is running, at least on WinNT/2k/XP). Then your
modified file was saved under the previous name of the EXE file. So, the
system doesn't _think_ your Hello World came from the tmp file, it really
did and therefore you cannot delete this file before the program has ended.

Very clever! I wonder why Windows prevents writing but allows renaming.
I think I will be able to use this trick for my app.

[Tim Robinson]

Post by Steve Kobes
Very clever! I wonder why Windows prevents writing but allows renaming.
I think I will be able to use this trick for my app.

Because renaming a file only affects its directory entry (i.e. the directory
is written to), whereas writing to a file affects the actual contents. In
fact, you should be able to move a running executable anywhere on the same
volume (drive letter).

[Norman Black]

Post by Steve Kobes
Very clever! I wonder why Windows prevents writing but allows

renaming.

Post by Steve Kobes
I think I will be able to use this trick for my app.

Windows memory maps the executable file. It uses the executable file as
the backing store (page file) for the read only data in the executable
file. Once the file is opened Windows could care less what the file name
is since it holds a file handle to the file itself. The name is only a
listing in a directory that points to the "file".

--
Norman Black
Stony Brook Software

Post by Steve Kobes

Post by Dieter Schmeer

Post by Steve Kobes
After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!

Well, not really. First, the EXE was renamed to ~VC90.tmp. (Note: You can
rename an EXE while it is running, at least on WinNT/2k/XP). Then your
modified file was saved under the previous name of the EXE file. So, the
system doesn't _think_ your Hello World came from the tmp file, it really
did and therefore you cannot delete this file before the program has ended.

Very clever! I wonder why Windows prevents writing but allows

renaming.

Post by Steve Kobes
I think I will be able to use this trick for my app.

[James Brown]

An executable cannot alter itself whilst running, end-of-story.

There used to be a trick under older versions of Windows (9x/NT/2K)
where an executable could allocate a section of virtual memory,
copy some code into it, unlink the image from the disk-file and then
execute the code-fragment directly from RAM, which did the file-altering -
afterwards the code-stub would reload the executable and carry on executing.

This is no longer possible due to small changes in the way the win32 loader
works. Suffice to say, an executable cannot unlink itself from disk because
there aren't any user-mode references to the various kernel objects that are
used to perform this trick. Also the prefetch cache manager keeps a lock
onto your executable as it is running (under XP/Server2003) and doesn't
release
this lock until after your exe has terminated.

So, you'll have to find some other way to achieve what you are trying to do.

James
--
www.catch22.org.uk
Free Win32 Software, Source Code and Tutorials

Post by Steve Kobes
I want my program to modify its own EXE file. I do not want to start
a separate EXE that waits for the first one to quit, then modifies it.
CreateFile fails with a sharing violation when I try to open the EXE
with FILE_WRITE_DATA access. So, we might reasonably conclude that my
task is impossible. BUT...
I wrote a Hello World program, and while the message box was on the
screen, I opened its EXE as a binary file in Visual C++ 6 (no
workspace open), and I was able to edit it! After I hit Save, a file
called ~VC90.tmp appeared in the same folder. Its contents match
those of the EXE before the change, and I'm unable to delete it until
I close the message box, suggesting that the VC++ editor somehow made
the system think my Hello World process had come from this .tmp file.
But the EXE itself is changed!
How'd they do that?