Нашел интересный метод самоудаления запущенного ехе
https://github.com/LloydLabs/delete-self-poc Но — не работает на ХР. Сначала подумал, что из-за импорта SetFileInformationByHandle (апи доступна только с висты). Ладно, переписал на натив. все равно не работает на ХР (на других ОС работает). Интересно, почему так? Как бы эта ХР и даром не нужна, просто в который раз убеждаюсь, что современная NT — это, по факту, Виста и выше. То, что раньше — отличалось очень сильно.

IO_STATUS_BLOCK IoStatusBlock;
 
    if(NT_SUCCESS(NtSetInformationFile(hHandle, &IoStatusBlock, &fRename, sizeof(fRename) + sizeof(lpwStream),FileRenameInformation)))
        return TRUE;
    else
        return FALSE;
 
   if(NT_SUCCESS(NtSetInformationFile(hHandle, &IoStatusBlock, &fDelete, sizeof(fDelete),FileDispositionInformation)))
     return TRUE;
   else
     return FALSE;

Здравствуйте, morgot, Вы писали:

M>Нашел интересный метод самоудаления запущенного ехе

Главная проблема всех подобных методов — со временем они перестают работать. Единственный корректный вариант — через FILE_FLAG_DELETE_ON_CLOSE, если бы все системы нормально поддерживали его для EXE-файлов.

M>Нашел интересный метод самоудаления запущенного ехе
M>https://github.com/LloydLabs/delete-self-poc Но — не работает на ХР. Сначала подумал, что из-за импорта SetFileInformationByHandle (апи доступна

Довольно стремное решение, юзает какой то баг фс. Если файл реально удаляется и его место подчищается и становится доступным для записи — то процесс после такого удаления может совершенно внезапно свалится, если система затребует подкачать страницу с кодом/данными из ехешника, а ее содержимое окажется перетерто или вообще окажется что FILE_OBJECT сдох, хотя последнего не должно быть, по идее. Во избежании таких проблем стоит подстраховаться, и пробежаться по всем страницам имажа сделав их все dirty таким образом -> VirtualProtect(page, RWX) -> *(volatile int *)page = *(volatile int *)page; -> VirtualProtect(page, orig_protection);

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Главная проблема всех подобных методов — со временем они перестают работать.

Я понимаю, что это андок и нестабильность, интересно только с чисто исследовательской стороны. Почему там работает , а там нет?

Здравствуйте, ononim, Вы писали:

O>Довольно стремное решение, юзает какой то баг фс. Если файл реально удаляется и его место подчищается и становится доступным для записи — то процесс после такого удаления может совершенно внезапно свалится

Может, но врядли это где-то нужно в продакшне, разве что деинсталляторы удалять.

Вообще, мне просто стало интересно, почему не работает на ХР — ведь по факту это NT. Подобный баг (в плане, что работало на висте+ , но не ХР) встречал еще с WinSec, конкретно с правами на хендлы. Все таки , видимо, серьезно поменяли там ядро..

p.s. уже ради чистоты эксперимента попробовал не натив, а это http://hex.pp.ua/fileextd.php — такая же ошибка, на переименовании. Короче говоря, задача в NT5 решения не имеет.

Здравствуйте, morgot, Вы писали:

M>Почему там работает , а там нет?

Ну вот почему во всех виндах до десятки можно удалить файл с образом загруженного драйвера ядра, а в десятке — нет?

M>врядли это где-то нужно в продакшне, разве что деинсталляторы удалять.

В продакшене, подозреваю, это — единственная цель честная применения технологии. Все остальные — малварные.

M>Вообще, мне просто стало интересно, почему не работает на ХР — ведь по факту это NT. Подобный баг (в плане, что работало на висте+ , но не ХР) встречал еще с WinSec, конкретно с правами на хендлы. Все таки , видимо, серьезно поменяли там ядро..
Тут скорее драйвер нтфс замешан

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, morgot, Вы писали:

M>>Нашел интересный метод самоудаления запущенного ехе

ЕМ>Главная проблема всех подобных методов — со временем они перестают работать. Единственный корректный вариант — через FILE_FLAG_DELETE_ON_CLOSE, если бы все системы нормально поддерживали его для EXE-файлов.
Самый беспроблемный вариант MoveFileEx(xxx, NULL, MOVEFILE_DELAY_UNTIL_REBOOT).

Здравствуйте, Quebecois, Вы писали:

Q>Самый беспроблемный вариант MoveFileEx(xxx, NULL, MOVEFILE_DELAY_UNTIL_REBOOT).

Только если EXE предварительно скопирован во временный каталог и запущен оттуда, а процесс из основного экземпляра завершился. Вся эта машинерия не то, чтобы очень проста для надежной реализации.

Они могли бы, кстати, среди великого обилия своих мало кому нужных служб сделать поддержку технологии, подобной MOVEFILE_DELAY_UNTIL_REBOOT, но без перезагрузки. Всего-то делов — раз в несколько секунд проверять состояние файлов/каталогов из списка, и удалять освободившиеся. А еще лучше — сделать нормальную поддержку FILE_FLAG_DELETE_ON_CLOSE для чего угодно.

morgot:

M>Нашел интересный метод самоудаления запущенного ехе
В старые добрые времена процесс воздавал батник, а батник ожидал окончания процесса-папы, а потом прибивал и его и себя.
Надёжный способ.

Здравствуйте, Bill Baklushi, Вы писали:

BB>В старые добрые времена процесс воздавал батник, а батник ожидал окончания процесса-папы, а потом прибивал и его и себя.

В батнике нет способа ждать именно завершения процесса. Проще всего тупо циклить на попытках удаления файла.

BB>Надёжный способ.

Единственный надежный.

Здравствуйте, morgot, Вы писали:

M>Нашел интересный метод самоудаления запущенного ехе

Такое себе. Что если ехе запущен с флешки, а на флешке FAT?

Здравствуйте, Alexander G, Вы писали:

AG>Что если ехе запущен с флешки, а на флешке FAT?

Почему именно на флешке? На HDD/SSD тоже может быть FAT.

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

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В батнике нет способа ждать именно завершения процесса.

Чо?!
Просто строчка my.exe запускает с ожиданием завершения, а через errorlevel можно код выхода проверять.
Чтобы без ожидания надо start использовать.

Здравствуйте, Bjorn Skalpe, Вы писали:

BS>Попробуй написать загрузчик, который будет в качестве данных в себе содержать другой исполняемый код. Он будет грузить эти данные в память, а потом запускать процесс

И на него будут ругаться чуть более, чем все антивирусы.

Здравствуйте, qaz77, Вы писали:

ЕМ>>В батнике нет способа ждать именно завершения процесса.

Q>Просто строчка my.exe запускает с ожиданием завершения

Запускать-то она запускает. Только вот при реализации всего этого в совокупности, сперва таки запускается EXE-деинсталлятор из установочного каталога. Если она запустит свою копию через батник — на экране будет висеть черное консольное окно, его придется искать и прятать. Далее, этой копии нужно передать параметры — в частности, путь установочного каталога. Этот путь, внезапно, может оказаться на японском или хинди, а корректной обработки юникода cmd.exe не обещает. По факту оно вроде бы работает, но закладываться на это я бы не стал — придется кодировать/раскодировать строки. Городить все это только для того, чтобы использовать ожидание завершения процесса, запущенного из батника? Гораздо правильнее создать батник уже в процессе-копии, и запустить параллельно перед самым завершением.

Ну малварь почти вся использует именно батники, если уж на то пошло.. еще , наверное , можно юзать WSH как замену оного.
для продакшна всегда использовал MoveFile после ребута, а этот способ просто интересно выглядит.

BS>Попробуй написать загрузчик, который будет в качестве данных в себе содержать другой исполняемый код. Он будет грузить эти данные в память, а потом запускать процесс, а сам исполняемый файл загрузчика по завершению удаляться этим процессом. В результате в памяти существует процесс без файла.
Побаяню: http://rsdn.org/forum/winapi/3651105.1

Автор: ononim
Дата: 24.12.09

Правда хз, будет ли работать код as is в десятке, проверять лень.

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Только вот при реализации всего этого в совокупности, сперва таки запускается EXE-деинсталлятор из установочного каталога.
Никто не мешает в UninstallString записать запуск именно батника, а батник уже будет exe запускать.

Здравствуйте, qaz77, Вы писали:

Q>Никто не мешает в UninstallString записать запуск именно батника, а батник уже будет exe запускать.

Раз не мешает — делайте. Будете объяснять пользователям, что за странное черное окно мелькает при запуске, что за левая кнопка висит все это время на панели задач, и почему после обновления системы вдруг перестал удаляться установочный каталог, в котором все это лежит.