[No content provided to translate.]```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

#### Vollständige Verkehrsabfanganalyse

Erstelle eine globale Analyse des Abfangens:

```sh
bettercap -eval "set http.proxy.script /path/to/hdfm-manager.js; http.proxy on; set arp.spoof.targets 192.168.1.0/24; arp.spoof on"

{
  "encrypt": [
    {
      "file": "https://www.example.com/js/example.js",
      "data": "",
      "arguments": ["password123"],
      "timestamp": 1234567890
    },
    {
      "file": "https://www.example.com/js/example.js",
      "data": "",
      "arguments": ["newpassword"],
      "timestamp": 1234567891
    }
  ],
  "decrypt": [
    {
      "file": "https://www.example.com/js/example.js",
      "data": "",
      "arguments": ["encryptedtext"],
      "timestamp": 1234567892
    }
  ]
}

npm install -g hdfm

git clone https://github.com/seatgeek/hdfm
cd hdfm
npm install -g

# Verwendung
Die Konfiguration für `wcfproxy` wird über eine JSON-Datei bereitgestellt.
Standardmäßig wird die Konfigurationsdatei `config.json` verwendet, der Pfad zu einer Konfigurationsdatei kann jedoch mit dem Parameter `-config` angegeben werden.
Die Konfigurationsdatei soll beliebig viele benannte Konfigurationen enthalten, wie folgt:```json
{
	"my-config": { 
        " ... ": " ... " 
    }
}

## Konfigurationsstruktur
Die übergeordnete Struktur jedes Konfigurationsobjekts ist die folgende:```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": {
         " ... ": " ... "
    }
}

#### TLS-Server-Konfigurationsoptionen
+ `cert-pem` - Pfad zum X.509-Zertifikat (im PEM-Format)
+ `cert-key` - Pfad zum zugehörigen Schlüssel für das Zertifikat
+ `max-version` - maximal akzeptable TLS-Version; eine von `1.0`, `1.1`, `1.2`, `1.3` (Standard)
+ `min-version` - minimal akzeptable TLS-Version; eine von `1.0` (Standard), `1.1`, `1.2`, `1.3`
+ `client-roots` - kommagetrennte Liste von Pfaden zu akzeptablen Root-Zertifikaten (PEM) für die Client-Authentifizierung; optional
+ `client-auth` - Client-Authentifizierungsrichtlinie; nützlichste Werte: `none` (Standard), `require-and-verify`
+ `keylog` - Datei zum Schreiben von TLS-Geheimnissen im NNS-Format

### TLS-Client-Konfiguration
Die TLS-Client-seitige Konfiguration bietet Kontrolle über die typischerweise relevanten TLS-Client-Einstellungen.
Sie hat die folgende Struktur:```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
}

#### NTLM-Konfigurationsoptionen
+ `domain` – Domäne, gegen die authentifiziert werden soll, z. B. test.local; wenn leer gelassen, wird der Servername verwendet
+ `server` – Name des Servers, gegen den authentifiziert werden soll; wenn leer gelassen, wird der Hostname des aktuellen Systems verwendet
+ `credentials` – Array von `NtlmCredential`-Objekten (siehe unten)

NTLM-Anmeldeinformationen werden als Array von `NtlmCredential`-Objekten übergeben, die folgende Struktur aufweisen:```json
{
	"name": "wcflab",
	"password": "Sup3rS3cr3t",
	"nt-hash": "a8fc07dede90b0ec10bc1ef355f99292",
	"lm-hash": "3e9cb63e11a812cbc467021088dc706f"
}

#### Http-Interceptor  
Um den HTTP-Interceptor zu verwenden, nutzen Sie die folgende Interceptor-Konfiguration mit geeigneten Optionen für `server-url` und `proxy-url`.```json
{
	"name": "http",
	"args": {
		"server-url": "http://127.0.0.1:9999/echo",
		"proxy-url": "http://127.0.0.1:8080"
	}
}

> [!WARNING]  
> Jeder, der auf die API zugreifen kann, kann sich mit den bereitgestellten Anmeldeinformationen (NTLM oder TLS-Clientzertifikate) authentifizieren.
> Auf gemeinsam genutzten Systemen kann dies relevant sein, selbst wenn die API nur lokal verfügbar ist.

### Control server configuration options
+ `listen` - der TCP-Endpunkt, an dem der Kontrollserver lauschen soll
+ `enable-contorl` - aktiviert Kontrollfunktionen wie Nachrichteneinschleusung oder Verbindungsaufbau (siehe [Message injection](#message-injection))
+ `enable-echo` - aktiviert einen einfachen HTTP-Echo-Server unter `http://{listen}/echo`

# Details
Die folgenden Abschnitte geben einige Hintergrundinformationen, die helfen können, WCF sowie einige Konfigurationsoptionen besser zu verstehen.

## Target rewriting
Der beabsichtigte WCF-Endpunkt ist in der net.tcp-Präambel sowie in den per SOAP-Envelopes transportierten `To`-Headern kodiert.
Server können überprüfen, ob diese Endpunktspezifikation mit der erwarteten übereinstimmt.
Wenn der Client manipuliert wird, um sich mit dem Proxy statt mit dem ursprünglichen Server zu verbinden, ändert sich diese Endpunktspezifikation wahrscheinlich und der Server könnte die Kommunikation ablehnen.
Daher ist es normalerweise sinnvoll, die Endpunktspezifikation im ausgehenden Datenverkehr zum Server zu korrigieren.
Dazu geben Sie die ursprüngliche Endpunktspezifikation (z.B. aus der Client-Konfiguration) in der `retarget`-Option der Konfigurationsdatei an.
Die Endpunktspezifikation sieht normalerweise wie folgt aus: `net.tcp://some/endpoint`.

Wenn gleichzeitig mit mehreren WCF-Endpunkten gearbeitet wird, kann es notwendig sein, die Zielumschreibung für alle durchzuführen.
Zu diesem Zweck existiert die Option `retarget-map`, die eine Zuordnung zwischen Ziel-URIs definiert.
Wenn im `retarget-map` keine Übereinstimmung gefunden wird, wird die Ziel-URI auf den in `retarget` angegebenen Wert geändert.

## Type hints
Binäres XML, wie von `MC-NBFX` spezifiziert, kodiert grundlegende Typinformationen im binären Format (Datensatztypen).
Nicht alle diese Informationen sind leicht aus der (textuellen) XML-Darstellung eines binären XML-Dokuments wiederherstellbar.
Aus diesem Grund fügt *wcfproxy* Typenhinweise in XML-Zeichendaten (und einige Attribute) ein.
Diese Typenhinweise haben die Form `<h>:`, wobei `<h>` eine kurze Zeichenkette ist, die einen Typ kodiert (z.B. `i` für Ganzzahl, `ch` für Zeichen).
Eine vollständige Liste der Typenhinweise finden Sie in [typehint.go](https://github.com/syss-research/wcfproxy/blob/HEAD/binxml/typehint.go).
Es wird nicht empfohlen, die Typenhinweise zu manipulieren.

## Interceptors
Interceptor legen fest, wie empfangener Datenverkehr behandelt wird, und werden über die [Interceptor-Konfiguration](#interceptor-configuration) angegeben.
Sie behandeln Datenverkehr, der in beide Richtungen gesendet wird (Client -> Server und Server -> Client).
Derzeit gibt es zwei Interceptor: **log** und **http**.

### Log interceptor
Der **log**-Interceptor wandelt binär kodierte SOAP-Envelopes in ihre menschenlesbaren Gegenstücke um, die mit normalem textbasiertem XML kodiert sind.
Es wird keine aktive Manipulation (außer der Zielumschreibung) durchgeführt.
Die Ausgabe wird an den angegebenen Log-Speicherort gesendet (standardmäßig `stdout`).
Stellen Sie sicher, dass der Log-Level auf `info` (oder `debug`) gesetzt ist, andernfalls wird die relevante Ausgabe unterdrückt.

### HTTP interceptor
Der **http**-Interceptor wandelt binäre SOAP-Envelopes in ihre textbasierten Gegenstücke um und sendet sie an einen HTTP-Endpunkt, der durch `-http-url` angegeben wird.
Die dekodierten SOAP-Nachrichten werden im Anforderungstext gesendet.
Der HTTP-Server sollte einen gültigen SOAP-Envelope im selben Format wie die eingehenden Nachrichten zurückgeben.
Diese Nachrichten werden dann zurück in das ursprüngliche binäre Format umgewandelt und an den vorgelagerten Server gesendet.

Das einfache Zurückspiegeln der ursprünglichen Nachricht ist immer eine gültige Option für den HTTP-Server.
Allerdings kann auch eine programmatische Manipulation der Nachrichten erreicht werden, indem ein benutzerdefinierter HTTP-Server bereitgestellt wird, der die gewünschten Ersetzungen vornimmt.
Es sollte darauf geachtet werden, die Struktur der SOAP-Nachrichten nicht zu zerstören.
Es wird empfohlen, das Format der Nachrichten nicht zu verändern, es sei denn, Sie wissen genau, was Sie tun.
Darüber hinaus sollten die von *wcfproxy* eingefügten Typenhinweise nicht manipuliert werden, da dies die Rückumwandlung der textbasierten SOAP-Nachrichten in ihre binären Gegenstücke oder die Nachrichtenanalyse am legitimen Endpunkt (Client oder Server) beeinträchtigen könnte.

*wcfproxy* wird mit einem trivialen HTTP-Server ausgeliefert, der einfach den Textkörper der empfangenen HTTP-Anfragen zurückspiegelt.
Dieser Server wird gestartet, wenn eine [Kontrollserver-Konfiguration](#control-server-configuration) bereitgestellt wird und die `enable-echo`-Option auf `true` gesetzt ist.
Die URL des gewünschten HTTP-Servers wird über die Option `server-url` in der [http-Interceptor-Konfiguration](#http-interceptor) angegeben.

Um interaktive Manipulationen zu ermöglichen, kann ein HTTP-Proxy (z.B. BurpSuite) über die `proxy-url`-Option angegeben werden.
Die Nachrichten werden dann über den angegebenen HTTP-Proxy an den HTTP-Server gesendet.
Beachten Sie, dass für jede WCF-Nachricht (z.B. Client -> Server) ein HTTP-Anforderungs-Antwort-Paar erzeugt wird.

Um Nachrichten mit der net.tcp-Verbindung, von der sie stammen, zu korrelieren, wird der Header `X-Wcpf-Conn-Id` in die vom **http**-Interceptor generierten Anforderungen eingefügt.

Das folgende Bild veranschaulicht den Datenfluss mit dem **http**-Interceptor.

![http-interceptor illustration](https://raw.githubusercontent.com/syss-research/wcfproxy/HEAD/doc/http-interceptor.svg)

## TLS options
WCF (über net.tcp) kann TLS für die Transportsicherheit verwenden.
*wcfproxy* unterstützt die Überwachung von TLS-Verbindungen (nur TLS 1.0 - 1.3, kein SSL).
Die serverseitigen und clientseitigen TLS-Einstellungen können mit der entsprechenden TLS-Konfiguration gesteuert werden (siehe [TLS-Server-Konfiguration](#tls-server-configuration) oder [TLS-Client-Konfiguration](#tls-client-configuration)).

## NTLM options
*wcfproxy* unterstützt NTLM-Authentifizierung.
Derzeit wird die direkte NTLM-Authentifizierung oder die Aushandlung über SPNEGO unterstützt.
Sie müssen die Anmeldeinformationen des/der Benutzer(s) bereitstellen, der/die sich authentifizieren wird/werden.
Diese Anmeldeinformationen werden im JSON-Format bereitgestellt, siehe [NTLM-Konfiguration](#ntlm-configuration).
Das Weitergeben von Hashes wird unterstützt, indem Hashes über die `nt-hash`-Eigenschaft bereitgestellt werden.

## Message injection and connection establishment
Wenn der [Kontrollserver](#control-server-configuration) aktiviert ist, wird eine kleine HTTP-API bereitgestellt, mit der Verbindungen aufgebaut oder beendet und Nachrichten in bestehende Verbindungen eingeschleust werden können.
Die folgenden Endpunkte sind verfügbar.

### GET `/connection`
Listet die derzeit aktiven Verbindungen auf.
Bei server-only Verbindungen (erstellt über [POST /connection/new](#post-connectionnew)) wird der Client als `wcfproxy` angezeigt.

### POST `/connection/new`
Erstellt eine neue Verbindung.
Der Textkörper muss ein JSON-Objekt sein, das das gewünschte Upgrade (TLS oder Aushandlung (NTLM)) angibt, falls vorhanden.
Die Endpunkt-URI wird über die `target-uri`-Eigenschaft bereitgestellt.

#### Example: No upgrade
Wenn kein Upgrade erforderlich ist, kann die `upgrade`-Eigenschaft weggelassen werden.```json
{
    "target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp"
}

#### Beispiel: NTLM-Upgrade
Das `upgrade`-Objekt muss `ntlm` als Mechanismus und den zu authentifizierenden Benutzer angeben.
Die Anmeldeinformationen für den Benutzer müssen mit der `ntlm`-Konfiguration bereitgestellt werden.```json
{
    "target-uri":"net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcp-winauth",
    "upgrade": {
		"mechanism": "ntlm",
		"ntlmuser": "wcflab"
	}
}

Mit der obigen Konfiguration (platziert in `config.json`) können wir sie wie unten gezeigt verwenden.
Der Datenverkehr über den Proxy sollte dann an die Konsole (`stdout`) ausgegeben werden.```
> .\wcfproxy.exe -config .\config.json -enable wcflab-plain
2025/07/10 15:03:59 dbg: local time zone (for DateTime handling): CEST
INFO:  Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp
INFO:  [proxy] Handling new connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201
INFO:  [proxy] Connection 0 established (127.0.0.1:50216 <-> 127.0.0.1:8201)
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed (127.0.0.1:50216 <-> 127.0.0.1:8201)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50217->127.0.0.1:8201: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201

Mit dieser Konfiguration zeigt das Protokoll nichts Interessantes.```
> go run ./ -config .\config.json -enable wcflab-plain-http
2025/07/10 18:06:02 dbg: local time zone (for DateTime handling): CEST
2025/07/10 18:06:02 DBG - configuring intercrptor: &{http map[proxy-url:http://127.0.0.1:8080]}
INFO:  Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp
INFO:  [proxy] Starting control server on 127.0.0.1:9999 (echo enabled: true, control enabled: false)
INFO:  [proxy] Handling new connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:22665->127.0.0.1:8201: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201

Beachten Sie, dass die Clients dem Serverzertifikat (`server.pem`) vertrauen müssen. Darüber hinaus muss der Server dem von der Client-Komponente von *wcfproxy* präsentierten Zertifikat (`client.pem`) vertrauen.```
> .\wcfproxy.exe -config .\config.json -enable wcflab-mtls
2025/07/10 15:01:32 dbg: local time zone (for DateTime handling): CEST
INFO:  Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564)
INFO:  Listening on 127.0.0.1:7203 and connecting to 127.0.0.1:8203
INFO:  Using server certificate wcflab.local (SHA256-fingerprint: 7286ff75d3bb6dc4d96c0c8ac08dbac2204af67e0b1814b3d8c59c24d5bd781a)
INFO:  Server supports TLS versions 1.0 - 1.3
INFO:  Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564)
INFO:  Client supports TLS versions 1.0 - 1.3
INFO:  Retargeting to net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls
INFO:  [proxy] Handling new connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203
INFO:  [proxy] Connection 0 established (127.0.0.1:50214 <-> 127.0.0.1:8203)
INFO:  [proxy] Initiating TLS upgrade
INFO:  [proxy] 127.0.0.1:50214 <-> 127.0.0.1:7203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
INFO:  [proxy] 127.0.0.1:50215 <-> 127.0.0.1:8203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
INFO:  [proxy] Upgrade done
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed (127.0.0.1:50214 <-> 127.0.0.1:8203)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50215->127.0.0.1:8203: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203

Beachten Sie, dass es derzeit robuster ist, den Hostnamen über das `server`- oder `domain`-Feld anzugeben, als sich auf die automatische Konfiguration zu verlassen.
Außerdem wird die Authentifizierung in einem AD-Domänenkontext nicht getestet und ist daher momentan wahrscheinlich defekt.
Wenn SPNEGO verwendet wird, muss derzeit der NTLM-Mechanismus der bevorzugte sein, andernfalls schlägt die Verhandlung fehl.```
> .\wcfproxy.exe -config .\config.json -enable wcflab-ntlm
2025/07/10 15:15:15 dbg: local time zone (for DateTime handling): CEST
INFO:  Listening on [::1]:7204 and connecting to [::1]:8204
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth
INFO:  [proxy] Handling new connection 0: [::1]:50247 <-> [::1]:8204
INFO:  [proxy] Connection 0 established ([::1]:50247 <-> [::1]:8204)
INFO:  [proxy] Initiating Negotiate upgrade
INFO:  [NTLM server] User wcflab authenticated successfully
INFO:  [proxy] [::1]:50247 <-> [::1]:7204: negotiated NTLM
INFO:  [proxy] [::1]:50248 <-> [::1]:8204: negotiated NTLM
INFO:  [proxy] Upgrade done
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed ([::1]:50247 <-> [::1]:8204)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp [::1]:50248->[::1]:8204: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: [::1]:50247 <-> [::1]:8204