# BCHackTool installs and launches pentesting and OSINT tools from one menu

> BCHackTool is a shell script that presents a colourised menu of popular penetration testing and OSINT tools, downloads the ones you pick and runs them, on either Kali Linux or Termux. It suits people who want a toolbench quickly rather than a curated one they maintain themselves.

**ByCh4n/BCHackTool** — All-in-one launcher and installer for popular penetration-testing and OSINT tools on Kali Linux and Termux.

- Repository: https://github.com/ByCh4n/BCHackTool
- Website: https://github.com/ByCh4n/BCHackTool
- Stars: 550 · Forks: 88
- Language: Shell
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/bych4n-bchacktool

## A toolbench assembled on demand rather than curated

BCHackTool describes itself as an all-in-one launcher and installer for popular penetration testing and OSINT tools, built for Kali Linux and Termux. The stated motivation is practical rather than ideological: it presents a colourised menu, downloads the selected tools automatically and runs them, so that you do not have to clone and configure each project by hand. That last clause is the whole value proposition, and it is worth being precise about what it saves. Setting up an OSINT tool by hand is often a git clone, a pip install of a specific version, a configuration file with an API key placeholder, and a hunt through a README for the right invocation. Doing that for a dozen tools is an afternoon that never quite finishes.

The feature list describes a small, focused piece of software rather than a toolkit of its own. You get menu-driven access to a curated set of pentesting and OSINT tools, the same menu on both Kali Linux and Termux, a colourised interface with an auto-rotating banner, one-key setup where dependencies and tools are installed on demand, and helper flags for version, author information and cleanup. Note what is absent. There is no scanning engine here, no exploit framework, no report generator. The tool installs and launches other people's projects. Its value is entirely in removing the setup friction, and its risk profile is entirely inherited from the tools it fetches.

The audience is therefore narrower than the topic list suggests. The topics cover ethical hacking, hacking tools, penetration testing, security tools, OSINT, Kali Linux and Termux, and the repository is written in Shell with a ShellCheck workflow badge in the CI configuration. This is a bench organiser for a practitioner who already knows which tool they want and does not want to spend time installing it.

## Two entry scripts, one for each environment

The repository is small and its layout explains the design. At the top level there is bchacktool.sh, bchacktool-termux.sh, a banners/ directory, a file named update, the README, the licence and the GitHub configuration. Two separate launcher scripts rather than one script with a platform check is the notable choice. The rationale appears in the requirements: root privileges on Kali Linux through sudo, while Termux runs without root. That difference is not a flag, it is a different execution model, because the package managers and installation paths available on a rooted Kali system and inside a Termux environment are not the same set. Splitting into two scripts means each one can be written for its environment rather than branching at runtime.

The requirements list is short and worth taking at face value, because the tool depends on network access and on writing to system locations. You need bash, you need git and an active internet connection, and you need either a Kali Linux or Termux environment. The git requirement is a tell: the tools are fetched with git rather than downloaded as archives, which means each tool arrives with its own history, which matters if you later want to update or remove it. The cleanup flag is the counterpart to that, described as removing tools downloaded by the script.

The banners/ directory holds the artwork the auto-rotating banner draws from, and the update file at the root is presumably the mechanism by which the script itself is refreshed, separate from the tools it installs. The distinction between the update path for the installer and the update path for the installed tools is the mechanism behind most of the operational risk in the design, and it is worth understanding before you rely on it.

## Installing on Kali Linux and on Termux

On Kali the documented route is four commands, and it runs the script under sudo:

```bash
git clone https://github.com/ByCh4n/BCHackTool
cd BCHackTool
chmod +x bchacktool.sh
sudo ./bchacktool.sh
```

The chmod step is what makes the script executable, and the sudo invocation is what lets it install dependencies into system locations and fetch tools into places your user account cannot write. On Termux the same clone applies but there is no sudo:

```bash
git clone https://github.com/ByCh4n/BCHackTool
cd BCHackTool
chmod +x bchacktool-termux.sh
./bchacktool-termux.sh
```

The second script is the Termux entry point and it runs as your normal user. Both flows then drop you into the same colourised menu, and you pick a tool from it, at which point the script installs whatever that tool needs and runs it. The helper flags sit alongside the menu. There is -v and --version to show the script version, -h and --help to show author and project information, and -s and --sil to remove the tools the script downloaded.

The cleanup flag is the one to know about in advance. On a shared machine, or on a Kali installation where you would rather not leave a bench of cloned repositories in your home directory, the removal path is one flag rather than a manual hunt through directories. That this is a supported operation rather than an afterthought is a point in the design's favour, given that the script writes to the filesystem on your behalf.

## What running a script as root that clones third party code actually means

The honest limitation of this project is not a bug in it, it is the shape of what it is. You are running a shell script, with root privileges, that uses your network connection to fetch code from other people's repositories and then execute it. Each of those steps is individually reasonable and the combination is worth understanding rather than glossing over. The cloned tools are third party projects maintained by other people, at versions the script chooses, and the script is the mechanism by which those versions are selected.

The consequence is that there is no pinning of what you end up running. The script has a version, v3.2, and it has a -v flag, but the tools it installs move independently of it. A change in one of those upstream projects reaches your machine the next time you install or update that tool through this script, with no version choice available to you and no record in your own repository of what you had before. That is the practical difference between this and a curated toolchain, where each tool is pinned, mirrored and upgraded deliberately.

The second limitation is scope of trust. The auto-rotating banner and the colourised menu are cosmetic, and the helper flags are simple, but the value of the script lies in the long list of tools it fetches and the sequence of shell commands it runs to prepare them. That list is long enough that reading it line by line is a real cost, which is exactly why the ShellCheck workflow in the CI configuration is worth a mention, since it at least catches the class of error that would break the script rather than the class of error that would surprise you.

There is also a licensing and distribution point that is easy to overlook. The script is MIT licensed and the author disclaims all liability for misuse, which is standard, but the tools it installs carry their own licences, and a bench of cloned repositories in a commercial environment may come with obligations that the MIT licence on this repository does not cover.

## The alternative is a list you keep yourself

The obvious alternative is not a competing product, it is a file of your own. A text file listing the tools you use, with the clone command and the install step for each, does the same job as far as the outcome goes, and it has three advantages over this script. You choose which tools are in it, so you are not accepting a curated set from someone else's judgement. Each entry can be pinned to a tag or a commit, so an upstream change does not silently alter your environment. And the file is reviewable in a way that a script performing dynamic installation is not, because a command in a text file is a command you can read before running.

The cost of that approach is the friction the script exists to remove. You write the install steps once per tool, you maintain them as upstream instructions change, and you handle the case where a tool needs system packages rather than just a clone. For someone who already has a working bench, that cost is sunk and the text file wins. For someone setting up a new environment, the script saves the afternoon.

A second alternative is the package managers themselves. Kali ships many security tools as apt packages, and Python based OSINT tools install cleanly with pip or pipx into an isolated environment. That route gives you version control through the package manager and, in the pipx case, dependency isolation, which the script does not offer since it clones into directories and runs tools in place. The distinction in approach is that this project treats installation as a solved problem to be automated away, while the package manager route treats it as a dependency to be managed properly, and the second is the better answer for a machine you care about.

A third option is a container. Running each tool in its own image, with the image tag as your version pin, gives isolation and reproducibility without needing the script, at the cost of network setup and the annoyance of a shell inside a container for interactive work.

## The release history says what to expect

The version history is short and uneven, and it is the most informative fact about the project for an adopter. Version 3.2 was released on 2026-08-01 and the last push to the repository carries the same date. Before that there is version 3.1 from 2021-11-29 and version 3 from 2021-02-11. So the long stretch, close to five years, lies between version 3.1 and version 3.2, following a gap of only a few months after version 3.

The repository is not archived, and the recent release is current, so the project is not dead. But the gap is a fair signal about how this kind of tool usually progresses. A script whose value depends on the upstream tools it installs needs to be revisited whenever those tools change their installation instructions, and the intervals in this history suggest that does not happen on a schedule.

The author is Hüseyin Altıntaş, working under the handle ByCh4n, with the project credited in part to lazypwny751, and the repository carries a disclaimer stating that the project is provided for authorized security testing and educational purposes only, to be used exclusively on systems you own or have explicit permission to test. The author accepts no liability for misuse or any damage. For a tool that exists to give you fast access to offensive tooling, that disclaimer is a necessary part of the package rather than boilerplate, and it should shape how you present the tool to colleagues.

## Conclusion

Adopt BCHackTool if you work on Kali Linux or Termux, you want a bench of common security and OSINT tools available in a couple of minutes, and you are comfortable running shell scripts with root privileges that pull code from third party repositories. Do not adopt it as a curated toolchain for a team, since it has no version pinning for the tools it installs and its own release history has a long gap. Before you run it, read the disclaimer and confirm your use is authorised, review the shell scripts the way you would review any code you run as root, and check the flag documentation, including the -s cleanup option, before you hand it to anyone else.

## FAQ

### What does BCHackTool actually do?

It is an all-in-one launcher and installer for popular penetration testing and OSINT tools, built for Kali Linux and Termux. It presents a colourised menu, downloads the selected tools automatically and runs them, so you do not have to clone and configure each project by hand.

### How do I install BCHackTool on Kali Linux?

Clone the repository with `git clone https://github.com/ByCh4n/BCHackTool`, enter the directory with `cd BCHackTool`, make the script executable with `chmod +x bchacktool.sh` and run it with `sudo ./bchacktool.sh`. Root privileges are needed on Kali because the script installs dependencies into system locations.

### Does BCHackTool work on Termux?

Yes. Termux is supported through a separate script, `bchacktool-termux.sh`, which is run without sudo since Termux operates without root. The clone and chmod steps are the same, and the same menu is presented once the script starts.

### What command line flags does BCHackTool support?

There are three pairs. `-v` and `--version` show the script version, `-h` and `--help` show author and project information, and `-s` and `--sil` remove the tools the script downloaded, which is the cleanup path for a shared machine.

### What are the requirements for running BCHackTool?

You need bash, git and an active internet connection, plus either a Kali Linux or a Termux environment. Root privileges through sudo are required on Kali Linux, while Termux runs without root.

### Is BCHackTool maintained and what licence does it use?

The repository is not archived and the last push was on 2026-08-01, which is the release date of version 3.2. The earlier versions are 3.1 from 2021-11-29 and 3 from 2021-02-11, so the cadence is uneven. The project is licensed under the MIT licence and the README states it is for authorized security testing and educational purposes only.

## Sources

- [ByCh4n/BCHackTool on GitHub](https://github.com/ByCh4n/BCHackTool)
- [License: MIT](https://github.com/ByCh4n/BCHackTool/blob/main/LICENSE)
- [Project website](https://github.com/ByCh4n/BCHackTool)
- [README](https://github.com/ByCh4n/BCHackTool/blob/main/README.md)
- [Releases](https://github.com/ByCh4n/BCHackTool/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bych4n-bchacktool