# dasciam/mc-hooks architecture

> Architecture diagram of the GitHub repository dasciam/mc-hooks, generated by GitDiagram from its file tree, README and a sample of source files (last updated 2026-06-25). It is an AI-made overview: check details against the source.

- Interactive diagram: https://gitdiagram.com/dasciam/mc-hooks
- Repository: https://github.com/dasciam/mc-hooks

## Overview

1. **Project shape**
   - This is a very small C++/CMake repository centered around a single source file, `main.cpp`.
   - The architecture is intentionally minimal: build system + one compiled binary + two third-party libraries used for reverse-engineering demos.

2. **Primary purpose**
   - The README makes the intent explicit: it is an educational demo for **signature scanning** and **inline function hooking** on **Windows DLLs**.
   - So the core “application” is not a business app or service; it is a low-level Windows native program that likely interacts with another process/module or with loaded DLL code.

3. **Execution boundary**
   - The main runtime boundary is **Windows x64**.
   - The program is built with a **MSVC-compatible toolchain** and targets Windows binaries, which matters because the hooking library and inline patching are architecture- and ABI-sensitive.

4. **Core source boundary**
   - `main.cpp` is the only project source file, so it likely contains the entire demo flow:
     - locate a target function or code pattern,
     - resolve an address from a signature scan,
     - install a hook,
     - demonstrate redirected execution or interception.
   - There is no evidence of a multi-module domain split; all runtime behavior is concentrated here.

5. **Signature-scanning subsystem**
   - The project depends on **libhat**, which the README identifies as a pattern/signature scanning library.
   - This subsystem is the “discovery” phase: it helps find code/data in a binary by matching byte patterns instead of relying on exported symbols or fixed addresses.

6. **Hooking subsystem**
   - The project depends on **safetyhook**, an x86/x64 inline hooking library.
   - This is the “interception” phase: once a target address is found, the code can patch the function prologue and redirect execution to custom logic, typically while preserving a trampoline to the original function.

7. **Data flow**
   - The natural flow is: **binary/module memory → signature scan → resolved address → hook installation → intercepted execution path**.
   - The key handoff is from the scanner to the hooker: the output of pattern matching becomes the input address for inline patching.

8. **Build and dependency management**
   - The project uses **CMake** as the build orchestrator.
   - `cmake/CPM.cmake` indicates use of **CPM.cmake** for fetching/managing dependencies, so the third-party libraries are likely pulled in at configure time rather than vendored as source.
   - This means the repo boundary is small, with external libraries forming a clear dependency layer.

9. **Toolchain support**
   - `toolchain/toolchain-mingw64.cmake` shows the repo includes an alternate **MinGW-w64** toolchain file.
   - That suggests the build system is prepared for more than one Windows-targeting compiler environment, even though the README specifically calls out MSVC.

10. **Platform/infrastructure assumptions**
   - The code is meant for **native Windows** development and runtime, not cross-platform portability.
   - The architecture depends on Windows DLL loading, x86/x64 calling conventions, and executable memory patching semantics.

11. **Non-goals / boundary clarity**
   - There is no sign of networking, persistence, UI, database access, or multi-process orchestration.
   - The repository is essentially a focused proof-of-concept around binary analysis and code redirection, not a larger product system.

12. **How to diagram it**
   - A good architecture diagram would show:
     - one application box for `main.cpp`,
     - a build/dependency layer via CMake + CPM,
     - external libraries `libhat` and `safetyhook`,
     - a Windows DLL/module target being scanned and hooked,
     - and the resulting control-flow redirection back into custom code.

Main entry points: [`CMakeLists.txt`](https://github.com/dasciam/mc-hooks/blob/main/CMakeLists.txt) (CMake), [`cmake/CPM.cmake`](https://github.com/dasciam/mc-hooks/blob/main/cmake/CPM.cmake) (CPM), [`main.cpp`](https://github.com/dasciam/mc-hooks/blob/main/main.cpp) (Demo app), [`toolchain/toolchain-mingw64.cmake`](https://github.com/dasciam/mc-hooks/blob/main/toolchain/toolchain-mingw64.cmake) (MinGW toolchain)

## Diagram (Mermaid)

```mermaid
flowchart TD

subgraph group_build["Build"]
  node_cmake["CMake<br/>build system<br/>[CMakeLists.txt]"]
  node_cpm["CPM<br/>dependency manager<br/>[CPM.cmake]"]
  node_toolchain["MinGW toolchain<br/>toolchain file"]
end

subgraph group_runtime["Runtime"]
  node_app["Demo app<br/>C++ entrypoint<br/>[main.cpp]"]
  node_target[("DLL target<br/>windows module")]
  node_scan{{"Signature scan<br/>discovery stage"}}
  node_address(("Resolved address<br/>resolved symbol"))
  node_hook{{"Inline hook<br/>interception stage"}}
  node_custom["Custom logic<br/>hook handler"]
end

subgraph group_deps["Dependencies"]
  node_libhat["libhat<br/>signature scanner"]
  node_safetyhook["safetyhook<br/>inline hook library"]
end

node_cmake -->|"builds"| node_app
node_cmake -->|"uses"| node_cpm
node_cmake -.->|"can select"| node_toolchain
node_cpm -->|"fetches"| node_libhat
node_cpm -->|"fetches"| node_safetyhook
node_app -->|"inspects"| node_target
node_app -->|"performs"| node_scan
node_scan -->|"uses"| node_libhat
node_scan -->|"produces"| node_address
node_address -->|"feeds"| node_hook
node_hook -->|"uses"| node_safetyhook
node_hook -->|"redirects to"| node_custom
node_custom -.->|"intercepts"| node_target

click node_cmake "https://github.com/dasciam/mc-hooks/blob/main/CMakeLists.txt"
click node_cpm "https://github.com/dasciam/mc-hooks/blob/main/cmake/CPM.cmake"
click node_toolchain "https://github.com/dasciam/mc-hooks/blob/main/toolchain/toolchain-mingw64.cmake"
click node_app "https://github.com/dasciam/mc-hooks/blob/main/main.cpp"

classDef toneNeutral fill:#f8fafc,stroke:#334155,stroke-width:1.5px,color:#0f172a
classDef toneBlue fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#172554
classDef toneAmber fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#78350f
classDef toneMint fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px,color:#14532d
classDef toneRose fill:#ffe4e6,stroke:#e11d48,stroke-width:1.5px,color:#881337
classDef toneIndigo fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px,color:#312e81
classDef toneTeal fill:#ccfbf1,stroke:#0f766e,stroke-width:1.5px,color:#134e4a
class node_cmake,node_cpm,node_toolchain toneBlue
class node_app,node_target,node_scan,node_address,node_hook,node_custom toneAmber
class node_libhat,node_safetyhook toneMint
```

## Components

### Build

CMake-based build and toolchain setup.

- [CMake](https://github.com/dasciam/mc-hooks/blob/main/CMakeLists.txt): build system · Configures and generates the Windows C++ build. · `CMakeLists.txt`
- [CPM](https://github.com/dasciam/mc-hooks/blob/main/cmake/CPM.cmake): dependency manager · Fetches external libraries during configure time. · `cmake/CPM.cmake`
- [MinGW toolchain](https://github.com/dasciam/mc-hooks/blob/main/toolchain/toolchain-mingw64.cmake): toolchain file · Alternate Windows-targeting compiler configuration. · `toolchain/toolchain-mingw64.cmake`

### Runtime

Windows-native demo execution and target module interaction.

- [Demo app](https://github.com/dasciam/mc-hooks/blob/main/main.cpp): C++ entrypoint · Single-file program that drives the scan-and-hook proof of concept. · `main.cpp`
- **DLL target**: windows module · Loaded binary or DLL region being searched and patched.
- **Signature scan**: discovery stage · Finds a target function or code pattern by matching bytes.
- **Resolved address**: resolved symbol · Matched location used as the hook insertion point.
- **Inline hook**: interception stage · Patches the target prologue and redirects execution.
- **Custom logic**: hook handler · Replacement or interception code reached through the hook.

### Dependencies

Third-party libraries used for scanning and hooking.

- **libhat**: signature scanner · Third-party library for pattern and signature scanning.
- **safetyhook**: inline hook library · Third-party library for x86/x64 inline function hooking.

## Connections

- CMake → Demo app: builds · Compiles the demo application.
- CMake → CPM: uses · Invokes CPM for dependency acquisition.
- CMake → MinGW toolchain: can select · Supports an alternate MinGW-w64 toolchain.
- CPM → libhat: fetches · Brings in the scanning library.
- CPM → safetyhook: fetches · Brings in the hooking library.
- Demo app → DLL target: inspects · Operates on a Windows DLL or module image.
- Demo app → Signature scan: performs · Searches for a byte pattern or function signature.
- Signature scan → libhat: uses · Delegates pattern matching to libhat.
- Signature scan → Resolved address: produces · Returns the matched code address.
- Resolved address → Inline hook: feeds · Supplies the hook installation point.
- Inline hook → safetyhook: uses · Delegates inline patching to safetyhook.
- Inline hook → Custom logic: redirects to · Transfers control into custom interception logic.
- Custom logic → DLL target: intercepts · Runs in place of or alongside the original code path.