How can I adjust the Image File Execution Options per-process invocation(like a CreateProcess call)?
It is possible to programmatically enable application verifier, but this works by creating a persistent registry key in hkey_local_machine that affects all processes, and requires administrator access to do so. I'd like to enable the equivalent of specific application verifier checkboxes for individual processes, not per-exe.
Related
I'm trying to get a process name from its pid. User is running as Administrator, UAC enabled, not elevated.
Some system processes, like services.exe, have their security set up in such way that OpenProcess(PROCESS_QUERY_INFORMATION ... fails with ERROR_ACCESS_DENIED. Same result with PROCESS_QUERY_LIMITED_INFORMATION access right. However, I can see that Process Explorer can at least list all these processes, along with their pid and file name (when running as non-elevated Administrator).
My question is, how can I do the same (get file name from pid), given that non-elevated administrator cannot follow the usual route of OpenProcess() + GetProcessImageFileName()?
Have you tried Process32First() and Process32Next() with a handle retrieved by CreateToolhelp32Snapshot()? It doesn't give you the full path but should at least let you get the file name.
Have you tried PROCESS_QUERY_LIMITED_INFORMATION instead? It requests a lower level of access that can provide at least the name of the executable. It allows you to call QueryFullProcessImageName which provides the information you're looking for
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684919(v=vs.85).aspx
You can't open system processes (more precisely, processes running under another account - in this case user SYSTEM) without SE_DEBUG privilege enabled for your process.
If you are running as admin, you can easily set the privilege:
http://support.microsoft.com/kb/131065/en-us
I would like to execute a procedure that should be fired only upon windows system startup, and startup here does not mean program startup. Is there anything that I can do to trigger my procedure. If possible, i would like to avoid messing with the registry. I am using delphi 2010.
There are many options, but all will involve settings that require admin rights. These options include:
Put your routine in a service that is set to start automatically. This will start up when the system starts up and before any user has logged on.
Add an entry to HKLM\Software\Microsoft\Windows\CurrentVersion\Run. This will execute when an interactive user logs on.
Add a scheduled task with an appropriate trigger, e.g. At startup.
I'm writing an application in Delphi 2010, and I'd like to provide the option to the administrator to configure it via Group Policy. Any recommendations on good ways to make my application GPO aware? Note, I am only looking to create a computer based GPO, not user.
My current solution involves simply first determining if any values have been written to the registry at HKLM\software\policies\MyProgram. If they have, I assume that GPO has been applied and I use this location to read configuration.
If nothing exists at the above registry location, I proceed to reading configuration at the standard location, whether that's an INI file, or another reg key does not matter. At this point, I make the assumption in the program that group policies are not being used.
Would anyone suggest a better way to make this application GPO aware?
It's not that you have to be group policy aware, it's that the group policy has to be aware of the registry keys your program uses.
The purpose of custom Group Policy Templates is to have a user-interface for managing a custom set of registry keys used by a particular program. The domain administrator sets the policy to the desired values, and the policy is pushed out to machines on the domain.
In your case, the custom policy template will define the corresponding HKLM registry keys that your program uses. You can now trust that the values stored in:
HKLM\Software\MickSoftware\My Program 2010
are what the administrator has desired be there.
Note: The following "policy" registry locations are non-persistent:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
HKEY_CURRENT_USER\SOFTWARE\Policies
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
"This means that when you log off the computer or when you shut down the computer, the policy settings are removed."
So it seems to me you want to store your registry values where you normally store them, e.g.:
HKLM\Software\Avatar Software Creations\HelpDesk\DatabaseServer
ServerName: REG_SZ = "lithium"
UserID: REG_SZ = "helpdesk"
Password: REG_SZ = "aSBsb3ZlIHlvdSBLaXJzdGVuIFNoZWxieSBHdXllcg=="
How do I change the startup list? Basically I have a program that is a computer locking system and when I enter it into the registry to start up when login, it is like the last thing to open.
Which startup list are you using to launch your application?
There are actually quite a few startup lists (see below). The order of application launch within a given list is not configurable (e.g. there is no way to choose which application in the Startup Folder launch first) but, the order in which the startup lists are iterated is fixed (e.g. Applications in the Common Startup Folder will always launch first, before applications in the Startup Folder).
It sounds like you want to launch your application on user login, so listing your application path in the All Users-Run registry key should ensure that it launches fairly soon after logon.
Add a string (REG_SZ) value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run registry key with the path to your application as the data.
(Aside: Background reading on the arcane terminology of the Windows registry)
STARTUP ORDER FOR WINDOWS 9X/ME
config.sys
autoexec.bat
wininit.ini
winstart.bat
system.ini
win.ini
All Users-RunOnce (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce)
All Users-RunServices
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices)
All Users-RunOnce
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce)
All Users-Run
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run)
All Users-RunOnceEx
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx)
All Users-RunEx
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunEx)
Current User-RunOnce
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce)
Current User-Run
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run)
Current User-RunOnceEx
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnceEx)
Current User-RunEx
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunEx)
Common Startup Folder
Startup Folder
STARTUP ORDER FOR WINDOWS NT4/2000/XP
BootExecute
(`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
Services
User enters a password and logon to the system
UserInit
(HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\UserInit)
Shell
(HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell)
All Users-RunOnce
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce)
All Users-Run
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run)
All Users-RunOnceEx
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx)
All Users-RunEx
(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunEx)
Current User-RunOnce
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce)
Current User-Run
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run)
Current User-RunOnceEx
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnceEx)
Current User-RunEx
(HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunEx)
Common Startup Folder
Startup Folder
(Source)
I have a Windows executable that is launched from within a service by calling CreateProcessWithLogonW() with a set of specfied user details.
This works fine and the process starts as expected. However, when this process tries to launch other processes itself, currently just using CreateProcess() these start then die straight away - they are executables that require desktop access.
After reading up on Microsoft's article on CreateProcess() - http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx
I think can see why this is happening and it makes sense to an extent. CreateProcess() knows the calling process is impersonating a user so it uses it's parent process, which in this case is the Local System account. But of course anything run in the local system account doesn't have the access we need, so the launched process dies.
Oddly when I was previously using LogonUser() and CreateProcessAsUser() to launch the initial executable within the service, it worked fine. But I had to change this to CreateProcessWithLogonW() due to problems with not having the correct privileges.
Does anybody know of a solution to this? I've seen talk about this elsewhere on the web but not with any definite solution. It seems like I possibly need the token of the user i'm logging on with in CreateProcessWithLogonW() with so I can use it to launch the other processes later? But I have no way of getting hold of this token, can this be retreived for the current user in any way?
Any help would be greatly appreciated, thanks :)
We solved the problem using some code that I found long-ago. The "copyright" section of one of the source modules contains the following:
/////////////////////////////////////////////////////////////
// CreateProcessAsUser.cpp
//
// Written by Valery Pryamikov (1999)
//
// Command line utility that executes a command under specified user identity
// by temporarily installing itself as a service.
//
// Based on Keith Brown's AsLocalSystem utility (http://www.develop.com/kbrown)
// Uses some code from Mike Nelson's dcomperm sample utility
// and from tlist sample (Microsoft Source Code Samples)
//
// Use:
// CreateProcessAsUser.exe [-i[nteractive]]|[-s[ystem]]|
// [-u"UserName" -d"DomainName" -p"Password"]|[-a"AppID"] command
// Command must begin with the process (path to the exe file) to launch
// -i process will be launched under credentials of the
// "Interactive User" (retrieved from winlogon\shell process)
// -a process will be launched under credentials of the user
// specified in "RunAs" parameter of AppID.
// -s process will be launched as local system
// -u -d -p process will be launched on the result token of the
// LogonUser(userName,domainName,password,LOGON32_LOGON_BATCH...)
//
// either (-s) or (-i) or (-a) or (-u -d -p) parameters must supplied
//
// Examples:
// CreateProcessAsUser -s cmd.exe
// CreateProcessAsUser -a"{731A63AF-2990-11D1-B12E-00C04FC2F56F}" winfile.exe
//
/////////////////////////////////////////////////////////////
Perhaps this information will yield hits within your Google searches - I attempted a few quick attempts but came up empty-handed.
We decomposed the internals into a set of API that yielded the results we needed.
Do you own the code launched using CreateProcessWithLogonW (and which in turn calls CreateProcess)? If you do not then you might need to perform IAT (or API) hooking on it (i.e. at run-time), as to substitute any calls to CreateProcess with an appropriate procedure that also uses CreateProcessWithLogonW or CreateProcessWithTokenW. See APIHijack, Detours.
After this is done, the child process may require access to HKCU. If you are not already doing this, you should load the profile of each impersonated user, once per user, before calling CreateProcessWithLogonW.
By default, CreateProcessWithLogonW
does not load the specified user
profile into the HKEY_USERS registry
key. This means that access to
information in the HKEY_CURRENT_USER
registry key may not produce results
that are consistent with a normal
interactive logon. It is your
responsibility to load the user
registry hive into HKEY_USERS before
calling CreateProcessWithLogonW, by
using LOGON_WITH_PROFILE, or by
calling the LoadUserProfile function.
Isn't there an option for services to allow them to interact with the desktop? If setting that option for your service is a possibility, that would probably be the simplest solution.
I'm assuming that this process is a service; that isn't specified in the question, but seems logical given that it is running as Local System account.
Where you're getting stuck isn't in CreateProcess, It's in CreateService. If you want your service to be able to interact with the desktop, you have to specify SERVICE_INTERACTIVE_PROCESS as one of the flags to the argument dwServiceType. This setting is inherited by child processes of the service.
You can also modify an existing service's setting by using the Services tool, select Properties for the service, click on the "Log On" tab, and select the check box "Allow service to interact with desktop".