How trickster0/tartarusgate works
Purpose
Windows-native C/assembly proof-of-concept for invoking low-level Windows system services while attempting to avoid user-mode API hook interception. The solution is organized as a single Visual C++ project rather than a service, library, or web application.
Build and Entry Point
• Visual Studio solution: HellsGate.sln
• Native project definition: HellsGate/HellsGate.vcxproj
• Process entry and orchestration are expected in HellsGate/main.c.
• The project targets the Windows runtime and depends on Windows process, memory, and native system-call interfaces.
Native Syscall Dispatch Layer
HellsGate/hellsgate.asm is the architecture-defining assembly boundary. It likely contains syscall transition stubs and instruction-level dispatch logic, separating native service invocation from the C control plane. This is the critical platform-specific component and cannot be ported without replacing its Windows/x64 assembly assumptions.
C Control Plane
HellsGate/main.c coordinates the workflow: resolving required native functions, preparing arguments and buffers, selecting syscall behavior, and invoking assembly-backed routines. It is the primary control-flow entry point between normal Win32 process execution and the lower-level dispatch layer.
Shared Native Types and Contracts
HellsGate/structs.h defines the C/assembly interoperability contract: native structures, function-pointer forms, constants, and syscall-related metadata used by the control plane and dispatch implementation. Changes here can affect calling conventions, memory layout, and both compilation units simultaneously.
Primary Flow and Boundaries
1. Program execution begins in HellsGate/main.c.
2. C code identifies or prepares native API/service call metadata.
3. Shared definitions from HellsGate/structs.h establish parameter layouts and routine contracts.
4. Calls cross into HellsGate/hellsgate.asm for the low-level system-service transition.
5. Results return to C for subsequent memory/process operations or cleanup.
The key boundary is C-to-assembly: it depends on exact ABI behavior, register usage, stack alignment, and Windows native-service conventions.
Infrastructure and External Dependencies
• Build environment: Visual Studio/MSBuild via HellsGate.sln and HellsGate/HellsGate.vcxproj.
• Runtime: Windows, with architecture-sensitive native assembly.
• External dependency surface is primarily the operating system’s native syscall interface; no separate server, database, package manager, or cloud service is represented in the repository tree.
Main entry points: main.c C control plane · HellsGate.vcxproj Native C++ project · hellsgate.asm Syscall dispatch stubs · structs.h Native contracts
Components 8
Build
- Visual Studio solution
HellsGate.sln - Native C++ project
HellsGate/HellsGate.vcxproj
Native execution
- C control plane · Coordinates metadata, arguments, and syscall invocation.
HellsGate/main.c - Native contracts · Defines ABI-sensitive types, layouts, and syscall metadata.
HellsGate/structs.h - Syscall dispatch stubs · Performs the architecture-specific native service transition.
HellsGate/hellsgate.asm
Windows runtime
- Windows process runtime
- Native syscall interface · Operating-system native service interface reached by assembly dispatch.
- Process and memory operations
Connections 11
- Visual Studio solution → Native C++ project: contains
- Native C++ project → C control plane: builds
- Native C++ project → Native contracts: includes
- Native C++ project → Syscall dispatch stubs: assembles
- C control plane → Native contracts: uses layouts and metadata
- Syscall dispatch stubs → Native contracts: follows ABI contract
- Windows process runtime → C control plane: starts process
- C control plane → Syscall dispatch stubs: invokes low-level routines
- Syscall dispatch stubs → Native syscall interface: system-service transition
- Native syscall interface → Process and memory operations: executes services
- Process and memory operations → C control plane: returns status and results