Skip to main content

​
Overview

Osiris implements several advanced technical features that make it unique. These constraints ensure minimal footprint, maximum performance, and enhanced detection avoidance.

​
Core Technical Constraints

​
No C Runtime Library (CRT)

The C++ runtime library (CRT) is not used in release builds.
Osiris implements its own minimal runtime on Windows to avoid dependencies on the standard C/C++ runtime library. Implementation Details:
  • Windows: Custom CRT implementation in Platform/Windows/CRTWindows.cpp
  • Linux: Links only against the C library (-lc), not the C++ standard library
  • Entry Point: Custom DllMain entry point instead of standard CRT initialization
Benefits:

Smaller Binary Size

No CRT bloat results in significantly smaller DLL/SO files

Fewer Dependencies

No runtime library dependencies to worry about

Faster Loading

No CRT initialization overhead

Better Control

Complete control over initialization and shutdown
Compiler Flags: 
/nodefaultlib        # Don't link default libraries
/ENTRY:"DllMain"      # Custom entry point
/sdl-                # Disable SDL checks
/GS-                 # Disable buffer security

​
No Heap Memory Allocations

Osiris does not perform heap memory allocations at runtime.
All memory is allocated statically or from pre-allocated memory pools managed by the custom allocation system in MemoryAllocation/. Why No Heap?
Static allocation eliminates allocation/deallocation overhead and prevents memory fragmentation.
Without dynamic allocation, memory leaks are impossible.
Memory layout is known at compile time, making debugging easier.
No heap-based vulnerabilities or corruption issues.
Implications for Developers: 
// ❌ These are NOT allowed:
new Object();
delete ptr;
malloc(size);
free(ptr);
std::vector<T> v;  // Uses heap internally
std::string s;     // Uses heap internally

// ✅ Use these instead:
static Object obj;
StaticVector<T, MaxSize> v;  // Fixed-size vector
FixedString<MaxLength> s;    // Fixed-size string

​
No Static Imports (Windows)

Windows release builds have no static imports.
All Windows API functions are loaded dynamically at runtime, making the import table empty. Implementation:
  • System Calls: Direct syscalls via Platform/Windows/Syscalls/WindowsSyscall.asm
  • Dynamic Loading: Functions loaded via custom dynamic resolution
  • No Import Table: Empty IAT (Import Address Table)
Benefits:

Stealth

Harder to detect by static analysis tools

Flexibility

Can choose which APIs to use at runtime

Compatibility

Better handling of missing or hooked APIs

Security

Avoid IAT hooking attacks
Link Flags: 
/nodefaultlib        # No default libraries

​
No Thread Creation

Osiris does not create any new threads.
All code executes on existing game threads, typically through hooks and callbacks. Rationale:
No thread synchronization complexity (mutexes, locks, etc.)
Reduces risk of race conditions and deadlocks
New threads can be suspicious to anti-cheat systems
No thread overhead or context switching
How Work Gets Done:
  • Hooks: Function hooks intercept game code execution
  • Callbacks: Register callbacks with game systems
  • Frame Processing: Work is done during game frame updates

​
No Exception Handling

Exceptions are not used in release builds.
Exception handling is disabled to reduce binary size and improve performance. Compiler Flags: 
# Exception handling flags removed
/EHsc removed from flags
Error Handling Alternatives: 
// ❌ Don't use exceptions
try {
    operation();
} catch (const std::exception& e) {
    handleError();
}

// ✅ Use return codes
if (!operation()) {
    handleError();
    return false;
}

// ✅ Use optional types
if (auto result = operation()) {
    use(*result);
} else {
    handleError();
}

​
No External Dependencies

Osiris has no external dependencies.
The entire codebase is self-contained with no third-party libraries. What This Means:

Self-Contained

Everything needed is in the repository

No Package Managers

No vcpkg, Conan, or npm needed

Simple Builds

Just compiler and CMake required

Full Control

Complete control over all code
Platform APIs: Osiris only uses:
  • Operating system APIs (Win32, POSIX)
  • Game engine interfaces (Panorama UI, Source 2 SDK)
  • Standard C library (minimal usage)

​
Additional Technical Details

​
Symbol Visibility

CXX_VISIBILITY_PRESET hidden
C_VISIBILITY_PRESET hidden
All symbols are hidden by default, reducing binary size and preventing symbol conflicts.

​
Position Independent Code

POSITION_INDEPENDENT_CODE ON
Enables ASLR (Address Space Layout Randomization) support and is required for shared libraries on modern systems.

​
Security Hardening (Release vs Debug)

  • Stack protection: Disabled (/GS- or -fno-stack-protector)
  • SDL checks: Disabled (/sdl-)
  • Exceptions: Disabled
  • RTTI: Minimal
  • Optimizations: Maximum

​
Performance Characteristics

Fast Load Time

No CRT initialization, minimal imports

Low Memory Usage

Static allocation, no heap fragmentation

Minimal Overhead

No exception handling, no thread synchronization

Small Binary

No CRT, hidden symbols, stripped binaries

Fast Execution

Optimized release builds, no runtime checks

Predictable

Deterministic behavior, no allocations

​
Binary Size Comparison

The technical constraints result in very small binaries:
  • Without these optimizations: ~2-3 MB typical
  • With Osiris optimizations: Significantly smaller due to:
    • No CRT bloat
    • No exception handling tables
    • No unwind tables
    • Hidden/stripped symbols
    • No external dependencies

​
Development Implications

These constraints require careful programming:
Plan memory usage at design time
Use fixed-size containers and buffers
Handle errors via return codes or optional types
Hook into game threads instead of creating new ones
Load Windows APIs dynamically
Test both Debug and Release builds regularly

​
Compatibility

These technical features are compatible with:
  • Windows 10/11 (x64)
  • Linux (x64) with kernel 4.x+
  • Counter-Strike 2 latest version
The design ensures the code adapts to game updates through dynamic pattern scanning and runtime API resolution.

Build docs developers (and LLMs) love

Get started for freeTalk to us