Why Does TBomb Installation Fail With Python Errors in Kali Linux?

You clone the repo, run the install, and pip throws a wall of red text at you. Nine times out of ten, people assume TBomb itself is broken. It’s not. Your Kali Linux Python setup is the thing causing every single one of those errors, and the fixes are pretty straightforward once you know which error points to which problem.

Your Kali Has Python 3.12, and TBomb Wasn’t Built for It

Kali is a rolling release distro, so it keeps moving forward. Somewhere around late 2024, the default Python jumped to 3.12 and above. TBomb’s requirements.txt file was written with Python 3.9 or 3.10 in mind, and the developer never went back to update it.

So when pip tries to build those older packages under 3.12, things fall apart. You’ll see an error that looks like this:

error: subprocess-exited-with-error
× Getting requirements to build wheel did not run successfully.

How You Fix It

First, check what Python your Kali is actually using:

bash

python3 --version

If that comes back as 3.12 or anything higher, you need to install Python 3.11 alongside it. Don’t replace your system Python, don’t uninstall anything. Kali’s own tools need whatever version it shipped with.

Run these:

bash

sudo apt update
sudo apt install python3.11 python3.11-venv python3.11-dev

Then confirm it’s there:

bash

python3.11 --version

You should see Python 3.11.x in the output. That’s it for now. You’ll use this version through a virtual environment later, not as a system-wide change.

The “No Module Named distutils” Error

This one catches more people than anything else. The error is short and blunt:

ModuleNotFoundError: No module named 'distutils'

Here’s what happened. Python had this module called distutils that a lot of packages used in their build scripts. It was marked as deprecated in Python 3.10, and then Python 3.12 removed it completely. Gone. Several packages that TBomb depends on still reference distutils in their setup files, so they crash the moment pip tries to compile them on 3.12.

How You Fix It

If you really want to stay on Python 3.12 and skip the 3.11 install, upgrading setuptools gives you a partial workaround:

bash

pip install setuptools --upgrade

I say partial because it only covers packages that use distutils indirectly. Anything that does a hard import distutils right at the top of its setup.py will still break before setuptools gets a chance to step in.

The proper fix is just using Python 3.11, where distutils still exists and works normally. If you already installed 3.11 from the step above, this whole problem goes away when you create your virtual environment against that version.

Pip Refuses to Install Anything – “Externally Managed Environment”

This is a newer one that trips up people who haven’t used Kali in a while. You run a pip install command and get:

error: externally-managed-environment
× This environment is externally managed

Kali now enforces something called PEP 668, which basically means the system Python belongs to apt, and pip isn’t allowed to touch it. The system is protecting itself from you accidentally overwriting libraries that Kali’s tools depend on.

You’ll find guides online that say just add --break-system-packages to your pip command. Sure, that removes the error. It also opens the door for pip to install package versions that conflict with what apt put there, and that can break your Kali tools, your desktop, all sorts of things.

How You Fix It

Stop installing into system Python entirely. Create a virtual environment instead. It’s an isolated copy of Python that pip can write to without bothering anything else on your system.

Create one using Python 3.11:

bash

python3.11 -m venv ~/tbomb-env

Activate it:

bash

source ~/tbomb-env/bin/activate

You’ll see (tbomb-env) show up at the start of your terminal prompt. While that’s active, every pip command targets the venv, not the system. PEP 668 doesn’t apply here because this environment is yours, not apt’s.

When you’re done later, just type:

bash

deactivate

Stale Pip Inside the Venv Causes Build Failures

You made your venv, activated it, and pip still throws errors when installing TBomb’s requirements. Something like:

ERROR: Could not build wheels for [package]

or maybe:

pip._vendor.packaging.requirements.InvalidRequirement

The problem is that the pip version that comes bundled inside a new venv is almost always old. Sometimes seriously old. And older pip can’t handle newer wheel formats, messes up dependency resolution, and fails on packages that would install just fine with a current version.

How You Fix It

Right after you activate the venv, before you install anything else, upgrade pip and its related tools:

bash

pip install --upgrade pip setuptools wheel

Check the version:

bash

pip --version

You want to see pip 23.x or higher. Anything below version 22 is going to give you problems with TBomb’s dependency tree.

Complete Install Sequence From a Clean Start

All the individual fixes above fit into one clean sequence. If you’re starting from scratch or want to redo things properly, follow this in order:

bash

# Install Python 3.11
sudo apt update
sudo apt install python3.11 python3.11-venv python3.11-dev -y

# Clone the TBomb repo
git clone https://github.com/TheSpeedX/TBomb.git
cd TBomb

# Create and activate a virtual environment
python3.11 -m venv ~/tbomb-env
source ~/tbomb-env/bin/activate

# Upgrade pip first
pip install --upgrade pip setuptools wheel

# Install TBomb's dependencies
pip install -r requirements.txt

# Run it
python TBomb.py

The order here matters. Skip the pip upgrade and you’ll get build failures. Create the venv against the wrong Python version and you’re back to the distutils problem. Follow it top to bottom and you clear every issue in one pass.

Mechanize Throws a “Cannot Import Mapping” Error

Sometimes the venv install goes smoothly for most packages but mechanize specifically blows up with:

ImportError: cannot import name 'Mapping' from 'collections'

This is a Python version thing again, just a different flavor. Starting with Python 3.10, the Mapping class moved from collections to collections.abc. Older versions of the mechanize package still import it from the old location, so they crash on 3.10 and above.

How You Fix It

Check which mechanize version TBomb is asking for:

bash

grep mechanize requirements.txt

If it’s pinned to anything below 0.4.9, that’s your culprit. The mechanize developers fixed the import in that release. Open the requirements file:

bash

nano requirements.txt

Find the mechanize line and change it to:

mechanize>=0.4.9

Save the file, then run pip again:

bash

pip install -r requirements.txt

If the old version was already installed, force pip to replace it:

bash

pip install --force-reinstall mechanize>=0.4.9

urllib3 and requests Version Conflicts

TBomb pulls in both requests and colorama, and sometimes their sub-dependencies step on each other. Pip’s resolver will either warn you:

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed.

Or you’ll get a harder crash when you actually run the script:

ImportError: cannot import name 'DEFAULT_CIPHERS' from 'urllib3'

That second error means requests pulled in a version of urllib3 that doesn’t match what it expects. Either too new or too old.

How You Fix It

Pin urllib3 to a range that works with the version of requests TBomb uses:

bash

pip install "urllib3>=1.26,<2.0"

Then reinstall requests so it links against the pinned version:

bash

pip install --force-reinstall requests

About those yellow resolver warnings, if the script actually launches and works after you see them, they were cosmetic. Pip is just flagging a potential future conflict, not an actual current failure.

TBomb Starts But Immediately Crashes on Connection Errors

Everything installed, the venv is active, you run python TBomb.py and it throws:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='...') Max retries exceeded

This one has nothing to do with Python or your install. TBomb relies on third-party SMS gateway APIs, and those services go down, rotate their URLs, or start blocking requests all the time. Your setup is fine. The tool’s backend is the problem.

How You Fix It

Make sure it’s not your network first:

bash

curl -I https://api.github.com

If you get a 200 response, your internet and DNS work. The issue is upstream.

Check the TBomb repo’s recent activity:

bash

cd TBomb
git log --oneline -5

If the last commit is several months old and the GitHub issues page is full of reports about dead endpoints, the tool’s API list hasn’t been maintained. A few things you can try:

• Pull the latest changes in case something was pushed recently:

bash

git pull origin master
pip install -r requirements.txt
python TBomb.py

• Look for active forks of TBomb on GitHub that might have updated API endpoints.

Beyond that, dead APIs are the developer’s problem to fix. There’s nothing you can do locally to make a server that shut down start responding again.