How can a non-admin program cover your entire screen with a window?

Question

This year, since many students are online, College Board (the company that administers AP Exams in the US, along with the SAT) recently released its Digital Testing App. Once installed, and going through a setup, it allows you to go through a test demo to mirror the actual test conditions. However, once you do, it covers your entire screen and prevents you from ALT+TAB to another window. The "select window" UI still shows up, but if you actually try to switch, the Testing App window still remains.

This ability could make sense if the program was given administrator privileges on install (like Respondus Lockdown Browser, I believe), but the Testing App wasn't, and yet still could. This could just be a trick like just a really big window, but I'm not completely sure. Could anyone shed some light on this and how could they do this?

Answer 1

Fullscreen is easy: The vast majority of video games, for example, do it. I don't know if Windows has a dedicated API call for this, but if it doesn't, it's easy to fake: Just make a screen-sized window with the "Always on Top" attribute and no window decorations.

Disabling ALT+TAB is harder, but there are a number of options: for example, the accessibility toolkit lets you intercept arbitrary keystrokes. The only key combination that no application can disable is CTRL+ALT+DELETE.

Answer 2

A fullscreen app in C#:

using System;
using System.Windows.Forms;

namespace FullScreen
{
    static class Program
    {
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            var fullscreen = new Form();
            fullscreen.TopMost = true;
            fullscreen.WindowState = FormWindowState.Maximized;
            fullscreen.MinimizeBox = false;  // remove minimize button
            fullscreen.MaximizeBox = false;  // remove maximize button
            fullscreen.ControlBox = false;   // remove X button
            fullscreen.FormBorderStyle = FormBorderStyle.None;
            Application.Run(fullscreen);
        }
    }
}

Disabling Alt+Tab with globalmousekeyhook:

using Gma.System.MouseKeyHook;
var hook = Hook.GlobalEvents();
hook.KeyDown += (o, e) =>
{
    if (e.Alt) e.Handled = true;
};

Likewise you can disable the use of the Win mostly, except for Win+L (lock screen).

hook.KeyDown += (o, e) =>
{
    if (e.KeyCode == Keys.LWin || e.KeyCode == Keys.RWin) e.Handled = true;
};

Disabling Ctrl+Alt+Delete is possible by remapping at least one of the keys to nothing using the Registry Key System\CurrentControlSet\Control\Keyboard Layout. However, writing to that Registry key needs permissions. You can try it using SharpKeys, just be warned that you might screw up your system permanently.

Answer 3

The Windows API have native support for doing this.

A scripting language I have experience with, AutoHotKey, can readily make full screen any window available, using a single line of code. These functionalities are not some complex "hack" into the OS, but are built-in functions of the OS given to external software.

You can also make commands to capture keystrokes and intercept the keyboard to prevent Alt-Tab behavior.

Of course, depending on how the program is made, I can likewise use AutoHotKey to unlock the screen and perform Alt-Tabbing by using system calls instead of keystrokes.

Answer 4

From a security POV the reason this is possible in Windows is that there are 3 (more than that really) permissions levels that a program may run at.

Windows Store apps run with enumerated App permissions that restrict the application's ability to run as the desktop user.

A normal "desktop" program runs with the full privileges of the desktop user, except with administrative privileges stripped.

An elevated program runs with the desktop user's full permissions including administrative permissions on the box.

The "middle" level is still quite powerful, enabling the application to perform any actions that the user can perform, and is why you should be very careful when installing desktop applications. This includes managing the keyboard and windows, reacting to mouse/keyboard events, shutting down other desktop applicaitons, etc.

Answer 5

To answer this question, you need to understand the context and history of operating systems and their security model.

Desktop operating systems were designed in a time where the biggest security consideration was protecting you and the system itself from the other human users of the system. When multiple people are all using a shared machine, you need to make sure that one user's program can't affect others, and that other people can't read and/or write your private files.

"Administrative" permissions (sudo, UAC, or similar) largely protect the system itself from its users. In order to write system files and configuration (/bin, /etc, C:\Windows, HKLM, etc), or to gain access to another user's data, a user needs admin rights. Admin permissions usually have little to do with the GUI you see on your screen; in the end, they're mostly for file permissions.

A basic assumption of the classic desktop security model is that every program that you as a user run is trustworthy. Your programs should be able to read and write your private files (hopefully at your direction), and should be able to do whatever they need to do with your input and output devices.

This model worked well through the era when software came in cardboard boxes, because most software was indeed trustworthy. (And even if it wasn't, there usually wasn't much to be gained by doing evil things.)

The internet and constant connectivity changed that. Not all software is trustworthy, and your private data (to which you necessarily have full access) is far more valuable than anything else on the system.

Smartphone operating systems (iOS and Android specifically) were actually quite innovative in how they shifted the security model. Similar to how browsers sandbox websites, mobile OSes assume that only one human will use the device, and treat apps as untrusted.

Basically, they changed the security model to include protecting the user from malicious programs.

The mobile OS enforces isolation between each app's data (by running each app as a separate Unix user), limit the control that apps have over the GUI, and the system APIs are designed in such a way that apps must be granted explicit permission to call a wide range of APIs — a concept that simply did not exist in the desktop world.

Desktop operating systems are trying catch up to modern reality with "App Store" apps on Windows and Mac (and snaps on Linux) that are sandboxed and isolated like mobile apps. However, developers have to choose to write their programs in a way that's compatible with the sandbox and publish it on each platform's Store. It's very difficult to sandbox existing desktop apps because they make so many assumptions based on the classic model, that they break completely when sandboxed and denied permissions.

Thus, desktop OSes still allow pretty much anything you download to run with the full, wide-ranging capabilities that your user account has.

So... with all of that in mind, it should become glaringly obvious why your testing spyware app is able to do what it does. In fact, the only question you might have is why wouldn't it? The app runs as your user, and has full control over your user's GUI session. It can intercept any keyboard input, take screenshots of your entire screen, control what window gets focus, and even change the behavior of or kill your other running apps.

And it's not even necessarily bad that programs are able to do these things. These are individually all useful capabilities for apps that serve as utilities for you — a hotkey app needs to globally intercept keyboard input, a screenshot app needs to take screenshots of other apps, a power user window switching app needs to control focus, and developer tools need to fiddle with other processes to debug them. But combining those things together can lead to very uncomfortable results.

As a user who understands what the desktop security model is designed to defend against, it should be clear that precisely because every random app has complete and total access to the most valuable part of your computer—your data—that if you want to run untrusted programs, at the minimum, they should be run under a separate user account, and ideally, inside a throwaway VM. Otherwise, the app can do pretty much anything other than modifying the OS itself.