Оффлайн
- Регистрация
- 25.01.17
- Сообщения
- 763
- Реакции
- 224
- Репутация
- 292
Работа с реестром в Windows x64
Когда-то давным-давно делал для себя утилиту, которая читала данные из ключей автозапуска системного реестра. Эти данные тогда практически с 90% гарантией могли показать заражена ли система и где лежит вредоносный файл. Особо изощренных способов сокрытия тогда еще так широко не применялось и для того, чтобы обеспечить себе автоматический запуск после перезагрузки системы троянцы практически всегда помещали ссылку на себя в ключ автозапуска. А совсем недавно решил проверить, будет ли это работать в 64-битной ОС.
Программа была написана с применением функций из «комплекта» Registry Functions. Там есть всё необходимое для относительно удобной работы с системным реестром.
А совсем недавно решил проверить, будет ли это работать в 64-битной Виндовс. Запустил — вроде работает:
Решил узнать, что это за странный подключ - «OptionalComponents». Уж не зловред ли какой? Путь к ключу, разумеется, помню наизусть:
Открываю привычный regedit, захожу в автозапуск, а он пуст:
Как так? Исходника под рукой не оказалось, но на том же MSDN есть прекрасный пример. Меняю две строчки под свои нужды:
Но результат тот же.
Немного поразмыслив, понимаю, что программа работает корректно, так как параметр
Первое, что пришло в голову — недостаточно прав. То есть ключи есть, но не отображаются. Запустил regedit не просто так, а от имени администратора. Результат тот же — ключ пуст.
Решил просто устроить поиск по тому, что нашла программа. НажимаюСtrl+F иввожу
Хм... Ничего не понимаю — вот он ключ Run. Вроде бы тот же самый. Листаю выше — вроде все как надо - «Windows\CurrentVersion»
Вот и «Microsoft»:
И тут все внезапно становится на свои места - ну как же я мог забыть:
«Wow6432Node» - это нам привет от 64-битной Виндовс. Когда-то я уже писал об особенностях работы 64- и 32-битных приложений и специальной обертке WoW64.
Получается, что моя программа, скомпилированная для 32-битной операционной системы оказалась в «песочнице». То есть сама операционная система делает то, что обычно делают руткиты — подменяет вызовы функций своими. Выходит, программа даже не знает, что что-то пошло не так — никаких сообщений об ошибке, никаких предупреждений. Каждое 32-битное приложение получает доступ к вымышленному 32-битному миру, в котором есть ключи автозапуска системного реестра. Хорошо, что эти ключи хоть срабатывают так же, как настоящие.
Представьте себя на месте человека, создающего антивирус. Вам обязательно нужно будет проверять ключи автозапуска. Причем учитывая растущую популярность 64-битных операционных систем (вместе с большими объемами оперативной памяти) нужно учитывать то, что могут появиться вредоносы и для них.
Как с этим бороться? Очевидно, что придется делать две версии программы — для 32- и для 64-битных операционок. Тут вас ждет небольшая «засада» - например, Visual Studio 2010 Express так любимая студентами и не только за свое бесплатное распространение, не умеет просто так компилировать 64-битные приложения. Обэтомнедвусмысленноговоритсявдокументации:
То есть нужно еще поискать .NET Framework SDK. Я брал с официального сайта. Чего и вам советую.
Немного поплясав с бубном заставляем это компилироваться под х64. Перед запуском добавим в ключ автозапуска тестовый ключ:
Это позволит сразу понять, всё ли получилось.
Проверяем:
Работает. Теперь проверим, можно ли той же программой прочитать ключ из 32х окружения. Меняемпутькключус
на
ивызываемсразуобавариантадлянаглядности:
Вот, собственно, и все. Но при создании утилит, совершающих подобные действия, будет трудно обойтись без создания двух версий. Причем та, которая будет работать в 64-битной среде должна дублировать функционал 32-битной. Кстати, это может служить наглядной причиной того, почему 64-битные приложения имеют больший размер и занимают больше памяти — приходится предусматривать лишний функционал, чтобы не оставить без внимания важные детали.
Нужно заметить, что для разработчиков подобные ситуации с обработкой странных нюансов не редки. То есть если вы делаете что-то сложнее «HelloWorld» и хотите, чтобы все было предсказуемо в ОС разной разрядности, то придется как следует заморочиться. А если потребуется сделать программу кроссплатформенной не только в контексте битности, но и для кардинально разных операционных систем (Windows/Linux), то забот будет еще больше. В то же время, чтение реестра совсем не является обыденной задачей программиста, если только он не хранит там настройки своей программы. Но даже если и хранит, то скорее всего он будет читать то, что сам в реестр записал, а значит таких проблем не будет. Так что нужно опасаться только за судьбу создателей «низкоуровневых» утилит, вроде AVZ. А занимающиеся этим программисты скорее всего уже прошли эти «грабли».
Так что по прошествии уже практически года с момента последней публикации о 64-битности можно с сожалением констатировать - за это время мир IT не слишком далеко продвинулся в избавлении от 32-разрядных ограничений. Может это связано с тем, что настольные компьютеры отживают свой век, уступая место другим решениям и что-то менять в области, которая скоро станет никому не нужной это бессмысленная трата времени?
Когда-то давным-давно делал для себя утилиту, которая читала данные из ключей автозапуска системного реестра. Эти данные тогда практически с 90% гарантией могли показать заражена ли система и где лежит вредоносный файл. Особо изощренных способов сокрытия тогда еще так широко не применялось и для того, чтобы обеспечить себе автоматический запуск после перезагрузки системы троянцы практически всегда помещали ссылку на себя в ключ автозапуска. А совсем недавно решил проверить, будет ли это работать в 64-битной ОС.
Программа была написана с применением функций из «комплекта» Registry Functions. Там есть всё необходимое для относительно удобной работы с системным реестром.
А совсем недавно решил проверить, будет ли это работать в 64-битной Виндовс. Запустил — вроде работает:
Решил узнать, что это за странный подключ - «OptionalComponents». Уж не зловред ли какой? Путь к ключу, разумеется, помню наизусть:
Открываю привычный regedit, захожу в автозапуск, а он пуст:
Как так? Исходника под рукой не оказалось, но на том же MSDN есть прекрасный пример. Меняю две строчки под свои нужды:
Но результат тот же.
Немного поразмыслив, понимаю, что программа работает корректно, так как параметр
действительно должен быть в запуске. Кстати, а где же он тогда?
Первое, что пришло в голову — недостаточно прав. То есть ключи есть, но не отображаются. Запустил regedit не просто так, а от имени администратора. Результат тот же — ключ пуст.
Решил просто устроить поиск по тому, что нашла программа. НажимаюСtrl+F иввожу
Хм... Ничего не понимаю — вот он ключ Run. Вроде бы тот же самый. Листаю выше — вроде все как надо - «Windows\CurrentVersion»
Вот и «Microsoft»:
И тут все внезапно становится на свои места - ну как же я мог забыть:
«Wow6432Node» - это нам привет от 64-битной Виндовс. Когда-то я уже писал об особенностях работы 64- и 32-битных приложений и специальной обертке WoW64.
Получается, что моя программа, скомпилированная для 32-битной операционной системы оказалась в «песочнице». То есть сама операционная система делает то, что обычно делают руткиты — подменяет вызовы функций своими. Выходит, программа даже не знает, что что-то пошло не так — никаких сообщений об ошибке, никаких предупреждений. Каждое 32-битное приложение получает доступ к вымышленному 32-битному миру, в котором есть ключи автозапуска системного реестра. Хорошо, что эти ключи хоть срабатывают так же, как настоящие.
Представьте себя на месте человека, создающего антивирус. Вам обязательно нужно будет проверять ключи автозапуска. Причем учитывая растущую популярность 64-битных операционных систем (вместе с большими объемами оперативной памяти) нужно учитывать то, что могут появиться вредоносы и для них.
Как с этим бороться? Очевидно, что придется делать две версии программы — для 32- и для 64-битных операционок. Тут вас ждет небольшая «засада» - например, Visual Studio 2010 Express так любимая студентами и не только за свое бесплатное распространение, не умеет просто так компилировать 64-битные приложения. Обэтомнедвусмысленноговоритсявдокументации:
То есть нужно еще поискать .NET Framework SDK. Я брал с официального сайта. Чего и вам советую.
Немного поплясав с бубном заставляем это компилироваться под х64. Перед запуском добавим в ключ автозапуска тестовый ключ:
Это позволит сразу понять, всё ли получилось.
Проверяем:
Работает. Теперь проверим, можно ли той же программой прочитать ключ из 32х окружения. Меняемпутькключус
на
ивызываемсразуобавариантадлянаглядности:
Вот, собственно, и все. Но при создании утилит, совершающих подобные действия, будет трудно обойтись без создания двух версий. Причем та, которая будет работать в 64-битной среде должна дублировать функционал 32-битной. Кстати, это может служить наглядной причиной того, почему 64-битные приложения имеют больший размер и занимают больше памяти — приходится предусматривать лишний функционал, чтобы не оставить без внимания важные детали.
Нужно заметить, что для разработчиков подобные ситуации с обработкой странных нюансов не редки. То есть если вы делаете что-то сложнее «HelloWorld» и хотите, чтобы все было предсказуемо в ОС разной разрядности, то придется как следует заморочиться. А если потребуется сделать программу кроссплатформенной не только в контексте битности, но и для кардинально разных операционных систем (Windows/Linux), то забот будет еще больше. В то же время, чтение реестра совсем не является обыденной задачей программиста, если только он не хранит там настройки своей программы. Но даже если и хранит, то скорее всего он будет читать то, что сам в реестр записал, а значит таких проблем не будет. Так что нужно опасаться только за судьбу создателей «низкоуровневых» утилит, вроде AVZ. А занимающиеся этим программисты скорее всего уже прошли эти «грабли».
Так что по прошествии уже практически года с момента последней публикации о 64-битности можно с сожалением констатировать - за это время мир IT не слишком далеко продвинулся в избавлении от 32-разрядных ограничений. Может это связано с тем, что настольные компьютеры отживают свой век, уступая место другим решениям и что-то менять в области, которая скоро станет никому не нужной это бессмысленная трата времени?