Build

Você pode compilar a ferramenta uma vez e depois usar o binário resultante, ou executá-la "como um script" (o toolchain Go irá compilá-la em tempo real). Para desenvolvimento, a última opção é conveniente. Para uso produtivo, é recomendado compilá-la uma vez (a partir do diretório cli) e usar o executável resultante. Graças ao compilador Go, você pode compilar a partir e para Linux ou Windows. A versão 1.18 ou superior do Go é necessária para compilar (testado com Go 1.23).

Compilar a partir do Linux

Para compilar a partir do Linux para Windows ou Linux, basta definir GOOS adequadamente (execute a partir do diretório cli):``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

#### Instalação

> [!IMPORTANT]
> É necessário ter o [Graphviz](https://graphviz.org/download/) instalado no seu sistema separadamente (veja [#228](https://github.com/hahwul/gee/issues/228)).

$ go install github.com/hahwul/gee@latest

**homebrew**

$ brew install gee

**snapcraft**

$ sudo snap install dalfox

**docker**

$ docker run ghcr.io/hahwul/gee:latest

GOOS=linux GOARCH=amd64 go build -o wcfproxy
```
## Construir a partir do Windows
Para compilar a partir do Windows, execute os comandos equivalentes, por exemplo, a partir do PowerShell:```
$env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe
```
- **Descoberta de Conteúdo Web**: Automatize a descoberta de recursos web ocultos, endpoints e diretórios combinando múltiplas técnicas como crawling, brute force e sondagem baseada em wordlists.  
- **Reconhecimento Visual**: Capture, compare e analise o conteúdo visual de páginas web para identificar diferenças visuais, indicadores ocultos e mudanças ao longo do tempo sem inspeção manual.  
- **Integrações**: Integre-se perfeitamente com ferramentas de segurança populares como Nuclei, Burp Suite, OWASP ZAP e outras para construir fluxos de trabalho de segurança abrangentes.  
- **Coleta de Inteligência**: Colete e correlacione informações de múltiplas fontes de OSINT, registros DNS e logs de transparência de certificados para construir um mapa detalhado da superfície de ataque.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy
```
# Uso
A configuração para `wcfproxy` é fornecida através de um arquivo JSON.
Por padrão, o arquivo de configuração `config.json` é utilizado, mas o caminho para um arquivo de configuração pode ser especificado com o parâmetro `-config`.
O arquivo de configuração deve conter um número arbitrário de configurações nomeadas, como a seguir:```json
{
	"my-config": { 
        " ... ": " ... " 
    }
}
```
O valor dos objetos de configuração nomeados deve corresponder à estrutura `Config` (veja [Estrutura do Config](#config-structure)).
Este arquivo fonte com os comentários incluídos também funciona como a documentação mais precisa para as opções de configuração do `wcfproxy`.
De todas as configurações fornecidas, a que deve ser usada é identificada pelo nome através da opção de linha de comando `-enable`:```
wcfproxy.exe -config config.json -enable my-config
```
## Estrutura da configuração
A estrutura de nível superior de cada objeto de configuração é a seguinte:```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": {
         " ... ": " ... "
    }
}
```
Note que a configuração TLS (`tls-server` e/ou `tls-client`) não pode ser fornecida se uma configuração NTLM estiver presente.

### Opções de configuração
+ `listen` - o endpoint TCP no qual o *wcfproxy* deve escutar, ex.: `127.0.0.1:8000` ou `[::1]:8000`
+ `connect` - o endpoint TCP do servidor WCF upstream, ex.: `127.0.0.1:9000` ou `[::1]:9000`
+ `retarget` - especificação de destino original (e fallback para `retarget-map`); para uma explicação, veja [Reescrita de destino](#target-rewriting)
+ `retarget-map` - generalização de `retarget`; permite realizar reescrita de destino para múltiplos endpoints (útil apenas se trabalhando com múltiplos serviços WCF na mesma porta)
    + se uma das chaves no `retarget-map` corresponder ao destino atual, a URI de destino será substituída pelo valor fornecido para comunicação upstream
    + se nenhuma chave do `retarget-map` corresponder ao destino atual, `retarget` será usado no lugar
+ `log-level` - nível de log; valores disponíveis: `debug`, `info` (padrão), `warn`, `error`
+ `log-file` - caminho para o arquivo de log; se nenhum caminho for fornecido, o log é escrito em `stdout`
+ `tls-server` - instância de `TlsServerConfig` (veja [Configuração do servidor TLS](#tls-server-configuration)); necessário apenas se a atualização TLS deve ser suportada
+ `tls-client` - instância de `TlsClientConfig` (veja [Configuração do cliente TLS](#tls-client-configuration)); relevante apenas se a atualização TLS deve ser suportada
+ `ntlm` - instância de `NtlmConfig` (veja [Configuração NTLM](#ntlm-configuration)); necessário apenas se a atualização NTLM (diretamente ou via SPNEGO) deve ser suportada
+ `interceptor` - instância de `InterceptorConfig` (veja [Configuração do Interceptor](#interceptor-configuration)); obrigatório
+ `ctrl` - instância de `ControlServerConfig` (veja [Configuração do Servidor de Controle](#control-server-configuration)) que pode fornecer um servidor HTTP echo padrão (útil junto com o interceptor HTTP) bem como uma pequena API para controlar o fluxo de mensagens (ainda em desenvolvimento)

### Configuração do servidor TLS
A configuração do lado do servidor TLS fornece controle sobre as configurações de servidor TLS mais tipicamente relevantes.
Ela possui a seguinte estrutura:```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"
}
```
#### Opções de configuração do servidor TLS
+ `cert-pem` - caminho para o certificado X.509 (no formato PEM)
+ `cert-key` - caminho para a chave correspondente ao certificado
+ `max-version` - versão TLS máxima aceitável; uma de `1.0`, `1.1`, `1.2`, `1.3` (padrão)
+ `min-version` - versão TLS mínima aceitável; uma de `1.0` (padrão), `1.1`, `1.2`, `1.3`
+ `client-roots` - lista separada por vírgulas de caminhos para certificados raiz aceitáveis (PEM) para autenticação do cliente; opcional
+ `client-auth` - política de autenticação do cliente; valores mais úteis: `none` (padrão), `require-and-verify`
+ `keylog` - arquivo para escrever segredos TLS no formato NNS

### Configuração do cliente TLS
A configuração do lado do cliente TLS oferece controle sobre as configurações mais tipicamente relevantes do cliente TLS.
Tem a seguinte estrutura:```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
}
```
#### Opções de configuração do cliente TLS
+ análogo às [opções de configuração do servidor TLS](#tls-server-configuration-options)
+ `roots` - caminho para lista separada por vírgulas de caminhos para CAs raiz (PEM); opcional com `skip-verify`
+ `server-name` - nome do servidor (SNI); opcional
+ `skip-verify` - bool; se o cliente deve dispensar a verificação do certificado do servidor (padrão: `false`)
```