Код ошибки a64f32fa 0x00000405

Очень удобная фича для управления настройками в системе и для системного администрирования.

К сожалению, режим Бога используют не только сисадмины, но и авторы вирусов.

Специалисты из антивирусной компании McAfee Labs рассказывают о трояне Dynamer, который использует режим Бога, чтобы скрыться от обнаружения в системе.

Dynamer при установке записывает свои файлы в одну из таких папок внутри %AppData%. В реестре создаётся ключ, который сохраняется после перезагрузки, запуская каждый раз бинарник зловреда.

Таким образом, исполняемый файл нормально запускается по команде из реестра, но вручную зайти в эту папку нельзя: как указано в списке выше, папка <241d7c96-f8bf-4f85-b01f-e2b043341a4b>работает как ярлык на настройки «Подключение к компьютерам и программам на рабочем месте» (RemoteApp and Desktop Connections).

Вот содержимое папки, если открыть её в проводнике.

Более того, авторы трояна добавили к названию папки "com4.", так что Windows считает папку аппаратным устройством. Проводник Windows не может удалить папку с таким названием.

Аналогично, удаление невозможно из консоли.

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

Троян Dynamer впервые обнаружен несколько лет назад, но Microsoft до сих пор считает его «серьёзной угрозой» для пользователей Windows.

Список имён папок (GUID) в режиме Бога для быстрого доступа к отдельным настройкам Windows

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Настройки Windows 10: часть III, или куда приводят скрипты

В Microsoft анонсировали функцию настройки Windows 10 в зависимости от интересов пользователя

Скрипт настройки Windows 10. Часть II

Средняя зарплата в IT

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 45

Ему и не нужно обновляться, эта утилита имеет минимальный и, главное, достаточный функционал для выполнения своих функций. Если добавить туда разных (имхо, не нужных) фич — это породит новые баги, бОльшую ресурсоемкость и так далее. Зачем это всё?

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

1) Создайте ограниченного пользователя
2) Запретите этому пользователю запись во все папки кроме папки профиля и еще нескольких на ваш выбор.
3) С помощь SRP (https://habrahabr. ru/post/101971/) запретите созданному пользователю запуск любых программ из тех папок, в которые ему разрешена запись.

Результат: всё что запишется от имени пользователя, не может запуститься. От всех атак подобная система не защитит, так и SRP, и AppLocker достаточно легко обходятся (https://habrahabr. ru/post/282373/), однако сильно осложнит жизнь многим зловредам.

Для еще большей защиты, накатите Linux в Dual Boot или виртуальную машину, и серфите по недоверенным сайтам из-под Linux, там подобные фичи настраиваются легче, да и вирей под линь намного меньше. Во FreeBSD даже есть встроенная песочница. Ну и на крайний случай существует OpenBSD, найти и несанкционированно запустить зловред под которой, является сверхсложной задачей

> что будет, если на томе, который монтируется как "/", создать директорию "/dev"

она там и так есть, и в неё при загрузке монтируется devtmpfs, в которой уже udev создаёт файлы девайсов.

/dev Зачем её создавать? Она и так есть в "/".

А вообще полезная штука, учитывая что в новых виндах порой сложно найти привычные менюшки.

В linux нету зарезервированных имен любая utf-8 строка заканчивающаяся терминирующим \0 будет валидным путем к файлу или каталогу.
В корневой fs важно наличие каталога /dev с минимальным набором устройств в противном случае это сильно осложнит работоспособность многих программ (конечно можно обойтись и без него вообще минимально для старта unix достаточно только выполняемого файла init).
BTW то что вы назвали томом в UNIX является блочным устройством.
Думаю что если изменить имя файла или каталога на "." или ".." доступом через блочное устройство и замонтировать fs пропустив проверку целостности то этот файл или каталог можно будет увидеть в списке файлов но никак нельзя будет к нему доступиться (точнее открыть). Соответственно после fsck он будет переименован и попадет в /lost+found каталог содержащей его fs.

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

Тем не менее можно осложнить возможность удалить файлы и каталоги, если их имена сделать в неустановленной локально кодировке тогда многие штатные средства дадут сбой если не удастся сделать биективное отображение имен из fs в кодировку пользователя и обратно, но на уровне API никаких проблем нет. Еще можно создавать несколько миллионов пустых файлов и каталогов (если позволит установленный лимит при создании fs) тогда штатно удалить и найти только что-то с неизвестным именем среди этого будет сложно (правда удалить все достаточно просто).

Более кардинальный подход это создать свою искусственную fs в пространстве пользователя или ядра в которой будут свои нестандартные правила доступа но сначала как минимум потребуется получение прав root. Также можно подменить системные вызовы open, openat итп.