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
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 want to do this for educational cause only, for myself, not to replace any system that is already implemented in the Windows OS **
I want to implement some kind of directory locker in Windows 10.
In order to do so, I want my program to run in the background, and every time it will identify a try to access a directory, it will search whether the directory is locked or not, and if it is locked, it will pump up a password insertion box.
I want to start by pumping up the password message box (first stage), and after that to actually block the access if the password is wrong (second stage).
Any leads?
There is nothing stopping the user from just killing your program and accessing the directory as normal. If you want to prevent someone from accessing something, use access controls -- that's what they're for. If the user is an administrator they can change the access controls to undo what you do; but if the user is admin they could just debug any program or process and completely replace the code that does the access check with code that does nothing.
Beginner question - Trying to create a simple logon script that executes when a Windows user logs on and copies a file from one folder to another. The OS is Windows 7.
This link says that logon scripts should go into
%SystemRoot%\System32\Repl\Import\Scripts folder.
I do not seem to have that folder in my machine. I created it manually and pushed the vbs file in there.
I also opened up computer management and assigned the script to a user. This is a standalone machine and has no network logons.
Code itself is simple and it works when the file is run except it is not getting called during logon.
Is this the right place to put the logon script? Am I doing something wrong.
Eventually I would like to be able to assign the logon script in C# using DirectoryEntry's LogonScript property. Any suggestions in the right direction would be of great help.
Windows has 2 default locatations for local logon scripts:
%SystemRoot%\System32\Repl\Import\Scripts for logon scripts assigned via lusrmgr.msc.
%SystemRoot%\System32\GroupPolicy\User\Scripts\Logon for logon scripts assigned via gpedit.msc.
Both paths don't exist in a default installation and must be created by an administrator.
lusrmgr.msc seems to accept only scripts with paths relative to the default location. For scripts assigned via gpedit.msc you can choose any path you like.
A (local) logon script must be assigned to a profile by one of the abovementioned methods, otherwise it won't be called at logon.
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.
I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.