构建

你可以选择一次性编译该工具然后使用生成的二进制文件，或者像运行脚本一样直接运行它（Go 工具链会在运行时编译）。 对于开发，后一种方式更便捷。 对于生产使用，建议一次性编译（从 cli 目录执行）并使用生成的可执行文件。 得益于 Go 编译器，你可以从 Linux 或 Windows 构建，并针对 Linux 或 Windows 构建。 构建需要 Go 至少 1.18 版本（已用 Go 1.23 测试）。

从 Linux 构建

要从 Linux 为 Windows 或 Linux 构建，只需适当设置 GOOS（从 cli 目录执行）：``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

抱歉，我无法处理这个请求，因为提供的输入内容为空。请提供需要翻译的 Markdown 文本。```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

从Windows构建

要从Windows构建，请执行相应的命令，例如从PowerShell：``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

<!-- 无输入内容，返回空字符串 -->```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

用法

wcfproxy 的配置通过 JSON 文件提供。 默认情况下，使用配置文件 config.json，但可以通过 -config 参数指定配置文件的路径。 配置文件旨在包含任意多个命名的配置，例如：```json { "my-config": { " ... ": " ... " } }

命名配置对象的值应与 `Config` 结构体匹配（参见 [Config structure](#config-structure)）。
这个包含注释的源文件同时也是 `wcfproxy` 配置选项的最准确文档。
在所有提供的配置中，要使用的配置通过 `-enable` 命令行选项按名称指定：```
wcfproxy.exe -config config.json -enable my-config

配置结构

每个配置对象的顶层结构如下：```json { "listen": "[::1]:8000", "connect": "[::1]:9000", "retarget": "net.tcp://127.0.0.1:8000/WCFLab/WCFDemoService/nettcp", "retarget-map": { "nettcps": "net.tcp://localhost:8210/WCFLab/WCFDemoService/nettcps", "winauth": "net.tcp://localhost:8220/WCFLab/WCFDemoService/nettcp-winauth" }, "log-level": "debug|info|warn|error", "log-file": "path/to/log/file", "tls-server": { " ... ": " ... " }, "tls-client": { " ... ": " ... " }, "ntlm": { " ... ": " ... " }, "interceptor": { " ... ": " ... " }, "ctrl": { " ... ": " ... " } }

请注意，如果存在 NTLM 配置，则不能提供 TLS 配置（`tls-server` 和/或 `tls-client`）。

### 配置选项
+ `listen` - *wcfproxy* 应监听的 TCP 端点，例如 `127.0.0.1:8000` 或 `[::1]:8000`
+ `connect` - 上游 WCF 服务器的 TCP 端点，例如 `127.0.0.1:9000` 或 `[::1]:9000`
+ `retarget` - 原始目标规范（以及 `retarget-map` 的回退）；有关说明请参见 [Target rewriting](#target-rewriting)
+ `retarget-map` - `retarget` 的泛化；允许对多个端点执行目标重写（仅当在同一端口上使用多个 WCF 服务时有用）
    + 如果 `retarget-map` 中的某个键与当前目标匹配，则目标 URI 将替换为给定的值用于上游通信
    + 如果 `retarget-map` 中没有键与当前目标匹配，则使用 `retarget` 替代
+ `log-level` - 日志级别；可用值：`debug`、`info`（默认）、`warn`、`error`
+ `log-file` - 日志文件路径；如果未提供路径，则日志写入 `stdout`
+ `tls-server` - `TlsServerConfig` 的实例（参见 [TLS server configuration](#tls-server-configuration)）；仅当需要支持 TLS 升级时才需要
+ `tls-client` - `TlsClientConfig` 的实例（参见 [TLS client configuration](#tls-client-configuration)）；仅当需要支持 TLS 升级时才相关
+ `ntlm` - `NtlmConfig` 的实例（参见 [NTLM configuration](#ntlm-configuration)）；仅当需要支持 NTLM 升级（直接或通过 SPNEGO）时才需要
+ `interceptor` - `InterceptorConfig` 的实例（参见 [Interceptor Configuration](#interceptor-configuration)）；必需的
+ `ctrl` - `ControlServerConfig` 的实例（参见 [Control Server Configuration](#control-server-configuration)），它可以提供一个默认的 HTTP 回显服务器（与 HTTP 拦截器一起使用很有用）以及一个用于控制消息流的小型 API（仍在开发中）

### TLS 服务器配置
TLS 服务器端配置提供对大多数典型相关 TLS 服务器设置的控制。
其结构如下：```json
{
	"cert-pem": "path/to/certificate",
	"cert-key": "path/to/certificate-key",
	"max-version": "1.0|1.1|1.2|1.3",
	"min-version": "1.0|1.1|1.2|1.3",
	"client-roots": "path/to/client-ca1,path/to/client-ca2",
	"client-auth": "none|request|require-any|verify-if-given|require-and-verify",
	"keylog": "path/to/keylog-file"
}

TLS服务器配置选项

• cert-pem - X.509证书的路径（PEM格式）
• cert-key - 证书对应密钥的路径
• max-version - 可接受的最大TLS版本；可以是 1.0、1.1、1.2、1.3（默认）
• min-version - 可接受的最小TLS版本；可以是 1.0（默认）、1.1、1.2、1.3
• client-roots - 逗号分隔的可接受客户端认证根证书（PEM）路径列表；可选
• client-auth - 客户端认证策略；最常用的值：none（默认）、require-and-verify
• keylog - 用于以NNS格式写入TLS密钥的文件

TLS客户端配置

TLS客户端配置提供了对最典型的TLS客户端设置的控制。 它具有以下结构：```json { "cert-pem": "path/to/certificate", "cert-key": "path/to/certificate-key", "max-version": "1.0|1.1|1.2|1.3", "min-version": "1.0|1.1|1.2|1.3", "roots": "path/to/root-ca1,path/to/root-ca2", "server-name": "therealone.local", "skip-verify": false }

#### TLS 客户端配置选项
+ 类似于 [TLS 服务器配置选项](#tls-server-configuration-options)
+ `roots` - 指向根CA（PEM）路径的逗号分隔列表的路径；使用 `skip-verify` 时可选的
+ `server-name` - 服务器名称（SNI）；可选
+ `skip-verify` - 布尔值；客户端是否应放弃验证服务器证书（默认：`false`）


### NTLM 配置
NTLM 配置指定了域名、服务器名称以及用户凭据。
对于每个应能够通过代理进行身份验证的用户，必须提供有效的凭据。```json
{
	"domain": "test.local",
	"server": "server.local",
	"credentials": [
		{ 
            " ... ": " ... "
        }
	]
}

NTLM 配置选项

• domain - 要认证的域，例如 test.local；如果留空，将使用服务器名称
• server - 要认证的服务器名称；如果留空，将使用当前系统的主机名
• credentials - NtlmCredential 对象数组（见下文）

NTLM 凭据作为 NtlmCredential 对象数组传递，这些对象具有以下结构：```json { "name": "wcflab", "password": "Sup3rS3cr3t", "nt-hash": "a8fc07dede90b0ec10bc1ef355f99292", "lm-hash": "3e9cb63e11a812cbc467021088dc706f" }

+ `name` - 用户名
+ `password` - 用户的密码；将从中派生哈希值；覆盖用户已有的哈希值
+ `nt-hash` - 用户密码的 NT 哈希（十六进制）；密码的替代方案
+ `lm-hash` - 用户密码的 LM 哈希（十六进制）；密码的替代方案；大多数情况下不需要

如果提供了密码，则会从中计算出 LM 哈希（并非所有密码都能计算）和 NT 哈希。
该用户已有的任何哈希值将被计算出的哈希值覆盖。
也可以只提供用户的哈希值。
在大多数场景下，不应要求提供 LM 哈希。

### 拦截器配置
拦截器配置指定应使用的拦截器（按名称），并可选择指定拦截器特定的参数。
有关拦截器的说明，请参阅[拦截器](#interceptors)。

#### 日志拦截器
要使用日志拦截器，只需使用以下拦截器配置即可。
输出将写入主日志位置，该位置可能是文件或 `stdout`，具体取决于 `log-file` 配置。```json
{
	"name": "log"
}

HTTP 拦截器

要使用 HTTP 拦截器，请使用以下拦截器配置，并为 server-url 和 proxy-url 设置合适的选项。```json { "name": "http", "args": { "server-url": "http://127.0.0.1:9999/echo", "proxy-url": "http://127.0.0.1:8080" } }

+ `args.server-url` - 你的HTTP服务器拦截端点的URL（例如一个简单的回显端点）；关于HTTP拦截器如何工作的详细信息，请参见 [HTTP拦截器](#http-interceptor-1)
+ `args.proxy-url` - HTTP代理的URL；可选项

### 控制服务器配置
*wcfproxy* 附带了一个内置的Web服务器，它提供两个功能。
首先，它可以提供一个HTTP端点，简单地反射所有发送给它的内容。
这与[HTTP拦截器](#http-interceptor-1)结合使用时非常有用。```json
{
	"ctrl": {
		"listen": "127.0.0.1:9999",
		"enable-control": false,
		"enable-echo": true
	}
}

[!WARNING]
任何能够访问API的人都可以使用提供的凭据（NTLM或TLS客户端证书）进行身份验证。在共享系统上，即使API仅在本地可用，这也可能具有相关性。

控制服务器配置选项

• listen - 控制服务器应监听的TCP端点
• enable-contorl - 启用控制功能，如消息注入或连接建立（参见消息注入）
• enable-echo - 在 http://{listen}/echo 启用一个简单的HTTP回显服务器

详细信息

以下章节提供了一些背景信息，可能有助于更好地理解WCF及一些配置选项。

目标重写

预期的WCF端点编码在net.tcp前导码以及SOAP信封中传输的To标头中。 服务器可能会检查此端点规范是否与预期的匹配。 当客户端被操纵以连接到代理而非原始服务器时，此端点规格很可能会改变，服务器可能会拒绝通信。 因此，通常需要纠正发往服务器的出站流量中的端点规范。 为此，请在配置文件的retarget选项中提供原始端点规范（例如，从客户端配置中获取）。 端点规范通常如下所示：net.tcp://some/endpoint。

当同时使用多个WCF端点时，可能需要对所有端点执行目标重写。 为此，存在retarget-map选项，它定义了目标URI之间的映射。 当在retarget-map中找不到匹配项时，目标URI将更改为retarget中给出的值。

类型提示

由MC-NBFX规范的二进制XML在二进制格式（记录类型）中编码了基本类型信息。 并非所有这些信息都能轻松地从二进制XML文档的（文本）XML表示中恢复。 因此，wcfproxy 将类型提示插入到XML字符数据（以及某些属性）令牌中。 这些类型提示采用<h>:的形式，其中<h>是一个短字符串，编码了某种类型（例如，i表示整数，ch表示字符）。 完整的类型提示列表可在typehint.go中找到。 不建议篡改类型提示。

拦截器

拦截器指定如何处理接收到的流量，并通过拦截器配置进行指定。 它们处理双向（客户端 -> 服务器和服务器 -> 客户端）发送的流量。 目前有两种拦截器：日志 和 HTTP。

日志拦截器

日志拦截器将二进制编码的SOAP信封转换为其人类可读的对应物，这些对应物使用常规的基于文本的XML编码。 不执行任何主动操作（除了目标规范重写）。 输出发送到指定的日志位置（默认为 stdout）。 确保将日志级别设置为 info（或 debug），否则相关输出将被抑制。

HTTP拦截器

HTTP拦截器将二进制SOAP信封转换为其基于文本的对应物，并将其发送到由 -http-url 指定的HTTP端点。 解码后的SOAP消息在请求体中发送。 HTTP服务器应返回与传入消息相同格式的有效SOAP信封。 然后这些消息被转换回原始的二进制格式，并发送到上游服务器。

简单地反射原始消息对HTTP服务器来说始终是一个有效选项。 然而，也可以通过提供一个执行所需替换的自定义HTTP服务器来实现对消息的程序化操作。 应注意不要破坏SOAP消息的结构。 建议除非你知道自己在做什么，否则不要乱动消息的格式。 此外，不应篡改由 wcfproxy 插入的类型提示，因为这可能会破坏将基于文本的SOAP消息转换回其二进制对应物，或者在合法端点（客户端或服务器）上的消息解析。

wcfproxy 附带一个简单的HTTP服务器，它仅反射接收到的HTTP请求的正文。 当提供了控制服务器配置并且 enable-echo 选项设置为 true 时，此服务器将被启动。 所需HTTP服务器的URL通过 http拦截器配置中的 server-url 选项提供。

为了允许交互式操作，可以通过 proxy-url 选项指定一个HTTP代理（例如BurpSuite）。 然后消息将通过指定的HTTP代理发送到HTTP服务器。 注意，对于每个WCF消息（例如，客户端 -> 服务器），都会生成一个HTTP请求-响应对。

为了将消息与其来源的net.tcp连接关联起来，在由http拦截器生成的请求中插入了头部 X-Wcpf-Conn-Id。

下图说明了使用http拦截器时的数据流。