The project idea came to me while working on a custom loader and C2.
I encountered a problem most security researcher face, the tool to assess the security no longer worked after a while..

So the question was why did it worked at first and then it didn't worked anymore ?
EDR systems analyze binaries with different methods and share telemetry through their network so that even if the execution path is different it still has the same structure to decide how to differ the execution path.

Another EDRs aspect, which should not be ignored, is that the software is stochastic but it's run on a determinitic machine.
As such at the end, the EDR needs to decide between death or alive without full information.

The question I asked myself: Can I build a framework which makes sure that I can determine the boundaries of detection engines ?

This project should answer the above question and map the boundaries of detections engines.
The project is a dual-use framework as the probe could also be weaponised and be used malicously.

I need positve answers for below questions:

Is it possible to write an agent with minimal footprint that it seems like noise ?
Is it possible without relying on the target's telemetry (like ETW and others) to decide what the boundary is ?
Is it possible to produce a fully closed loop that makes sure any anomaly can be detected ?
Is it possible to make it adapdable to the feedback we received fromt the closed loop ?

I think I have found the architecture to address most of the problems others have faced when trying to build such an architecture.s We will see if theory and practice will correlate.

Hierarchical Structure

  Cephas-Shikigami/
  ├── Cephas (Research Arm)
  │   ├── Mimir (Oracle) — EDR behavior analyzer + telemetry
  │   ├── ShadowLoki (Tripwire) — Parallel state validator, anomaly detection
  │   └── Fenrir (Fuzzer) — Permutation generator, cadence tester
  │
  ├── docs (Documentation)
  │   ├── Architecture — Design docs (Shikigami + Cephas)
  │   └── Protocol — Bifrost packet specification
  │
  ├── maLang (Language)
  │   ├── Runes — Opcode definitions (rune ID mapping)
  │   └── Rituals — Example .maLang ritual files
  │
  └── Shikigami (Offensive Arm)
  ├── Bifrost (C2 Network)
  │   ├── Bifrost — Multi-agent communication system
  │   ├── Protocol — BifrostPacket definition
  │   └── Ratatoskr — Packet dispatcher + queuing
  │
  ├── Loki (Agent)
  │   ├── Huginn — Opcode execution engine (15 WinAPIs)
  │   └── Munnin — State machine + memory tracking
  │
  ├── Pipeline
  │   ├── Sindri — maLang parser (tokenizer)
  │   ├── Mjolnir — Serializer (TLV encoding)
  │   └── Ivaldi — Agent builder (MetaData → Loki)
  │
  └── Future
        ├── Nebelheim — Crypter/packer (post-MVP)
        └── Odin — Operator TUI (post-MVP)

Closed Adaptive Feedback Loop

We need to have a closed adaptable loop and make sure that the output we receive is verifable.
To make it adaptable we will use genetic algorithms and make sure that the next probes adapt.

TODO: [ ] Need further explaination how the components interact
TODO: [ ] Explain what genetic algorithm will be used and why

Cephas (Research Arm) Components

Cephas is the research arm, which will analyze the telemtry from probing with Shikigami .

Oracle (Mimir)

Mimir is the EDR analyzer, which will tell us when an anomaly has been detected.
He is also the one which tells Fenrir and Ivaldi how to adapt the probe and payload.

Tripwire (Shadow Loki)

Shadow Loki is a copy of the probe we will send to the target to enable us anomaly detection.
The component makes sure that the telemetry received by the target is verifable.

Fuzzer (Fenrir)

Fenrir uses maLang rituals to see if the order of function calls result in interessting behavior.

Shikigami (Offensive Arm) Components

Shikigami is the offensive arm, it must be developed first beacuse Cephas need the data gathered by it.

UI (Odin)

Odin is the operators user interface. Not decided yet how to display everything.

Command & Control (C2)

Packet

Custom Message Packets (BifrostPacket) which represent one function of the WinAPI.

Server (Bifrost)

Bifrost is our communication system which communicates using BifrostPacket.

Dispatcher (Ratatoskr)

Ratatoskr is our packet dispatacher in the command queue of our probe.
The dispatcher can be an internal component of the C2 or deployed as standalone component.

Probe

Vessel (Loki)

Loki is our programmable probe, which holds two ravens inside.
The probe needs to always be unique so the EDR cant build a signature for the probe.

Ravens (Execution and State)

Huginn (Thought/Execution) is the execution engine.
Muninn (Memory/State) is our state machine to keep track of changes and retain previous decisions.

Proping Pipeline

DSL (maLang)

maLang is our domain specific language (DSL) for probe behavior development.
It is lika a RISC (Reduced Instruction Set Computer) Assembly Language without branching.
The desgin eliminates the issue of state explosion as it is fully linear and fully verifiable.

Parser (Sindri)

Sindri is our zero copy linear maLang parser which provides the data to Mjolnir and Ivaldi.

Serializer (Mjolnir)

Mjolnir receives the data from Sindri and creates a waves file (.sea extension) which is some sort of IR.

Builder (Ivaldi)

Ivaldi receives the META section and Runes information from Sindri and builds Loki using Makefiles.

Crypter / Packer (Nebelheim)

Nebelheim will be our crypter and packer in the future.

Deployment (Lab Environment)

As we want to study behavioral analysis of binaries by EDRs, we won't bother to bypass detection on deployment.
What we will do is use an AD Lab to spawn Windows VMs and then deploy our probe using GPO.

The whole topology of the LAB will be shown here in the future.

MVP OPERATOR WORKFLOW (WIP)

Cub3rs create maLang file per specifications and file format (LOCKED)
Sindri parses the maLang files and extracts META and BEHAVIOR Sections (LOCKED)
Sindri parses the META Section information and saves it to MetaData (LOCKED)
Sindri parses the BEHAVIOR Section information line by line and sends it to Mjolnir (LOCKED)
Mjolnir generate the Wave file (serialized bifrost packets) and saves it in the vault (WIP)
Sindri sends the MetaData information to Ivaldi
Ivaldi create the Loki vessel using the MetaData
Sindri tells Bifrost/Ratatoskr to dispatch packets from wave file**

** ONLY IN MVP: We will later make sure that Odin (UI) tells Bifrost/Ratatoskr to dispatch.

NOTE: Cub3rs are the operators of the framework

Roadmap

Below we find the current to do list.

Refactor Shiki
Refactor Sindri
Split META and BEHAVIOR section into two files
Rewrite Mjolnir (WIP - Plan is setup)
Build a MVP

Code TODOs

sindri/src/sindri_parse.c:                            // TODO: [ ]  0. Create the sea file path
sindri/src/sindri_parse.c:                            // TODO: [ ]  1. Write Wave magic
sindri/src/sections/behavior/sindri_behavior_parse.c: // TODO: [ ]  2. Send parsedTokens to Mjolnir to serialize
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  3. Write Packet Magic   --> WritePacketMagic()
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  4. Write OpCode to file --> WriteOpCode()
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  5. Write ID to file     --> WriteID() [static at first]
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  6. Write Flags          --> WriteFlags()
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  7. Write Payload Length --> WriteLength()
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  8. Write Payload        --> WritePayload()
sindri/tools/mjolnir/src/mjolnir.c:                   // TODO: [ ]  9. Write HMAC           --> Hmac(Header + EncPayload + SecretKey)
sindri/src/sindri_parse.c:                            // TODO: [ ] 10. Write HMAC           --> Hmac(EncFile + SecretKey)
include/shiki_strings.h:                              // TODO: [ ] We need to change everything to ShikiBuffers
include/shiki_mem.h:                                  // TODO: [ ] Make it use ShikiBuffer
include/shiki_errors.h:                               // TODO: [ ] INFO CODES AND DEBUG 
sindri/src/sindri.c:                                  // TODO: [ ] Put into own function
sindri/src/sindri_parse.c:                            // TODO: [ ] Add asserts
sindri/src/sections/meta/sindri_meta_attributes.c:    // TODO: [ ] Rename the function
sindri/src/sections/meta/sindri_meta_parse.c:         // TODO: [ ] Move to shiki_meta_debug.h
sindri/src/sections/behavior/sindri_behavior_parse.c: // TODO: [ ] Send parsedTokens to Mjolnir to serialize
sindri/tools/mjolnir/include/mjolnir.h:               // TODO: [ ] Recheck the SerialBuilder struct

Note: This list is only for orientation. Click here more information.

Future Ideas

ShikiTracer
Unit Testing System
Change to ShikiBuffer (WIP)
Remove memset

Here we save some ideas we might do in the future.