FrameworkGuidesModulesRelease NotesAbout

Year of V-Days

The V-Day release model defined how the Veil Framework evolved over its formative period. This retrospective looks back at the annual cycle of coordinated releases, what each one delivered, and the lessons learned about maintaining security tooling on a structured cadence.

The Annual Cycle

Each year brought a rhythm of planned updates. The team would accumulate changes — new payload types, encoding improvements, bug fixes, compatibility updates — and batch them into scheduled releases. The V-Day label gave each release a recognizable identity and a focal point for both the development team and the user community.

This approach had trade-offs. On the positive side, each release was thoroughly tested, well-documented, and delivered as a coherent package. On the negative side, useful fixes sometimes waited weeks or months to reach users, and the batching process occasionally created integration challenges when multiple large changes landed simultaneously.

Release Highlights

Early V-Days

The earliest releases focused on establishing the framework's core capabilities. Payload generation options were limited but functional, and the emphasis was on proving the concept of a modular evasion testing tool. Community feedback from these early releases shaped the architecture decisions that defined later versions.

Mid-Period Maturity

As the framework matured, V-Day releases grew in scope. New modules (PowerView, Catapult, Pyherion, Pillage) were introduced during this period, each arriving in its own V-Day cycle. The modular architecture proved its worth here — new modules could be added without disrupting existing functionality.

Later Evolution

Later V-Days shifted from adding new capabilities to refining existing ones. Stability, compatibility, and documentation became the primary focus. The 2.2.0 release exemplifies this phase — it focused on encoding reliability and pipeline stability rather than new features.

Eventually, the scope of necessary changes exceeded what the V-Day model could comfortably accommodate, leading to the 3.0 release — a major version that required its own extended development and testing cycle.

Lessons Learned

Scheduled releases build trust. Users and defensive teams could plan around known release dates. This predictability was valuable for teams that needed to coordinate detection testing with framework updates.

Batching has diminishing returns. Small, focused releases are easier to test and deploy than large, multi-component releases. As the framework grew, the V-Day batching model became harder to execute cleanly.

Documentation is not optional. Every V-Day that shipped with thorough release notes and migration guidance had smoother adoption than releases where documentation lagged.

Detection testing should be continuous. The V-Day model encouraged periodic detection testing (after each release), but the ideal is continuous detection validation, not point-in-time assessments.

Related