Hklm software microsoft windows nt currentversion winlogon alternateshells availableshells

One thing I do hate in the new Windows 2012 Core setup is that PowerShell is not the default shell when one logs in. Microsoft made it so that in Core most of the Administration task are done via PowerShell or Remote Administratio tools. The fist thing one must do is to take ownership of the HKLMS

One thing I do hate in the new Windows 2012 Core setup is that PowerShell is not the default shell when one logs in. Microsoft made it so that in Core most of the Administration task are done via PowerShell or Remote Administratio tools. The fist thing one must do is to take ownership of the HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells Registry key since we will be modifying it. To achieve this Microsoft was nice enough to include the GUI version of the registry editor so we only need to type regedit in the command prompt and hit enter, after it comes up we can navigate to the key image We right-click on the Key AvailableShells and click on Permission, on Permissions click on Advanced and click on Change image Add the Administrator account, click on OK and on the previous screen click on Apply. Create a registry value under the key with the name of 40000 and set the value to:

powershell.exe -noexit -command "& {set-location $env:userprofile; clear-host}"

image

Now when you log off and log back in you will be greeted with a PowerShell window.

image

The reason why we use 40000 is that when you install the full GUI Explorer.exe will be 90000 and we want to PowerShell to be the Shell only if we are in Core or in Server-Gui-Mgmt-Infra.

To make life simpler here is a script you can either copy and paste in to a PowerShell window or create a .ps1 file and execute from there:

# Use C# to leverage the Win32API
$definition = @"

using System;

using System.Runtime.InteropServices;

namespace Win32Api

{

public class NtDll

{

[DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]

public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled);

}

}

"@
Add-Type -TypeDefinition $definition -PassThru
$bEnabled = $false

# Enable SeTakeOwnershipPrivilege
$res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)

# Take ownership of the registry key
$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey('SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells', [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)
$acl = $key.GetAccessControl()
$acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")


# Set Full Control for Administrators
$rule = New-Object System.Security.AccessControl.RegistryAccessRule("Administrators","FullControl", "Allow")
$acl.AddAccessRule($rule)
[void]$key.SetAccessControl($acl)


# Create Registry Value
[void][Microsoft.Win32.Registry]::SetValue($key,"90000",'powershell.exe -noexit -command "& {set-location $env:userprofile; clear-host}"')

I hope you found the blog post information useful.

The command in syneticon-dj’s answer does not work, because a normal elevated administrator does not have write access to the key. The comments mention that you need to change the permissions. But this involves a lot of clicking in regedit.exe and does not work for scripted installations.

I use the following PowerShell script:

 $definition = @"
 using System;
 using System.Runtime.InteropServices;
 namespace Win32Api
 {
    public class NtDll
    {
       [DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]
       public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled);
    }
 }
 "@

 Add-Type -TypeDefinition $definition -PassThru  | out-null

 $bEnabled = $false

 # Enable SeTakeOwnershipPrivilege
 $res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)

 $key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey("SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells", [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)
 $acl = $key.GetAccessControl()
 $acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")
 $key.SetAccessControl($acl)

 $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("BUILTINAdministrators","FullControl","Allow")
 $acl.SetAccessRule($rule)
 $key.SetAccessControl($acl)

 New-ItemProperty -path "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells" -name 90000 -value "%SYSTEMROOT%System32WindowsPowerShellv1.0Powershell.exe" -propertyType String

it first changes the permissions on the key and then sets PowerShell as the shell.

Notice this may only work on an English OS, as it refers to the ‘Administrators’ group.

  • Remove From My Forums
  • Question

  • Hello

    Very frustrating issue

    We have 4 core servers that were built from another team. We have been given them to manage, so we are in the process of converting them to GUI (as core is not required for business purposes)

    I have carried out the following steps:

    1. Mount the Windows Server 2012 ISO to the host.
    2. open an administrative command prompt
    3. mkdir c:mount
    4. check your wimfile to determine the correct index for the OS (mine was 4) -the command is dism /get-imageinfo /ImageFile:d:sourcesinstall.wim
    5. ‘dism /mount-wim /wimfile:d:sourcesinstall.wim /index:4 /mountdir:c:mount /readonly
    6. powershell (enter PowerShell prompt)
    7. install-windowsfeature server-gui-mgmt-infra,server-gui-shell –restart –source c:mountwindowswinsxs
    8. Rebooted server

    Once the server has come back up, it boots with a powershell interface, the server management — but nothing else. No metro UI, no start menu. No desktop. We can run explorer from command prompt, as well as control panel etc

    I have tried the additonal steps below to no avail

    Remove the features (both from server management and powershell) and attempted reinstall following reboot

    Enabled dot net and dot net features prior to steps 1-8

    DISM.exe /online /enable-feature /all /featurename:NetFx4
    DISM.exe /online /enable-feature /all /featurename:MicrosoftWindowsPowerShell

     None of these steps have worked. Im wondering if perhaps a pre-requisite or other requirement is simply not met for these servers?

    Any advise would be appreciated

Answers

  • We ended up creating a PSS case with Microsoft, however the issue was so simple I have included the fix (for future generations that run across this same issue)

    Carry out the conversion to Full GUI

    Check the following key:

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell

    Ours was set to ‘powershell not exist -command’

    Change this to explorer.exe

    Logoff and back on again

    GUI should be restored

    For whatever reason, this key was not getting updated as part of the conversion process. Still awaiting some feedback from Microsoft in relation to this

    • Marked as answer by

      Thursday, June 2, 2016 7:13 AM

    • Edited by
      TechieBuff
      Monday, November 21, 2016 4:50 AM
      mistype

Продолжаю решать задачи получения программ из автозапуска, начавшуюся с получения путей к папкам Startup из реестра :)

Задача: получить все программы из автозапуска в реестре

Ключи для примера:

  • HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
  • HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun

Пример получения по ключу списка значений, в котором будут программы на автозапуск для текущего пользователя:

import winreg

from typing import Optional
from winreg import QueryInfoKey, EnumValue, OpenKey, HKEYType


def get_key(path: str) -> Optional[HKEYType]:
    # Example:
    #     path = r"HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders"
    #     registry_key_name = "HKEY_LOCAL_MACHINE"
    #     relative_path = r"SoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders"
    registry_key_name, relative_path = path.split('\', maxsplit=1)
    registry_key = getattr(winreg, registry_key_name)

    try:
        return OpenKey(registry_key, relative_path)
    except:
        return


key = get_key(r"HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun")

_, number_of_values, _ = QueryInfoKey(key)
for i in range(number_of_values):
    name, value, type_value = EnumValue(key, i)
    print(name, value)

Does anyone know how Server Core knows it has to start cmd.exe as shell?

It being just another version of Windows, you would expect it to be specified the same way as it always has from NT on, via one of these registry keys:

  • HKLMSoftwareMicrosoftWindows NTCurrentVersionWinLogon
  • HKCUSoftwareMicrosoftWindows NTCurrentVersionWinLogon
  • Value Shell, REG_SZ = the executable to start as shell (full path if it isn’t in C:Windows).

However, that isn’t what I found in Server 2016 Core. The Shell value doesn’t exist in the HKCU branch, and in the HKLM branch it is set to «explorer.exe» like in a full GUI installation.

Knowing where to find it could allow someone to use another shell (powershell for instance), or let it open the sconfig menu by default instead of just an empty CMD window (meaning instead of the cmd window, instead of besides it as would be via the Run registry key).

asked Jun 20, 2018 at 6:54

Luc VdV's user avatar

6

EDIT: Of course I find another answer to this within minutes of posting.
https://serverfault.com/questions/1098102/how-to-start-cmd-as-default-shall-for-windows-server-core-2022

I was trying to remember how I accomplished this in the past so I could change my shell to pwsh instead of powershell when I found this question. It jogged my memory so I figure I would share.

I never found official documentation on this, but through experimentation on Server Core 2016 and Hyper-V Server 2019 I discovered that the String Value with the largest numeral Name in HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells will run at login.
I did not extensively test the ‘highest numeral’ hypothesis, but observed that my script stored in the Data of 60000 runs while 30000 does not. I also tested by adding a new String Value named 90000 with the data notepad and only notepad runs at login, not 60000 or 30000.

Example:
screenshot

This change is immediate, so all you need to do is log off and back on to see the results.

Maybe I’ll find this next time I forget how to do this :)

answered Apr 20, 2022 at 18:47

Mike's user avatar

MikeMike

314 bronze badges

I also saw the hklm shell= explorer.exe (the default windows shell), but expected cmd.exe for server core.
I did see whenever a user connects runonce.exe is runs (from startup folder) with a switch /AlternateShellStartup

However, how it knows to do that, is another question

answered Feb 19, 2021 at 15:19

JamKomo's user avatar

  • Remove From My Forums

 none

Как стать владельцем ветки реестра и удалить ее?

  • Вопрос

  • Стоит задача, массово удалить ветку реестра HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells на многих компах. Владельцем этой ветки является: TrustedInstaller. Поэтому пытаюсь
    для начала стать владельцем этой ветки

    Набросал скриптик на PS:

    $acl = Get-Acl "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells"
    $person = [System.Security.Principal.NTAccount]"BUILTINAdministrators"          
    $access = [System.Security.AccessControl.RegistryRights]"FullControl"
    $inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit"
    $propagation = [System.Security.AccessControl.PropagationFlags]"None"
    $type = [System.Security.AccessControl.AccessControlType]"Allow"
    $rule = New-Object System.Security.AccessControl.RegistryAccessRule($person,$access,$inheritance,$propagation,$type)
    $acl.AddAccessRule($rule)
    $acl |Set-Acl

    Скрипт выполняется с ошибкой: Set-Acl : Requested registry access is not allowed.

    Т.е. не получается стать владельцем этой ветки реестра. Если делать смену владельца руками — то все проходит нормально. Что я делаю не так?

Ответы

  • Спасибо за помощь. Решилось обычным батником :)

    SetACL.exe -on "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells" -ot reg -actn setowner -ownr "n:Administrators"
    SetACL.exe -on "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells" -ot reg -actn ace -ace "n:Administrators;p:full"
    SetACL.exe -on "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells" -ot reg -actn setowner -ownr "n:Administrators"
    SetACL.exe -on "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells" -ot reg -actn ace -ace "n:Administrators;p:full"
    reg delete "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAlternateShells" /f	

    • Помечено в качестве ответа

      15 июля 2019 г. 10:05

Permalink

Cannot retrieve contributors at this time


This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters

Show hidden characters

HKCUEnvironmentUserInitMprLogonScript
HKCUSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRun
HKCUSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRunonce
HKCUSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRunonceEx
HKCUSoftwareMicrosoftWindows NTCurrentVersionWindowsLoad
HKCUSoftwareMicrosoftWindows NTCurrentVersionWindowsRun
HKCUSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell
HKCUSOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorerRun
HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemShell
HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun
HKCUSOFTWAREMicrosoftWindowsCurrentVersionRunOnce
HKCUSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
HKCUSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff
HKCUSoftwarePoliciesMicrosoftWindowsSystemScriptsLogon
HKCUSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun
HKCUSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnce
HKCUSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnceEx
HKLMEnvironmentUserInitMprLogonScript
HKLMSOFTWAREMicrosoftActive SetupInstalled Components
HKLMSOFTWAREMicrosoftWindows CE ServicesAutoStartOnConnect
HKLMSOFTWAREMicrosoftWindows CE ServicesAutoStartOnDisconnect
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRun
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRunonce
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftwareMicrosoftWindowsCurrentVersionRunonceEx
HKLMSoftwareMicrosoftWindows NTCurrentVersionWindowsIconServiceLib
HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonAlternateShellsAvailableShells
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAppSetup
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonTaskman
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonUserinit
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonVmApplet
HKLMSoftwareMicrosoftWindowsCurrentVersionGroup PolicyScriptsShutdown
HKLMSoftwareMicrosoftWindowsCurrentVersionGroup PolicyScriptsStartup
HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesExplorerRun
HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemShell
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnce
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunOnceEx
HKLMSoftwarePoliciesMicrosoftWindowsSystemScriptsLogoff
HKLMSoftwarePoliciesMicrosoftWindowsSystemScriptsLogon
HKLMSoftwarePoliciesMicrosoftWindowsSystemScriptsShutdown
HKLMSoftwarePoliciesMicrosoftWindowsSystemScriptsStartup
HKLMSOFTWAREWow6432NodeMicrosoftActive SetupInstalled Components
HKLMSOFTWAREWow6432NodeMicrosoftWindows CE ServicesAutoStartOnConnect
HKLMSOFTWAREWow6432NodeMicrosoftWindows CE ServicesAutoStartOnDisconnect
HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRun
HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnce
HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionRunOnceEx
HKLMSYSTEMCurrentControlSetControlSafeBootAlternateShell
HKLMSystemCurrentControlSetControlTerminal ServerWdsrdpwdStartupPrograms
HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-TcpInitialProgram

Содержание

  1. Грузимся модно
  2. Вадим Стеркин
  3. Чем удобны команды
  4. Запуск элементов ActiveX
  5. Получение списка элементов ActiveX
  6. Переход в известные папки
  7. Список известных папок для команд shell
  8. Об авторе
  9. Параметр shell в реестре windows
  10. 1. В автозагрузке операционной системы
  11. 2. Вместо проводника
  12. 3. Вместе с userinit.exe или uihost.exe
  13. dojuk
  14. Записки сисадмина
  15. В помощь админу и эникейщику
  16. Автоматический запуск программ в Windows
  17. Автозапуск из файлов инициализации
  18. Папки автозапуска
  19. Системный реестр: автозапуск, общий для всех версий Windows
  20. Особенности автозапуска в Windows NT/2000/XP
  21. Особенности автозапуска в Windows ME/2000/XP
  22. Автозапуск при отработке Windows Logon
  23. Параметр Shell
  24. Параметр System
  25. Параметр VmApplet
  26. Параметр Userinit

Грузимся модно

title

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

Мне кажется или все разленились? Уже никто
не хочет думать! Некоторые задачи стали
настолько тривиальны, что никто даже не
думает над их решением. Я это к тому, что
большая часть людей считает, что в Windows’е
можно сделать автозагрузку через VxD или RUN в
реестре. хммм. давайте копнем поглубже и
увидим неограниченые возможности скрытые в
Windows.

Люди особо «творческого» ума могут
сообщить нам, что загрузится можно
скопировав себя куда-то в «C:WINDOWSГлавное
менюПрограммыАвтозагрузка»(В Windows XP это
будет выглядеть где-то так: «C:Documents and
SettingsUserПрограммыАвтозагрузка»). Не
спорю, такой вариант сработает, но давайте
сделаем немного иначе. Местоположение этой
папки система узнает с реестра. Упоминания
о ней можно найти в таких разделах:

HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionExplorerShell
Folders
HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionExplorerUser Shell
Folders
HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionexplorerShell
Folders
HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionexplorerUser
Shell Folders

Значение там хранится в переменных «Startup»
и «Common Startup». Все дело в том, что в
переменную «Common Startup» можно написать
все, что угодно. То есть записав туда «c:windowssystemmy_secret_program»
мы запустим все программы находящиеся в
каталоге «my_secret_program». Привет Билли 🙂

Ну. Тут есть два варианта, использовать
WIN.INI или SYSTEM.INI. В WIN.INI ключ «windows»
содержит две переменные load и run. Придаваемые
им значения и есть программы которые надо
загрузить. Например:
.
[windows]
load=my_secret_pogram1.exe
run=my_secret_pogram2.exe
.

А в SYSTEM.INI метод немного другого характера. В
ключе «boot» есть параметр Shell, он задает
программу которая будет служить GUI для Windows.
По умолчанию это Explorer, но можно указывать и
другую программу 🙂 А самое интересное то,
что можно указать и Explorer с параметром/параметрами.
На что он услужливо запустит передаваемый
параметр. Например:
.
[boot]
Shell=Explorer.exe my_secret_pogram.exe
.

И снова подарки от майкрософт 🙂 Шелл еще
указывается в реестре: «HKEY_LOCAL_MACHINESOFTWAREMicrosoft
Windows NTCurrentVersionWinlogonShell». По умолчанию там
Explorer, но его можно заменить.

Ну что, поехали дальше. Что такое бат файлы
знают все (я надеюсь. ), но не все знают что
существует достаточно интересный файл
winstart.bat, который находится в папке Windows. Он
автоматически запускается системой каждый
раз при загрузке. Это обычный Bach файл с
досовскими командами. Чтобы с его помощью
запустить нашу программу добавляем в файл
что-то вроде: c:windowsmy_secret_program.exe.

В противовес ему прилагается dosstart.bat,
который как и winstart находится в директории
Windows, но запускается он если выбрать «Перезагрузить
компьютер в режим эмуляции MS-DOS».

И конечно же Autoexec.bat, про который нельзя не
упомянуть говоря про батники :), запускается
при каждой загрузке твоего металлического
друга еще до винды. А для счасливых
обладателей NT/XP я имею другую прекрасную
новость. У них Autoexec.bat не грузится, зато Microsoft
не обделила и их вниманием, они могут
пользоваться файлом Autoexec.NT 🙂 Его работа
заключается в том, что если у DOS’овской
программы нет ярлыка, то настройки для
создания DOS-BOX’а берутся из него. А он в свою
очередь тот же батник 🙂 А если кто-нибудь
хочет загрузится в NT с Autoexec.bat (удовольствие
для исключительных извращенцев), тогда
придется покопаться в реестре. В разделе:

Значение переменной ParseAutoexec установите
равным «1». Вот и все 🙂

Хех. Про реестр рассказали уже столько
баек, что мне даже стыдно про него упоминать,
но ради приличия перечислю стандартные
ключи автозагрузки и то, о чем знают
немногие. Итак, стандартные места откуда
можно загрузится:

HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionRunServices
HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionRunServicesOnce
HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionRun
HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionRunOnce

HKEY_CURRENT_USERSoftware MicrosoftWindowsCurrentVersionRun
HKEY_CURRENT_USERSoftware MicrosoftWindowsCurrentVersionRunOnce
HKEY_CURRENT_USERSoftware MicrosoftWindowsCurrentVersionRunServices

Тут все просто в нужном разделе, создаем
параметр со значением запускаемой проги. А
теперь встречайте RunOnceEx! Что очень
удивительно, мало кто знает как в этом ключе
прописать свою программу. Вот рекомендации
по использованию 🙂

1 Создаем ключ(если его нету)

2 Создаем строковую переменную со
значением программы которую надо запустить,
но в интересном формате:

«DLL|Function|Arguments» или «||command parameters»

То есть у нас есть два варианта: мы можем
запустить некоторую функцию Function или exe-шник.

Ах да. В NT есть еще один раздел:

HKEY_LOCAL_MACHINESoftware MicrosoftWindows
NTCurrentVersionWinlogonUserinit

Работает он также, как и классический RUN.

Windows NT позволяет запускать специально
написанные программы до регистрации
пользователя (logon). Эти программы
подразделяются на две группы: драйверы и
сервисы. Все дело в том, что любую Win32
программу можно запустить до logon с помощью
специального сервиса. В Windows NT Resource Kit
включен сервис srvany.exe, выполняющий именно
эти задачи :). Его подробное описание
находится в файле srvany.wri. Почитай на досуге 🙂

Ну и наконец, после такого прогрузона я
скажу, что если тебе влом копаться в этом
дерьме, то ты можешь просто скопировать
my_secret_pogram.exe в корень диска C: и
переименовать в Explorer.exe. Он запустится до
настоящего Эксплорера 🙂 И это работает во
всех версиях Windows.

Теперь ты вооружен. Надеюсь после прочтения
этого ты задумаешься, каким способом будет
грузится твой новый троян 🙂 Удачи!

Источник

Вадим Стеркин

lib 64Вы, наверное, знакомы с командами shell, которые позволяют открывать различные системные и пользовательские расположения. Например, команда shell:Libraries в Windows 7 открывает библиотеки. Я предлагаю вам посмотреть, откуда они берутся и как их применять для ускорения работы.

Чем удобны команды

Поскольку тема явно не новая, я предлагаю вам взглянуть на ее практическое применение в этой и следующей статьях. С помощью команд shell вы можете:

shell commands profile

Запуск элементов ActiveX

Сначала я расскажу о реже упоминаемом источнике команд, а заодно и менее распространенном (но иногда очень нужном) способе их запуска.

содержит список апплетов ActiveX, которые можно определить по наличию подраздела ShellFolder, Видите словесную связь с командой shell? Название подраздела реестра (GUID) можно использовать в качестве кода запуска, поставив после команды shell три двоеточия. Например, команда:

открывает папку Недавние места. Она отличается от папки Недавние документы тем, что в ней не отображаются недавно открытые файлы, а только список мест (папок, поисков, элементов панели управления), которые вы недавно открывали в проводнике и диалоговых окнах. К этой папке мы вернемся в следующей статье, в рамках рассказа о тонкой настройке окон «Открыть» и «Сохранить как».

Проводник Windows (explorer) понимает команды shell в качестве параметров командной строки, что можно использовать для команд в реестре. Так, в контекстные меню папки, рабочего стола и компьютера можно добавлять команды для открытия элементов панели управления, системных и пользовательских папок.

Получение списка элементов ActiveX

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

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

Переход в известные папки

Более известный способ запуск команд основан на использовании кодовых слов, т.е. текстовых идентификаторов папок, которые понятны системе. Например, избранное проводника можно создать открыть так.

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

Так, для создания ярлыка, щелкните правой кнопкой мыши на рабочем столе и выберите Создать — Ярлык. Затем введите команду:

Все кодовые слова для команд можно найти в разделе реестра

Заглянув в его подразделы, можно подметить два момента:

Во втором случае мы как раз имеем дело с элементами ActiveX, а GUID в значении параметра указывает на подраздел в HKLMSOFTWAREClassesCLSID, o котором шла речь выше. Теперь вы видите, почему при запуске команд путем вызова GUID используется дополнительная пара двоеточий.

Список известных папок для команд shell

Ниже приводится список этих команд для Windows Vista и Windows 7:

Об авторе

Источник

Параметр shell в реестре windows

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

where hide viruses

В зависимости от продвинутости создателя вируса это может быть реализовано по-разному. Рассмотрим самые распространенные случаи, где прячутся вирусы:

1. В автозагрузке операционной системы

autorun

В столбце «Команда» не должно быть подозрительных элементов, например C:Program Filesnovirus.exe

Команда msconfig позволяет только отображать и отключать ненужные программы из автозагрузки, для полного удаления следов необходимо почистить соответствующие ветки реестра (посмотреть в столбце «Расположение»).

Как альтернативe команде msconfig можно использовать программу XPTweaker.

В разделе «Система» перейти на закладку «Загрузка системы», прокрутить скроллом немного вниз до заголовка «Автозагрузка». Также просмотреть внимательно список загружаемых вместе с операционной системой приложений и при необходимости удалить ненужные. Программа удаляет информацию сразу и в реестре Windows.

Дополнительно:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun и

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun

2. Вместо проводника

В ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon
Параметр Shell (reg_sz) вместо значения «explorer.exe» заменяется вирусом на свой, например C:WINDOWSsystem32h6d8dn.exe или подобную хрень.

Нужно посмотреть запись в реестре по адресу HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, исправить «хрень» у записи параметра Shell (reg_sz) на «explorer.exe» и запомнить путь нахождения и имя файла вируса, чтобы удалить его вручную.

3. Вместе с userinit.exe или uihost.exe

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

Некоторые вирусы могут изменить запись в реестре у трех параметров (у всех или только некоторых) Userinit, UIHost и Shell, расположенных по адресу:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Оригинальные параметры записи в реестре должны быть следующими :

Userinit = C:WINDOWSsystem32userinit.exe
UIHost = logonui.exe
Shell = explorer.exe

whereviruseshide

Вирус может прописать себя например так :

После удаления нужно заменить файлы userinit.exe, logonui.exe (находятся в C:WINDOWSsystem32) и explorer.exe (находится в C:WINDOWS) на аналогичные файлы из дистрибутива виндовса (найдете поиском), т.к. остатки червя могут находиться в файлах ключей. Или скачайте отсюда.

После нужно проверить файл hosts (открыть любым тестовым редактором) на наличие запретов на известные сайты антивирусных программ: C:windowssystem32driversetchosts. Удалить все после строки 127.0.0.1 localhost

Также запрет на загрузку сайтов может быть прописан в реестре по следующим адресам:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersPersistentRoutes

HKEY_LOCAL_MACHINESYSTEMControlSet <номера 001 или 002>ServicesTcpipParameters PersistentRoutes

Удалить их содержимое полностью кроме строки «По умолчанию» с неприсвоенным значением.

Источник

userinfo v8dojuk

Записки сисадмина

В помощь админу и эникейщику

Автоматический запуск программ в Windows

Начиная с 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

Итак, я приведу полные пути к ключам: «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 — сетевого динамического обмена данными.

Расширения в именах файлов, перечисленных в этом параметре, не обязательны.

Источник

Понравилась статья? Поделить с друзьями:
  • Hklm software microsoft windows nt currentversion image file execution options
  • Hklm software wow6432node microsoft windows nt currentversion svchost netsvcs hpsvc
  • Hklm software wow6432node microsoft windows currentversion uninstall
  • Hklm software wow6432node microsoft windows currentversion run что это
  • Hklm software policies microsoft windows windowsupdate au