ProjectsProjects

Problem

Android triage usually starts with a long setup: install apktool, configure jadx, write one-off grep scripts, and chase results across directories. By the time there is a baseline, a lot of analysis time is already gone.

Approach

A single CLI that runs the standard Android static-analysis stack in order: unpack with androguard, DEX cross-reference analysis, native ARM .so parsing with LIEF, packer detection via APKiD, secret extraction with Shannon entropy gating, C2 and crypto indicator sweep, YARA rule synthesis, and MITRE ATT&CK Mobile mapping. External tools are auto-detected and skipped gracefully when absent.

Highlights

• DEX analysis: dangerous permissions, exported components, suspicious APIs
• Native ARM .so parsing via LIEF (ptrace, dlopen, system imports)
• Packer and obfuscation detection via APKiD
• Secret extraction with Shannon entropy gating
• C2 and crypto indicator sweep with auto-generated YARA rules
• MITRE ATT&CK Mobile technique mapping

Problem

Content-layer LLM scanners (Lakera Guard, LLM Guard) score prompts and completions. They never see the JSON-RPC tool-call layer where MCP attacks actually live. Routing gateways handle auth and observability but do little adversarial detection. No one ships the intersection: inline JSON-RPC enforcement with tool-definition integrity tracking.

Approach

A transparent proxy that treats both the MCP client and every MCP server as hostile. Every tool definition, call, and result is offered to the policy engine before forwarding. A blocked request gets a spec-valid JSON-RPC error with the original id so the agent never hangs. Ships three policies out of the box (minimal, default, strict) and supports YAML-defined custom rules.

Highlights

• 10 MCP attack classes: tool poisoning, rug pull, shadowing, hidden instructions, arg exfiltration, and more
• Transparent stdio and HTTP proxy: no changes to client or server
• Policy-as-code (YAML): minimal, default, and strict bundled
• Interactive approval flow for unrecognized or changed tools
• Evidence-grade audit trail, exportable as SARIF, JSON, or HTML
• Offline by default: no outbound calls, no telemetry, fail-closed under load

Problem

Cloud security teams often have the telemetry they need, but not the connective tissue that turns raw events into a usable incident story. The hard part is not collecting data. It is normalizing it, correlating it, explaining why a detection fired, and giving an analyst a next step that does not waste time.

Approach

Ingests CloudTrail, GuardDuty, and Security Hub samples, normalizes them into a common event model, runs defensive detections, correlates suspicious activity, and generates analyst-ready findings, timelines, and manager summaries.

Highlights

• Root account usage
• Console login without MFA
• Privileged AssumeRole
• CloudTrail tampering
• Public sensitive port exposure
• GuardDuty plus CloudTrail corroboration

Problem

LLM applications are often deployed without rigorous security testing against prompt injection or sensitive data leakage. Traditional scanners aren't built for the non-deterministic nature of model responses.

Approach

A scanner that probes LLM endpoints with specialized payloads and runs the responses through YAML-defined detectors mapped to the OWASP Top 10 for LLMs.

Highlights

• Prompt injection (direct/indirect)
• Sensitive data disclosure (PII, secrets)
• Output handling (XSS, SQLi injection)
• Jailbreak detection
• Resource abuse & token exhaustion
• SIEM-ready JSON logging

Problem

Cloud security scanners find misconfigurations in isolation. They don't tell you which 5 of those 200 findings chain together into an actual account compromise path.

Approach

Models IAM principals and resources as a directed graph. Finds multi-step privilege escalation paths across service boundaries by matching chains against 12+ built-in attack tactics.

Highlights

• PassRole + Lambda/EC2/Glue
• IMDS credential theft
• Confused Deputy via S3 triggers
• IAM policy self-escalation
• Lambda code hijack
• Policy version rollback

Problem

Static shellcode runners are easily detected. Manual encryption and evasion patching is tedious and error-prone during OSEP-style engagements.

Approach

An advanced generator that applies stackable encryption layers (XOR, AES, RC4) and runtime evasion patches (AMSI/ETW) to shellcode using a standardized Jinja2 template engine.

Highlights

• Stackable encryption (XOR, AES, RC4, Caesar)
• AMSI & ETW runtime patching
• 9+ Output formats (EXE, DLL, VBA, HTA, PS1, JS, MSBuild)
• RW -> RX memory allocation safety
• Randomized namespaces and class names
• SQLite tracking of generated payloads

Problem

Running Claude Code against a local model means picking a quantization that fits your VRAM, configuring environment variables, and verifying both ends agree on the protocol. The setup gap is what stops most people from trying it.

Approach

Detects GPU, CPU, and RAM, picks a model that fits the available memory, downloads it via Ollama, and writes the Claude Code environment variables. The installer verifies the release tarball against the SHA256SUMS asset before extracting.

Highlights

• Hardware detection (GPU, VRAM, system RAM)
• Model selection that fits available memory
• Cross-platform installer (Linux, macOS, Windows, WSL2)
• SHA256-verified release tarball
• Idempotent re-runs (safe to re-install)
• Zero Python dependencies (pure shell)