Solved

self deletion

Posted on 2001-08-18
23
2,546 Views
Last Modified: 2007-11-27
I try to use code snippet below to delete the executable itself after run but fail , I don't know why, would you plz help?

========

#include <windows.h>

int main()
{
   
    ......//some here...

    HMODULE module = GetModuleHandle(0);

    CHAR buf[MAX_PATH];

    GetModuleFileName(module, buf, sizeof buf);

 
    __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;
}
===

Regards
Yinan
0
Comment
Question by:Wyn
  • 9
  • 6
  • 3
  • +4
23 Comments
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
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);
}
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
Note that the code above is for 95 and maybe for 98.
0
 
LVL 5

Author Comment

by:Wyn
Comment Utility
The program is based on win9x but it doesn't work, I don't know why.

I will try your code.

Thanks
Regards
Yinan
0
 
LVL 5

Author Comment

by:Wyn
Comment Utility
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;
}
=====

0
 
LVL 5

Author Comment

by:Wyn
Comment Utility
Nick , your version still doesn't work, my windows os is win98 second version.

Regards
Yinan
0
 
LVL 14

Expert Comment

by:AlexVirochovsky
Comment Utility
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.
0
 
LVL 32

Expert Comment

by:jhance
Comment Utility
So what's the point of calling DeleteFile from an _asm block vs. just calling it from C++?
0
 
LVL 15

Accepted Solution

by:
NickRepin earned 150 total points
Comment Utility
>>Oh , i miss one line,the code is this:

Well, it changes the whole stuff! Inspite of that it works, it is an ungly, ugly hack!

#include <windows.h>

void main()
{
   HINSTANCE hModule=GetModuleHandle(0);

   CHAR buf[MAX_PATH];
   GetModuleFileName(hModule,buf,sizeof(buf));

   HINSTANCE hKernel=GetModuleHandle("KERNEL32");
   DWORD pExitProcess=(DWORD)GetProcAddress(hKernel,"ExitProcess");
   DWORD pDeleteFile=(DWORD)GetProcAddress(hKernel,"DeleteFileA");
   DWORD pUnmapViewOfFile=(DWORD)UnmapViewOfFile;

   

   CloseHandle(HANDLE(4));

   __asm {
       lea     eax, buf
       push    0               // argument to ExitProcess
       push    0               // return address of ExitProcess
       push    eax             // argument to DeleteFile
       push    pExitProcess     // return address of DeleteFile
       push    hModule          // argument to UnmapViewOfFile
       push    pDeleteFile      // return address of UnmapViewOfFile
       push    pUnmapViewOfFile
       ret
   }

}
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
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.>>
0
 
LVL 4

Expert Comment

by:newmang
Comment Utility
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
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
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.
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 5

Author Comment

by:Wyn
Comment Utility
->>>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
0
 
LVL 4

Expert Comment

by:newmang
Comment Utility
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
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
Wyn, newmang claims that his answer is more fit for you. So reject my answer and accept his one.
0
 
LVL 5

Author Comment

by:Wyn
Comment Utility
My point is to become aware of how/why those code work/doesn't work.

Regards
Yinan
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
Does it work now with my changes?
0
 
LVL 4

Expert Comment

by:newmang
Comment Utility
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
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
Gavin,

no problem, thanks.
0
 
LVL 1

Expert Comment

by:titz
Comment Utility
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
0
 
LVL 1

Expert Comment

by:titz
Comment Utility
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
0
 
LVL 15

Expert Comment

by:NickRepin
Comment Utility
>>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.
0
 
LVL 49

Expert Comment

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

-- Dan
0
 
LVL 5

Author Comment

by:Wyn
Comment Utility
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!
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

When writing generic code, using template meta-programming techniques, it is sometimes useful to know if a type is convertible to another type. A good example of when this might be is if you are writing diagnostic instrumentation for code to generat…
Errors will happen. It is a fact of life for the programmer. How and when errors are detected have a great impact on quality and cost of a product. It is better to detect errors at compile time, when possible and practical. Errors that make their wa…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now