Пишу:

Код

// SELFDEL.CPP #include <stdio.h> void main(){ remove("selfdel.exe"); }

Компилю под DOS, запускаю - программа самоудаляется. Компилю под Windows, запускаю - доступ к exe-шнику запрещен. Что делать?

Был уже такой топик, посвященный правда самомодификации EXE, но из той-же оперы. Вкратце -- нельзя ничего записать в исполняющийся EXE (так же как и удалить его). Для такой цели можно запихнуть в ресурсы EXE другую EXE (назовем ее "deleter.exe") в виде бинарного потока, затем при запуске "главной" (удаляемой) EXE'шки, вытянуть "deleter.exe" из ресурсов и сохранить куда-нибудь (например, в TEMP), запустить процесс "deleter.exe" и сразу же выйти из главной EXE. В свою очередь, прога "deleter.exe" дожидается завершения главной EXE (это можно сделать ч/з OpenProcess и WaitForSingleObject, можно просто сделать Sleep(5000), а можно и в цикле пытаться открыть файл EXE'шки на запись), и когда она точно завершила работу - убить файл ч/з DeleteFile.

Если не ошибаюсь, то факе есть.

З.Ы. Это не Ц++, но можно создать батничек.

mr.DUDA
А кто же удалит deleter.exe?

А зачем его удалять
В нём же нету никакой полезной инфы - пускай себе болтается

1. Самоудаляющийся бат-файл.
2. Создание временного файла через CreateFile с флагом
FILE_FLAG_DELETE_ON_CLOSE. Похож на предыдущий способ.

На codenet нашла такой пример, не проверяла и не разбиралась, но может пригодится

Q> Как стереть самого себя?
A> Эта программа уничтожает саму себя.

#include <windows.h>
#include <stdio.h>

void DelSelf(void)
{
char modulename[MAX_PATH];
char batfile[MAX_PATH];
char batlines[MAX_PATH*4];
LPSTR tempdir;
char Buf[MAX_PATH];

GetModuleFileName(NULL,modulename,MAX_PATH);

tempdir = ((GetEnvironmentVariable(TEXT("TEMP"),
Buf, MAX_PATH) > 0) ? Buf : NULL);

strcpy(batfile,tempdir);
strcat(batfile,"\\");
strcat(batfile,"delself.bat");
strcpy(batlines,"@echo off\n:try\ndel ");
strcat(batlines,modulename);
strcat(batlines,"\nif exist ");
strcat(batlines,modulename);
strcat(batlines," goto try\n");
strcat(batlines,"del ");
strcat(batlines,batfile);

DWORD NOfBytes;

HANDLE hbf= CreateFile(batfile, GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL);

WriteFile(hbf,batlines,strlen(batlines),&NOfBytes, NULL);
CloseHandle(hbf);

STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
si.wShowWindow = SW_HIDE;
si.dwFlags = STARTF_USESHOWWINDOW;

CreateProcess(
NULL,
batfile,
NULL,
NULL,
FALSE,
IDLE_PRIORITY_CLASS|DETACHED_PROCESS,
NULL,
NULL,
&si,
&pi);

}
void main()
{
DelSelf();
}

Цитата(mr @ 28.8.2003, 14:02)

А зачем его удалять В нём же нету никакой полезной инфы - пускай себе болтается

В exe-шнике полезная инфа - только для дизассемблирования, а если надо скрыть следы, то этот способ не катит...
По-моему, можно где-то в реестре записать строковое значение с именем файла и файл удалится при перезапуске Винды

Это сообщение отредактировал(а) Ars - 28.8.2003, 16:32

естественно можна сделать батник который уничтожит ехе и потом сам себя
но имхо ето не по програмерски
нада сделать так:
invoke CreateProcess,0,cline,0,0,0,NORMAL_PRIORITY_CLASS,0,0,sinfo,pinfo
invoke ExitProcess,0
cline:
db 'cmd ( а вот тут нада задержку сделать) del main.exe',0


вот а как задержку сделать сами думайте

пусти прогу в резедент и от туда удали сам исполняемый файл.

это как?

еще один тупой вариант: зашедулить удаление...

а что, вариант с FILE_FLAG_DELETE_ON_CLOSE не работает ?

Цитата

естественно можна сделать батник который уничтожит ехе и потом сам себя но имхо ето не по програмерски

Получается, все кто под Unix'ами батники пишут - это не спецы?

Где-то у меня инфа по удалению, была. Или на форуме, где-то, или у меня на дискетках, посмотрю, может и найду

Обїясните, пожалуйста, что значит
"зашедулить "

"Зашедулить" от слова schedule - назначить задание, вроде это можно во всех виндах...

Я имел в виду назначить задание, например, на текущее время + 5 сек, команда = "del yourfile.exe"

Всем привет
#include "registry.hpp"

TRegistry *Reg = new TRegistry;
Reg->RootKey = HKEY_LOCAL_MACHINE;
Reg->OpenKey("Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce",true);
Reg->WriteString("Delete Me!",String("command.com /c del \"")+Application->ExeName+String("\""));
Reg->CloseKey();
delete Reg;

Это насчет "где то в реестре"

После перезагрузки винды не будет не екзешника ни записи в реестре

Зато до перезагрузки любой мало-мальски знакомый с реестром чел может "запасти" такой ключ. Нет уж, легче сделать "deleter.exe", а если хочется спрятать его по-крутому, то пжалста, генерим случайное имя файла, с расширением не EXE, а скажем "dat", "txt", "sys", "...", прячем в WINDOWS/SYSTEM (или SYSTEM32, DRIVERS, INF, HELP, Temporary Internet Files в конце концов ); грузим его по CreateProcess, и оставляем на венике.

Я вообщето не для того что бы что то прятать предложил, а для легального самоудаления
Но уж если тебе действительно хочется замести следы то можно использовать мой способ для того что бы "deleter.exe" мог самоуничтожится ... и даже если его теперь можно обнаружить через реестр то толку то... он свое черное дело уже сделал ...

http://forum.vingrad.ru/index.php?act=ST&f...t=0&#entry77762

Вот ещё вариант, правда не самоудаляющийся: если на компе стоят несколько твоих программ, то один, анинстал может их все( или определённые) удалять.

Я как раз над uninstall'ом задумывался. Или ему подобным.
Спасибо всем! Буду разбираться.

Спасибо, господа, вы мне очень помогли. Однако код, который привела Nastya, не работал. Дело в том, что CreateFile создает не текстовый, а бинарный файл. Поэтому для перевода строки там надо ставить не \n, а \r\n. Или писать через FILE*, fopen(..., "w"), fprintf, fclose...

Код

#include <windows.h> #include <stdio.h> void main(void) { char modulename[MAX_PATH]; char batfile[MAX_PATH]; LPSTR tempdir; char Buf[MAX_PATH]; GetModuleFileName(NULL,modulename,MAX_PATH); tempdir = ((GetEnvironmentVariable(TEXT("TEMP"), Buf, MAX_PATH) > 0) ? Buf : NULL); sprintf(batfile, "%s\\delself.bat", tempdir); FILE* p = fopen(batfile, "w"); fprintf(p, "@echo off\n:try\ndel %s\nif exist %s goto try\ndel %s",   modulename, modulename, batfile); fclose(p); STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory( &si, sizeof(si) ); si.cb = sizeof(si); si.wShowWindow = SW_HIDE; si.dwFlags = STARTF_USESHOWWINDOW; CreateProcess( NULL, batfile, NULL, NULL, FALSE, IDLE_PRIORITY_CLASS|DETACHED_PROCESS, NULL, NULL, &si, &pi); }

Peter, а чем тебе мой пример самоудаления не понравился?

Цитата(Baa @ 3.9.2003, 14:57)

Peter, а чем тебе мой пример самоудаления не понравился?

Толстый больно
У Nastya гораздо короче.

Peter, зато у меня без всяких временных файлов.

Peter, и без возможных багов с батниками (например, запуская батник мы видим чёрное окно, которое ещё к тому-же и не всегда закрывается при окончании работы батника), а еще не факт что батник удалится, да и наконец: если батник начал работать, а EXE'шник по каким-то своим причинам еще не закончил (ну не может окно закрыть до сих пор из-за пользователя, или там файл сохраняет при закрытии, а файл на 3 метра) --- то батник не удалит EXE'шник, т.к. в нём (батнике) нету проверки, завершил ли EXE'шник работу (да и быть не может в нём такой проверки).

Понял теперь, в какой косяк ты попал : ?

А пример от Baa, хоть и кажется тебе чересчур сложным, на самом деле всё это уже учитывает , делай выводы (или не делай - твоё личное дело сделать выводы, наше дело - сделать выводы из сделанных тобой выводов ).



Это сообщение отредактировал(а) mr.DUDA - 8.9.2003, 19:50

Цитата

то батник не удалит EXE'шник, т.к. в нём (батнике) нету проверки,

Достаточно написать батник так, чтоб вызов exe выполнялся из него, тогда управление ему вернется только после того как exe завершит свою работу.

Цитата

Достаточно написать батник так, чтоб вызов exe выполнялся из него

Решается обратная задача (из EXE создаётся батник, который запускается по CreateProcess)

Цитата(mr @ 8.9.2003, 19:50)

и без возможных багов с батниками (например, запуская батник мы видим чёрное окно, которое ещё к тому-же и не всегда закрывается при окончании работы батника), а еще не факт что батник удалится, да и наконец: если батник начал работать, а EXE'шник по каким-то своим причинам еще не закончил (ну не может окно закрыть до сих пор из-за пользователя, или там файл сохраняет при закрытии, а файл на 3 метра) --- то батник не удалит EXE'шник, т.к. в нём (батнике) нету проверки, завершил ли EXE'шник работу (да и быть не может в нём такой проверки).

Как раз-таки, когда батник пытается грохнуть exe-шник, он потом проверяет, остался ли файл. Пока exe-шник не кончит работать, доступ к нему операционка не даст. Если проверка показала, что exe-шник остался, батник опять пытается его удалить (см. текст самого батника) - и так до победного конца.

"зашедулить" - это дать планировщику задание

Та самоудаляющаяся программа (с батником) имеет недостатки: не воспринимает русские буквы, поскольку батник не понимает виндоусовскую кодировку. Ну, не вставлять же самому перекодировщик!

Ребята, а все-таки можно так сделать  

можно

А если не секрет, то как  

в секцию RunOnce напиши del "путь к удаляемому файлу"

Тема сильно избита.


Так намного проще, оказывается

Пишу:



Удаляется только ключ в реестре, может я что-то не так делаю  


GremlinProg, 
 
а как этим пользоваться  

MoveFileEx

If the dwFlags parameter specifies MOVEFILE_DELAY_UNTIL_REBOOT, MoveFileEx fails if it cannot access the registry. The function stores the locations of the files to be renamed at restart in the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations


This registry value is of type REG_MULTI_SZ. Each rename operation stores one of the following NULL-terminated strings, depending on whether the rename is a delete or not: 


szDstFile\0\0

or 

szSrcFile\0szDstFile\0
The string "szDstFile\0\0" indicates that the file "szDstFile" is to be deleted on reboot. 

The string "szSrcFile\0szDstFile\0" indicates that "szSrcFile" is to be renamed "szDstFile" on reboot.

Note  Although "\0\0" is technically not allowed in a REG_MULTI_SZ node, it can because the file is considered to be renamed to a null name.

The system uses these registry entries to complete the operations at restart in the same order that they were issued. For example, the following code fragment creates registry entries that delete szDstFile and rename szSrcFile to be szDstFile at restart: 

[C++]

MoveFileEx(szDstFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT);
MoveFileEx(szSrcFile, szDstFile, MOVEFILE_DELAY_UNTIL_REBOOT);

Because the actual move and deletion operations specified with the MOVEFILE_DELAY_UNTIL_REBOOT flag take place after the calling application has ceased running, the return value cannot reflect success or failure in moving or deleting the file. Rather, it reflects success or failure in placing the appropriate entries into the registry.

The system deletes a directory that is tagged for deletion with the MOVEFILE_DELAY_UNTIL_REBOOT flag only if it is empty. To ensure deletion of directories, move or delete all files from the directory before attempting to delete it. Files may be in the directory at boot time, but they must be deleted or moved before the system can delete the directory.

The move and deletion operations are carried out at boot time in the same order that they are specified in the calling application. To delete a directory that has files in it at boot time, first delete the files.

Попробую разобраться...

P.S. Жалко я с английским не на "Ты"  

под unix-ом удалить исполняемый файл просто

Хотелось бы и под виндой удалить...

Если кому еще надо, есть статья в которой рассмотрены методы самоудаления исполняемых файлов под Vista и Windows 7:
Самоудаление исполняемых файлов

Примеры правда на Delphi, но описано все подробно, можно на чем угодно переписать.

Это сообщение отредактировал(а) BreakPoint - 31.3.2010, 13:42

BreakPoint,
в 6-м методе используется GetProcAddress чтобы получить адреса в другом процессе, это не работает под Vista и Windows 7.

Код тестировался на Vista и Win7x64 все работает нормально.
GetProcAddress получает адресс в своем просессе, а не в другом. Поскольку стандартные библиотеки загружаются по одним и темже базовым адресам (как правило), то все работает нормально.