# domain_hunter_pro: a Burp extension whose real product is the SQLite project file

> domain_hunter_pro is a BurpSuite extension for authorised bug bounty testers that keeps every asset, note and completion flag in a local SQLite project instead of a spreadsheet. Its distinctive part is not collection but arithmetic: collapsing resolved IP addresses into minimal CIDR blocks and deleting anything whose ASN does not belong to the target.

**bit4woo/domain_hunter_pro** — domain_hunter的高级版本，SRC挖洞、HW打点之必备！自动化资产收集；快速Title获取；外部工具联动；等等

- Repository: https://github.com/bit4woo/domain_hunter_pro
- Website: https://www.bilibili.com/video/BV1eA411P7xC/
- Stars: 2,148 · Forks: 206
- Language: Java
- License: not declared
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/bit4woo-domain-hunter-pro

## A Burp extension whose real product is the SQLite project file

domain_hunter_pro is a Java extension for BurpSuite, and the README is explicit that it has to be used with BurpSuite. There is no standalone mode, no CLI and no documented API, so the tool has no meaning on its own. What it actually contributes is a place to keep an engagement. The first thing the quick start does is create a new project, or open an existing one, and a project is a SQLite database file with a .db extension. That single decision is the reason the project exists. The README opens by asking whether you are still managing targets in Excel and still copying and pasting while testing, and the SQLite file is the answer: domains, subdomains, related and similar domains, email addresses, Java package names, web titles, IP addresses, remarks and completion flags all live in rows you own, next to the .db you can copy, back up or open with any SQLite client. Distribution is a jar from the repository's releases, and the only installer script committed at the top level is install_java_utilbox.bat, so the documented path assumes a Windows machine running Java.

## The apex domain is the key, and collection starts from your own browsing

The data model has one organising idea: the apex domain. The README states that the main domain is the core of target management, and that every related domain, subdomain, similar domain, email address and Java package name is derived from it, with baidu.com used as the worked example throughout the screenshots. That is a deliberate scope decision rather than a technical one. Everything the tool collects is filtered through a single root you chose, so an engagement cannot silently accumulate unrelated hosts the way a paste buffer does. The second idea is how data enters. Rather than enumerating a target on its own, the extension reads traffic you generate yourself: you browse through a proxy, the traffic is captured, and the search function then extracts the domains related to your root out of that captured traffic. So subdomain, related domain, similar domain, email and Java package collection are all derived from one browsing session, and the quality of the result is bounded by how thoroughly you actually browsed. Two collection paths do reach outward on their own: a zone transfer check against the authoritative server of the main domain, and support for an IP range or an IP:port pair as the target scope, plus a domain blacklist to keep unwanted hosts out.

## The title pass, dork style search, and a port the README does not explain

The Titles tab is the progress view and the part that talks to the network. Clicking get title issues requests to subdomains, in multiple threads, and collects the web title, the IP address and whether a CDN is in front, then puts the results in columns you can sort, search, annotate, mark for importance and mark as tested. The search there is not only plain text: it supports dork-like queries over the hostname, the port, the IP and the length, so you can slice a large result set without exporting it. Double-clicking a row opens the URL in a browser you choose, and a second double-click action runs a Google search for that domain or host, which is how the tool hands a finding back to a search engine. The progress columns are the honest answer to the spreadsheet problem, since a tester's state lives with the assets instead of beside them. One detail deserves a second look before anyone relies on it. The README describes the title request as going to port 80 or 433, and gives no explanation for that pair. 433 is not the port HTTPS normally uses, and the document never says whether the second value is a deliberate setting, a typo, or a port your own environment has to supply, so the behaviour is worth confirming in the plugin rather than assumed.

## IP aggregation into minimal CIDR blocks, and assets deleted by ASN

The most distinctive part of the project is what it does with the IP column after the title pass. The README collects the resolved addresses and aggregates them into the smallest enclosing networks, and it is careful to say these are not necessarily class C blocks. The worked examples in the README are short: 8.8.8.8 together with 8.8.8.10 reduces to 8.8.8.8/30, while 8.8.8.8 together with 8.8.8.20 reduces to 8.8.8.0/27. That difference is the whole reason to use the tool for the job, since a pair of addresses in the same /24 does not make the rest of the /24 yours, and a scanner that reports whole class C blocks hands you hosts you were never given. Two rules then decide what enters that calculation. A host that is a domain name, but whose ASN does not belong to the target company or organisation, is usually a CDN or a cloud provider such as Tencent Cloud, Huawei Cloud or Cloudflare, so it is excluded from the aggregation and has to be marked by hand with Add Host To Black List. A host that is already an IP address, with an ASN outside the target organisation, is treated as a non-target asset and deleted outright. That second rule is the one to read twice. A legitimate service hosted on a cloud ASN that is not registered to the target is removed from your inventory by the tool, on the basis of registration data rather than of anything you observed, and the only documented remedy is the manual blacklist entry, which is the inverse operation. Any scope you did not write down yourself can be gone before you notice.

## mvn package, a GitHub Packages token and a settings.xml with a typo in its path

The README tells you to build the jar yourself if you want the newest features, and the reason is implied by the release history rather than stated: the newest published release is v2.0 from 2024-06-29, while the code has moved on. If you have already used GitHub Packages, three commands are enough:

```bash
git clone https://github.com/bit4woo/domain_hunter_pro
cd domain_hunter_pro
mvn package
```

The jar appears under domain_hunter_pro/target/. If you have not, the README says to create or modify a Maven settings file, and the path it gives is /Users/xxxxxx/.m2/setttings.xml, with three t's in the filename. That is not a typo in this article, it is how the document is written, and it is worth checking against the file you already have rather than creating a second one that Maven will ignore. The settings file needs a profile pointing at Maven Central and at GitHub Packages, and a server entry carrying your own GitHub credentials, because the build resolves dependencies from a private package registry:

```xml
    <server>
      <id>github</id>
      <username>你的GitHub用户名</username>
      <password>你的GitHub access token 通过https://github.com/settings/tokens获取</password>
    </server>
```

The token is generated from the GitHub settings page the README links. So the cost of running the current source is a GitHub account with package access, a token stored in plaintext in your settings file, and a Maven build, on top of having a BurpSuite installation to load the result into.

## The Tools tab and the right-click menu as the connective tissue

The rest of the extension is glue, and it is where the design shows its working habits. The Tools tab is a utility shelf: open several URLs in a loop in the default or a chosen browser, convert multi-line text into a List or into an array, pull named fields out of a JSON payload, find the lines containing a string, convert between an IP address and a network, and decode HTML or Unicode escapes. These are conveniences rather than features, and the README gives no input validation rules for any of them. The Burp context menu is the part with more weight. From a request in the proxy you can add the selected URL or domain to the target manager, look a URL up and attach a remark to it, set its importance or mark the testing task done, and start a new thread that sends the same request to every target site and parses the responses for what you asked for. That last item is the one to think about before using it on a large list, because it is a mass request loop against every host in the project, and the README documents no rate limiting, no concurrency control and no way to resume partway. The feature list in the README also ends with an ellipsis in both the short and the long version of the same section, which is a fair signal about how complete the written documentation is.

## A push on 2026-09-24, a v2.0 tag from 2024, and no licence at the top level

The maintenance picture has a shape worth noting. The last push to the repository was on 2026-09-24, so the source is being changed, yet the three published releases are v1.9-alpha from 2022-11-18, v1.9 from 2023-04-18 and v2.0 from 2024-06-29. That gap is the reason the README spends a section telling you to package the build yourself, and it means the jar most users install from the releases page is not the code in the repository. Licensing is the more serious silence. No licence is identified for the repository, and the top-level file list holds .github/, .gitignore, Help.assets/, Help.md, README.md, _config.yml, assets/, doc/, img/, install_java_utilbox.bat, pom.xml, resources/ and src/ with no licence file among them. For a project whose main asset is a jar that people add to a security tool, that absence is not a formality: there is no grant text in the repository to point at, and no stated terms for redistribution of the built jar. If you need one, ask the authors or treat the build as private work. The same pass finds the documentation gaps that matter in practice. There is no description of the SQLite schema, so your data is portable as a file but unreadable without reading the source, and no export format, so leaving the tool means going through the database.

## Conclusion

domain_hunter_pro suits a tester who runs one engagement at a time inside Burp and wants scope, notes and progress in a file rather than a spreadsheet, and its per-project .db is the part that keeps working after you stop using the tool. The arithmetic in the title pass is the part worth reading twice, because the ASN rule that deletes an asset whose ASN is not the target organisation will also delete a legitimate host on a cloud provider, and the documented way to keep such a host is the inverse mechanism, a manual blacklist entry. Do not adopt it if your workflow needs a documented schema, an export format or a non-Burp entry point, since the README describes none of the three and the jar is a Burp extension with no standalone mode. Verify first: the port the title pass actually requests, which the README prints as 80 or 433 with no explanation; whether the newest release jar matches the current source, since v2.0 dates from 2024-06-29 while the last push was on 2026-09-24; and the licence, because no licence file sits at the top of the repository.

## FAQ

### Does domain_hunter_pro work outside BurpSuite?

No. The README states that the software is a BurpSuite plugin and has to be used with BurpSuite, and it documents no command line or standalone mode. Installation means loading the jar into Burp.

### How are my targets stored, and can I open them without the tool?

Each project is a SQLite database file with a .db extension, created from the interface or opened again later. The README does not document the schema or an export format, so the file is yours to keep and to query with a SQLite client, but reading it means finding the table definitions yourself.

### How do I build the newest version instead of downloading a release?

Clone the repository and run mvn package, then take the jar from domain_hunter_pro/target/. Resolving the dependencies also needs a GitHub access token in your Maven settings file, because the build uses GitHub Packages.

### How does domain_hunter_pro turn collected IP addresses into network ranges?

It aggregates the addresses from the title pass into the smallest enclosing networks, which the README says are not necessarily class C blocks: 8.8.8.8 and 8.8.8.10 give 8.8.8.8/30, while 8.8.8.8 and 8.8.8.20 give 8.8.8.0/27. Addresses belonging to a CDN or cloud ASN are excluded from that calculation.

## Sources

- [bit4woo/domain_hunter_pro on GitHub](https://github.com/bit4woo/domain_hunter_pro)
- [Issues](https://github.com/bit4woo/domain_hunter_pro/issues)
- [Project website](https://www.bilibili.com/video/BV1eA411P7xC/)
- [README](https://github.com/bit4woo/domain_hunter_pro/blob/master/README.md)
- [Releases](https://github.com/bit4woo/domain_hunter_pro/releases)

---

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