Delving Into Windows CE, Part3: Introducing Team82’s Open-Source Debugger

This is part 3 of Team82’s four-part series on our analysis of the Windows CE attack surface. CE is a legacy OS still found in many operational technology environments. In part 1 of this series, we wrote about simple Windows CE application development, which helped us understand the OS and further our research. In part 2, we examined Windows CE’s debugger constructs.

A Freely Available Windows CE Debugger

Team82’s vulnerability research on critical applications and devices is usually focused on commercially available, production-ready applications. This contrasts the research in part 1 of our series on the Windows CE attack surface where we developed a simple Windows CE application and debugged it. 

Researching closed-source applications presents a major challenge for us when it comes to debugging; Visual Studio 2005 was the only debugger we found for Windows CE environments, however it was not built for debugging close-source applications. In part 2 of our series, for example, we provided a breakdown of the debugging constructs utilized when debugging with Visual Studio 2005. With our understanding of the constructs, we arrived at the conclusion that we are actually capable of introducing our own debugging tools that will utilize these remote debugging protocols.

In this blog, we will present our open-source debugger that allows researchers and developers to debug any Windows CE application from the comfort of your host machine. This debugger is focused on the essential components that allow a security researcher to debug and test an application for analysis and vulnerability hunting.

We invite you to download and use the debugger here.

Why Use Team82’s Windows CE Debugging Client

It seems that as a legacy platform, Visual Studio—the main Windows CE application development environment—is also the main utility applicable for application testing. And so as we drilled down into testing such applications, we needed to invest in building a setup for our vulnerability research. We learned this is not an especially accessible platform for eager vulnerability researchers that want to test an application. Two main hurdles consumed much of our valuable research time:

• First, was setting up an emulator/device and a Windows virtual machine capable of running older versions of Visual Studio. 

• Second was that debugging an executable without having its source code required us to patch-in a breakpoint into the tested application to enable debugging.

What is Required To Use Our Client

• A Windows CE based device or an emulator

• Debugging agent executables (can be found as part of the Visual Studio 2005 installation):

  • Clisenshutdown.exe: Shutdown commanding agent service

  • CMAccept.exe:  Make commanding agent service accept incoming clients connections

  • CommandClient.exe: Execute commanding agent service

  • DeviceDMA.dll: Device memory manipulation related routines library

  • eDbgTL.dll: Debugging library

  • TcpConnectionA.dll: Network related routines library

  • Edm.exe: Agent implementing debugging routines

Team82’s Windows CE debugging client: Debugging client custom made and implemented in Python to help us with Windows CE application vulnerability research.

Debugging A Windows CE Application

Our goal is to debug the application we created in part 1 of this series, to showcase the debugging capabilities provided by our custom utility. We will make modifications to the running application to present these capabilities.

The debugger project is composed of two separate components: a background connection component and the debugger client itself. The first component we will explain how to use is the background component, which initiates communication between the client debugger and a remote Windows CE system where our target application runs.

It’s simple to use this component.  All you need to do is to invoke the agents located on the remote system. If you recall in a previous blog, similarly to how you start debugging with Visual Studio.

Then we run the Python module:

As a side note, this component allows users to upload a target executable, using the –target optional parameter, to the device in a predetermined location. This becomes very handy when needing to debug a new executable.

After following the steps above, we can start our debugging client with the following command in the terminal.

Understanding Team82’s Debugger Client

The debugger client enables researchers to dynamically analyze Windows CE applications and test for security issues in them. The client is composed of several essential components. All the components except for a log view are interactive and enable researchers to remotely interact with the underlying process of a debugged application. Implementing this client relied on an analysis we conducted and showcased in a previous blog. In this analysis, we researched the original debugging constructs implemented by Microsoft Visual Studio, used to debug Windows CE applications. 

Before jumping into debugging our application we will present the different components that make up our debugger client.

Disasm-View

Memory-hex view enables the researcher to have a preview of the memory segment in the process. The view has an interactive cursor moved by using the arrow keys. This view also allows researchers to edit live memory by entering edit mode with the Insert key and editing the hexadecimal values and pressing the Enter key to commit changes.

Log View

The log view, as the name suggests, is responsible for presenting the debugger logs, allowing keeping track of the different events during a debugging session.

Breakpoints View

The Breakpoints view allows researchers to keep track of the different breakpoints in the debugging session and also manage them in a single spot.

Thread Contexts View

Thread-contexts view displays the threads and the corresponding registers in the context of the debugged process. This view also enables the modification of register values, which is essential when testing the application.

Debugging Our Application

Now that we are fairly familiar with the different components of our debugger we can try to debug our application to showcase the utility in action. As you may recall from part 1 of this series we created a Windows CE application with graphical user interface. To set a goal for our debugging attempt, we decided we will modify the application behavior during runtime.

First thing we should do is to execute our background component and upload our target application binary.

With that done we can go ahead and run our debugger to execute the target application in a new debugging session.

As you can see, the debugger utility puts a breakpoint on the entry point of our developed application, allowing us to place another breakpoint in the specific code area where we intend to apply our modifications. 

In our case, we placed the breakpoint right before the graphical component is initialized with its relevant parameters.

We intend to modify the text about to be displayed into a different string. Doing so, we present the memory editing feature of our debugger which is an essential part of debugging and application testing.

Having our modified memory set, we can continue the program execution and see the results.

As you can see in the image provided above, we managed to actively change the behavior of a running application on a remote Windows CE system with our custom debugger. This is apparent by the change of the title artifact in the application that changed to the value “AAAAAA”.

This was a brief example for a use case using our debugger utility, in which we as security researchers are interested in interacting with the underlying process of a target application. This is for instance a common scenario when a researcher wants to develop an exploit payload for a discovered vulnerability. It is also beneficial to us as we continue this series toward real vulnerability research we conducted on Windows CE systems used in critical infrastructure.