DropMyRights Shell - u name it.. DMR_Shell or Ma-xP

I have been working on this project for a little bit now. For those who have followed this link
SRP-Basic User
this will be a continuation. For those who have not seen that link, I have been using DropMyRights and SRP in various manners to drop my admin account into a user mode, with the restrictions that go with a user applied to all I do.

First, the title of this thread. What to name this. lol, my first thought was that running in xp as a user that is locked down would be about as secure as using a mac. Not foolproof but pretty hardy. Thus the Ma-xP. But, DMR-Shell is probably more descriptive.

Anyway, here is what I will call 'sort of final' version of this tool.
Here is the link
DMR-Shell or Ma-xP ??

EDIT: OOPS ! My bad, I pasted the wrong link here. The link above is for an earlier version of DMR_Shell. Here is the correct one.

The REAL McCoy


The archive consists of:
DMR-Shell.exe - this toggles between user and admin shell's
MyStart.exe - this is an autostart tool to help with certain aspects
MyStart.ini - a sort of template for autostarts using MyStart.exe
SG-Runner.exe - this is a tool to help with the RunAs feature of xp
WhoAmI.exe - I kept forgetting if I was admin or user, so I made this to tell

You should keep all of these files together and make shortcuts to other places. WhoAmI.exe is the only one that has no .ini file to look for, and the others look where the live.

This is 100% betaware, void of any malicious code with no outbound connections created, no file deletions, no password stealing, no advertisements, no cpu resource hogging, no bho's, no.. well, it is free and does what it is supposed to and nothing else.

But you should not run it on a system that you are worried about losing data on. Practice safe hex.

Ok, this would require a lot more space and time than I can give at the moment, so a quick recap. Some programs, like RivaTuner, do not like to play well in a user environment. When DMR_Shell.exe switches your from an admin (your normal account you use everyday) to a user (still your normal account, just demoted to a user temporarily), most programs run normally. I have seen a few that will not, Unlocker being the prime example. It is when you change back to the admin shell from the user shell that issues arise.

Because you are demoted to a user, you must have admin rights to get back to the admin shell. This requires using a RunAs. When the RunAs starts the shell as normal admin again, it basically is reloading your profile. That means anything set to autostart is processed. Here is where troubles can begin.

The MyStart.exe tool uses the MyStart.ini to configure itself. I find programs, like RivaTuner and Speedfan, that have autostart entries but that do not behave normally on profile reloads, and add them to the .ini. ( also make sure to remove all other autostart entries to ensure MyStart.exe handles them only ) There is an example in there usng these 2 programs, it should explain it well enough. Essentially it keeps programs from starting up if they are already running. I drop a shortcut to it in a starup folder or a reg Run key, and it starts my items up on bootup as well as handles the shell switching.

When coming back into an admin shell, I noticed that RivaTuner was not working correctly even though I used MyStart.exe to not let it start more than once. It would appear it needs to be shut down just before the admin profile is reloaded, then restarted. What I came up with was in the MyStart.ini, an area labeled [StopOnAdmin]. In this section you can name any process you wish, as many as you wish, and if DMR_Shell.exe finds them running when it is changing shells from user to admin, it will perform a taskkill on them.

Since the tasks will be killed before the admin profile reload, now MyStart.exe can start them up again. This seems to have solved every problem I was confronted with except for the Unlocker issue. That particular one is due to the program requiring debug permissions, and I don't need it that bad for what I am using this for.

One thing I dislike is using RunAs. It seems slow and clunky unless you are using it very sparingly. I made the program SG-Runner.exe just to help out. Both SG-Runner.exe and DMR_Shell.exe will create and/or share a file called SG-Crypt.ini. This file houses your admin username and password, in a light form of encryption. This way you are not incessantly asked to provide it by a prompt. The SG-Runner tool lets you drop items onto it's small window to runas the admin, or there is a context menu on it's title bar. This context menu basically lets you set 4 context menu's that operate on different file types or objects througout windows. This is what I use. A simple right click on something, and then choose the appropriate option and away you go. Delete the SG-Crypt.ini file to reset your admin username and password. Both programs are capable of creating it with prompts.

WhoAmI.exe is just a message box that displays for a few seconds to confirm if you are currently a user or an admin. Funny how one forgets using this tool.

That is the very short and abbreviated version. I should also mention, that DMR_Shell.exe will start your SecondaryLogon service and set it to automatic. It will not undo this at all, so should you try it and stop using it, be aware that service will be running.

As I stated in the other thread, I have DMR_Shell now capable of locking down these items:

Code:

    * c:\documents and settings\<user>\start\program files\autostart
    * c:\documents and settings\all users\start\program files\autostart
    * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
    * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
    * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
    * HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
    * HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

I don't know about other methods, but with my method I figured out how to restrict these areas from yourself as a user, yet allow access to yourself as an admin. And it seems that those two directories that are restricted can do so with just Simple File Sharing enabled.

You can engage this feature by running from command line
DMR_Shell.exe /i or -i

and reverse the restrictions with
DMR_Shell.exe /u or -u

I plan on using this for LAN parties I attend from time to time. I have been using it in day to day use on an as-needed basis. It is quick and convenient and seems to give the same protection as if using LUA with SuRun/Admin.

You be the judge. Please remember, while I have tried this out an many machines, I kept adding features and tested new features and old ones. That does not mean there are no bugs at all. Always seems to be one or two lurking somewhere. Post back if you find one and I will fix it asap.

Sul.

 

Is there any place that environment variables for the RunAs user can be set?

 

There are 2 answers depending on your meaning.

If you ask, can an environment variable be set that holds the username/password for a RunAs, yes.

If you ask, does this tool of mine have a method to set an environment variable that holds the username/password for RunAs, no, not anymore.

But not RunAs as typically is used, as the password is required via a prompt. I have read code snippets where the password was piped into the RunAs. Every method I tried with that failed. I did get it to work by using something like this.

file.txt (has only one line, one word, "password")
RunAs /noprofile /user 'application.exe' < file.txt

This does input the the password but it is a plain text file with your password. Not good. And as Prorootect showed, Kay Mustard has a link on his site that shows just how easy it is to get the username and password from a standard RunAs.

My tool does use a RunAs, but the .ini is encrypted the password, so for some reason it protects it from that exploit test.

I have ealier versions that used environment variables as an option to store the encrypted username and password, and it meant you no longer needed an .ini file for them at all. However, I decided to do away with the registry writes, and that put an end to the env variables. I know there are some 3rd party apps that would set an environment variable permanently, but I really don't like to have dependencies on apps others don't have. It is bad enough that I have not coded my own version of DMR in c yet.

I need sleep.

Sul.

 

Thanks for this tool Sully. I've been following your earlier thread too. A few questions:

1. Will it work if no (i.e. blank) password is set for the admin account.

2. Will it work on Windows XPHome SP1 (I know, I know ) ?

3. Is a reboot required at any stage while trying it out.
~~If not, that is good news because I could venture to try it in a Returnil session.

Your approach sounds really very interesting.

 

I wrote it so that it checks for a blank password and tells you it is blank and you need one (it checks the .ini, not your profile). You should have a password for your admin account. If you do not, you are asking for trouble. You probably know that. Besides, RunAs requires a password.

It does work on xphome, however you must put taskkill.exe into sys32 from xp pro.

No reboot is required. You run DMR_Shell the first time, it asks for usename & password. It creates the SG-Crypt.ini file, then starts the SecondaryLogon service if not already started. Then it kills explorer.exe and restarts it using DropMyRights.exe. When you use it agian, it checks for username and password in the .ini file, and if OK, it stops explorer.exe (using taskkill.exe) and then start explorer.exe again as admin. If you were to reboot, it would start normal no matter which mode you were in when you shut down.

Sul.

EDIT: I have used this on many vmWare machines now, and on my own production machine at home and work. I have used it on my wifes and kids machines. A couple good buds have used it. My brothers have used it. So far, even when developing, there have been no problems at all. I would feel safe myself just trying it out, as all it does is restart explorer.exe. The part of changing registry permissions and file permissons for the autostart blocking, is the only part that I would think could go wrong. But again, having tested it out on many machines, has not been problematic. Just though I would ease any apprehension.

 

Re: setting Environment variables, I wasn't thinking of passwords, actually.

I support an app that is often used with a specially created user account. Occasionally users want to set environment variables for this user (not related to passwords or security, just garden variety variables) so that the app can use the variables when it runs. Most clients run the app on a server and they can control the user logins etc. quite readily.

However, for my support purposes, I run the app locally from the commandline. It would be great if I had a way to easily keep a "profile" set up for each client, being able to duplicate whatever rights their user has, plus whatever env. variables they have set.

I've looked at various "elevated Run As" utils, but not found anything that will keep the settings plus allow env. variables to be easily accessible with an ini.

 

You can programmatically set the environment in HKCU\Environment or HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. This requires a logoff/logon to implement, but they are permanent.

You might look up setx, a resource kit tool. It works a charm, but is not on machines by default.

If I understand this, you want a profile of environment variables? These could be temporary? While you work on certain 'clients' settings etc? There are ways to put environment variables as temporary. A basic idea would be akin to this:

I have 4 variables I want to use. Name, Share, Username, Password (this is for the program I am supporting). I create those 4 env variables (%name%,etc). They are blank by default or contain a simple value.

Now I can make a batch file that sets each of those, depending on the parameter. So if you called the batch file CustSupp.bat, you could use something like CustSupp.bat Sharon. Then the batch file could match on sharon, and set each env variable to whatever data sharon would use. You could access it via command line, even code up stuff, because the variables exist always, you just change them as you need them.

Something like that? There are other ways too.

Sul.

 

Sorry, I should have said that I currently do use batch files to to run the app, and I do set env. variables in the batch files, and use setlocal and endlocal.

What I was thinking was that it would be great to be able to right-click and select "Run as ABC" and that would load the variables that a specific client always uses, so that I don't have to keep putting the "constant" set commands in the .cmd files and the batch set lines only would need to have the job-specific variables set.

Another example is that clients use different versions of this app, so often I have to change multiple env. variables to match their version (paths, version numbers, etc). It would be nice to have a way to have a single location for specifying the client's version, instead of having that info in each batch file.

Or, an alternative to client-centric profiles, have a set of "run As" profiles for each app version I support, "Run As ver 7.1p56" "Run As ver 8.p058" etc.

 

Yes. It could be done. Let me think for a bit. I have an idea.

Sul.

 

Thanks, Sully -- I don't want to distract the conversation from your security usage aspect though -- should this continue in a separate thread?

 

Yes please do. Coming up with a solution now.

Sul.

 

And thanks also for all the detailed answers Sully. One final question:

My HP machine has an admin account and another one (called owner) with admin privileges.
Can I use the owner account with your software or should I always use the admin account. Thanks again!

 

@soccerfan

You should use the account that you use all the time.

Explanation:

RunAs, which is used to bring you out of the user shell to the admin shell, has 4 parameters.
/noprofile
/profile
/env
/netonly

This works like it does because, you are an admin. You startup, login, all your apps and data are where you use them everyday. When you start explorer with DMR, nothing is happening except you stop the shell and then start it in a demoted state.

However, when you go want to go back to admin shell, your demotion is holding you back from doing this. You must start explorer with admin rights. That is why the RunAs is needed. However, if you were to provide the username and password for your other admin account, when explorer started back up, it would not be to your normal desktop, but to the other admin desktop (or a state thereof). So this tool really is designed to let YOU demote YOU, and then let YOU promote YOU. The beauty of it is that things never really change.

That explain it?

Sul.

 

Understood . I use my usual owner account and I'm good to go. Thanks.