ShadowStrike EDR A Learning Journey...

[ShadowStrike-Labs]

Hi everyone,

I’m a 10th-grade high school student, and for the past two years I’ve been developing a from-scratch Endpoint Detection and Response engine called ShadowStrike.

ShadowStrike is a long-term project written primarily in C/C++, with some low-level components implemented in x86-64 Assembly for evasion and exploit-related detection logic. The codebase is currently large and admittedly messy, and the project is still pre-alpha. It does not compile yet and is under heavy active development. This is expected at this stage.

My interest in cybersecurity started early. I’ve been coding in C++ since I was around 11–12 years old, and before this project I experimented with smaller antivirus and security tools.
The first year of ShadowStrike was mostly about architecture, experimentation, and understanding how real EDR systems are structured. The second year focused on implementing core components and detection modules.

I decided to publish the project early because I realized that waiting for perfection would mean never releasing it at all. ShadowStrike is now open-source under GPLv3 so I can learn from the community, receive feedback, and gradually turn this into a more structured, enterprise-style EDR/AV engine.

Current direction and features (all under active development):
Kernel-level monitoring via a custom Windows sensor (“Shadow Sensor”)

File system, process, registry, and memory-focused detection logic

Custom memory-mapped databases for performance:

HashStore

PatternStore

SignatureStore (using Aho-Corasick, Boyer-Moore, B+ Trees, KMP failure functions, etc.)

SQLite-based console/management storage

Ongoing work on evasion and exploitation detection (JIT spray, injection patterns, etc.)

I’m also considering implementing a mini hypervisor to prevent malware from disabling the EDR and for future emulation purposes. However, I may instead rely on Windows Hypervisor Platform to avoid conflicts with VBS. This decision is still under evaluation.

At the moment, the project needs serious refactoring, cleanup, and better orchestration between components. Development has slowed slightly while I improve my low-level understanding. I’m currently learning Ghidra to better analyze and reason about the assembly-level parts of the system.

This is a long-term effort. My rough goal is to reach a first fully working version with a GUI and all major modules integrated around 2028–2029.

I’m sharing this project not as a finished product, but as a learning journey built in public.
Feedback, technical criticism, and discussion are very welcome.