User Interface Replacement for Explorer

• Download demo project - 30.1 KB
• Download source files - 20.1 KB

Introduction

The desktop that most people use with Windows 2000 and Windows XP is called the Explorer User Interface. This is an application at C:\Windows\explorer.exe. The Explorer User Interface gives us the power to access our Windows System through the use of the task bar, desktop, and Explorer directory browser. On some systems, the Explorer User Interface provides too much flexibility and user control. On Kiosk systems, you would probably want to limit the user's interaction only with the Kiosk application but still give the administrator some user interface to restart the Kiosk application or execute maintenance. This article is about replacing the standard Explorer User Interface with your own user interface.

Please note that this article covers changing system settings that could potentially limit access to your computer. The demo software does contain multi methods to try and limit this possibility, but run the demo at your own risk.

Background

We want to create a kiosk system that limits people from gaining access to our computer. You can try and limit access by various means, but sometimes the access is not restrictive enough or too restrictive. How many times have you seen kiosks that got corrupted and could not be restarted by the regular attendants? We want to alleviate this problem by giving the attendant some ability to restart the kiosk software. We will accomplish this by having the kiosk software run on top of a user interface. If the kiosk software fails, the user interface is present to allow the software to be restarted. Some places try and do this by changing many registry settings to disable applications, disable using the command line interpreter, etc., but most of this increased security just creates maintenance problems. Instead of configuring the user interface, let's just replace it.

This is not security by obscurity. This is security by limiting the user's interface. There is a setting in the group policy that does all this for us. See the following image:

The Custom User Interface setting allows us to use our own user interface instead of the standard Explorer. The trick is to know what to put on our own user interface to restrict access but allow for simple maintenance. In this following example, we are using the command line interpreter as the application that we want to remain running. On login, the User Interface application is started and the command line interpreter is started. Every 10 seconds, we check to ensure that there is a command line interpreter executing, otherwise we start a new one.

We need to provide access to administrators. This can be accomplished by enabling buttons based upon the user's security level (e.g. part of the Administrators group). For this example we have not implemented that but we do provide the "Group Policy Editor" button to access the group policy editor and the Command interface to execute any application on your system. These two features should ensure that you are able to switch back to the Explorer User Interface.

Please note that if you run explorer, the Explorer User Interface is launched and the familiar task bar will appear. The group policy editor can be run by entering gpedit.msc in the command line interpreter or Start > Run.

Using the User Interface

You can see how this works by copying UserInterface.exe to a simple to access directory. For this example we will use C:\. Launch the application and you will get the black screen above.

1. Click the Group Policy Editor button
2. Browse to Local Computer Policy > User Configuration > Administrative Templates > System
3. Double click Custom User Interface
4. Select Enabled
5. In the Interface File Name text box, enter C:\UserInterface.exe
6. Restart your computer

When you restart the computer, you will be using the new user interface. As long as you do not run explorer, you will remain in the new user interface. To restore Explorer as the system interface, follow these instructions:

1. Click the Group Policy Editor button
2. Browse to Local Computer Policy > User Configuration > Administrative Templates > System
3. Double click Custom User Interface
4. Select Not Configured
5. Restart your computer

Using the Code

The MainForm is a really ugly GUI which provides limited functionality. It starts the command line interpreter and checks to see if it is running.

private void ActionMonitorProcess() 
{
    System.Diagnostics.Process[] processes = 
            System.Diagnostics.Process.GetProcesses();
    for (int i = 0; i < processes.Length; i++) 
    {
        if (processes[i].ProcessName == COMMAND_PROCESS_NAME) 
        {
            return;
        }
    }
    LaunchCmd();
}

If the command line interpreter is not running, it is started:

private void LaunchCmd() 
{
    string s = "";
    try 
    {
        System.Diagnostics.Process.Start(COMMAND);
        timerCmd.Start();
    } 
    catch (Exception ex) 
    {
        s = "Could not launch the command line processor." + NL + NL;
        s += ex.Message + NL + NL;
        s += ex.StackTrace;
        textBoxMain.Text = s;
        timerError.Start();
    }
}

As you can see, we use the System.Diagnostics classes to create and monitor processes. The most complicated one, which is not complicated at all, is the command:

private void CmdExecute() 
{
    string s = "";
    string command = textBoxCommand.Text.Trim();

    // check to see if there is a command to execute
    if (command.Length == 0) 
    {
        return;
    }

    // break off the command into the command and the arguments
    string[] arr = command.Split(new char[] { ' ' });
    command = arr[0];
    string arguments = "";

    for (int i = 1; i < arr.Length; i++) 
    {
        if (arguments.Length > 0) 
        {
            arguments += " ";
        }
        arguments += arr[i];
    }

    // execute the command
    try 
    {
        System.Diagnostics.ProcessStartInfo o = 
        new System.Diagnostics.ProcessStartInfo(command, arguments);
        System.Diagnostics.Process.Start(o);
    } 
    catch (Exception ex) 
    {
        s = "Could not launch " + textBoxCommand.Text.Trim() + "." + NL + NL;
        s += ex.Message + NL + NL;
        s += ex.StackTrace;
        textBoxMain.Text = s;
        timerError.Start();
    }
}

Even the logging off and shutting down is just an execution of a process:

private void CmdExit() 
{
    if (APPLICTION_MODE) 
    {
        Application.Exit();
        return;
    }

    ShutdownDialog dlg = new ShutdownDialog();
    if (dlg.ShowDialog() == DialogResult.Cancel) 
    {
        return;
    }

    string arguments = "";
    string s = "";

    if (dlg.ShutdownType == ShutdownType.Restart) 
    {
        arguments = "-r -t 00";
    } 
    else if (dlg.ShutdownType == ShutdownType.Shutdown) 
    {
        arguments = "-s -t 00";
    } else 
    {
        arguments = "-l -t 00";
    }

    try 
    {
        System.Diagnostics.ProcessStartInfo o = 
        new System.Diagnostics.ProcessStartInfo(SHUTDOWN, arguments);
        System.Diagnostics.Process.Start(o);
    } 
    catch (Exception ex) 
    {
        s = "Could not shutdown the application." + NL + NL;
        s += ex.Message + NL + NL;
        s += ex.StackTrace;
        textBoxMain.Text = s;
        timerError.Start();
    }
}

Conclusion

Creating a basic user interface for a limited access computer or kiosk system is very simple and all the functionality is currently present in Windows. Creating your own user interface may be much easier than trying to lock down the computer using security and policy settings--especially for small organizations that do not have the administrative knowledge in-house.