Changelog

This page tracks the ongoing evolution of the Veil Framework. Each entry documents what changed, why it mattered, and any migration notes for teams upgrading between versions.

For detailed write-ups on major releases, see the individual release notes linked below.

---

Veil 3.0

A ground-up rearchitecture of the framework's core. The 3.0 cycle replaced the legacy Python 2 codebase with Python 3, overhauled the module loading system, and introduced a cleaner CLI interface. This was the largest single change in the project's history, driven by Python 2 end-of-life and years of accumulated technical debt.

Key changes:

• Full Python 3 migration
• Redesigned module selection interface
• Improved payload output handling and file management
• Updated dependencies and removed deprecated libraries
• Restructured internal API for module developers

Read the full Veil 3.0 release notes →

---

Version 2.2.0

Focused on stability and payload format improvements. The 2.2.0 release addressed several long-standing issues with payload encoding and added support for additional output formats.

Key changes:

• New payload output formats
• Improved encoding reliability
• Bug fixes for edge cases in the generation pipeline
• Documentation updates

Read the 2.2.0 release notes →

---

V-Day Releases

The "V-Day" release cycle was an ongoing practice of coordinated, periodic updates to the framework. Rather than shipping changes continuously, the team batched improvements into scheduled releases. This approach allowed for more thorough testing and gave defensive teams time to prepare for updated techniques.

• V-Day Release Overview →
• May 15th V-Day Release →
• On Your Mark: May V-Day →
• Year of V-Days →

---

Earlier Iterations

The framework has evolved through numerous iterations since its initial development. Early versions focused primarily on AV evasion payload generation. Over time, the scope expanded to include Active Directory enumeration (PowerView), payload delivery (Catapult), Python obfuscation (Pyherion), and post-exploitation (Pillage).

Each expansion reflected real-world assessment needs — teams wanted an integrated toolkit rather than stitching together disparate scripts. The modular architecture accommodated this growth without requiring a monolithic rewrite until the 3.0 cycle.

---

How to Read This Changelog

Version numbers follow the pattern major.minor.patch:

• Major versions indicate significant architectural changes or breaking compatibility
• Minor versions add features or modules within the existing architecture
• Patch versions address bugs, security fixes, and documentation updates

When upgrading between major versions, review the migration notes in each release page carefully. Module configurations from earlier versions may not transfer directly.