【Nmap 设备类型识别技术】整体概况

深入解构 Nmap 设备类型识别技术：源码级硬核解析与实战指南

摘要：本文档将以 Nmap 7.98 (DEV) 源码为基准，深入剖析 Nmap 设备类型识别（Device Type Identification）的底层原理。不同于网络上泛泛而谈的教程，本文将深入 C++ 核心引擎，解构OS指纹探测 、服务版本识别 以及MAC厂商查找三大核心支柱的运行机制、数据流转与代码实现。结合实战抓包与源码断点分析，我们将彻底厘清"设备类型"这一字段究竟是如何被填充的。本文适合安全研究员、网络工程师及 C++ 开发者深度阅读。

[深入解构 Nmap 设备类型识别技术：源码级硬核解析与实战指南](#深入解构 Nmap 设备类型识别技术：源码级硬核解析与实战指南)
- 目录
- [1. 前言：设备类型识别的"罗生门"](#1. 前言：设备类型识别的“罗生门”)
- [2. 宏观视角：识别引擎的架构与时序](#2. 宏观视角：识别引擎的架构与时序)
  - [2.1 核心执行时序](#2.1 核心执行时序)
  - [2.2 核心函数调用链](#2.2 核心函数调用链)
- [3. 核心支柱一：OS 指纹识别（TCP/IP 协议栈指纹）](#3. 核心支柱一：OS 指纹识别（TCP/IP 协议栈指纹）)
  - [3.1 技术原理：协议栈的"口音"](#3.1 技术原理：协议栈的“口音”)
  - [3.2 源码深潜：osscan2.cc 的探测艺术](#3.2 源码深潜：osscan2.cc 的探测艺术)
    - [3.2.1 探测序列构建](#3.2.1 探测序列构建)
    - [3.2.2 核心探测包发送](#3.2.2 核心探测包发送)
  - [3.3 指纹生成与匹配：match_fingerprint](#3.3 指纹生成与匹配：match_fingerprint)
- [4. 核心支柱二：服务版本探测（应用层 Banner 匹配）](#4. 核心支柱二：服务版本探测（应用层 Banner 匹配）)
  - [4.1 技术原理：主动握手与正则提取](#4.1 技术原理：主动握手与正则提取)
  - [4.2 源码深潜：service_scan.cc 与正则引擎](#4.2 源码深潜：service_scan.cc 与正则引擎)
  - [4.3 数据提取：getVersionStr 详解](#4.3 数据提取：getVersionStr 详解)
- [5. 核心支柱三：MAC 地址与厂商识别（链路层辅助）](#5. 核心支柱三：MAC 地址与厂商识别（链路层辅助）)
  - [5.1 局限性：二层直连的诅咒](#5.1 局限性：二层直连的诅咒)
  - [5.2 源码流程：从 ARP 到 OUI 查表](#5.2 源码流程：从 ARP 到 OUI 查表)
- [6. 全链路数据流转：从探测到输出](#6. 全链路数据流转：从探测到输出)
- [7. 实战案例：海康威视摄像头跨网段识别](#7. 实战案例：海康威视摄像头跨网段识别)
- [8. 总结与启示](#8. 总结与启示)

1. 前言：设备类型识别的"罗生门"

在使用 Nmap 进行资产测绘时，你是否遇到过这样的困惑：

为什么扫描同一台设备，有时显示 Device Type: webcam，有时却仅显示 OS: Linux？
为什么明明是海康威视的摄像头，厂商字段却显示"Unknown"？
跨网段扫描时，设备类型识别率为何大幅下降？

这些问题的根源在于，"设备类型识别"在 Nmap 中并非单一功能，而是三个独立子系统协同（甚至竞争）工作的结果。这三个子系统分别是：

OS 指纹探测 (-O)：通过 TCP/IP 协议栈实现的差异来推断硬件类型。
服务版本探测 (-sV)：通过应用层服务的 Banner 信息（如 HTTP Server 头）正则匹配出设备类型。
MAC OUI 查询：通过网卡 MAC 地址前缀查询硬件厂商（仅限同网段）。

本文将剥开 UI 的迷雾，直接从 C++ 源码层面揭示这三者的运作机制。

2. 宏观视角：识别引擎的架构与时序

在深入代码细节前，我们需要建立全局视野。Nmap 的执行流并非线性，而是一个分阶段的 pipeline。

2.1 核心执行时序

设备类型识别分散在扫描周期的不同阶段：

主机发现与 MAC 获取（二层） ：
- 在扫描初期 (ultra_scan)，若判定目标在同一网段（二层直连），Nmap 会通过 ARP/ND 协议获取目标 MAC 地址。这是MAC 厂商识别的基础。
端口扫描 ：
- 确定哪些端口开放，哪些端口关闭。这是后续 OS 探测和服务探测的前提。
服务/版本探测 (-sV) ：
- 针对开放端口，建立完整 TCP 连接，发送探针，匹配响应。这是应用层设备类型识别的来源。
操作系统探测 (-O) ：
- 针对开放和关闭端口发送精心构造的 TCP/UDP/ICMP 包，生成指纹。这是协议栈层设备类型识别的来源。
结果输出 ：
- 将上述三个维度的信息整合输出。

2.2 核心函数调用链

渲染错误: Mermaid 渲染失败: Parse error on line 2: ... TD A[nmap_main (nmap.cc)] --> B[nex ----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

3. 核心支柱一：OS 指纹识别（TCP/IP 协议栈指纹）

这是 Nmap 最引以为傲的技术之一，也是设备类型识别最底层的手段。

3.1 技术原理：协议栈的"口音"

RFC 标准虽然规定了 TCP/IP 协议的行为，但不同操作系统内核在实现细节上存在差异。例如：

初始 TTL 值：Linux 通常是 64，Windows 通常是 128。
TCP 窗口大小：不同 OS 在 SYN 包中的默认窗口大小不同。
TCP 选项顺序：MSS、SACK、Timestamp 等选项的排列顺序各异。
ICMP 错误响应：对异常包的回复速率限制和错误码生成机制不同。

Nmap 发送一系列探测包（T1-T7, IE, U1 等），记录目标的响应特征，组合成"指纹"，然后与 nmap-os-db 数据库比对。

3.2 源码深潜：`osscan2.cc` 的探测艺术

OS 探测的核心逻辑在 osscan2.cc 中。

3.2.1 探测序列构建

OSScan::os_scan_ipv4 是 IPv4 OS 探测的入口。它会构建一个探测任务列表 probesToSend。

osscan2.cc 定义了多种探测类型：

cpp 复制代码

// osscan2.h
typedef enum OFProbeType {
  OFP_UNSET,
  OFP_TSEQ,   // TCP 序列预测探测 (发送 6 个 SYN 包)
  OFP_TOPS,   // TCP 选项探测
  OFP_TECN,   // ECN (显式拥塞通知) 探测
  OFP_T1_7,   // T1-T7 探测 (针对开放/关闭端口的不同组合)
  OFP_TICMP,  // ICMP 回显探测
  OFP_TUDP    // UDP 探测 (针对关闭端口)
} OFProbeType;

3.2.2 核心探测包发送

以 TCP 探测为例，send_tcp_probe 函数（osscan2.cc:2385）负责构造并发送裸包。注意它使用的是 rawsd（原始套接字）或 ethsd（以太网帧发送），绕过了操作系统的 TCP 栈，从而实现对 TCP 头部字段的完全控制。

cpp 复制代码

// osscan2.cc
int HostOsScan::send_tcp_probe(HostOsScanStats *hss, int ttl, bool df, ...) {
    // ... 构造 IP 头 ...
    // ... 构造 TCP 头，允许自定义 Flags, Window, Options ...
    // ... 发送 ...
}

Nmap 会发送特定的 TCP 选项组合。例如 prbOpts 数组定义了不同探测包使用的 Option 模板：

cpp 复制代码

// osscan2.cc:103
static struct {
  u8* val; int len;
} prbOpts[] = {
  {(u8*) "\x03\x03\x0A\x01\x02\x04\x05\xb4\x08\x0A\xff\xff\xff\xff\x00\x00\x00\x00\x04\x02", 20},
  // ...
};

这些看起来像乱码的字节流，实际上精心设计的 TCP Option 组合（Window Scale, MSS, Timestamp, SACK 等），用于诱发目标 OS 暴露出特定的处理逻辑。

3.3 指纹生成与匹配：`match_fingerprint`

当收集到足够的响应后，HostOsScan::makeFP 会组装指纹。生成的指纹是一个 ASCII 字符串，包含 SEQ, OPS, WIN, T1... 等多个测试项。

指纹示例（简化版）：

text 复制代码

SCAN(V=7.98%E=4%D=...)
SEQ(SP=...%GCD=...%ISR=...)
OPS(O1=...%O2=...)
WIN(W1=...%W2=...)
...

最后，调用 match_fingerprint (osscan.cc:527) 将生成的指纹与 nmap-os-db 进行比对。

关键点 ：nmap-os-db 中的每一条指纹都有 Class 行，定义了设备类型：

text 复制代码

Fingerprint Linux 3.10 - 4.11
Class Linux | Linux | 3.X | webcam
Class Linux | Linux | 4.X | webcam
...

如果匹配成功，Nmap 就会从 Class 行中提取 webcam 赋值给 OS_Classification.Device_Type。

这就是通过 OS 探测识别出"设备类型"的原理：它本质上是根据 TCP/IP 行为推断出内核版本，再查表得知该内核常用于哪种设备。

这是另一种完全不同的识别思路。它不关心底层协议栈，而是直接"问"服务：你是谁？

4.1 技术原理：主动握手与正则提取

Nmap 的 -sV 选项会尝试与开放端口建立连接，并发送一系列探针（Probes）。探针可能是一个简单的 GET / HTTP/1.0，也可能是特定的 RTSP 请求或 SIP 请求。

目标服务收到探针后返回响应（Banner）。Nmap 使用 nmap-service-probes 文件中的正则表达式库对响应进行匹配。

4.2 源码深潜：`service_scan.cc` 与正则引擎

服务探测的主逻辑在 service_scan 函数中。

加载规则 ：AllProbes::service_scan_init 加载 nmap-service-probes。
执行探测 ：launchSomeServiceProbes 调度 nsock 库进行异步 I/O。
正则匹配 ：当收到数据时，调用 ServiceProbeMatch::testMatch (service_scan.cc:532)。

cpp 复制代码

// service_scan.cc:532
const struct MatchDetails *ServiceProbeMatch::testMatch(const u8 *buf, int buflen) {
    // ...
    // 调用 PCRE2 执行正则匹配
    rc = pcre2_match(regex_compiled, (PCRE2_SPTR8)bufc, buflen, ...);
    
    if (rc >= 0) {
        // 匹配成功，提取信息
        getVersionStr(..., devicetype, ...);
    }
    // ...
}

4.3 数据提取：`getVersionStr` 详解

这是服务探测识别设备类型的核心。nmap-service-probes 文件中的规则通常包含 d// 模板，用于指示如何从正则捕获组中提取设备类型。

例如海康威视的 RTSP 规则（伪代码）：

text 复制代码

match rtsp m|^RTSP/1\.0 200 OK\r\n.*Server: Hikvision| d/webcam/ p/Hikvision RTSP server/

m|...|：正则表达式。
d/webcam/：如果匹配成功，将设备类型设置为 webcam。

源码实现见 ServiceProbeMatch::getVersionStr (service_scan.cc:974)：

cpp 复制代码

// service_scan.cc:974
int ServiceProbeMatch::getVersionStr(..., char *devicetype, ...) const {
    // ...
    // 如果规则定义了 devicetype 模板 (例如 d/webcam/)
    if (devicetypelen > 0) *devicetype = '\0';
    
    // 执行模板替换
    if (devicetype_template) {
         rc = dotmplsubst(subject, ..., devicetype_template, devicetype, ...);
    }
    // ...
}

总结：服务探测的设备类型识别，完全依赖于规则库的质量 和目标服务的诚实度。如果服务 Banner 被修改或隐藏，这种方法就会失效。

5. 核心支柱三：MAC 地址与厂商识别（链路层辅助）

这是最直观但局限性最大的方法。

5.1 局限性：二层直连的诅咒

MAC 地址是链路层概念。在跨越路由器（三层转发）访问目标时，源 IP 看到的 MAC 地址是网关的 MAC 地址，而不是目标的真实 MAC。

因此，Nmap 只有在判断目标与扫描机处于同一网段（直接连接）时，才会尝试获取并解析目标 MAC。

5.2 源码流程：从 ARP 到 OUI 查表

判断直连 ：
Target::directlyConnected() (Target.h) 用于判断目标是否直连。这通常基于 IP 子网掩码计算，并结合 ARP 探测结果。
获取 MAC ：

在 targets.cc 的 refresh_hostbatch 中，如果是直连，Nmap 会通过 ARP 请求获取目标 MAC，并调用 Target::setMACAddress (Target.cc:457) 存储。

厂商查询 ：

在输出阶段，调用 MACPrefix2Corp (MACLookup.cc)。

cpp 复制代码

// MACLookup.cc
const char *MACPrefix2Corp(const u8 *prefix) {
    // 查找 24位 (OUI), 28位, 36位 前缀
    // 数据来源于 nmap-mac-prefixes 文件
}

注意：MAC 厂商识别仅提供厂商名称（如 "Hangzhou Hikvision Digital Technology"），它不会直接填充 Device Type 字段（如 "webcam"），但它为用户判断设备类型提供了强有力的辅助信息。

6. 全链路数据流转：从探测到输出

让我们把三个支柱串联起来，看看最终的 Device Type 是如何确定的。

Nmap 的 Target 类 (Target.h) 是核心数据容器：

Target::FPR：存储 OS 探测结果（包含 OS_Classification -> Device_Type）。
Target::ports：存储端口和服务探测结果（包含 ServiceNFO -> devicetype）。
Target::MACaddress：存储 MAC 地址。

冲突与融合 ：

有趣的是，Nmap 并不强行融合这三种来源的设备类型。它们在输出中是独立展示的：

MAC 行：

text 复制代码

MAC Address: 10:12:48:XX:XX:XX (Hangzhou Hikvision Digital Technology)

（来源：MAC 支柱）

端口服务行：
text 复制代码
```
80/tcp open http Hikvision IP Camera httpd
Service Info: Device: webcam
```
（来源：服务探测支柱，Device: webcam 来自 d/webcam/）
OS 探测行：
text 复制代码
```
Running: Linux 3.X
OS details: Linux 3.10 - 4.11
```
（来源：OS 探测支柱。虽然 XML 输出中会有 osclass type="webcam"，但在默认文本输出中，这里主要显示 OS 家族。需配合 -v 或 XML 查看 OS 判定的设备类型）

7. 实战案例：海康威视摄像头跨网段识别

假设我们扫描一台位于另一网段（192.168.2.64）的海康摄像头。

场景特征：

跨网段 -> MAC 识别失效（无法获取真实 MAC）。
开放端口 -> 80 (HTTP), 554 (RTSP)。

Nmap 内部视角：

MAC 阶段 ：Target::directlyConnected() 返回 false。跳过 ARP。Target::MACaddress 为空。
服务探测阶段 (-sV) ：
- Nmap 连接 554 端口。
- 发送 RTSP 探针。
- 收到 Banner: RTSP/1.0 200 OK ... Server: Hikvision Streaming Media Server。
- ServiceProbeMatch 命中规则，提取 devicetype = "webcam"。
OS 探测阶段 (-O) ：
- 发送 T1-T7 等包。
- 收到 TTL=64, Window=5792 等特征。
- match_fingerprint 命中 Linux 3.10 指纹，其 Class 定义为 webcam。
输出阶段 ：
- 因为无 MAC，不显示 MAC 行。
- 服务行显示 Service Info: Device: webcam。
- OS 行显示 Running: Linux 3.X。

结论：在跨网段场景下，**服务版本探测（-sV）和OS 指纹探测（-O）**成为了识别设备类型的唯二手段。如果防火墙屏蔽了 OS 探测包（如 ICMP/UDP），或者服务 Banner 被修改，识别就会失败。

8. 总结与启示

通过源码分析，我们得出以下结论：

没有魔法 ：Nmap 的"智能"识别完全建立在硬编码的规则库（nmap-os-db, nmap-service-probes）和严格的协议匹配逻辑之上。
多维验证：设备类型识别是三个维度的拼图。MAC 提供厂商线索，服务 Banner 提供应用层自述，OS 指纹提供底层内核特征。
源码即真理 ：当扫描结果令人困惑时，查看源码中的 match_fingerprint 或 ServiceProbeMatch::testMatch 逻辑，结合抓包数据，是排查问题的终极手段。

对于开发者而言，理解这些机制有助于编写更精准的扫描工具；对于运维人员，这有助于理解为什么某些设备会被 Nmap "误判"，以及如何通过修改 Banner 或防火墙规则来防御扫描。

本文基于 Nmap 7.98 (DEV) 源码分析，部分逻辑可能随版本迭代而变化。

【Nmap 设备类型识别技术】整体概况

深入解构 Nmap 设备类型识别技术：源码级硬核解析与实战指南

目录

1. 前言：设备类型识别的"罗生门"

2. 宏观视角：识别引擎的架构与时序

2.1 核心执行时序

2.2 核心函数调用链

3. 核心支柱一：OS 指纹识别（TCP/IP 协议栈指纹）

3.1 技术原理：协议栈的"口音"

3.2 源码深潜：osscan2.cc 的探测艺术

3.2.1 探测序列构建

3.2.2 核心探测包发送

3.3 指纹生成与匹配：match_fingerprint

4. 核心支柱二：服务版本探测（应用层 Banner 匹配）

4.1 技术原理：主动握手与正则提取

4.2 源码深潜：service_scan.cc 与正则引擎

4.3 数据提取：getVersionStr 详解

5. 核心支柱三：MAC 地址与厂商识别（链路层辅助）

5.1 局限性：二层直连的诅咒

5.2 源码流程：从 ARP 到 OUI 查表

6. 全链路数据流转：从探测到输出

7. 实战案例：海康威视摄像头跨网段识别

8. 总结与启示

3.2 源码深潜：`osscan2.cc` 的探测艺术

3.3 指纹生成与匹配：`match_fingerprint`

4.2 源码深潜：`service_scan.cc` 与正则引擎

4.3 数据提取：`getVersionStr` 详解