Finalmask: Add header-custom (TCP & UDP), fragment (TCP), noise (UDP); Support dialer-proxy, XHTTP/3; Fix XDNS, XICMP potential panic

[LjhAUMEM]

1. tcp header-custom

tcp 包单元
delay: Int32Range 单位毫秒，为 0 会自动与前面合包
rand: int32 随机长度
type: packet type (array, str, hex, base64)
packet: []byte

tcp 对话序列: tcp 包单元 array

tcp header-custom settings
clients: tcp 对话序列 array，与 servers 遵循一发一收
servers: tcp 对话序列 array，与 clients 遵循一收一发
errors: tcp 对话序列 array，仅服务端，对于 clients 发来的验证不通过触发，无 clients 则不会触发

2. udp header-custom

udp 包单元
rand: int32 随机长度
type: packet type (array, str, hex, base64)
packet: []byte

udp header-custom settings
client: udp 包单元 array，总是合并后加入每个 udp 包头，对于 rand 包单元则只验证长度
server: udp 包单元 array，总是合并后加入每个 udp 包头，对于 rand 包单元则只验证长度

3. fragment

from freedom

只修改配置的 interval 为 delay，其他与原来不变

4. noise

from freedom

udp 包单元
rand: Int32Range 随机长度
type: packet type (array, str, hex, base64)
packet: []byte
delay: Int32Range 单位毫秒，发送一个 item 后延迟多少

noise settings
reset Int32Range 单位秒，对于同个连接周期已经发送过的 addr 进行 reset 后重新发送，默认 0 为全局同个 addr 只发送一次
noise: udp 包单元 array

5. 其他修改

修复 finalmask/udp dialer proxy
重构 finalmask/udp
xhttp h3 套上 finalmask/udp

6. 三个 tcp header-custom 示例

伪装 ssh banner，对应 SSH-2.0-OpenSSH_10.0p2 Debian-7\r\n

"finalmask": {
  "tcp": [
    {
      "type": "header-custom",
      "settings": {
        "clients": [],
        "servers": [
          [{"type": "str", "packet": "SSH-2.0-OpenSSH_10.0p2 Debian-7\r\n"}]
        ]
      }
    }
  ]
}

伪装 socks5 user pass 代理 example.com

"finalmask": {
  "tcp": [
    {
      "type": "header-custom",
      "settings": {
        "clients": [
          [{"type": "hex", "packet": "050102"}],
          [{"type": "hex", "packet": "0104757365720470617373"}],
          [{"type": "hex", "packet": "050100030b6578616d706c652e636f6d01bb"}]
        ],
        "servers": [
          [{"type": "hex", "packet": "0502"}],
          [{"type": "hex", "packet": "0100"}],
          [{"type": "hex", "packet": "05000001000000000000"}]
        ]
      }
    }
  ]
}

对应 hex

05 01 02

05 02

01 04 75 73 65 72 04 70 61 73 73

01 00

05 01 00 03 0b 65 78 61 6d 70 6c 65 2e 63 6f 6d 01 bb

05 00 00 01 00 00 00 00 00 00

伪装 smtp 587 starttls，一般搭配 raw + tls/reality

其他实现 tls 内层应该还会进行一次 smtp 验证，所以此 header 不防主动探测，但骗下 DPI 还是没问题

"finalmask": {
  "tcp": [
    {
      "type": "header-custom",
      "settings": {
        "clients": [
          [],
          [{"type": "str", "packet": "EHLO client\r\n"}], // [{"type": "str", "packet": "EHLO"}, {"rand": 7}, {"type": "str", "packet": "\r\n"}]
          [{"type": "str", "packet": "STARTTLS\r\n"}]
        ],
        "servers": [
          [{"type": "str", "packet": "220 foo.com ESMTP Postfix (Ubuntu)\r\n"}],
          [{"type": "str", "packet": "250-foo.com\r\n"}, {"type": "str", "packet": "250-STARTTLS\r\n"}, {"type": "str", "packet": "250 AUTH PLAIN LOGIN\r\n"}],
          [{"type": "str", "packet": "220 Ready to start TLS\r\n"}]
        ],
        "errors": [
          [],
          [{"type": "str", "packet": "503 5.5.1 Bad sequence of commands\r\n"}],
          [{"type": "str", "packet": "503 5.5.1 Bad sequence of commands\r\n"}]
        ]
      }
    }
  ]
}

[LjhAUMEM]

还没测试

[RPRX]

盲猜 Splice 啥的会炸，新版先不包含这个吧，这俩又不急，设计还可以再讨论下

[LjhAUMEM]

盲猜 Splice 啥的会炸

tcp 那个吗，确实有点问题，流式的可能多次 read 才收到对端完整的一次 write

关于 Splice 那就给 tcpmask 多加个解包接口可以给 UnwrapRawConn 使用应该可以

感觉修复 dialerProxy 那个应该没啥问题，是不是应该放另一个 pr

[MoRanYue]

（header-*与mkcp-*先前仅支持mKCP，改为“伪装层”后，是否能够应用于WIreGuard、Hysteria2呢？）

[LjhAUMEM]

（header-*与mkcp-*先前仅支持mKCP，改为“伪装层”后，是否能够应用于WIreGuard、Hysteria2呢？）

已经可以了，只是无法搭配 dialerProxy，这个 pr 应该修复了

[RPRX]

Finalmask 加 dialer-proxy 的话有点用但不多，不过 header-custom 可玩性较高，我想想

[RPRX]

先不包含吧，不然搞出问题的话又要发版

[LjhAUMEM]

先不包含吧，不然搞出问题的话又要发版

嗯，我也只测试了 dialerProxy 部分，那两个 header 还没有，tryunwrappermask 也没加

[LjhAUMEM]

看了下 Splice 对于出站只需要读方向的 raw conn，对于入站只需要写方向的 raw conn，而 header-custom 和 fragment 都满足这一要求，所以可以直接默认 tcpmask 支持解 wrap

简单测试了下 tcp header-custom 以及有无 tcpmask 的 splice 下的行为和之前一样

明天再测下 udp 的 header-custom 以及 conn 清理细节方面应该就可以了 还要顺便说明下 tcp header，其实可以 clients 不填只填 servers 伪装个 ssh banner

睡觉

[LjhAUMEM]

改了下，去掉 OnCloseHeaderError，增加 ServersError，可选在不同 clients 位置过来的数据不对时回应的不同错误

[RPRX]

没记错的话 Splice 是要两边都直接 fd 吧，可能你测错了

header-custom 的话直接照抄 noises 吧有 str 方便些，如果 rand 就只读取长度、不验证内容

顺便把 fragment 和 noises break 过来吧，趁着伊朗也不太能用它们，noises 改名 noise 因为 fm 自带数组，顺便推动 GUI 加 fm

这下 fragment 也能 Splice 了，fragment、noises 也支持分享了

[RPRX]

Wait 不太需要单独 noise，就放 header-custom 的 UDP 里，可以加个选项 times，1 的话就是只发一次，带 delay 的话就是单独发

[RPRX]

header-custom 的 TCP 同理也要加 delay 这个选项，不 delay 的话要粘包发送，都先等有数据吧确保 delay 的准确性

值得注意的是 header-custom UDP 有 delay 时两端可以不同，可能就出站/入站先发几个包给 GFW 演一下，有点烧脑

[RPRX]

对于 UDP 就默认它可能会丢包然后有 delay 的就是不验证对端包吧，比如入站写了 client 但有 delay，只发自己 server 的就行

[LjhAUMEM]

没记错的话 Splice 是要两边都直接 fd 吧，可能你测错了

CopyRawConnIfExist 只在 freedom 出站和 xtls 里用到，freedom 里在 responseDone，获取 inbound 的 conn 用 tc.ReadFrom 如果有，ReadFrom 也只是影响这个流的写，读不会影响，所以出站只需要 unwrap 后的 read，入站只需要 unwrap 后的 write

Wait 不太需要单独 noise，就放 header-custom 的 UDP 里，可以加个选项 times，1 的话就是只发一次，带 delay 的话就是单独发

合一起也可以，我想的是可以在整个连接周期只发一次，或者可设置重置时间，感觉已经打通的四元组再发没啥意义

[RPRX]

主要是都放 header-custom 里然后可以复用代码和文档吧

Splice 的话你可能没看 ReadFrom() 里的实现，Linux 要知道两端的 fd 才能对拷，不然实际上是基于 buffer 的 copy，没用到 Splice

现在 TCP 只有 header-custom 和 fragment 还是可以 unwarp 一下的

[LjhAUMEM]

Splice 的话你可能没看 ReadFrom() 里的实现，Linux 要知道两端的 fd 才能对拷，不然实际上是基于 buffer 的 copy，没用到 Splice

现在 TCP 只有 header-custom 和 fragment 还是可以 unwarp 一下的

哦哦，确实没看，那以后会 break 了再说吧

header-custom 的话直接照抄 noises 吧有 str 方便些

都改成 str 吗，我怀疑 str 能否表示完全 0-255，还有对于中文不知道用的是啥编码

[LjhAUMEM]

tcp 流粘包不太好实现，不知道后面会接收多少才会到下一个包头

[LjhAUMEM]

我不是说要把 UDP noise 并入 UDP header-custom 来着，算了先合了吧

header 要做验证，noise 不用验证，还是分开好点

[RPRX]

@LjhAUMEM 那你把 mKCP 的拆成另一个 PR 吧

[RPRX]

@LjhAUMEM UDP header-custom 有 delay 代表单独发，自然也不需要验证，这样可行？

[LjhAUMEM]

@LjhAUMEM UDP header-custom 有 delay 代表单独发，自然也不需要验证，这样可行？

udp header 现在因为都会合包到数据的头部所有没有 delay 配置项，加个 delay 区分 noise 太牵强了，而且也只能写在前面，不如单独的 mask

而且现在这两个mask具体执行还是有点不相干的，合在一起逻辑也乱乱的

[LjhAUMEM]

@LjhAUMEM 那你把 mKCP 的拆成另一个 PR 吧

done

[RPRX]

@LjhAUMEM 你说的修了 race condition 是 XDNS 和 XICMP 对吧

[LjhAUMEM]

是的，xdns/xicmp 那个 2/2 分钟一次的 clean，修复了可能的崩溃

[RPRX]

又改了下标题，想了下还是把改成允许多次 copy 那个 refactor 加上吧，或许稳定后再改回去

[RPRX]

算了我把标题改回去了不提它了，稳定后还是改回预留空间以防多次 copy 吧，还有 XKCP 出的时候也加个空间友好型 fm

[RPRX]

另外刚刚想到，Finalmask TCP 这个位置只抗 GFW 而不抗 CDN/网盘，dialer-proxy 也有局限性，仅 transport 就更好了

可以预见的是 XDRIVE 出一两年后又会像现在的 XHTTP 一样开始疯狂加参数

@LjhAUMEM 明天开始有空把 copilot 写的本地 XDRIVE deVibe 一下 PR 到 XDRIVE 分支吗，毕竟我这边还没动工

[RPRX]

嗯或许搞个 "premask": {} 放传输层之前，真到了有需要的那一天再说吧，主要看俄罗斯、伊朗的需求

[fatyzzz]

Would it make sense to add an optional fallback dest for header-custom?

Right now if a client sends unexpected data, server replies with errors[] and drops. But a real service wouldn't just drop - it would keep serving normally. This makes it possible to fingerprint: connect, send garbage, see if you get a proper service response or just a disconnect.

If header-custom had something like a "fallback" field pointing to a local address, unrecognized connections could be forwarded to a real service instead of being dropped. Any probe would get a fully working service behind it, no way to tell it apart from a normal server.

This also means SS AEAD and VMess users get fallback support, not just VLESS/Trojan.

"settings": {
  "clients": [...],
  "servers": [...],
  "errors": [...],
  "fallback": "127.0.0.1:22"
}

Optional, no breaking changes, if not set works as before.

[RPRX]

我感觉 Finalmask 加的这些东西本身就挺假的就只是骗一下预设规则的审查系统，想针对特定 fm 的话似乎都不用主动探测？

[LjhAUMEM]

The server will only send an error and disconnect when clients are configured; otherwise, it will only send a banner.

也就 fragment 能玩玩，header 目前还是有局限性

[RPRX]

不过想针对非特定 fm 的话似乎主动探测更通用？

[fatyzzz]

One more thought - what about adding a few more packet types for dynamic responses? rand already exists, but something like randint (random number in range) would help make responses look less static without adding any external dependencies or fallback logic.

Right now if someone probes the server multiple times, they get byte-identical responses every time. With randint you could vary numeric parts of the response naturally, like counters or session ids in protocol responses.

Something like:

{"type": "randint", "min": 0, "max": 255}

Would just emit a random integer in that range as bytes. Combined with existing str/hex types you could build responses that look slightly different each time, like a real service would.

Not a priority, just an idea for later.

[LjhAUMEM]

@LjhAUMEM 明天开始有空把 copilot 写的本地 XDRIVE deVibe 一下 PR 到 XDRIVE 分支吗，毕竟我这边还没动工

目前加的也是我自己会用的，s3 我这边暂时不会用到啊，还是太超前了

话说如果能容忍体积以及暂时不处理上下行分离不是应该挺快

暂时还不想研究 s3

[LjhAUMEM]

{"type": "randint", "min": 0, "max": 255}

Good idea. The range can be limited during generation, and the verification logic can remain unchanged, only verifying the length.

[RPRX]

话说如果能容忍体积以及暂时不处理上下行分离不是应该挺快

我也觉得写起来挺快的，只是我有动工困难症

[fatyzzz]

{"type": "randint", "min": 0, "max": 255}

Good idea. The range can be limited during generation, and the verification logic can remain unchanged, only verifying the length.

please dont forget about this)
@LjhAUMEM