Deadwing

KO | EN

gitlite — search

#typescript #ai-agents #ai #dsh-plugin #deepseek-harness #open-source #cli #claude-code #codex #developer-tools #react #windows

★ 122 Open GitHub ↗

SMM driver/rootkit for platform memory access with R3 <-> R0 <-> R-2 communication.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Deadwing

This repository **demonstrates** the possibility of communication between user mode and SMM to achieve user goals. This project is designed to give an ability to researchers (I guess?) to work with the platform "unconstrained" through inter-mode communication between user mode and SMM (R3 <-> R0 <-> R-2, respectively) with specific SMI data being passed to the handler "directly".

**Deadwing** is currently a simple utility to read and write memory (virtual, physical), memory translation, however, the list will be expanded over time.

Demo:

https://github.com/user-attachments/assets/1806e068-22c4-44d9-a252-1b732e95e448

## Boot sequence with Deadwing

The boot sequence along with the **Deadwing** drivers is described in the image below:

![Sequence](https://raw.githubusercontent.com/xsh3llsh0ck/Deadwing/master/img/DeadwingSeq.png)

A more detailed description is below:

1. DXE Dispatcher finds a HOB with SMM drivers that contains an SMM driver - **Deadwing**. The driver **caches some services, allocates a page to handle virtual addresses and registers an SMI** with a specific GUID (Child SMI). The SMI handler will later validate the data and process the user's commands.
2. DXE Dispatcher finds a HOB with some DXE drivers. Such a HOB may contain the following driver - **DeadwingDxe**. This DXE driver is responsible for **caching the protocol for communication, publishing the data package to the OS kernel modules and exposing several APIs for communication with SMM**. To achieve these goals, the driver **establishes two callbacks**. The first callback is responsible for **determining whether an SMI handler is available**. The second one is responsible for **converting and publishing the data package**. The exposed API, which will later be used by the OS kernel module, is responsible for **setting up the data buffer and convoying it to the SMM**.

## Working in RT phase

The work in the RT phase is as follows:

1. The user starts the user application (**DwUM**). Then, enters the `cache` command - this is necessary to cache data about the current session (**Dir Base** and **EPROCESS** of the kernel and user application are cached).
2. The user application **sends a request** to the driver.
3. The driver **processes the user data packet, setups a buffer based on the received data, and fires the SMI**.
4. The SMI handler **receives the setuped buffer, validates it, executes the command, fills the communication buffer with its own data, edits the user buffer (if any), and returns control to the system**.
5. The driver **gets the status with which the command was processed** and, if all is well, the user application can get the necessary data.

## Building
The project is being built on MSVC (v143+), **specifically** the kernel driver and user application. SMM and DXE drivers **can be built by any compiler**, as long as **EDK2** build utilities are used.

The project uses **VisualUefi** to work with **EDK2** under VS. The project structure has the following representation:

To build **OVMF** images, navigate to `Ovmf/OVMF.md`.

> [!IMPORTANT]
> Also, pay attention to the `Conf.h` headers in the DXE and SMM code directories, they configure some subtle compilation points.

## Running

> [!CAUTION]
> **This project has not been tested on physical machines. All actions are at your own risk, and I'm not responsible for any damage caused. Test on machines with Flashback technology or have a SPI flash programmer at hand.**

The project provides the possibility to start as a **normal driver** or by **infecting other drivers** (this is true for both SMM driver and DXE driver). In the first case, the driver will start its entry point immediately. In the second case, the driver will move to new pages, initialize, and return control to the infected driver.

Also, the user can try to patch their firmware to be able to run drivers without infection.

## Commands list

List of available **DeadwingUM** (**DwUM**) commands.

## Output examples

1. `varead` command (`notepad.exe` base address)
   
   ![varead](https://raw.githubusercontent.com/xsh3llsh0ck/Deadwing/master/img/varead.png)

2. `physread` command (`SMST` table address)
   
   ![physread](https://raw.githubusercontent.com/xsh3llsh0ck/Deadwing/master/img/physread.png)
   
3. `priv` command
   
   ![priv](https://raw.githubusercontent.com/xsh3llsh0ck/Deadwing/master/img/priv.png)

## Acknowledgements

- **Cr4sh, SmmRootkit** - for the memory page remapping idea.

## Credits

@0x00Alchemist, 2024

Deadwing

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README