Dorks Eye, a Python script that turns search engines into a dork scanner

A single Python file that runs dork queries, nothing more

Dorks Eye is one script, dorks-eye.py, at the root of the repository, with a requirements.txt beside it and no package to install and no server to deploy. The repository listing holds only Img/, LICENSE, README.md, dorks-eye.py and requirements.txt, which tells you the shape of the project before you read a line of it. The author describes it as a script to find Google dorks, collecting pages and applications that search engines have already picked up. It does not scan anything on its own. It queries search engines with dork syntax and reports the links that come back.

That distinction matters for how you should read everything else about the tool. Dorks Eye is a passive collection aid for whatever is already indexed. It finds the pages a search engine knows about, which includes admin login pages, sensitive documents, email lists and other data that was left reachable. It performs no authentication attempts, no exploitation, and no scanning of the target hosts themselves, and the output is just a list of links. The stated audience is people looking for exposed content, and the tool's usefulness to anyone else depends entirely on whether the underlying search index happens to hold what they need.

Version 2.0 exists because Google started blocking automated searches

The reason for the current version is stated in plain terms: Google does not like automated searches anymore and began blocking them more aggressively. The author's answer was to add engines rather than to defeat any specific detection. Dorks Eye v2.0 offers DuckDuckGo, Bing, Google, Brave Search and Yandex, with the Google option marked as often blocked by bot detection. The advice follows from the design: when Google blocks you, switch engines and keep searching.

Each engine brings a different index and a different result set, which is the practical advantage of the multi-engine layout. A dork that returns nothing on one engine can return pages on another, and the script's answer to a failed query is to try a different backend rather than to retry harder against the same one. The author also notes that the name says Google Dorking but dorks work on any search engine. The limits are equally explicit: too many requests in a short time leads to captchas or an IP block, and that is stated as the reason five engines exist. If your plan depends on volume, this script is working against the constraint that limits it.

The four dependencies tell you how the scraping is done

The dependency list in requirements.txt is short enough to be readable at a glance: ddgs, googlesearch-python, requests and beautifulsoup4. Two of those names point directly at search result retrieval, one points at raw HTTP, and one at HTML parsing. ddgs is a DuckDuckGo search library, googlesearch-python is the Python package for Google's own results, requests handles the HTTP traffic, and beautifulsoup4 parses the returned markup so links can be pulled out of it.

The practical consequence is that results come from two different kinds of source. Some engines are queried through a dedicated library, and the rest are reached by requesting result pages over HTTP and parsing them. That mix explains the observed behaviour without needing to guess: a different backend can start returning different markup, or start blocking the request, and there is no fallback path in the script for a page whose structure has changed. Nothing in the repository suggests any caching, retry with backoff, or proxy support, so the script is a straightforward request-and-parse loop. For a researcher who wants reproducibility across a long sweep, that is the part of the design worth checking before a large run.

Installing into a virtual environment on Kali, Parrot or BlackArch

The installation instructions start from a prerequisite the author states for all of the scripts: they should be simple and easy to use for everyone. Dorks Eye is written for Python 3 and is documented as tested on Kali Linux, Parrot Security OS, BlackArch and Termux. Recent changes in Parrot OS and Kali Linux are the stated reason for the virtual environment step, since the system Python can already carry packages that conflict with the dependencies. Clone the repository and enter the directory first:

git clone https://github.com/BullsEye0/dorks-eye.git
cd dorks-eye

Then create the environment and activate it:

python3 -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

And install the four dependencies into it:

pip3 install -r requirements.txt

The isolation advice is sound for these distributions specifically, because a system Python carrying unrelated tooling is the usual source of the dependency conflicts the author hit. Note what is not here: there is no configuration file to edit, no API key to supply, and no account to create. The script is ready to run as soon as the requirements resolve.

Running the script, picking an engine, and saving the links

Starting the tool is a single command:

python3 dorks-eye.py

You are then asked to choose a search engine with a number from 1 to 6, where option 6 searches all engines at once. Results are shown as links only, with no advertisements, and the output can be saved to a file with the number of results chosen by the user. That combination of a numeric menu and a saved output file is what makes the tool usable as part of a wider workflow rather than as a curiosity: you pick a dork, let it sweep several engines, and end up with a text file of links to review by hand.

When you are finished with the environment, it is deactivated with:

deactivate

One caveat about the saved output is worth stating plainly. The links are only what the search engines chose to surface for that query, so a quiet file is not proof that nothing exposed exists. Index coverage varies by engine and by page, and pages behind a login or excluded from indexing are invisible to this approach by construction. Treat the output as a lead list rather than as an inventory.

The Termux path skips the virtual environment

For Android under Termux, the documented procedure is shorter, because a Termux installation is already an isolated Python environment and does not need a nested venv:

git clone https://github.com/BullsEye0/dorks-eye.git
cd dorks-eye
pip install -r requirements.txt

The script is then launched with:

python dorks-eye.py

This is worth knowing for a specific reason rather than as trivia. Running the tool from a phone on a mobile network gives you an IP address and a connection that are not your desk's, which separates the identity doing the searching from the one attached to the office. Anyone running sweeps from a work network should think about the same separation before starting. The tool itself does nothing to manage this; there is no proxy support and no delay configuration, so request pacing and where the traffic comes from are both entirely in the operator's hands.

The dork payloads live in a separate repository

Dorks Eye ships no dork list of its own. The script is paired with a separate repository, google_dork_list, which is described as a collection of 13,760 dorks that work across all search engines and that is updated regularly. Splitting the two has an obvious practical consequence: the script and the payloads version independently, and upgrading the list does not require touching the tool.

The categories of pages the list is meant to surface are listed in the documentation, and they are the reason this kind of tooling exists at all: usernames and passwords, admin login pages, sensitive documents, government or military data, email lists, bank account details and vulnerable websites. Those categories are also the reason responsible use has to be the default rather than an afterthought. Everything Dorks Eye returns is already indexed publicly, but pulling a list of bank details or credential pages into a file and circulating it is a different act from reading a public search result. There is no authorisation prompt in the script and no logging of who searched what, so that judgement sits entirely with the operator.

The licence is AGPL-3.0. That is a meaningful constraint for anyone who plans to modify the script and keep it private, since the copyleft terms attach to derived works, and it also applies if you distribute a modified version. Anyone embedding this into a larger tool should read the licence text before assuming the script can be lifted into a proprietary codebase.

Editorial conclusion

Dorks Eye suits security researchers and OSINT practitioners who want to sweep indexed pages for exposed files and forgotten admin panels, and it suits nobody who needs guaranteed coverage, since results depend on whatever the search engines choose to surface. Before adopting it, check that the dork list you intend to use comes from the separate google_dork_list repository, and run it at a rate your own IP can afford, because the script gives you no proxy rotation and the documentation says too many requests in a short time ends in captchas or IP blocks.

Frequently asked questions

Official sources

1. BullsEye0/dorks-eye on GitHub
2. Issues
3. License: AGPL-3.0
4. README