Manisso/fsociety: a Python 2 penetration testing menu, and who should still install it

What Manisso/fsociety actually is: a menu over other people's tools

The README describes fsociety as "A Penetration Testing Framework, you will have every script that a hacker needs." Read the menu and the claim narrows. Every category is a list of existing programs: Information Gathering names Nmap, Setoolkit, WPScan, XSStrike and Crips; Password Attacks names Cupp and Ncrack; Exploitation Tools names ATSCAN, sqlmap, Shellnoob and Commix. fsociety does not implement a port scanner or a SQL injection engine. It presents those tools through one terminal interface so a tester does not have to remember each binary's invocation. The audience is a single operator on a laptop or a throwaway VPS who wants a remembered menu, not a team that needs a scheduling layer or a report format. The name comes from the Mr. Robot series, and the README leans into that with a GIF and a line saying fsociety contains all tools used in the show. That framing tells you what kind of project this is: a themed collection, assembled around a television reference.

How the launcher is wired: fsociety.py, fsociety.cfg and install.sh

The top level of the repository holds three files that explain the design. fsociety.py is the entry point. fsociety.cfg is the configuration the menu reads. install.sh is the script that pulls the underlying tools into place, and it is the reason the Dockerfile runs chmod +x install.sh before executing it. The menu categories in the README map to entries in that configuration rather than to modules inside the Python package, which is why the repository has no directory per category. The practical consequence is that the framework's behaviour depends on what install.sh fetched at install time and on what is already on PATH. The Dockerfile makes this explicit: it installs build-essential, sudo, git, wget, curl, nmap and ruby through apt, then runs pip install requests as the only Python dependency, then clones the repository and runs install.sh inside the image. Ruby appears there because several wrapped tools are Ruby programs. If a tool fails to install, the menu entry still exists; the failure surfaces when you choose it.

Installing fsociety on Linux and Termux with the one-line script

The README gives a single command for Linux, and the same command for Termux on Android after installing Termux from Google Play. It fetches a short URL and pipes it into bash, so the script runs without being saved to disk first.

bash <(wget -qO- https://git.io/vAtmB)

Running fsociety from Docker, which is the cleaner first use

The Docker path is the one the repository makes reproducible. Docker and Docker Compose are the stated dependencies, and docker-compose.yml defines a single service named fsociety that builds from the current directory. The Dockerfile starts from python:2.7-slim, so the Python 2.7 requirement is satisfied by the image rather than by your host. Four commands cover the lifecycle.

docker-compose build
docker-compose up -d
docker-compose exec fsociety fsociety
docker-compose down # destroys instance

The Python 2.7 dependency is the real constraint, not a footnote

The README states plainly that fsociety "Works with Python 2." The badge links to the Python 2.7.14 download page, and the Dockerfile pins python:2.7-slim. Python 2.7 reached end of life years ago, so a host running a current distribution will not have it, and the install script assumes it. That is the wrong-tool case: if your environment is Python 3 only and you cannot run a container, fsociety is not the project to bend into shape. The README does not document rollback, and uninstall is a top-level file with no explanation in the README, so removal is something you inspect rather than something you are told. The Dockerfile also contains an explicit workaround for container lifetime: the CMD runs python -c "import signal; signal.pause()" and the comment above it calls this a "Hack to keep the container running." That is a deliberate choice to keep a container alive with no service inside it, and it means the container is a shell you exec into, not a daemon. A second limitation is provenance. install.sh pulls tools from the network, and the README does not enumerate versions or checksums for any of them. Whatever you get is whatever was current when you ran it. Treat the install as a snapshot, not a reproducible build, unless you pin the container image yourself.

fsociety against a plain Nmap and sqlmap workflow

The honest alternative is not another framework. It is installing the two or three tools you actually use and calling them directly. Nmap and sqlmap are both named in the fsociety menu and both are widely packaged; if your work is port scanning followed by database testing, the menu adds a layer of indirection over commands you would type anyway. The difference in approach is that fsociety optimizes for breadth and recall, giving one operator a long remembered list of categories, while a direct workflow optimizes for control over flags and versions. A framework also hides which binary ran and with what arguments, and the README does not describe a logging or replay mechanism. If your work needs an auditable command history, the menu works against you. For teams that want a maintained Python 3 line, the README points to fsociety-team/fsociety, which is a different repository with a different maintenance history, and its state is not something this README describes.

Maintenance, licence and what the MIT terms do not cover

The repository is not archived and the last push was on 2026-07-21, so it is still receiving changes. That is not the same as the wrapped tools being current: fsociety's own commit activity says nothing about the Nmap, sqlmap or WPScan versions install.sh fetches. There are no releases in the repository listing, so there is no versioned artifact to upgrade to; updating means re-running update.sh or rebuilding the container, and the README does not document what update.sh preserves. The project is MIT licensed, which covers the fsociety code in this repository. It does not relicense the tools the menu invokes, and each of those carries its own terms that you should check separately. This is not legal advice, and the practical point is narrow: the MIT badge on the README applies to the launcher, not to everything the launcher runs. If you need a fixed tool set for repeatable engagements, the container image you build is the unit you control, not the upstream repository.

Editorial conclusion

Adopt Manisso/fsociety only if you are already running Python 2.7 in a disposable container and want a single menu over Nmap, sqlmap, WPScan and the rest, which is the case the bundled Dockerfile covers. Do not adopt it on a host where Python 2.7 is absent or where you need maintained code, because the README points Python 3 users at fsociety-team/fsociety instead. Before anything else, open fsociety.cfg and install.sh and read what they download.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Manisso/fsociety on GitHub
4. README