[AutoIT] (Self)Delete using asm

[[Beatrice]]

what's this?

normally you cannot delete an exe while running. to delete it, you have to run a code after the exe is terminated. what i'm doing here is injecting a code to an already running process, which makes your exe's deletion possible after its' termination. what it does is basically:

• find a 32 bit process available for injection (not x64 cos lazy)
• allocate some memory on the process
• write kernel32.sleep with the time you specify & kernel32.deletefilea using the file you pick (can be the exe itself of course)
• enumerate processes with Kernel32.K32EnumProcesses and loop through the pIDs until the specified process is terminated
• 
  
• delete the specified file
• clear the pages back & exit thread

and poof it just can delete your file without creating any bat files or such


what can it be used for?
you can have your script do anything irrelevant, and before exiting anytime before exiting (as the code will loop until the process is terminated) you can use this code to self delete without any junk. it could also be used for self update scripts.

Originally Posted by Jeoni

...

thanks to Jeoni this time it clears the memory with virtualfree leaving no garbage for real

shellcode:

 Spoiler

examples attached

i hope this helped someone out there. i know autoit is the worst possible way for injecting a code and this is not the cleanest way to do it but i still think it could be used.

[Serraniel]

#moved

[Jeoni]

Originally Posted by [Beatrice]

self delete without any junk

Well, to be precise, it does leave garbage, but at least no garbage files. The garbage are the two pages you allocate in the remote process and do not free afterwards. On normal consumer systems that amounts a memory leak of 8 KiB. May be larger if large pages are used.
To counter that, you can adjust your shellcode to first delete the page with the file name on it (well, one allocation, one page, would be enough for file name and code, but fine) and then delete the code page by using some basic return oriented programming resulting in the following shellcode:

push sleeptime
call Sleep
push filename
call DeleteFileA
push 0xC000 ; MEM_RELEASE
push 0
push filename
call VirtualFree
push 0 ; argument for ExitThread
push push 0xC000 ; MEM_RELEASE
push 0
push codeaddress
push &ExitThread
jmp VirtualFree

Of course, you may even calculate "codeaddress" in assembler. Or you may screw with the stack a bit around, so the thread can end naturally and not through ExitThread, but I'm too lazy for that. Anyhow, that way, it's not only without any garbage file but also with no memory leak in some remote process.
With best regards
Jeoni

[[Beatrice]]

Originally Posted by Jeoni

Well, to be precise, it does leave garbage, but at least no garbage files. The garbage are the two pages you allocate in the remote process and do not free afterwards. On normal consumer systems that amounts a memory leak of 8 KiB. May be larger if large pages are used.
To counter that, you can adjust your shellcode to first delete the page with the file name on it (well, one allocation, one page, would be enough for file name and code, but fine) and then delete the code page by using some basic return oriented programming resulting in the following shellcode:

 Spoiler

push sleeptime
call Sleep
push filename
call DeleteFileA
push 0x8000 ; MEM_RELEASE
push 0
push filename
call VirtualFree
push 0 ; argument for ExitThread
push 0x8000 ; MEM_RELEASE
push 0
push codeaddress
push &ExitThread
jmp VirtualFree

Of course, you may even calculate "codeaddress" in assembler. Or you may screw with the stack a bit around, so the thread can end naturally and not through ExitThread, but I'm too lazy for that. Anyhow, that way, it's not only without any garbage file but also with no memory leak in some remote process.
With best regards
Jeoni

I've updated the script, thank you so much for helping

[[Beatrice]]

updated to use K32EnumProcesses rather than sleep to be consistent.