Windows 10 Desktops vs. Sysinternals Desktops

One of the new Windows 10 features visible to users is the support for additional “Desktops”. It’s now possible to create additional surfaces on which windows can be used. This idea is not new – it has been around in the Linux world for many years (e.g. KDE, Gnome), where users have 4 virtual desktops they can use. The idea is that to prevent clutter, one desktop can be used for web browsing, for example, and another desktop can be used for all dev work, and yet a third desktop could be used for all social / work apps (outlook, WhatsApp, Facebook, whatever).

To create an additional virtual desktop on Windows 10, click on the Task View button on the task bar, and then click the “New Desktop” button marked with a plus sign.

newvirtualdesktop

Now you can switch between desktops by clicking the appropriate desktop button and then launch apps as usual. It’s even possible (by clicking Task View again) to move windows from desktop to desktop, or to request that a window be visible on all desktops.

The Sysinternals tools had a tool called “Desktops” for many years now. It too allows for creation of up to 4 desktops where applications can be launched. The question is – is this Desktops tool the same as the Windows 10 virtual desktops feature? Not quite.

First, some background information. In the kernel object hierarchy under a session object, there are window stations, desktops and other objects. Here’s a diagram summarizing this tree-like relationship:

Sessions

As can be seen in the diagram, a session contains a set of Window Stations. One window station can be interactive, meaning it can receive user input, and is always called winsta0. If there are other window stations, they are non-interactive.

Each window station contains a set of desktops. Each of these desktops can hold windows. So at any given moment, an interactive user can interact with a single desktop under winsta0. Upon logging in, a desktop called “Default” is created and this is where all the normal windows appear. If you click Ctrl+Alt+Del for example, you’ll be transferred to another desktop, called “Winlogon”, that was created by the winlogon process. That’s why your normal windows “disappear” – you have been switched to another desktop where different windows may exist. This switching is done by a documented function – SwitchDesktop.

And here lies the difference between the Windows 10 virtual desktops and the Sysinternals desktops tool. The desktops tool actually creates desktop objects using the CreateDesktop API. In that desktop, it launches Explorer.exe so that a taskbar is created on that desktop – initially the desktop has nothing on it. How can desktops launch a process that by default creates windows in a different desktop? This is possible to do with the normal CreateProcess function by specifying the desktop name in the STARTUPINFO structure’s lpDesktop member. The format is “windowstation\desktop”. So in the desktops tool case, that’s something like “winsta0\Sysinternals Desktop 1”. How do I know the name of the Sysinternals desktop objects? Desktops can be enumerated with the EnumDesktops API. I’ve written a small tool, that enumerates window stations and desktops in the current session. Here’s a sample output when one additional desktop has been created with “desktops”:

desktops1

In the Windows 10 virtual desktops feature, no new desktops are ever created. Win32k.sys just manipulates the visibility of windows and that’s it. Can you guess why? Why doesn’t Window 10 use the CreateDesktop/SwitchDesktop APIs for its virtual desktop feature?

The reason has to do with some limitations that exist on desktop objects. For one, a window (technically a thread) that is bound to a desktop cannot be switched to another; in other words, there is no way to transfer a windows from one desktop to another. This is intentional, because desktops provide some protection. For example, hooks set with SetWindowsHookEx can only be set on the current desktop, so cannot affect other windows in other desktops. The Winlogon desktop, as another example, has a strict security descriptor that prevents non system-level users from accessing that desktop. Otherwise, that desktop could have been tampered with.

The virtual desktops in Windows 10 is not intended for security purposes, but for flexibility and convenience (security always “contradicts” convenience). That’s why it’s possible to move windows between desktops, because there is no real “moving” going on at all. From the kernel’s perspective, everything is still on the same “Default” desktop.

 

 

 

Next Windows Kernel Programming Remote Class

The next public remote Windows kernel Programming class I will be delivering is scheduled for April 15 to 18. It’s going to be very similar to the first one I did at the end of January (with some slight modifications and additions).

Cost: 1950 USD. Early bird (register before March 30th): 1650 USD

I have not yet finalized the time zone the class will be “targeting”. I will update in a few weeks on that.

If you’re interested in registering, please email zodiacon@live.com with the subject “Windows Kernel Programming class” and specify your name, company (if any) and time zone. I’ll reply by providing more information.

Feel free to contact me for questions using the email or through twitter (@zodiacon).

The complete syllabus is outlined below:

Duration: 4 Days
Target Audience: Experienced windows developers, interested in developing kernel mode drivers
Objectives: ·  Understand the Windows kernel driver programming model

·  Write drivers for monitoring processes, threads, registry and some types of objects

·  Use documented kernel hooking mechanisms

·  Write basic file system mini-filter drivers

Pre Requisites: ·  At least 2 years of experience working with the Windows API

·  Basic understanding of Windows OS concepts such as processes, threads, virtual memory and DLLs

Software requirements: ·  Windows 10 Pro 64 bit (latest stable version)
·  Visual Studio 2017 + latest update
·  Windows 10 SDK (latest)
·  Windows 10 WDK (latest)
·  Virtual Machine for testing and debugging

Instructor: Pavel Yosifovich

Abstract

The cyber security industry has grown considerably in recent years, with more sophisticated attacks and consequently more defenders. To have a fighting chance against these kinds of attacks, kernel mode drivers must be employed, where nothing (at least nothing from user mode) can escape their eyes.
The course provides the foundations for the most common software device drivers that are useful not just in cyber security, but also other scenarios, where monitoring and sometimes prevention of operations is required. Participants will write real device drivers with useful features they can then modify and adapt to their particular needs.

Syllabus

  • Module 1: Windows Internals quick overview
    • Processes
    • Virtual memory
    • Threads
    • System architecture
    • User / kernel transitions
    • Introduction to WinDbg
    • Windows APIs
    • Objects and handles
    • Summary

 

  • Module 2: The I/O System
    • I/O System overview
    • Device Drivers
    • The Windows Driver Model (WDM)
    • The Kernel Mode Driver Framework (KMDF)
    • Other device driver models
    • Driver types
    • Software drivers
    • Driver and device objects
    • I/O Processing and Data Flow
    • Accessing devices
    • Asynchronous I/O
    • Summary

 

  • Module 3: Kernel programming basics
    • Setting up for Kernel Development
    • Basic Kernel types and conventions
    • C++ in a kernel driver
    • Creating a driver project
    • Building and deploying
    • The kernel API
    • Strings
    • Linked Lists
    • The DriverEntry function
    • The Unload routine
    • Installation
    • Testing
    • Debugging
    • Summary
    • Lab: deploy a driver

 

  • Module 4: Building a simple driver
    • Creating a device object
    • Exporting a device name
    • Building a driver client
    • Driver dispatch routines
    • Introduction to I/O Request Packets (IRPs)
    • Completing IRPs
    • Handling DeviceIoControl calls
    • Testing the driver
    • Debugging the driver
    • Using WinDbg with a virtual machine
    • Summary
    • Lab: open a process for any access; zero driver; debug a driver

 

  • Module 5: Kernel mechanisms
    • Interrupt Request Levels (IRQLs)
    • Deferred Procedure Calls (DPCs)
    • Dispatcher objects
    • Low IRQL Synchronization
    • Spin locks
    • Work items
    • Summary

 

  • Module 6: Process and thread monitoring
    • Motivation
    • Process creation/destruction callback
    • Specifying process creation status
    • Thread creation/destruction callback
    • Notifying user mode
    • Writing a user mode client
    • Preventing potentially malicious processes from executing
    • Summary
    • Lab: monitoring process/thread activity; prevent specific processes from running; protecting processes

 

  • Module 7: Object and registry notifications
    • Process/thread object notifications
    • Pre and post callbacks
    • Registry notifications
    • Performance considerations
    • Reporting results to user mode
    • Summary
    • Lab: protect specific process from termination; simple registry monitor

 

  • Module 8: File system mini filters
    • File system model
    • Filters vs. mini filters
    • The Filter Manager
    • Filter registration
    • Pre and Post callbacks
    • File name information
    • Contexts
    • File system operations
    • Filter to user mode communication
    • Debugging mini-filters
    • Summary
    • Labs: protect a directory from file deletion; backup file before deletion

Fun with AppContainers

AppContainers are the sanboxes typically used to run UWP processes (also known as metro, store, modern…). A process within an AppContainer runs with an Integrity Level of low, which effectively means it has no access to almost everything, as the default integrity level of objects (such as files) is Medium. This means code running inside an AppContainer can’t do any sigtnificant damage because of that lack of access. Furthermore, from an Object Manager perspective, named objects created by an AppContainer are stored under its own object manager directory, based on an identifier known as AppContainer SID. This means one AppContainer cannot interfere with another’s objects.

For example, if a process not in an AppContainer creates a mutex named “abc”, its full name is really “\Sessions\1\BaseNamedObjects\abc” (assuming the process runs in session 1). On the other hand, if AppContainer A creates a mutex named “abc”, its full name is something like “\Sessions\1\AppContainerNamedObjects\S-1-15-2-466767348-3739614953-2700836392-1801644223-4227750657-1087833535-2488631167\abc”, meaning it can nevr interfere with another AppContainer or any process running outside of an AppContainer.

Although AppContainers were created specifically for store apps, theye can also be used to execute “normal” applications, providing the same level of security and isolation. Let’s see how to do that.

First, we need to create the AppContainer and obtain an AppContainer SID. This SID is based on a hash of the container name. In the UWP world, this name is made up of the application package and the 13 digits of the signer’s hash. For normal applications, we can select any string; selecting the same string would yield the same SID – which means we can actually use it to “bundle” several processes into the same AppContainer.

The first step is to create an AppContainer profile (error handling ommitted):

PSID appContainerSid;
::CreateAppContainerProfile(containerName, containerName, containerName, nullptr, 0, &appContainerSid);

The containerName argument is the important one. If the function fails, it probably means the container profile exists already. In that case, we need to extract the SID from the existing profile:

::DeriveAppContainerSidFromAppContainerName(containerName, &appContainerSid);

The next step is prepare for process creation. The absolute minimum is to initialize a process attribute list with a SECURITY_CAPABILITIES structure to indicate we want the process to be created inside an AppContainer. As part of this, we can specify capabilities this AppContainer should have, such as internet access, access to the documents library and any other capabilities as defined by the Windows Runtime:

STARTUPINFOEX si = { sizeof(si) };
PROCESS_INFORMATION pi;
SIZE_T size;
SECURITY_CAPABILITIES sc = { 0 };
sc.AppContainerSid = appContainerSid;

::InitializeProcThreadAttributeList(nullptr, 1, 0, &size); 
auto buffer = std::make_unique<BYTE[]>(size); 
si.lpAttributeList = reinterpret_cast<LPPROC_THREAD_ATTRIBUTE_LIST>(buffer.get()); 
::InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &size)); 
::UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES, &sc, sizeof(sc), nullptr, nullptr));

We specified zero capabilities for now. Now we’re ready to create the process:

::CreateProcess(nullptr, exePath, nullptr, nullptr, FALSE,
	EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, 
        (LPSTARTUPINFO)&si, &pi);

We can try this with the usual first victim, Notepad. Notepad launches and everyhing seems OK. However, if we try to open almost any file by using Notepad’s File/Open menu item, we’ll see that notepad has no access to usual things, such as “my documents” or “my pictures”. This is because it’s runnign with Low Integrity Level and files are defaulted to Medium integrity level:

“AppContainer” in Process Explorer implies Low integirty level.

If we would want Notepad to have access to the user’s files, such as documents and pictures, we would have to set explict permissions on these objects allowing access to the AppContainer SID. Functions to use include SetNamedSecurityInfo (see the project on Github for the full code).

I’ve created a simple application to test these things. We can specify a container name, an executable path and click “Run” to execute in in AppContainer. We can add folders/files that would get full permissions:

appcontainer8

Let’s now try a more interesting application – Windows Media Player (yes, I know, who uses the old Media Player these days? But it’s an interesting example). Windows Media Player has the (annoying?) feature where you can only run a single instance of it at any given time. The way this works is that WMP creates a mutex with a very specific name, “Microsoft_WMP_70_CheckForOtherInstanceMutex“, if it already exists, it sends a message to its buddy (a previous instance of WMP) and then terminates. A simple trick we can do with Process Explorer is to close that handle and then launching another WMP.

Let’s try something different: let’s run WMP in an AppContainer. Then let’s run another one in a different AppContainer. Will we get two instances?

appcontainer4

Running WMP in this way popus up its helper, setup_wm.exe which asks for the initial settings for WMP. Clicking “Express Settings” closes the dialog but it then it comes up again! And again! You can’t get rid of it, unless you close the dialog and then WMP does not launch. Can you guess why is that?

If you guessed “permissions” – you are correct. Running Process Monitor when this dialog comes up and filtering for “ACCESS DENIED” shows something like this:

appcontainer5

Clearly, some keys need access so the settings can be saved. The tool allows adding these keys and setting full permissions for them:

appcontainer6

Now we can run WMP in two different containers (change the container name and re-run) and they both run just fine. That’s becuase each mutex now has a unique name prefixed with the AppContainer SID of the relevant AppContainer:

appcontainer7

The code can be found at https://github.com/zodiacon/RunAppContainer.

 

Public Windows Kernel Programming Class

After a short twitter questionaire, I’m excited to announce a Remote Windows Kernel Programming class to be scheduled for the end of January 2019 (28 to 31).

If you want to learn how to write software drivers for Windows (not hardware, plug & play drivers), including file system mini filters – this is the class for you! You should be comfortable with programming on Windows in user mode (although we’ll discuss some of the finer points of working with the Windows API) and have a basic understanding of Windows OS concepts such as processes, threads and virtual memory.

If you’re interested, send an email to zodiacon@live.com with the title “Windows Kernel Programming Training” with your name, company name (if any), and time zone. I will reply with further details.

Here is the syllabus (not final, but should be close enough):

Windows Kernel Programming

Duration: 4 Days (January 28th to 31st, 2019)
Target Audience: Experienced windows developers, interested in developing kernel mode drivers
Objectives: · Understand the Windows kernel driver programming model

· Write drivers for monitoring processes, threads, registry and some types of objects

· Use documented kernel hooking mechanisms

· Write basic file system mini-filter drivers

Pre Requisites: · At least 1 year of experience working with the Windows API

· Basic understanding of Windows OS concepts such as processes, threads, virtual memory and DLLs

Software requirements: · Windows 10 Pro 64 bit (latest official release)

· Virtual machine (preferable Windows 10 64 bit) using any virtualization technology (for testing and debugging)

· Visual Studio 2017 (any SKU) + latest update

· Windows 10 SDK (latest)

· Windows 10 WDK (latest)

Cost: $1950

Syllabus

  • Module 1: Windows Internals quick overview
    • Processes and threads
    • System architecture
    • User / kernel transitions
    • Virtual memory
    • APIs
    • Objects and handles
    • Summary

 

  • Module 2: The I/O System and Device Drivers
    • I/O System overview
    • Device Drivers
    • The Windows Driver Model (WDM)
    • The Kernel Mode Driver Framework (KMDF)
    • Other device driver models
    • Driver types
    • Software drivers
    • Driver and device objects
    • I/O Processing and Data Flow
    • Accessing files and devices
    • Asynchronous I/O
    • Summary

 

  • Module 3: Kernel programming basics
    • Installing the tools: Visual Studio, SDK, WDK
    • C++ in a kernel driver
    • Creating a driver project
    • Building and deploying
    • The kernel API
    • Strings
    • Linked Lists
    • Kernel Memory Pools
    • The DriverEntry function
    • The Unload routine
    • Installation
    • Summary
    • Lab: create a simple driver; deploy a driver

 

  • Module 4: Building a simple driver
    • Creating a device object
    • Exporting a device name
    • Building a driver client
    • Driver dispatch routines
    • Introduction to I/O Request Packets (IRPs)
    • Completing IRPs
    • Dealing with user space buffers
    • Handling DeviceIoControl calls
    • Testing the driver
    • Debugging the driver
    • Using WinDbg with a virtual machine
    • Summary
    • Lab: open a process for any access; zero driver; debug a driver

 

  • Module 5: Kernel mechanisms
    • Interrupt Request Levels (IRQLs)
    • Interrupts
    • Deferred Procedure Calls (DPCs)
    • Dispatcher objects
    • Thread Synchronization
    • Spin locks
    • Work items
    • Summary

 

  • Module 6: Process and thread monitoring
    • Process creation/destruction callback
    • Specifying process creation status
    • Thread creation/destruction callback
    • Notifying user mode
    • Writing a user mode client
    • User/kernel communication
    • Summary
    • Labs: monitoring process/thread activity; prevent specific processes from running; protecting processes

 

  • Module 7: Object and registry notifications
    • Process/thread object notifications
    • Pre and post callbacks
    • Registry notifications
    • Performance considerations
    • Reporting results to user mode
    • Summary
    • Lab: protect specific process from termination; hiding registry keys; simple registry monitor

 

  • Module 8: File system mini filters
    • File system model
    • Filters vs. mini filters
    • The Filter Manager
    • Filter registration
    • Pre and Post callbacks
    • File name information
    • Contexts
    • File system operations
    • Driver to user mode communication
    • Debugging mini-filters
    • Summary
    • Labs: protect a directory from write; hide a file/directory; prevent file/directory deletion; log file operations

 

Silent Process Exit – Is It Really?

While working on my GflagsX tool, there was yet another feature the tool was missing compared to the classic GFlags tool – Silent Process Exit support. But what is Silent Process Exit?

According to the documentation there are two scenarios that trigger Silent Process Exit:

  • Self exiting – one of the threads in the process calls ExitProcess.
  • A TerminateProcess call is issued from another (or the same process).

The documentation states that if a process exits because all threads terminate normally, then Silent Process Exit is not in effect. (also if kernel code kills a process, Silent Process Exit is not invoked).

The documentation may lead us to belive that if a process exits normally (no abnormal termination or exception) then Silent Process Exit will not be invoked. Let’s test that theory.

First, let’s configure Silent Process Exit with GFlags. (GFlagsX support is on its way). Run GFlags and select the Silent Process Exit tab:

SilentProcessExit1

Let’s test it with notepad. Type notepad.exe in the Image text box and press Tab. Some of the options light up. Let’s try something simple – generating a dump file when notepad terminates. Check Enable Silent Process Exit Monitoring and then set a dump folder location and dump type, like so:

SilentProcessExit2

Click Apply to apply the settings. Now launch Notepad. If you terminate it using (say) Task Manager, you’ll find a subfolder under the configured Dump Folder Location named Notepad.exe-(PID xxxx)-yyyyyyyy where xxxx is the terminating process ID and yyyyyy is the value returned from GetTickCount at the time of the exit (the number of milliseconds elapsed since Windows booted). Inside the folder you’ll find the dump file itself.

However, if you launch notepad again and just close its main window, you’ll find, perhaps surprisingly, that yet another folder was created with a new dump file. But why? Isn’t this a normal process termination?

Since we can be pretty sure no process (including notepad) called TerminateProcess, this means notepad called ExitProcess. Is this “normal”? Are there processes that terminate by just ending all their threads?

Let’s launch another notepad instance and attach WinDbg to it. Break into the debugger and add a breakpoint for ExitProcess:

0:000> x kernel32!ExitProcess*
00007ffe`1509b190 KERNEL32!ExitProcessImplementation (<no parameter info>)
0:000> bp KERNEL32!ExitProcessImplementation

Now let the process go and close notepad’s window. The breakpoint should hit:

Breakpoint 0 hit
KERNEL32!ExitProcessImplementation:
00007ffe`1509b190 4883ec28 sub rsp,28h

Let’s look at the call stack:

0:000> k
# Child-SP RetAddr Call Site
00 000000a1`4294f718 00007ffe`17119ce5 KERNEL32!ExitProcessImplementation
01 000000a1`4294f720 00007ffe`1711a345 msvcrt!_crtExitProcess+0x15
02 000000a1`4294f750 00007ff7`ffef934a msvcrt!doexit+0x171
03 000000a1`4294f7c0 00007ffe`15093034 notepad!__mainCRTStartup+0x1b6
04 000000a1`4294f880 00007ffe`17281461 KERNEL32!BaseThreadInitThunk+0x14
05 000000a1`4294f8b0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Now it seems clear: when the first (“main”) thread of notepad returns from its main function, the C-runtime library calls ExitProcess explicitly. And in fact this is what you’ll find with most executables. This is why when the main thread exits in a C/C++ application, the process ends wven if other threads still exist and executing. From the Windows kernel’s perspective, there is no “main” thread – all threads are equal.

Silent Exit Process support is part of NTDLL and the Windows Error Reporting Service. This is in contrast to tools such as ProcDump from Sysinternals that attaches a debugger to the monitored process and creates a dump file when it exits. To set it up, the global flag with the value 0x200 (512) must be set in the “Image File Execution Options” (IFEO) subkey (just like all other global flags). However, once the bit is set, the actual details need to be written into the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe. This is done on an image name basis just as with the IFEO key. Here is the example for notepad just shown:

SilentProcessExit3

Stay tuned for more info on Silent Process Exit support in GFlagsX!

 

Public Remote Windows Internals Training

  • Public 5-day remote class
  • Dates: November 5, 7, 8, 14, 15
  • Time: 8 hours / day. Exact hours TBD
  • Price: 2250 USD
  • Register by emailing zodiacon@live.com and specifying “Windows Internals Training” in the title
    • Provide names of participants (discount available for multiple participants from the same company), company name and time zone.
    • You’ll receive instructions for payment and other details
  • Virtual space is limited!

 

Objectives: Understand the Windows system architecture

Explore the internal workings of process, threads, jobs, virtual memory, the I/O system and other mechanisms fundamental to the way Windows works

Write a simple software device driver to access/modify information not available from user mode

Target Audience: Experienced windows programmers in user mode or kernel mode, interested in writing better programs, by getting a deeper understanding of the internal mechanisms of the windows operating system.

Security researchers interested in gaining a deeper understanding of Windows mechanisms (security or otherwise), allowing for more productive research

Pre-Requisites: Basic knowledge of OS concepts and architecture.

Power user level working with Windows

Practical experience developing windows applications is an advantage

C/C++ knowledge is an advantage

 

  • Module 1: System Architecture
    • Brief Windows NT History
    • Windows Versions
    • Windows 10 and Future versions
    • Tools: Windows, Sysinternals, Debugging Tools for Windows
    • Processes and Threads
    • Virtual Memory
    • User mode vs. Kernel mode
    • Objects and Handles
    • Architecture Overview
    • Key Components
    • User/kernel transitions
    • APIs: Win32, Native, .NET, COM, WinRT
    • Introduction to WinDbg
    • Lab: Task manager, Process Explorer, WinDbg

 

  • Module 2: Processes & Jobs
    • Process basics
    • Creating and terminating processes
    • Process Internals & Data Structures
    • The loader
    • DLL explicit and implicit linking
    • Process and thread attributes
    • Protected processes and PPL
    • UWP Processes
    • Minimal and Pico processes
    • Jobs
    • Nested jobs
    • Introduction to Silos
    • Lab: viewing process and job information; creating processes; setting job limits

 

  • Module 3: Threads
    • Thread basics
    • Creating and terminating threads
    • Processor Groups
    • Thread Priorities
    • Thread Scheduling
    • Thread Stacks
    • Thread States
    • CPU Sets
    • Thread Synchronization
    • Lab: creating threads; thread synchronization; viewing thread information; CPU sets

 

  • Module 4: Kernel Mechanisms
    • Trap Dispatching
    • Interrupts & Exceptions
    • System Crash
    • Object Management
    • Objects and Handles
    • Sharing Objects
    • Synchronization
    • Synchronization Primitives
    • Signaled vs. Non-Signaled
    • Windows Global Flags
    • Kernel Event Tracing
    • Wow64
    • Lab: Viewing Handles, Interrupts; creating maximum handles

 

  • Module 5: Memory Management
    • Overview
    • Small, large and huge pages
    • Page states
    • Address Space Layout
    • Address Translation Mechanisms
    • Heaps
    • APIs in User mode and Kernel mode
    • Page Faults
    • Page Files
    • Commit Size and Commit Limit
    • Workings Sets
    • Memory Mapped Files (Sections)
    • Page Frame Database
    • Other memory management features
    • Lab: committing & reserving memory; using shared memory; viewing memory related information

 

  • Module 6: Management Mechanisms
    • The Registry
    • Services
    • Starting and controlling services
    • Windows Management Instrumentation
    • Lab: Viewing and configuring services; Process Monitor

  • Module 7: I/O System
    • I/O System overview
    • Device Drivers
    • The Windows Driver Model (WDM)
    • The Windows Driver Foundation (WDF)
    • WDF: KMDF and UMDF
    • I/O Processing and Data Flow
    • IRPs
    • Plug & Play
    • Power Management
    • Driver Verifier
    • Writing a Software Driver
    • Labs: viewing driver and device information; writing a software driver

 

  • Module 8: Security
    • Security Components
    • Virtualization Based Security
    • Protecting objects
    • SIDs
    • Tokens
    • ACLs
    • Privileges
    • Access checks
    • AppContainers
    • Logon
    • User Access Control (UAC)
    • Process mitigations
    • Lab: viewing security information

regsvr32 can register cross-arch DLLs

Those working with COM know of the famous little utility called regsvr32.exe. This little tool can register a DLL COM server in the system registry, making it available to COM clients.

But how does it work? Is it truly a magical tool? Not so much. When instructed to register a COM DLL, regsvr32.exe does three things:

  1. Calls LoadLibrary to load the provided DLL into its address space.
  2. Calls GetProcAddress for the DllRegisterServer function which must be exported by the DLL – otherwise regsvr32 reports failure.
  3. Calls the function – DllRegisterServer and reports success or error depending on the returned HRESULT.

So in essence, the DLL registers itself.

The curious thing about regsvr32.exe is that using the 64-bit version of regsvr32 manages to register 32-bit COM DLLs (not just 64-bit DLLs).

How can this be? Windows rules state that a 64-bit process cannot load a 32-bit DLL, and vice versa (except for resource-only DLLs, which can be loaded cross architecture, which is not the case with COM DLLs).

Using ProcMonX (ProcMon works just as well), we setup capture for process creation and module load events only, and add a simple filter for regsvr32 process names:

regsvr32_1

regsvr32_2

Now by running the 64-bit regsvr32 on a 32-bit COM DLL, we get some output. Here is the interesting parts:

regsvr32_3

regsvr32_4

Now it’s clear: the 64-bit regsvr32 recognizes that the DLL is 32-bit and thus spawns the 32 bit regsvr32 to handle it. Perhaps regsvr32 is not that simple, after all.