shadow1ng/fscan · error

ms17010_read_pipe_error: %w

Error message

ms17010_read_pipe_error: %w

What it means

The Trans named-pipe request was sent but the read of the response failed outright. This variant wraps the underlying read error (%w), as opposed to the incomplete-response sibling, and means the vulnerability-detection reply (which should echo status 0x05 0x02 0x00 0xc0 = STATUS_INSUFF_SERVER_RESOURCES on vulnerable hosts) never arrived.

Source

Thrown at plugins/services/ms17010.go:383

		return false, osVersion, false, fmt.Errorf("%s", i18n.GetText("ms17010_tree_response_incomplete"))
	}

	// 命名管道请求
	treeID := reply[28:30]
	transNamedPipe := append([]byte(nil), transNamedPipeRequest...)
	transNamedPipe[28] = treeID[0]
	transNamedPipe[29] = treeID[1]
	transNamedPipe[32] = userID[0]
	transNamedPipe[33] = userID[1]

	if _, err = conn.Write(transNamedPipe); err != nil {
		return false, osVersion, false, fmt.Errorf("%s: %w", i18n.GetText("ms17010_send_pipe_error"), err)
	}

	n, readErr = conn.Read(reply)
	if readErr != nil || n < 36 {
		if readErr != nil {
			return false, osVersion, false, fmt.Errorf("%s: %w", i18n.GetText("ms17010_read_pipe_error"), readErr)
		}
		return false, osVersion, false, fmt.Errorf("%s", i18n.GetText("ms17010_pipe_response_incomplete"))
	}

	// 漏洞检测 - 关键检查点
	if reply[9] == 0x05 && reply[10] == 0x02 && reply[11] == 0x00 && reply[12] == 0xc0 {
		trans2SessionSetup := append([]byte(nil), trans2SessionSetupRequest...)
		trans2SessionSetup[28] = treeID[0]
		trans2SessionSetup[29] = treeID[1]
		trans2SessionSetup[32] = userID[0]
		trans2SessionSetup[33] = userID[1]

		if _, err = conn.Write(trans2SessionSetup); err != nil {
			return true, osVersion, false, nil
		}
		n, readErr = conn.Read(reply)
		if readErr != nil || n < 36 {
			return true, osVersion, false, nil

View on GitHub (pinned to 95cc12e753)

Solutions

1. Raise the read deadline and retry — vulnerable hosts that crash-and-reset the connection should be re-probed and cross-checked, since a reset on this exact request is a strong vulnerability indicator.
2. Unwrap the cause: ECONNRESET here, on an unpatched legacy host, often means the srvsvc handling crashed — verify manually with `nmap --script smb-vuln-ms17-010`.
3. Exclude IPS interference by scanning from a allow-listed host.
4. If the host never answers the pipe probe, mark inconclusive and verify patch level (KB4013389 and later) via other means.

conn.SetReadDeadline(time.Now().Add(readTimeout))
// buffer big enough: reply := make([]byte, 1024)
if n, err := conn.Read(reply); err != nil { /* retry; note ECONNRESET here may indicate vulnerability */ }

n, readErr := conn.Read(reply)
if readErr != nil {
    if errors.Is(readErr, syscall.ECONNRESET) {
        // srvsvc handler may have crashed — strong MS17-10 hint; flag for manual check
    }
    return fmt.Errorf("pipe probe read failed: %w", readErr)
}

When it happens

Trigger: checkMS17010VulnerabilityAt returns this when conn.Read(reply) after the transNamedPipe write returns a non-nil readErr.

Common situations: Read deadline expires because the server throttles or drops srvsvc Trans requests; IPS resets the flow on the exploit-shaped probe; server crashes processing the malformed-for-old-patches request (which itself is a vuln hint); packet loss.

Related errors

• ms17010_send_pipe_error: %w
• ms17010_smbv1_unsupported
• ms17010_send_session_error: %w
• ms17010_session_failed
• ms17010_send_tree_error: %w

AI-assisted analysis of shadow1ng/fscan@95cc12e753 (2026-09-06). Data as JSON: /api/errors/46e8a541e5f017c8. Report an issue: GitHub.