self deletion

This will not work at all on NT/2000/XP, inspite of the hack used.

Probably it will work on 95/98, but the following is much easier:

#include <windows.h>
int main()
{
   HMODULE module = GetModuleHandle(0);
   CHAR buf[MAX_PATH];
   GetModuleFileName(module, buf, sizeof buf);
   DeleteFile(buf);
}

Note that the code above is for 95 and maybe for 98.

The program is based on win9x but it doesn't work, I don't know why.

I will try your code.

Thanks
Regards
Yinan

Oh , i miss one line,the code is this:

====
#include <windows.h>

int main()
{
    HMODULE module = GetModuleHandle(0);

    CHAR buf[MAX_PATH];

    GetModuleFileName(module, buf, sizeof buf);

    CloseHandle(HANDLE(4));

    __asm {
        lea     eax, buf
        push    0               // argument to ExitProcess
        push    0               // return address of ExitProcess
        push    eax             // argument to DeleteFile
        push    ExitProcess     // return address of DeleteFile
        push    module          // argument to UnmapViewOfFile
        push    DeleteFile      // return address of UnmapViewOfFile
        push    UnmapViewOfFile
        ret
    }

    return 0;
}
=====

Nick , your version still doesn't work, my windows os is win98 second version.

Regards
Yinan

Wyn(Yinan), in 95/98 apps can't deletes yourself!
Only in Nt/2000 you can use MoveFileEx for this.
In my practice, I use for this next trick:
1.From my apps write to disk some little apps, that
  make only 2 things: delay (2 sec) and delete main apps.
2. Lunch this small apps.
3. Close main

Now, after end of small, in HD stay only small apps,
that can't help your  feind.

So what's the point of calling DeleteFile from an _asm block vs. just calling it from C++?

As to the following code:

#include <windows.h>
int main()
{
  HMODULE module = GetModuleHandle(0);
  CHAR buf[MAX_PATH];
  GetModuleFileName(module, buf, sizeof buf);
  DeleteFile(buf);
}

Seems this really does not work even on 95. The reason I thought it would work was the SDK documentation about the DeleteFile:
<<Windows 95: The DeleteFile function deletes a file even if it is open for normal I/O or as a memory-mapped file.>>

For what its worth I wrote the following code to run under W95. It would run then delete itself.

// Allows an executable to delete itself

#include <windows.h>
#include <stdlib.h>
#include <tchar.h>

int WINAPI WinMain(HINSTANCE h, HINSTANCE h2, LPSTR psz, int n)
{
     // Is this the original EXE or the clone EXE ?
   // If command line = 1 arg this is the original
   // If the command line > 1 arg this is the clone
   if (__argc==1)
        {
      // Original EXE, spawn clone EXE to delete this one
      // Copy this EXE into users TEMP dir.
      TCHAR sz_path_orig[_MAX_PATH], sz_path_clone[_MAX_PATH];
      GetModuleFileName(NULL,sz_path_orig,_MAX_PATH);
      GetTempPath(_MAX_PATH,sz_path_clone);
      GetTempFileName(sz_path_clone,__TEXT("Del"),0,sz_path_clone);
      CopyFile(sz_path_orig,sz_path_clone,FALSE);

      // Open clone EXE using FILE_FLAG_DELETE_ON_CLOSE, this ensures that the clone will die
      // when it terminates.
      HANDLE hfile=CreateFile(sz_path_clone,0,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_FLAG_DELETE_ON_CLOSE,NULL);

      // Spawn clone EXE by passig our EXE process's handle and path
      TCHAR sz_cmdline[512];
      HANDLE hproc_orig = OpenProcess(SYNCHRONIZE,TRUE,GetCurrentProcessId());
      wsprintf(sz_cmdline,__TEXT("%s %d \"%s\""),sz_path_clone,hproc_orig,sz_path_orig);
      STARTUPINFO si;
      ZeroMemory(&si,sizeof(si)) ;
      si.cb=sizeof(si);
      PROCESS_INFORMATION pi;
      CreateProcess(NULL,sz_cmdline,NULL,NULL,TRUE,0,NULL,NULL,&si,&pi);
      CloseHandle(hproc_orig);
      CloseHandle(hfile);
      // This original process can now terminate
      }
   else
        {
      // Clone EXE : When original EXE terminates, delete it.
      HANDLE hproc_orig = (HANDLE)_ttoi(__targv[1]);
      WaitForSingleObject(hproc_orig,INFINITE);
      CloseHandle(hproc_orig);
      DeleteFile(__targv[2]);
      // Do any clean up stuff here
      }
   return 0;
}


If you need an NT/2000 version I could play around with this code to see if it can be made to work or else you can use this as a base to work from but you said earlier that you need code to run under 95 and this will do the trick

Cheers - Gavin

The problem is that NT does not allow to execute a file which is opened with FILE_FLAG_DELETE_ON_CLOSE.

The code above with the hack works fine on NT4.

->>>Well, it changes the whole stuff!
=========

Yes, I just want to know why it changes the whole stuff,what does that line actually do indeed!??

i.e.:
CloseHandle(HANDLE(4));


 

->>>HINSTANCE hKernel=GetModuleHandle("KERNEL32");
  DWORD pExitProcess=(DWORD)GetProcAddress
(hKernel,"ExitProcess");
  DWORD pDeleteFile=(DWORD)GetProcAddress(hKernel,"DeleteFileA");
  DWORD pUnmapViewOfFile=(DWORD)UnmapViewOfFile;
===============
Why use GetProcAddress? Why not use API name directly as the original version do?

Best Regards
Yinan

NickRepin

I know that it doesn't work on NT kernels - I said as much in my post.

Earlier in the series of posts it was stated that the user wanted code that runs on Win 9x which the code I posted does and it is not a hack it uses standard Win32 APIs so it seems to me it fitted the requirements elucidated by the user.

Cheers - Gavin

Wyn, newmang claims that his answer is more fit for you. So reject my answer and accept his one.

My point is to become aware of how/why those code work/doesn't work.

Regards
Yinan

Does it work now with my changes?

NickRepin

Please don't misunderstand my last post - I did not intend to claim that my answer is "more fit for you" and I don't believe I did.

I only acknowledged your comment that my code will not work under the NT kernel (which I stated when I posted the code) and that it would work under the 9x kernel which was what the original poster required.

No offence was intended......

Cheers - Gavin

Gavin,

no problem, thanks.

hi to all,

i think that the simplest solutions which works under all operating systems, is the use
of a .BAT file.

in your app you create the .BAT-file and write only only line in it
delete app.exe

then you call this BAT-file immediatly before you close your app. that is all.
and it works fine.

regards to all
titz

hi,
i am very sorry: i forgot the most important line in the BAT-file.
here it is completely:

killx.BAT:

delete app.exe
delete killx.bat


that's all. because a bat-file can kill himself.

regards
titz

>>My point is to become aware of how/why those code work/doesn't work.

When executing an .EXE, Windows opens it as a so-called section (something like CreateFileMapping), then maps the file into memory by MapViewOfFile.

By design (at least, on the Windows versions where the code above works) the handle returned by CreateFileMapping???("file.exe") is always 0x00000004. MapViewOfFile returns a pointer to memory, by design it is the pointer to the beginning of the file, and also by design HINSTANCE (or HMODULE) is just a pointer which points to the beginning of the file.

To delete itself, the executable must UnmapViewOfFile first, then close the file mapping object which in turn releases the file locks that prevent deletion. Then you can delete the file.

Once you called UnmapViewOfFile, the memory pointed by HINSTANCE becomes invalid, so if you called UnmapViewOfFile from within the C code, you would get an exception, for example:

address             instructions
00400000            MZ... (EXE header) == HINSTANCE
...
0040332A            push 00400000 ; HINSTANCE
00403330            call UnmapViewOfFile
00403336            ... other code here ....

UnmapViewOfFile unmaps all memory section beginning from 00400000. When UnmapViewOfFile returns, the IP (istruction pointer) register points to 00403336 which is not a valid piece of memory any more.

Because of this we have to place all the code to be executed on the stack, because the stack is not a part of the executable image, and it is not affected by UnmapViewOfFile().

DWORD pUnmapViewOfFile=(DWORD)UnmapViewOfFile;

The code above usually (by the compiler design) returns the address of the import thunk, which is a part of the executable image, and not the true address of the UnmapViewOfFile:


address             instructions
00400000            MZ... (EXE header) == HINSTANCE
...
00420000            jmp 77BF0500   ; import thunk
...                 .....

77B00000            MZ... (KERNEL32.DLL header) == HINSTANCE
....
77BF0500            proc UnmapViewOfFile
....                ......

So actually pUnmapViewOfFile points to a jump instruction to UnmapViewOfFile (00420000), and not to the UnmapViewOfFile itself (77BF0500). It's ok, because while we execute this particular jmp, it is still valid.

On the other hand,

DWORD pDeleteFile=(DWORD)GetProcAddress(hKernel,"DeleteFileA");

this code returns the true address (say 77BF0600), which is in the memory space of KERNEL32.DLL. We cannot use jmp thunks here, because they will be unmapped after UnmapViewOfFile.

P.S. It would be fine if you gave me additional points for such a time-consuming explanation.

Now I know why I hang around here!  Nick, that is utterly cool beyond words.  Look for points in C++ section.

-- Dan

another 100pt, ok? I have increased it .I miss my email ,also this new comment,so this late. i will check it soon,tks you very much,Nick!