I was tired of studying security tools from static cheatsheets, so I built ShellStack

#security #typescript #react #showdev

I was tired of studying security tools from static cheatsheets, so I built ShellStack

When I started prepping for CEH and doing more CTFs, I ran into the same wall over and over: every resource for learning offensive security tools was either a wall of text in a PDF, a GitHub gist with no context, or a cheatsheet that assumed you already knew what half the flags did.

I didn't want notes. I wanted something that felt like sitting at an actual terminal — where I could browse tools, see real commands with context, and build the exact command I needed without digging through five tabs.

So I built ShellStack.

🔗 Live: https://shell-stack.vercel.app/
💻 Code: https://github.com/shlokkokk/ShellStack

What it actually does

ShellStack is a cybersecurity study platform built around one idea: learning security tools should feel operational, not passive.

280+ curated offensive security tools, organized into 19 categories, each with deep-dive docs — commands, common flags, when to use it, installation notes, and real examples
Interactive command builders — instead of memorizing flag combos, you fill in a form and get a ready-to-copy command generated live
20 CEH-aligned learning modules, built for structured study instead of flipping through slides
1,000+ command cheat sheet with fast search and one-click copy
A terminal-inspired UI that actually feels like a cyber-ops console instead of another docs site

The build

Stack: React 19, TypeScript, Vite, Tailwind CSS, GSAP, React Router, Radix UI primitives

A few things I focused on:

Search that actually ranks results. Early on, tool search was just naive string matching, which meant typing "nmap" could bury the actual Nmap entry under ten unrelated tools that happened to mention it in a description. I rebuilt it to weight exact and prefix matches higher, so the tool you're looking for shows up first, not buried on page 3.

Command builders that don't feel like a form. The tricky part wasn't the UI, it was designing a data model that could represent wildly different tools (a text-flag-heavy tool like Nmap vs. a mostly-positional-args tool) without a special case for every single one. Each tool's builder config lives in its own data file, so adding a new interactive tool doesn't mean touching the builder logic itself.

Content as data, not hardcoded pages. All 280+ tools and 20 CEH modules live in structured data files (src/data/tools/, src/data/modules/), not scattered across component files. This means the entire tool directory, cheat sheet, and CEH explorer all pull from the same source of truth — adding a new tool is a data entry, not a new component.

What's next

I'm still refining the command builder UX — it works, but I'm not 100% sure it's intuitive for someone seeing it cold. If you try it out, I'd genuinely love to know where it trips you up.

Also planning to expand the CEH module coverage and add a few more interactive builders for tools that currently only have static command references.