bettercap: a Go framework for WiFi, BLE, HID and CAN-bus recon and MITM

What bettercap replaces, and for whom

The README describes bettercap as a framework written in Go that aims to give security researchers, red teamers and reverse engineers an "easy to use", "all-in-one solution" for reconnaissance and attacking WiFi networks, Bluetooth Low Energy devices, CAN-bus, wireless HID devices and Ethernet networks. That list is the point. A wireless assessment that touches 802.11, a BLE peripheral and a CAN segment normally means three or four tools with three or four configuration formats. bettercap puts them behind one session and one command grammar.

The audience is narrow on purpose. This is not a network monitoring product for operations teams, and it is not a packet capture GUI. It assumes you understand what a deauthentication frame does, what a PMKID association attack targets, and why ARP, DNS, NDP and DHCPv6 spoofers exist. The README lists all of those as features; it does not explain when using them is lawful. That judgement is left entirely to the operator, which is the correct place for it but also means the project offers no guardrails.

If your work is defensive, bettercap is still readable as a specification of what an attacker does, module by module. If your work is offensive and authorised, it is a single binary that covers radios most toolkits ignore.

Modules, caplets and the session loop

The repository layout tells you more about the architecture than the README does. Top-level directories include core, firewall, log, modules, network, packets, session and tls, and the Makefile builds the packages core, firewall, log, modules, network, packets, session and tls into a single binary. Each capability is a module registered with the session, which is why the documentation is organised as a module index (wifi, ble, canbus, hid, ethernet) rather than as a feature list.

Caplets are the scripting layer. The caplets directory in the repository holds them, the Makefile install target creates $(PREFIX)/share/bettercap/caplets, and the Dockerfile clones the separate bettercap/caplets repository into /usr/local/share/bettercap/caplets. A caplet is a sequence of commands the interactive shell would otherwise take one at a time, which is how a repeatable assessment gets recorded and replayed instead of retyped.

Alongside the shell there is a REST API module with asynchronous event notification over websocket, and a web UI built on top of it. The UI is what most people mean when they search for bettercap gui or bettercap web ui: a browser view of the same session, useful when you want to watch hosts appear rather than read a scrolling terminal.

Proxies exist at three levels: packet, TCP and HTTP/HTTPS application. The README says they are fully scriptable through javascript plugins, and go.mod confirms the javascript engine is github.com/robertkrimen/otto. That is an older, pure-Go ECMAScript interpreter rather than a modern engine, which is a reasonable choice for embedding and a real constraint if you expect current language features in your plugins.

Installing bettercap and running a first recon session

The project's own build path is a Go toolchain plus the native libraries the modules link against. The Dockerfile installs gcc, g++, build-base, libpcap-dev, libusb-dev, linux-headers, libnetfilter_queue-dev, iptables and wireless-tools in the build stage, which is a fair summary of the system dependencies. If you build from source, the Makefile's default target does the work.

make
sudo make install

The first command builds the binary named by TARGET (bettercap by default) and regenerates network/manuf.go through network/make_manuf.py, so python3 is needed even for a plain build. The second copies the binary to $(PREFIX)/bin, which is /usr/local/bin unless you override PREFIX, and creates the caplets directory under $(PREFIX)/share/bettercap. On distributions that package bettercap, the package manager is the shorter route; the README points at the project homepage and the releases page rather than listing per-distribution commands.

A container is also published. The Dockerfile ends with an entrypoint of /app/bettercap and exposes 80, 443, 53, 5300, 8080, 8081, 8082 and 8083. Those ports are the HTTP, HTTPS, DNS and API surfaces the proxies and REST module use, so a container run has to publish them deliberately rather than with a blanket host-network flag.

Once the binary is on your PATH, start it and look at what the session knows about itself. The README's feature list maps directly onto module names: wifi for scanning and handshake capture, ble for scanning and characteristic enumeration, hid for 2.4GHz MouseJacking with DuckyScript support, canbus for DBC decoding, injection and fuzzing, and the ethernet module for ARP, DNS, NDP and DHCPv6 spoofing. Enabling a module and letting it run is the whole first session; there is no separate daemon to configure.

For the browser view, the REST API module has to be started and the web UI served from it. The documentation covers this under the api.rest module and the web UI usage page, and the exposed port list above shows the defaults the container expects. The README does not spell out the exact command sequence for the UI, so read the module page before assuming a flag.

Where bettercap is the wrong instrument

The Linux dependency on iptables and libnetfilter_queue is not incidental. It is how the firewall and packet redirection layers work, which means the MITM side of bettercap is tied to netfilter semantics. On a platform without that, or in a container without NET_ADMIN, the spoofing and proxy modules have nothing to attach to. The Makefile even carries a build_with_race_detector target, a reminder that this is concurrent packet handling where timing bugs are a category of failure rather than an edge case.

Radio modules need radio hardware. Scanning BLE, injecting HID frames or touching CAN-bus requires the corresponding adapter; the Go dependencies (bettercap/gatt, bettercap/nrf24, go.einride.tech/can, tarm/serial) are the software half only. A laptop with a stock WiFi card will not give you monitor mode, and no amount of configuration in bettercap changes that.

There is also a scope problem. bettercap is an active tool. Running the wifi module in a populated office, or leaving a spoofer enabled on a production segment, affects other people's traffic immediately. If your goal is passive visibility, a capture stack that never transmits is the better fit, and bettercap will be the wrong choice even though it can capture.

Finally, the README and the repository do not document a rollback path for the firewall and routing changes the MITM modules make. If you enable redirection and the session dies, restoring the host's networking is your responsibility, and the documentation is silent on the procedure.

How bettercap differs from Kismet and from aircrack-ng

Kismet is the closest comparison on the wireless side, and the difference is philosophical. Kismet is a passive wireless detector and IDS-style observer: it listens, logs and alerts, and it is built to run for long periods without disturbing the environment. bettercap is an interactive framework that transmits. It deauthenticates, spoofs ARP and DNS, and proxies traffic. If you want a sensor that can sit on a wall for months, Kismet is designed for that and bettercap is not.

Against aircrack-ng, the split is breadth versus focus. aircrack-ng is a set of small 802.11 utilities, each doing one job, which makes them easy to read and easy to compose in shell scripts. bettercap folds 802.11 together with BLE, HID, CAN-bus and IP-layer MITM behind one session, a REST API and a web UI. The cost of that breadth is a larger binary, more system dependencies, and a GPL 3 licence rather than a per-tool mix.

There is a scripting difference too. aircrack-ng workflows are shell pipelines; bettercap workflows are caplets and javascript plugins running inside the process. Caplets are more portable across machines, and harder to debug when a plugin misbehaves because the failure happens inside a long-running session rather than in a pipe you can inspect.

Maintenance, licensing and the cost of staying current

The repository is not archived, and the last push was on 2026-08-13, so the project is under current work. Recent releases are v2.41.4 on 2025-08-18, v2.41.5 on 2025-12-15 and v2.41.7 on 2026-05-11. That cadence matters for anyone scripting against the REST API or writing caplets, because module command names are part of the interface and a minor release can change them.

The upgrade cost is mostly environmental. go.mod declares go 1.25.0 while the Dockerfile builds with golang:1.24-alpine, so the two build paths do not assume the same toolchain; check which one you are following. Building from source also pulls native headers (libpcap, libusb, libnetfilter_queue) that must match your kernel and distribution, and the manuf resource generation step needs python3. Container users get a smaller surface but inherit the exposed port list.

On licensing: the README states bettercap is released under the GPL 3 license, and the repository carries LICENSE.md. The GitHub metadata reports NOASSERTION because the licence text is not a verbatim match for a recognised template, which is a packaging detail rather than a different licence. GPL 3 is a copyleft licence with distribution obligations, so if you ship bettercap inside a product or a managed appliance, the terms of that distribution are yours to review with counsel. Nothing here is legal advice.

SECURITY.md exists at the top level, which is the file to read before reporting a vulnerability rather than opening a public issue.

Editorial conclusion

Adopt bettercap if you already own the hardware and the authorisation: an 802.11 adapter that supports monitor mode and injection, a BLE or nRF24 dongle for the radio modules, and a written scope for the network you point it at. Skip it if you need a passive monitoring appliance or a single-purpose tool you can audit in an afternoon, because the Linux image depends on iptables and libnetfilter_queue and the Dockerfile publishes ports 80, 443, 53, 5300 and 8080 through 8083 on the host. Before you run anything, confirm your adapter's monitor-mode support, check the GPL 3 obligations against how you intend to redistribute the binary, and read SECURITY.md for how the maintainers want vulnerabilities reported.

Frequently asked questions

Official sources

1. bettercap/bettercap on GitHub
2. Issues
3. Project website
4. README
5. Releases