Multi-Fingerprint Aggregation Engines: Survey of fingers, Kscan, Nuclei and 7 Projects

In network security, fingerprinting is the foundational step for asset discovery and attack surface management. However, a single fingerprint library often has limited coverage—Nmap excels at network-layer service detection but falls short on web technology stacks; Wappalyzer is strong at frontend framework detection but cannot sense underlying protocols; WhatWeb identifies CMS accurately but lacks port scanning capabilities. In practice, a single target may involve network devices, web applications, cloud services, and other asset types simultaneously, so relying on just one fingerprint library inevitably leads to significant omissions.

The open-source community has responded with a wave of multi-fingerprint aggregation engines that unify multiple fingerprint sources into a single engine, delivering an “AllInOne” fingerprint identification solution. These projects are concentrated in the Go ecosystem, spanning from lightweight CLI tools to distributed asset management systems. This article conducts an in-depth survey of seven representative projects, comparing them across architecture design, fingerprint library integration depth, performance, and licensing.

Overview of Multi-Fingerprint Aggregation Engines

The core value of multi-fingerprint aggregation engines is solving the inherent problem of “insufficient single-library coverage.” By providing a unified engine layer, they combine multiple previously incompatible fingerprint libraries to achieve complementary identification and result aggregation.

Currently, seven open-source projects can load and combine multiple fingerprint libraries simultaneously. The diagram below shows how they are positioned:

flowchart TD
    A["Full-Stack<br/>fingers"] --- B["Protocol+App<br/>Kscan"]
    A --- C["Modular Combo<br/>xmap"]
    A --- D["Red Team Fast<br/>GoFinger"]
    A --- E["Rust Community<br/>ObserverWard"]
    A --- F["Enterprise System<br/>ARL"]
    A --- G["Template-Driven<br/>Nuclei"]

    style A fill:#9C27B0,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#FF9800,color:#fff
    style E fill:#4CAF50,color:#fff
    style F fill:#2196F3,color:#fff
    style G fill:#FF9800,color:#fff

Note: fingers sits at the center because it is currently the only engine that unifies 7 fingerprint libraries. Other projects have their own focus—Kscan and xmap emphasize dual-stack networking+application coverage, GoFinger targets red-team quick-recon scenarios, ObserverWard is the sole Rust implementation, ARL is positioned as a distributed asset management system, and Nuclei is renowned for its template-driven approach.

chainreactors/fingers — The Most Powerful Aggregation Engine

fingers is one of the core projects from the chainreactors team and currently the most feature-complete multi-fingerprint aggregation engine. Written in Go (98.8% Go), latest version v1.2.1 (2026-06-08), with ongoing commits as of 2026-07-04, the community is very active.

Integrated Fingerprint Libraries (7 total)

fingers’ TODO also includes nuclei technologies, fingerprinthub v4, tidefinger, and kscan as pending integration sources—meaning its aggregation capability is still expanding.

Architecture

fingers’ architecture revolves around the core pipeline of “multi-source input → unified engine → aggregated output”:

flowchart TD
    subgraph SRC["Fingerprint Sources"]
        A1["fingers Native"]
        A2["Wappalyzer"]
        A3["FingerprintHub"]
        A4["EHole / Goby"]
        A5["xray / nmap"]
    end

    subgraph ENGINE["Unified Engine"]
        B1["AC Keyword<br/>Pre-filter"]
        B2["RE2 Regex<br/>Matching"]
        B3["favicon hash<br/>md3/mmh3"]
        B4["TCP + HTTP<br/>Dual Protocol"]
    end

    subgraph OUT["Output Layer"]
        C1["Aggregated Output"]
        C2["CPE Format<br/>URI/FSB/WFN"]
    end

    SRC --> ENGINE --> OUT

    style A1 fill:#9C27B0,color:#fff
    style A2 fill:#4CAF50,color:#fff
    style A3 fill:#FF9800,color:#fff
    style A4 fill:#2196F3,color:#fff
    style A5 fill:#f44336,color:#fff
    style B1 fill:#2196F3,color:#fff
    style B2 fill:#2196F3,color:#fff
    style B3 fill:#2196F3,color:#fff
    style B4 fill:#2196F3,color:#fff
    style C1 fill:#4CAF50,color:#fff
    style C2 fill:#4CAF50,color:#fff

Note: fingers’ architecture has three layers—the source layer collects 7 fingerprint libraries, the engine layer performs matching (AC keyword pre-filtering + RE2 regex engine, introduced in 2026-05), and the output layer aggregates results with CPE (URI/FSB/WFN) format support. This layered design means adding a new fingerprint library only requires an adapter in the source layer—the engine logic stays unchanged.

Key Features

• Automatic result aggregation: Unified output from multiple fingerprint libraries without manual merging
• Blazing performance: <100ms per site, with all fingerprint engines rewritten for optimization
• AC keyword pre-filtering: Introduced in 2026-05, uses Aho-Corasick algorithm for fast pre-filtering, then RE2 for precise matching on the candidate set—drastically reducing regex computation
• favicon hash identification: Supports both md5 and mmh3 hash algorithms
• TCP+HTTP dual protocol identification: Both active TCP probe detection and passive HTTP response analysis
• 404/WAF/CDN/supply chain fingerprints: Covers non-standard fingerprint scenarios
• passive_only build tag: Decouples fingerprinthub from net/http dependencies for passive-only mode

Fingerprint Rule Format

fingers’ native YAML rule format is elegantly designed—a single rule can fully define a fingerprint:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

- name: frame
  default_port:
    - '1111'
  protocol: http
  rule:
    - version: v1.1.1
      regexps:
        regexp:
          - "finger.*test"
        header:
          - string
        body:
          - string
        md5:
          - [md5]
        mmh3:
          - '516963061'
      version:
        - version:(.*)
      level: 1
      send_data: "info\n"
      vuln: frame_unauthorized

Ecosystem Tools

License Risks

⚠️ fingers shows “License: None detected” on pkg.go.dev—it has not declared an explicit open-source license to date. Although the code is publicly accessible, there is legal compliance risk. Before commercial use or derivative development, it is advisable to confirm licensing terms with the chainreactors team.

⚠️ NPSL Concern: fingers’ nmap module directly parses the nmap-service-probes file, which may trigger derivative work clauses under the NPSL (Nmap Public Source License). If you need strict license compliance, disable the nmap fingerprint source via build tags and use only self-developed or non-NPSL fingerprint libraries.

Kscan — Protocol + Application Dual-Layer Fingerprinting

Kscan is a Go-based comprehensive scanner whose core feature is having independent network-layer protocol fingerprints and application-layer web fingerprints in two separate recognition systems.

Dual-Layer Fingerprinting

Key Features

• Accepts multiple input formats (IP, URL, file), auto-detecting URL paths and port protocols
• Port-based asset output with fingerprint and brute-force results
• Supports proxy settings, custom port ranges, multiple output formats
• gonmap available as a standalone library for other projects
• Built-in brute-force capabilities for 10+ protocols

License Note

Kscan uses GPL-3.0 (not MIT), a copyleft license with viral implications. If your project references Kscan’s code, it must be released under a compatible open-source license. Additionally, Kscan’s gonmap module directly parses nmap-service-probes, also facing NPSL compliance concerns.

xmap — Modular gonmap + appfinger

xmap builds on gonmap with architectural optimization, delivering modularized network service fingerprinting combined with web application fingerprinting.

Key Improvements Over gonmap

Module Composition

xmap has a clear positioning—it does not aim for an all-in-one solution but focuses on combining the two most commonly used fingerprint types (“service fingerprint + web fingerprint”) with a permissive MIT license.

GoFinger — Red Team Multi-Source Fingerprint Tool

GoFinger (associated with EHole) is positioned as a red-team asset fingerprint discovery and management tool, featuring 3400+ built-in fingerprint rules at approximately 3 minutes per 1000 URLs.

Key Features

• Multi-dimensional fingerprint integration: Native support for Chainreactors Fingers, Goby, EHole, and Wappalyzer
• Multi-source input: Seamlessly handles single URLs, URL list files, IP ranges, and more
• API integration: Supports linkage with Fofa, Quake, Hunter and other major asset discovery platforms
• Auto-deduplication: Deduplicates sites by IP and response body hash
• Site screenshots: Automatic screenshot capability (requires Chrome)
• Readable output: Presents fingerprint results in an easy-to-read format

GoFinger’s strength lies in its “red-team workflow” orientation—it is not merely a fingerprint engine but fuses fingerprinting with asset discovery APIs and site screenshots into a complete reconnaissance toolkit. Since it depends on fingers as one of its underlying engines, it inherits the same license risks.

ObserverWard / FingerprintHub — Rust Fingerprint Tooling

This pair is the only non-Go project in this survey. It is critical to distinguish the two components:

• FingerprintHub (GitHub): A YAML template fingerprint library maintained by the 0x727 community, containing 6000+ Nuclei-compatible YAML fingerprint rules. It is not a tool itself but a fingerprint rule repository.
• ObserverWard (侦查守卫, GitHub): A Rust-based web application and service fingerprinting tool that consumes FingerprintHub’s YAML templates to perform identification.

Key Features

• All fingerprint rules written in Nuclei-compatible YAML format, interoperable with the Nuclei ecosystem
• Detected technologies cross-referenced against CVE vulnerability databases
• Cross-platform single binary, simple deployment
• Python binding available (pip install observer-ward)
• Already integrated by chainreactors/fingers as one of its fingerprint sources
• spray tool also uses FingerprintHub as a supplementary library

Fingerprint Format

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# FingerprintHub YAML format example (Nuclei compatible)
id: technology-detect
info:
  name: Technology Fingerprint
  author: community
  severity: info
http:
  - method: GET
    path:
      - "{{BaseURL}}"
    matchers:
      - type: word
        part: header
        words:
          - "X-Powered-By: ThinkPHP"

ObserverWard is one of the most active Rust fingerprinting tools available. Its community-driven model and Nuclei-compatible format give it unique advantages in extensibility.

ARL — Asset Reconnaissance Lighthouse

ARL (Asset Reconnaissance Lighthouse) is a distributed asset reconnaissance system that treats fingerprinting as part of a complete asset management framework rather than as a standalone tool.

⚠️ Important: The TophantTechnology/ARL original repository has been deleted and is no longer accessible at the original URL. Several active community forks exist, such as Aabyss-Team/ARL, which largely maintain the original functionality. If you plan to use ARL, obtain it from a community fork.

Key Features

• System integration: Fingerprinting as part of a complete asset management system, not a standalone detection tool
• Asset discovery: Rapidly identify and organize internet-facing assets related to a target
• Multi-component architecture: Web, Worker, and Scheduler distributed components for horizontal scaling
• Fingerprint management: Supports batch import, deduplication, and custom rules
• Advanced features: GitHub keyword monitoring, site change detection
• ARL-Finger-ADD-Pro: Community extension for batch importing ARL 2.6.1 fingerprints with auto-deduplication

ARL’s unique value lies in its system integration capability—if your need extends beyond fingerprinting to building a complete asset reconnaissance management platform, ARL remains the most suitable choice.

Nuclei — Template-Driven Detection Framework

Nuclei is primarily positioned as a vulnerability scanner, but its http/technologies/ directory contains extensive technology fingerprint detection templates, effectively making it a multi-template-source fingerprint engine.

Capabilities as a Fingerprint Engine

Typical Workflow

1
2

# Subdomain discovery → HTTP probing → Fingerprinting → Vulnerability detection
subfinder -d example.com | httpx -silent | nuclei -t http/technologies/ -o fingerprints.txt

Nuclei’s unique value is that it is not a “pure” fingerprinting tool—fingerprint detection is just a small part of its vast template ecosystem. If you already use the ProjectDiscovery toolchain (subfinder, httpx, nuclei), integrating fingerprint detection into your existing pipeline costs zero additional overhead.

Comprehensive Comparison and Architecture Analysis

Panoramic Comparison

Integration Depth Comparison

Architecture Comparison

The architectural differences between the four core projects can be visualized as follows:

flowchart TD
    subgraph F["fingers"]
        F1["fingers Native"]
        F2["Wappalyzer"]
        F3["FingerprintHub"]
        F4["EHole / Goby<br/>xray / nmap"]
        FE["Unified Engine<br/>→ Aggregated → CPE"]
    end

    subgraph K["Kscan"]
        K1["Protocol: gonmap<br/>1200+ protocols"]
        K2["Application: Built-in<br/>20000+ fingerprints"]
        KE["Port→Protocol→App<br/>Correlated Output"]
    end

    subgraph X["xmap"]
        X1["gonmap<br/>Service Fingerprint"]
        X2["appfinger<br/>Web Fingerprint"]
        XE["Singleton Manager<br/>→ Cache Sharing"]
    end

    subgraph O["ObserverWard"]
        O1["FingerprintHub<br/>6000+ YAML Templates"]
        OE["Nuclei Compatible<br/>→ CVE Cross-ref"]
    end

    F1 --> FE
    F2 --> FE
    F3 --> FE
    F4 --> FE
    K1 --> KE
    K2 --> KE
    X1 --> XE
    X2 --> XE
    O1 --> OE

    style F fill:#e8f5e9,color:#333
    style K fill:#e3f2fd,color:#333
    style X fill:#fff3e0,color:#333
    style O fill:#f3e5f5,color:#333
    style FE fill:#9C27B0,color:#fff
    style KE fill:#2196F3,color:#fff
    style XE fill:#FF9800,color:#fff
    style OE fill:#4CAF50,color:#fff

Note: fingers has the most complex architecture—7 fingerprint sources funnel into a rewritten unified engine. Kscan uses a dual-layer architecture where protocol and application fingerprint layers work independently before correlated output. xmap follows a modular approach with two independent modules sharing cache via a singleton manager. ObserverWard is the simplest—a single engine consuming a community-maintained YAML template library.

Performance Characteristics

fingers has a clear performance advantage—its phased matching strategy (AC keyword pre-filtering + RE2 regex) achieves <100ms per site. Kscan’s total time depends on port range since it combines port scanning and brute-force. GoFinger processes approximately 1000 URLs in 3 minutes (~180ms/URL). ObserverWard benefits from Rust’s performance, excelling in high-throughput scenarios.

Selection Guidance and Considerations

Recommendations by Scenario

Selection Decision Tree

flowchart TD
    A["What is your<br/>core need?"] --> B["Need the most comprehensive<br/>multi-library aggregation"]
    A --> C["Need network+application<br/>dual-layer fingerprinting"]
    A --> D["Need a complete<br/>asset management system"]
    A --> E["Already using<br/>ProjectDiscovery toolchain"]

    B --> B1["fingers<br/>7 libraries, best performance"]
    C --> C1["Kscan<br/>1200 protocols 20000+ apps"]
    C --> C2["xmap<br/>gonmap+appfinger, MIT license"]
    D --> D1["ARL<br/>Distributed, community forks"]
    E --> E1["Nuclei + httpx<br/>Zero-cost pipeline integration"]

    style A fill:#9C27B0,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#2196F3,color:#fff
    style E fill:#2196F3,color:#fff
    style B1 fill:#4CAF50,color:#fff
    style C1 fill:#4CAF50,color:#fff
    style C2 fill:#4CAF50,color:#fff
    style D1 fill:#FF9800,color:#fff
    style E1 fill:#4CAF50,color:#fff

Note: Selection should start from actual needs—if maximizing fingerprint library coverage is the goal, fingers is the only choice. If simultaneous port scanning and web fingerprinting are needed, Kscan and xmap each have advantages (Kscan broader coverage, xmap more permissive license). For asset management system considerations, ARL’s distributed architecture is irreplaceable. If already running ProjectDiscovery tools, directly using Nuclei’s http/technologies/ templates is the lowest-cost approach.

Key Considerations

⚠️ License Warning: Although fingers is the most powerful engine, its pkg.go.dev page shows “License: None detected”—verify the license status before use. xmap is MIT licensed; Kscan is GPL-3.0 (not MIT, as incorrectly stated in some sources)—copyleft implications apply.

⚠️ NPSL Concern: fingers and Kscan’s nmap/gonmap modules directly parse nmap-service-probes, which may trigger NPSL derivative work clauses. To fully avoid NPSL concerns, disable nmap fingerprint sources and use only self-developed or non-NPSL libraries.

⚠️ Library Size ≠ Accuracy: A larger fingerprint library does not guarantee higher accuracy. fingers’ core advantage lies in its “one rule, one fingerprint” design philosophy and multi-library aggregation/deduplication capability, not sheer rule count.

⚠️ ARL Repository Deleted: The TophantTechnology/ARL GitHub repository is no longer accessible. Use community forks such as Aabyss-Team/ARL. The Apache-2.0 license declared by the original repository has ambiguous legal status after deletion; community forks mostly use MIT.

Summary

The multi-fingerprint aggregation engine ecosystem presents the following landscape:

• fingers sits at the top as the only engine truly unifying 7 fingerprint libraries with the best performance, but its unclear license is the biggest drawback.
• Kscan and xmap cover protocol+application dual-layer fingerprinting, suitable for scenarios requiring integrated port scanning and web identification.
• ObserverWard is the sole Rust representative, with Nuclei-compatible YAML format delivering excellent extensibility.
• ARL is a system-level asset management platform, but the original repository is deleted—community forks are required.
• Nuclei has expanded from vulnerability scanning into fingerprinting, ideal for teams already using the ProjectDiscovery toolchain.

When selecting, prioritize three things: license compliance (especially NPSL concerns and fingers’ undeclared status), actual coverage needs (whether both network and application layers are required), and ecosystem integration cost (whether related toolchains are already in use). There is no silver bullet—the best engine is the one that fits your specific scenario.

References

26. chainreactors/fingers (GitHub) — Multi-library aggregation engine (7 libraries)
27. lcvvvv/kscan (GitHub) — Comprehensive scanner (protocol+application dual-layer)
28. tongchengbin/xmap (pkg.go.dev) — gonmap + appfinger modular solution
29. tongchengbin/appfinger (pkg.go.dev) — Web application fingerprinting
30. 0x727/FingerprintHub (GitHub) — Community fingerprint library
31. emo-crab/observer_ward (GitHub) — Rust web fingerprint tool
32. EdgeSecurityTeam/EHole (GitHub) — Red team fingerprint tool
33. TophantTechnology/ARL (GitHub) — Asset Reconnaissance Lighthouse (original repo deleted)
34. projectdiscovery/nuclei (GitHub) — Template-driven detection framework
35. projectdiscovery/wappalyzergo (pkg.go.dev) — Wappalyzer Go implementation
36. chainreactors/spray (pkg.go.dev) — HTTP fuzz tool (fingers best practice)
37. chainreactors/morefingers (GitHub) — Fingers extension engine (closed-source)