X-osint: one sudo script, seventeen menu lookups, four API keys

chmod +x * and sudo bash setup.sh are the whole install

The documented install is seven lines, and on Linux every one of them runs with root:

sudo apt install python3-pip -y
cd $HOME
git clone https://github.com/TermuxHackz/X-osint
cd X-osint
chmod +x *
sudo bash setup.sh
sudo xosint OR python xosint

The Termux version is the same sequence with sudo dropped and apt replaced by pkg. That glob in the fourth line has no file type, so requirements.txt, vins.txt, google_Dorks.txt and subdomains.txt all become executable alongside setup.sh, and the one file that does the real work is the one the page never prints.

The update instructions say where the result lands. For Termux you delete the copy in $PREFIX/bin, for Linux you delete the copy in /usr/local/bin, then you re-clone and run setup.sh again. An install you have to remove from outside the clone directory wrote itself there.

Four install paths, and the macOS one never installs a dependency

Four routes reach the same menu, and each one costs something. The plain path leans entirely on setup.sh for its dependencies, because `pip install -r requirements.txt` appears only in the virtual environment route:

sudo apt install python3-pip python3-venv -y
cd $HOME
git clone https://github.com/TermuxHackz/X-osint
cd X-osint
chmod +x *.sh
python3 -m venv X-osint_venv
source X-osint_venv/bin/activate
pip install -r requirements.txt
sudo bash setup.sh
sudo xosint OR python xosint

The macOS section is the odd one out. It gives `python3 -m venv venv`, `source venv/bin/activate` and `deactivate` with no install step and no setup.sh line, so nothing in that section puts the nineteen packages from requirements.txt into the environment. The block right below it starts from a directory called X-osint-fork and activates X-osint_venv, the name the Linux route creates and the Mac instructions never do.

The optional block at the end goes the other way and deletes the clone: `sudo cp -r xosint /usr/local/bin`, `sudo chmod u+x xosint`, then `sudo rm -rf X-osint`.

The usage paragraph and the feature list number different things

The usage text teaches the menu with three examples: type 1 for IP Address Info, 2 for Email Address Info, and 15 for SMTP Analysis, then 00 to quit. The feature list disagrees on the third. Its fifteenth entry is Check Global InfoStealer Attack, and SMTP appears nowhere among the seventeen items, so the paragraph either names a slot from an older build or points at an entry the list forgot.

One numbering reference does hold up. The API key section says a Shodan key is needed for numbers 4 through 9, and those map cleanly onto Host finding, Ports finding, Subdomain Enumeration, CVE Exploits Finder, Email Finder and Exploit Open Source Vulnerability Database.

That range is also the honest description of what the tool is for. Those six entries touch machines that are not yours: they resolve hosts, open ports, walk subdomains, look up CVEs and query a database of open source vulnerabilities. Nothing in the file narrows them to a domain you own, checks permission, offers a dry run or provides an abort key, and the update option sits on the same menu.

Four API keys decide what the menu can return at all

A Shodan key from shodan.io covers options 4 to 9. Hunter is listed next. Opencagedata is called out, in capitals, as required for the phone number lookup, described as geolocation of numbers. A Google Custom Search key from cse.google.com is named last, for image work, and that sentence stops at the fragment for the Imag, so the rest of its scope is not in the file. Four menu entries therefore sit at an input prompt with nothing behind them unless you hold a key, and the page offers no local fallback for any of them.

What the page does not say is what any of those four services charges, or what their terms of use are. What ships alongside the code is a disclaimer.html file at the repository root and a bugs_report folder, so the legal side of running lookups against other people is addressed somewhere other than the install page.

The subdomain menu points at a word list the repository already commits

The subdomain entry carries its own notice. If the feature asks for a word list, the page sends you to a MediaFire link, tells you to extract the zip and to remember where you kept it before running the lookup.

That sits oddly beside the repository contents, because subdomains.txt is committed at the root next to vins.txt and google_Dorks.txt. None of those three is explained anywhere. vins.txt lines up with item 12, the VIN extractor named in the project's own description, and google_Dorks.txt has no matching entry among the seventeen menu items at all. Whether the committed list is the one the feature wants is not something the page answers, and the MediaFire copy is a zip you have to unpack before you can point anything at it.

requirements.txt holds nineteen packages and no DNS resolver

requirements.txt pins no versions. The OSINT core is visible in it: beautifulsoup4, requests, googlesearch-python, google-api-python-client, phonenumbers, opencage and distro. Image work accounts for Pillow and piexif, which serve items 3 and 16 on location and file metadata extraction. qrcode, prompt_toolkit and colorama belong to the terminal front end. Three packages belong to something else entirely: stripe, a payments library, speedtest-cli, a bandwidth meter, and Flask, a web server.

There is also no DNS resolver in that list, although item 10 is DNS Lookup and item 11 is DNS Reverse, which leaves both dependent on something the requirements file does not name. The project runs DeepSource, and its .deepsource.toml and bugs_report folder sit at the root next to the requirements file.

Menu option 99 replaces the install from a process holding root

Version 2.2 exists in the page but not in the project's release history, which has no GitHub releases at all. The Bugs Report section says version 2.2 has been through a DeepSource analysis scan and comes out free from bugs so far in version 2.2, then asks anyone on 2.1 to update. The last push on record is 2026-07-12.

The automatic update runs from inside the tool: start xosint, type 99, then pick termux or linux. On Linux the documented launch is `sudo chmod +x /usr/local/bin/xosint` followed by `sudo xosint`, so the process doing the updating is the one holding root, and it swaps the file in /usr/local/bin while running. The same page opens with a promotion block for four Discord bots, three of them about AirPods firmware, Apple support and Apple news rather than OSINT.

The partnership route runs a script this repository does not contain

The partnership section points at Alfredredbird/tookie-osint and says new features would continue to roll over from it. There are two ways in. From the menu, the NEXT tools entry offers tookie-osint and installs it. From the page, you run a script by name: `python.exe brib.py` on Windows, `python3 brib.py` on Linux and Mac.

That script is not among this repository's entries, which are .deepsource.toml, .github, .gitignore, Demo, Icons, LICENSE, README.md, bugs_report, disclaimer.html, google_Dorks.txt, images, requirements.txt, setup.sh, static, subdomains.txt, templates, vins.txt and xosint. The page asks you to run a script whose source you have not seen, pulled in through a repository the maintainer partnered with, using the tool that fetched it. Option 99 has the same shape, except there the replacement code arrives over the network from the running program and no signature step appears in the file.

Editorial conclusion

X-osint is a reasonable pick for someone already working in a Termux or Linux terminal who wants phone, email and IP lookups alongside subdomain enumeration in a single menu, on condition that you read setup.sh before running it under sudo and hold your own API keys. It fits poorly any investigation you are not authorized to run: items 4 through 9 resolve hosts, open ports and query vulnerability databases with no scope check, no dry run and no abort key, on the same menu that carries the self-update option. Check two things before you rely on it: what setup.sh writes outside the clone directory, since updating means deleting from $PREFIX/bin or /usr/local/bin, and which subdomain word list the feature actually reads, the committed subdomains.txt or the MediaFire archive.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. TermuxHackz/X-osint on GitHub