Recently, i was trying to give my application administrator rights without system asking for "Do you want to give administrator rights?" and i found a way which is working perfectly.
Solution I Found
I created a bat file named nonadmin.bat and wrote the below code in it
cmd min C set __COMPAT_LAYER=RunAsInvoker && start "" %1
and if we drag any exe on it, it gives them administrator rights (before it was not letting me access environment variables without it but after draging the file on bat it did work).
Question
Now my question is:-
What actually '__COMPAT_LAYER' means and what does it do?
How do i remove such a thing so that it asks for administrator rights again?
Does this reduce system security?
__COMPAT_LAYER, and How To Use It
__COMPAT_LAYER is a system environment variable that allows you to set compatibility layers, which are the settings you can adjust when you right-click on an executable, select Properties, and go to the Compatibility tab.
There are several options to choose from in addition to the one you know about:
256Color - Runs in 256 colors
640x480 - Runs in 640x480 screen resolution
DisableThemes - Disables Visual Themes
Win95 - Runs the program in compatibility mode for Windows 95
Win98 - Runs the program in compatibility mode for Windows 98/ME
Win2000 - Runs the program in compatibility mode for Windows 2000
NT4SP5 - Runs the program in compatibility mode for Windows NT 4.0 SP5
You can use multiple options by separating them with a space: set "__COMPAT_LAYER=Win98 640x480"
Unsetting the __COMPAT_LAYER Variable
These settings persist for as long as the variable exists. The variable stops existing when either the command prompt in which the variable was set is closed, or when the variable is manually unset with the command set __COMPAT_LAYER=.
Since you are setting the variable via batch script, the variable is automatically unset once the executable you drag onto it completes and the script closes. It is important to note that the variable settings persist to any child processes that are spawned by the executable you select.
The Security of Using __COMPAT_LAYER
Setting __COMPAT_LAYER to RunAsInvoker does not actually give you administrator privileges if you do not have them; it simply prevents the UAC pop-up from appearing and then runs the program as whatever user called it. As such, it is safe to use this since you are not magically obtaining admin rights.
You can also set the variable to RunAsHighest (only triggers UAC if you have admin rights, but also does not grant admin rights if you do not have them) or RunAsAdmin (always triggers UAC).
Related
I have a tablet running Windows 10, and I need to lock it down to only run my custom executables.
My launch executable require administrative privileges to perform some functions (e.g. change system clock, start other executables, open/close serial ports) and I have enabled "Run this program as an administrator" in the executable compatibility settings. Launching the application via double-click in an explorer window or via command line, the system is able to launch its other dependent executables and functions correctly.
However, I need to get this executable to launch on log-in, and research suggests replacing the registry key linking to explorer.exe with my own launch.exe to be the simplest approach. I proved this works with notepad.exe, but my launch.exe application doesn't start... I just get a black screen.
What am I missing here to get my own executable to launch?
Attempt Breakdown
By creating a registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell and setting its value to notepad.exe, I can get notepad to start on launch.
When I change the value of the Shell key to C:\Windows\notepad.exe, this works too.
When I change the value of the Shell key to my custom executable, e.g. C:\custom\launch.exe... I get a black screen and no evidence the executable was launched as no log files from my system are generated.
Workaround Solution:
I was able to use Task Scheduler to launch my application with highest privileges, thus side-stepping the problem in the question above.
To disable explorer.exe as required, I replaced the Shell key value with a custom do_nothing.bat script that does (almost) nothing... and thus doesn't trigger explorer.exe. The file cannot be empty as otherwise Windows throws an error.
do_nothing.bat:
rem ---DO SOMETHING TO PREVENT EXPLORER.EXE LAUNCHING---
cd \
I am currently using a VB-Skript, which is used to start a setup.exe file, which requires administrative privilleges in order to be installed correctly, if it is not started as an administrator it will return a corresponding error message. Both the script and the setup are located on a window share that is located in a network classified as "Worokplace" in Win7 (32 Bit).
I have the foloowing strange effect, which I do not understand:
I run explorer.exe as "Administrator", and start the script by doubleclicking, which results in a final errormessage that setup.exe requires administrative privileges in order to run. I thought that when I run explorer.exe as Administrator, all other processes started within will have the same privileges.
I tried the same by starting cmd.exe as an Administrator, run the vbs by simply typing myscript.vbs, and the installation succeeds.
Obviously, the same script started from explorer with administrative rights and started from cmd.exe with administrative right finally gets different privilleges, which is what I do not understand at all. Can anybody please explain what's going on there?
Thanks alot
Any process can start a child process, and the parent process can choose what environment (including access rights) the child process will run in. The difference is simply that cmd.exe allows child processes to inherit its own environment, while explorer.exe will only apply administrator privileges if it has been told to do so, either by right-click and 'Run as administrator' or by editing the properties of a shortcut.
The bottom line is simply that they are coded that way.
In matlab, I used a windows standalone application. There is a line in this application that writes a file in C:\...\...\. When I run the output exe file produced from this windows standalone application, the exe doesn't write in C:\...\...\ neither tells me that there is a security issues in that partition. All the execution does is nothing. But, when I right-click and run the exe as administrator, it runs correctly.
I want to do it without right-click and run as administrator. Are there is a command in matlab that can do that?
If you create a shortcut to your application, you can go to the Properties of the shortcut, click on Advanced in the Shortcut tab, and select "Run as administrator". That way, whenever you start the application from the shortcut it will be run as an administrator.
(Disclaimer: applications really shouldn't "foul their own nest" by writing into Program Files. This is bad design.)
Starting from Vista, unprivileged processes are not allowed to write to protected folders such as Program Files, because Program Files is designed to store code and not data. However, since this limitation has not been enforced in XP, MS has provided a backward-compatibility hack in the form of Virtual Store. Now, when a program tries to write to protected folder, its output is being redirected into a dedicated folder. This way, the program still "thinks" it writes to its usual location, while in fact it writes to an unprotected location. However, when you later check the Program Files location, you might not see the file - because it's not really there.
You can find more details here: User Account Control Data Redirection.
If you are administrator, add full control permission for your username to the destination folder. You do that by right clicking on the folder, going to properties and then security tab. Then edit and add you username with Full Control rights. Then you don;t have to run the the program as an administrator.
There is no way you can elevate a process once it is started, so Matlab cannot possibly have a command for that. Just running Matlab elevated.
In older versions of Windows, it was just open the Control Panel, select the System applet, select the Advanced tab, and then hit the Environment variables button. As a normal user, you could edit the "User variables" but not the "System variables".
In Windows Server 2008 R2, if I try to hit the Advanced System settings option in the System applet, it prompts for the Administrator password.
You can also use this direct command line to open the Advanced System Properties:
sysdm.cpl
Then go to the Advanced Tab -> Environment Variables
OK I found it. Arg, an exercise in frustration. They left the old window menu traversal path for changing environment variables in there, but limited access to administrators only. As a normal user, if you want to change it, you need to go through a different set of options to arrive at the same frigging window.
Control Panel -> User Accounts -> User Accounts -> Change my environment variables.
Step by step instructions:
Go to Control Panel \System and Security\System
Click on Change Settings
Go to “Advance” tab
Click on Environment Variables
Under "Start" enter "environment" in the search field. That will list the option to change the system variables directly in the start menu.
This can be done from the command line using the SETX command. For example to 'move' your temporary files to another disk:
SETX TEMP d:\tmp
In command line prompt:
set __COMPAT_LAYER=RUNASINVOKER
SystemPropertiesAdvanced.exe
Now you can set user environment variables.
I created a godmode folder on the desktop. just create a new folder on the desktop and call it GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
it will name the folder as godmode and populate the content with various config options, you can then just type in ENVIRO in the search to find the relevant config option, open it and it opens sysdm.cpl in the advanced tab, you can change the environment variables from there.
There are three ways
1) This runs the GUI editor for the user environment variables. It does exactly what the OP wanted to do and does not prompt for administrative credentials.
rundll32.exe sysdm.cpl,EditEnvironmentVariables
(bonus: This works on Windows Vista to Windows 10 for desktops and Windows Server 2008 through Server 2016. It does not work on Windows NT, 2000, XP, and 2003. However, on the older systems you can use sysdm.cpl without the ",EditEnvironmentVariables" parameter and then navigate to the Advanced tab and then Environment Variables button.)
2) Use the SETX command from the command prompt. This is like the set command but updates the environment that's stored in the registry. Unfortunately, SETX is not as easy to use as the built in SET command. There's no way to list the variables for example. Thus it's impossible to do something such as appending a folder to the user's PATH variable. While SET will display the variables you don't know which ones are user vs. system variables and the PATH that's shown is a combination of both.
3) Use regedit and navigate to HKEY_CURRENT_USER\Environment
Keep in mind that changes to the user's environment does not immediately propagate to all processes currently running for that user. You can see this in a command prompt where your changes will not be visible if you use SET. For example
rem Add a user environment variable named stackoverflow that's set to "test"
setx stackoverflow test
set st
This should show all variables whose names start with the letters "st". If there are none then it displays "Environment variable st not defined".
Exit the command prompt and start another. Try set st again
and you'll see
stackoverflow=test
To delete the stackoverflow variable use
setx stackoverflow ""
It will respond with "SUCCESS: Specified value was saved." which looks strange given you want to delete the variable. However, if you start a new command prompt then set st will show that there are no variables starting with the letters "st"
(correction - I discovered that setx stackoverflow "" did not delete the variable. It's in the registry as an empty string. The SET command though interprets it as though there is no variable. if not defined stackoverflow echo Not defined says it's not defined.)
Does anybody know if there is a feasible way on Windows XP to programmatically create and configure a user account so that after logging in from the console (no terminal services) a specific app is launched and the user is "locked" to that app ?
The user should be prevented from doing anything else with the system (e.g.: no ctrl+alt+canc, no ctrl+shift+esc, no win+e, no nothing).
As an added optional bonus the user should be logged off when the launched app is closed and/or crashes.
Any existing free tool, language or any mixture of them that gets the job done would be fine (batch, VB-script, C, C++, whatever)
SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon has two values
UserInit points to the application that is executed upon successful logon. The default app there, userinit.exe processes domain logon scripts (if any) and then launches the specified Shell= application.
By creating or replacing those entries in HKEY_CURRENT_USER or in a HKEY_USERS hive you can replace the shell for a specific user.
Once you ahve your own shell in place, you have very little to worry about, unless the "kiosk user" has access to a keyboard and can press ctrl-alt-del. This seems to be hardcoded to launch taskmgr.exe - rather than replacing the exe, you can set the following registry key
[SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
Debugger="A path to an exe file that will be run instead of taskmgr.exe"
I guess you're building a windows kiosk?
Here's some background in replacing the windows login shell - http://blogs.msdn.com/embedded/archive/2005/03/30/403999.aspx
The above link talks about using IE as the replacement, but any program can be used.
Also check out Windows Steady State - http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx