Comments 22
Создайте временный файл
cleanup.jsсо следующим содержимым:
Путь сей может оказаться несколько тернист, ибо " в лоб" мы рискуем получить вот это
А всё потому, что сначала может быть необходимым сделать вот это
assoc .js=JSFILEПричём сделать это из под админа (деинсталляшка обычно так и запускается, но тем не менее), иначе мы рискуем получить вот это
Но даже сделав это, мы рискуем получить вот это
Потому что надо как-то вот так (на моём компе по крайней мере):
var fso = new ActiveXObject("Scripting.FileSystemObject");
fso.DeleteFile("D:\\AutoDel\\AutoDel.js");
var path = "То\\что\\мы\\тут\\удаляем";
for (var count = 0; fso.FileExists(path) && count < 40; count++) {
try { fso.DeleteFile(path); break; } catch (e) { }
WSH.Sleep(500);
}Как-то так.
А можно из JS-движка на винде получить имя выполняемого скрипта? А то хардкодить путь к скрипту для fso.DeleteFile как-то некошерно.
assoc .js=JSFILEАга, тоесть если я специально настроил другую ассоцияцию с этим типом файла, то всё. делай заново? Не хорошо такие изменения без запроса согласия пользователя делать.
Безусловно нехорошо, просто без этого wscript cleanup.js не отрабатывал. Вообще весь этот костыль мне элегантным не кажется, здесь зависимость от js, я б с этим в продакшен не пошёл. В принципе можно либо тривиальным bat файлом обойтись, либо отложенное удаление сделать, я у Руссиновича вроде читал, что запущенный файл можно пометить для удаления и винда сама его прибьёт при перезагрузке, которую из деинсталлятора запросить можно.
Вроде как-то так (но боюсь ошибиться)
MoveFileEx(FileName, null, MoveFileFlags.MOVEFILE_DELAY_UNTIL_REBOOT)А посмотреть что там запланировано для удаления вроде как через PendMoves можно. Но я это не проверял, так что это неточно.
запущенный файл можно пометить для удаления и винда сама его прибьёт при перезагрузке, которую из деинсталлятора запросить можно.
Я вообще полагал, что оно всегда именно так и делается. Причем не только для запущенных файлов, но и для заблокированных по иным причинам. И не только для удаления, но и для перемещения.
В nsis, например, для команд копирования и удаления файлов есть ключ, приводящий к постановке задачи на выполнение операции после перезагрузки в случае невозможности сделать это сразу.
Также можно это сделать через ключ реестра PendingFileRenameOperations. Похоже, что вызов MoveFileEx с соответствующим флагом как раз помещает необходимые данные в этот ключ.
Кстати, еще в древних Win 95/98/me был механизм для таких же действий через WININIT.INI.
Инсталляторы, которые так делают, требуют перезагрузки.
То есть, снёс старую версию программы, хочешь поставить новую — а она тебе "сначала перезагрузись".
В 2023 у пользователя открыто 100500 окон и 200 вкладок в браузере. Перезагружаться ради обновления программы? Да ну, варварство какое-то.
Если речь о программе деинсталляции, которая убивает сама себя, то это решается просто. Достаточно записать убиватель программы деинсталляции в подкаталог для временных файлов, дав ему уникальное имя (UUID), запустить его и выйти, а уже тот после удаления программы деинсталляции может добавить себя для удаления при перезагрузке. Без перезагрузки будет лишь копиться мусор в подкаталоге для временных файлов (а он там и без того копится).
Впрочем, это не довод против других методов. Просто предполагал, что всегда используется что-то подобное, использующее стандартный документированный системный вызов.
Путь сей может оказаться несколько тернист, ибо " в лоб" мы рискуем получить вот это
В лоб, это
ShellExecute("D:\\AutoDel.js", ...);
?
Я бы запускал сразу
wscript.exe D:\Autodel.js
и не зависел бы от ассоциаций.
Писать в чужой процесс - плохо, не надо так делать! АВ вообще должен блочить подобные попытки на корню
Вы хотите что-то запретить в админских правах Windows?
Если плохо представляете себе их полномочия, то тогда попробуйте запретить нечто подобное root'у в Linux.
Вы хотите что-то запретить в админских правах Windows?
Права процесса в Windows определяются привязанным к нему (процессу) токеном доступа. По-умолчанию этот токен содержит права пользователя, но при создании процесса эти права можно урезать. В данном случае запретить PROCESS_VM_WRITE.
Но, видимо, это создаст проблемы с совместимостью. Так что так не делают.
Во-вторых, начиная с Vista в Windows реализован дополнительный механизм ограничени доступа — Mandatory integrity control (контроль целостности на основе полномочий, или, как перевела сама MS — «обязательный контроль целостности»), который ограничивает доступ процесса к объекту(в том числе — к другому процессу) на основе назначенных для них полномочий. Политика доступа по умолчанию запрещает изменение объекта с более высокими полномчиями из процесса с меньшими полоночиями, но возможны и другие варианты политики.
PS А еще есть специальная учетная запись, которая, начиная с Win 7(или Vista, не помню точно) является владельцем большинства исполняемых файлов системы: NT_SERVICE\Trusted Installer ( это — учетная запись одноименной службы). И администратору, чтобы изменить такие файлы, требуется использовать привилегию «Стать владельцем».
(«seTcbPrivilege») — позволяющей создать маркер доступа (аналог совокупности uid и gid для процесса в *nix) от имени любого пользователя, и содержащий любые группы — администратор по умолчанию не обладает
Я не знаю, от кого эта защита. Админ также не может открывать на чтение/запись адресное пространство системных процессов. Но стоит ему вызвать AdjustTokenPrivileges(...SeDebugPrivilege...) — и уже может. В итоге, каждая системная низкоуровневая программа начинается с этого заклинания. С SeTcbPrivilege не проверял, но судя по всему, ситуация с ней ничем не отличается.
Я не знаю, от кого эта защита.
Вопрос неправильно поставлен. Не "от кого", а "для кого". От пользователя с правами доменного администратора защититься в принципе невозможно. А вот помочь такому пользователю защитить систему от непреднамеренного запуска вредоносных программ можно. Например, запуская программы со списком привилегий, который не включает SeDebugPrivilege. В результате AdjustTokenPrivileges вернёт ERROR_NOT_ALL_ASSIGNED, и в системных процессах ничего прочитать не получится.
А как тогда отладкой заниматься? Процессу, запущенному с правами администратора должно быть можно всё. Если процесс пользовательский, то по умолчанию разрешить ему отлаживать только дочерние процессы. Плюсом можно дать возможность запрещать пользовательским процессам отладку вовсе
Создайте временный файл
cleanup.js
а что не питон? или VBA?
.bat файл может сделать себе del "%~f0"
Питона нет в стандартной инсталляции винды.
А bat-интерпретатор покажет богомерзкое чёрное окошко, которое может напугать пользователей.
хабр съел тэг <sarcasm>
у меня вот местами есть W7 и яваскрипта там тоже нет.
а окошко можно и спрятать
@start /b "" cmd /c del "%~f0" & exit /bПишут, что в 7-ке он уже есть: https://www.techwalla.com/articles/how-to-enable-windows-script-host-in-windows-7
Я помню, видел его даже в XP
Есть андок метод самоудаления через ntfs потоки. Работает с висты и выше. Но, для инсталятора , думаю, правильным было бы юзать MoveFileEx с флагом удалить после ребута.
Любой достаточно продвинутый деинсталлятор неотличим от зловреда