Violent Fungus C2 Coming in 2022

Update: I decided to code in C++ using Qt instead of C with Glib. It should fit all requirements, except for C and smallest executable. In addition, using Qt will speed up development time to ship a 1.0 release, and it will be much easier to create portable code. Finally, I added a dedicated Violent Fungus C2 page that will be kept up-to-date.


I’m building a command and control (C2) program suite to learn C2 software design and implementation at a fine-grained level. Additionally, I want to get proficient coding C targeting multiple platforms. Aiming for a 1.0 release in 2022.

Below are the core goals and features, as I see them in June 2021.

Core Goals

  • Small binary size.
  • Lean on resources.
    • Able to run on smaller ARM boards with 512MB of RAM and potentially embedded devices.
  • Handle a large number of active agents.
  • Use C as much as possible/appropriate.
  • Target GNU/Linux, NetBSD 9+, OpenBSD 6.9+, FreeBSD 13+, Microsoft Windows 10+ and Server 2016+, and Apple macOS 10.5+.
    • Architectures should be somewhat normal including x86, x86-64, ARM32, and ARM64 in particular.

Core Features

  • Support a large number of server services: HTTPS, DNS over UDP, FTP, SMB, ICMP, SMTP, raw TCP, and raw UDP, etc., shooting for more than anyone else.
  • Multi-user server and agents: multiple users can use the server and communicate with the same agents at the same time.
  • Plugin support: C initially, but Python and Lua are planned.
  • Agent…
    • relaying: relay communications to the server via other agents and to agents via other agents (return path doesn’t have to be the same).
    • time/day schedules: only operate on certain days and times, such as work hours.
    • queues: queue multiple commands/requests.
    • multiple server service communications: optionally communicate over multiple server services if available (such as multiple DNS queries and then SMTP) within the same session.
    • communication playbooks: predefined communication ordering to emulate normal traffic.
  • Asymmetric and symmetric encryption: rotating keys, using existing industry standards of AES and DSA, for example. Perhaps ChaCha on ARM boards and older processors that don’t have AES instructions available.
  • Decoupled transmission, data chunking, and data modification: allowing for independence at each level, one-to-many relationships, and independent plugin support.
  • Server API: frontends can use the remote server API, allowing for a decoupled experience where user interfaces can be remote and in whatever format is needed.

Leave a Reply

Your email address will not be published. Required fields are marked *