Deadwing - GitLite

KO | EN

gitlite — search

#hacktoberfest #ai #llm #android #rust #linux #docker #java #windows #awesome #kubernetes #vue #awesome-list #security

Deadwing

(★ 121)

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

파일 탐색기

최종 버전 다운로드 (.zip)

- Commands.c
- Commands.h
- Conf.h
- Deadwing.vcxproj
- Deadwing.vcxproj.filters
- Defs.h
- Globals.h
- Memory.c
- Memory.h
- Nt.c
- Nt.h
- PML4.h
- Relocations.c
- Relocations.h
- Serial.c
- Serial.h
- Smi.c
- Smi.h
- SmmMain.c
- Utils.c
- Utils.h
- VisualUefi.h
- DeadwingCppLib.hpp
- DeadwingCppLib.vcxproj
- DeadwingCppLib.vcxproj.filters
- README.md
- Conf.h
- DeadwingDxe.vcxproj
- DeadwingDxe.vcxproj.filters
- Defs.h
- DxeMain.c
- Globals.h
- Relocations.c
- Relocations.h
- Serial.c
- Serial.h
- Utils.c
- Utils.h
- VisualUefi.h
- Communication.c
- Communication.h
- DeadwingKM.inf
- DeadwingKM.vcxproj
- DeadwingKM.vcxproj.filters
- Defs.h
- Driver.c
- Triggers.h
- Utils.c
- Utils.h
- Commands.cpp
- Commands.hpp
- DeadwingUM.vcxproj
- DeadwingUM.vcxproj.filters
- HexDump.cpp
- HexDump.hpp
- Main.cpp
- README.md
- Service.cpp
- Service.hpp
- DeadwingSeq.png
- physread.png
- priv.png
- varead.png
- BaseCpuLib.lib
- BaseLib.lib
- DxeServicesTableLib.lib
- GlueLib.lib
- PeiHobLib.lib
- PeiServicesLib.lib
- PeiServicesTablePointerLib.lib
- RegisterFilterLib.lib
- SmmIoLibSmmCpuIo2.lib
- SmmMemLib.lib
- SmmServicesTableLib.lib
- - DeadwingDxe.inf
  - DeadwingDxe.uni
  - DeadwingDxeExtra.uni
- - Drivers.png
- - DeadwingSmm.inf
  - DeadwingSmm.uni
  - DeadwingSmmExtra.uni
- 60-Deadwing-x86_64.json
- OvmfPkgX64.dsc
- OvmfPkgX64.fdf
- README.md
.gitignore
Deadwing.default.props
Deadwing.props
Deadwing.sln
Doxyfile
DwPatch.py
LICENSE
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/xsh3llsh0ck/Deadwing

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd Deadwing

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. .NET

보통 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
.NET SDK dotnet 명령어를 쓰기 위한 SDK입니다.

dotnet restore

프로젝트에 필요한 패키지를 내려받습니다.

dotnet run

프로젝트를 빌드하고 바로 실행합니다.

✅ dotnet run 실행 후 터미널에 나타나는 안내 메시지나 주소를 확인하세요.

// 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:

```
<Random folder>
|
|-- EFI (VisualUefi folder)
|    |- debugger
|    |- edk2
|    |- EDK-II
|    |- openssl
|
|-- Deadwing (Project folder)
|      |- Deadwing
|            |- Deadwing    (SMM driver)
|            |- DeadwingDxe (DXE driver)
|            |- DeadwingKM  (Kernel driver)
|            |- DeadwingUM  (Controller app)
```

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.

|   Command   |                      Description                         |
|    :---:    |                         :---:                            |
| `ping`      | Pings SMI handler                                        |
| `physread`  | Reads from physical address                              |
| `varead`    | Reads from virtual address                               |
| `physwrite` | Writes to the physical address                           |
| `vawrite`   | Writes to the virtual address                            |
| `vtop`      | Translates virtual address to the physical address       |
| `priv`      | Changes process token and spawns system shell            |
| `exit`      | Exits from UM application without KM service termination |
| `term`      | Exits from UM application with KM service termination    |

## 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