Day 0: Perim ASM Framework
TL;DR
Perim is a modular CLI-based ASM engine (built in Go) that orchestrates reconnaissance into a repeatable, auditable pipeline: discover → resolve → probe → enrich → persist.
Over the next 15 days we’ll build the foundation in public — daily progress updates, masked screenshots, and engineering notes. We will offer invite-only, on-demand access to selected reviewers and will publish structured, sanitized reports for a small set of scanned domains as demonstration artifacts.
Why we’re building Perim ?
Reconnaissance is often treated as an ad-hoc exercise: run a tool, download results, forget. That creates:
Duplicate effort and noisy results
No historical context or diffs across runs
Poor reproducibility and weak evidence for triage
Perim intends to change that by providing a system for discovery: a living inventory that captures what exists, what responds, and what changed — so researchers and security teams can focus on high-signal findings.
What Perim is (quick) ?
Perim is a modular framework that coordinates multiple modules — each responsible for a specific task (enumeration, discovery, probing, crawling, enrichment, export). It provides:
A CLI for running orchestrated flows
Normalized, structured output for every discovered asset
Safe, scope-aware defaults for non-destructive probing
Export adapters (JSON/CSV/S3) and run metadata for auditability
Built with Go for concurrency, portability, and reliability.
The 15-Day Build Plan (what you’ll see)
We will publish a short devlog every day with: what we built, why it matters, masked screenshots, and lessons learned. Below is the high-level plan.
Phase A — Foundation (Days 0–3)
Day 0: Project kickoff — overview, goals, repo init.
Day 1: Subdomain enumeration (passive sources).
Day 2: Active + passive enumeration merged into a deduped inventory.
Day 3: Service discovery (safe port scans) & basic probing (HTTP/SSH).
Phase B — Enrichment & Discovery (Days 4–8)
Day 4: Perim crawler — controlled URL discovery and JS endpoint extraction.
Day 5: HTTP fingerprinting & basic tech detection.
Day 6: Directory discovery adapter (non-intrusive rules).
Day 7: Integration with nuclei-style checks for non-destructive CVE signals (safe subset).
Day 8: Storage & export adapters (JSON, CSV, S3).
Phase C — Polishing & Output (Days 9–13)
Day 9: Inventory diff engine — compare runs and highlight deltas.
Day 10: Exposure scoring prototype & prioritization heuristics (conceptual).
Day 11: Alerting hooks (email / Slack) and webhook adapters.
Day 12: Reporting templates (sanitized PDF/JSON reports).
Day 13: CLI polish, documentation
Phase D — Demo & Invitations (Days 14–15)
Day 14: Internal demo & selection of invite-only reviewers.
Day 15: Public wrap-up post, sample sanitized reports for selected demo domains, and next steps.
On-demand access & how to request it
We are preserving strict, invite-only access during the build phase. That helps us keep the project focused and safe.
If you’re a researcher, security engineer, or an org interested in participating:
- Send a DM to
@ph0enixProtocolon X (Twitter) with subject perim-feedback and a short note about your background.
We’ll review requests and onboard a small number of collaborators for focused feedback sessions. Access is granted at our discretion and may require an NDA for production data.
What the demo reports will include
Public demo reports will be deliberately sanitized and focus on methodology + impact. Each report will include:
Scope & run metadata: date, run ID, modules used, config summary
High-level inventory summary: counts of domains, IPs, responsive services (no raw hostnames unless authorized)
Examples of URL discovery patterns: annotated, masked screenshots showing capability
Delta highlights: sample examples of what changed between runs (masked)
Actionable insights: suggested next steps and triage tips (no exploit code)
No raw sensitive findings will be shared publicly.
How Perim helps both researchers & companies
For researchers
Repeatable workflows — reproduce a discovery and share sanitized evidence.
Normalized outputs — one schema across many tools.
Better signal — focus on responsive assets and changes rather than noisy lists.
For companies
Living inventory — know what’s newly exposed and when.
Audit-ready runs — reproducible runs with metadata for incident timelines and compliance.
Integrations — exportable results for ticketing systems, SIEMs, or asset databases.
FAQ
Q: Will you publish raw scans?
A: No. Public artifacts will be masked and focused on capability and methodology.
Q: Can I request Perim to scan my domain?
A: Yes — for demonstration purposes we will accept a small number of authorized domains and publish sanitized reports. Contact@ph0enixProtocol with proof of ownership and we’ll evaluate requests.
Q: Will Perim be open source?
A: The core repo will be public; license and contribution guidelines will be published with the repo. Some adapters or tooling may remain internal during the initial phase.
Q: What guarantees do you provide for invitees?
A: Invitees will get controlled access for feedback. Access is limited, time-bound, and may require an NDA for sensitive environments.
Final notes
This sprint is about engineering discipline: building a system rather than a collection of scripts. Over the next 15 days we’ll share the process, the tradeoffs, and the artifacts that demonstrate the power of a modular ASM engine.
If you want to be considered for early feedback or to request a demo scan for a domain you own, DM @ph0enixProtocol with perim-feedback and a short note about your use-case.
Let’s build something that brings clarity to the chaos.
