Minecraft finalmask

[Exclude0122]

听说最近国内中专机上了检测设备，Shadowsocks 用不了了。HTTP/TLS 有备案问题，更是用不了。所以我写了个 Minecraft Finalmask。国内机开个 MC 服，跑图流量大一点很合理吧 😁。

配置

客户端

"finalmask": {
  "tcp": [
    {
      "type": "xmc",
      "settings": {
        "usernames": ["user1"],
        "password": "13f462cb64c72770",
        "hostname": "mc.hypixel.net"
      }
    }
  ]
}

服务端

"finalmask": {
  "tcp": [
    {
      "type": "xmc",
      "settings": {
        "password": "13f462cb64c72770"
      }
    }
  ]
}

协议

C->S Handshake

Name	Value
Protocol Version	775 (26.1)
Address	默认使用真远程地址，可在配置中覆盖
Port	使用真远程端口
Intent	2

如果 Intent 是 1 则进入 Ping 模式，服务端户会响应客户端的 Ping 请求。

C->S Login Start

Name	Value
Username	默认 Dream，可配置
UUID	自动生成

S->C Encryption Request

Name	Value
Server ID	空字符串
Public Key	从 password 自动生成
Verify Token	随机 4 bytes
Should authenticate	true

C->S Encryption Response

Name	Value
Shared Secret	客户端生成对称加密用到的密钥，并用服务端的 Public Key 加密
Verify Token	加密后的 Verify Token + password。因为有 PKCS#1 v1.5 padding，所以在此处拼接 password 不会导致密文长度超过原版。

服务端在成功接收 Encryption Response 数据包后，将立即开启 AES/CFB8 加密。

服务端会检测 password 是否正确，如果正确则握手成功，进入转发模式；否则返回原版拒绝理由multiplayer.disconnect.authservers_down，并踢掉客户端。

客户端会使用 password 生成出同样的 RSA public key，防止 MITM 攻击。

[RPRX]

终究还是来了

[Exclude0122]

终究还是来了

啊？这个以前讨论过吗

[Fangliding]

怎么这东西也学reality弄个pubkey和shortid啊 一个密钥不就行了？安全性给上层

[Fangliding]

哎全是AI写的

[Snow-dash]

@Exclude0122 是伪装成mc协议还是真的放在mc协议里传输

[RPRX]

啊？这个以前讨论过吗

https://t.me/projectXtls/1473 ，这个是真的 MC 协议的话需要改名 XMC，否则 header-custom 就能解决的问题就别加了

依稀记得以前看到过一个项目是真的 MC 协议，不清楚能不能过游戏加速器，链接你们找找

[Exclude0122]

@Exclude0122 是伪装成mc协议还是真的放在mc协议里传输

开启加密前完全遵守 mc 协议进行握手+密钥协商，开启加密有后就直接开始转发了。不过自己实现的 mc 协议肯定和原版有区别，以后可以写一个 minecraft-dialer mod，使用真原版客户端。

[RPRX]

开启加密前完全遵守 mc 协议进行握手+密钥协商，开启加密有后就直接开始转发了

加密包也要符合 MC 协议规范啊不然 header-custom 的科学计算器似乎就能实现？不然很容易被 GFW 和游戏加速器 gank

[Exclude0122]

怎么这东西也学reality弄个pubkey和shortid啊 一个密钥不就行了？安全性给上层

pubkey 是原版 mc 就有的东西，shortid 是为了服务端验证客户端，如果是真 mc 客户端的话会提示 Authentication servers are down

[Exclude0122]

开启加密前完全遵守 mc 协议进行握手+密钥协商，开启加密有后就直接开始转发了

加密包也要符合 MC 协议规范啊不然 header-custome 的科学计算器似乎就能实现？不然很容易被 GFW 和游戏加速器 gank

加密也符合 MC 协议规范，用的是握手阶阶段协商出来的密钥

[Fangliding]

原版mc不是填个地址端口就能进去了

[Exclude0122]

原版mc不是填个地址端口就能进去了

会因为 shortid 不对被踢

[Exclude0122]

我本来还想写一个 fallback，如果 shortid 不对就转发到真 mc 服务器。不过 finalmask 这一层好像不能接管连接，WrapConnClient WrapConnServer 返回 err 连接就直接被关闭了

[RPRX]

会因为 shortid 不对被踢

这是搞了个 MC 版 REALITY 出来吗，如果 MC 这加密足够可靠的话或许也可以加成安全层？只是想了一下

[LjhAUMEM]

我本来还想写一个 fallback，如果 shortid 不对就转发到真 mc 服务器。不过 finalmask 这一层好像不能接管连接，WrapConnClient 返回 err 连接就直接被关闭了

fallback 是 server 管的吧，我之前写的 WrapConnServer err 是继续返给上层，但是后面被人改了

[Exclude0122]

mc 是 rsa 1024 bits + AES/CFB8，并不可靠 😅
我写这些只是想防一下简单的主动探测

[Fangliding]

原版mc不是填个地址端口就能进去了

会因为 shortid 不对被踢

我的意思是这个pubkey原版mc游戏（至少客户端UI）不存在 为什么这里还要填个这东西 一个鉴权用的字符串不就行了

[Exclude0122]

原版mc不是填个地址端口就能进去了

会因为 shortid 不对被踢

我的意思是这个pubkey原版mc游戏（至少客户端UI）不存在 为什么这里还要填个这东西 一个鉴权用的字符串不就行了

客户端 pin 服务端公钥，防止 MITM
mc 原版是靠微软的认证服务器防 MITM 的

[Fangliding]

我觉得用字符串或者hex派生出来就够了 没必要像reality那样严格分开公私钥 数据要安全上面就用tls或者vlessenc

[RPRX]

看群里的讨论 https://t.me/projectXray/4991727 貌似 MC 这加密也就是 SS 的水平，那还是加成 mask 别加成安全层了

[Exclude0122]

我觉得用字符串或者hex派生出来就够了 没必要像reality那样严格分开公私钥 数据要安全上面就用tls或者vlessenc

https://pkg.go.dev/crypto/rsa#GenerateKey

go 不支持生成确定性的 RSA 私钥

我要不把 private key 和 sha256 改成可选项，如果不填就随机生成一个。如果用户不在意 MITM 可以不填。

[Exclude0122]

把 short id 也改成可选项，不填就不认证客户端

[Fangliding]

我觉得用字符串或者hex派生出来就够了 没必要像reality那样严格分开公私钥 数据要安全上面就用tls或者vlessenc

https://pkg.go.dev/crypto/rsa#GenerateKey

go 不支持生成确定性的 RSA 私钥

RSA密钥本质就是两个大素数 标准库生成方法复制出来用扩展欧几里得算法或者别的什么求个逆出来就是整个私钥了 AI两分钟就弄好了

[Exclude0122]

我觉得用字符串或者hex派生出来就够了 没必要像reality那样严格分开公私钥 数据要安全上面就用tls或者vlessenc

https://pkg.go.dev/crypto/rsa#GenerateKey
go 不支持生成确定性的 RSA 私钥

RSA密钥本质就是两个大素数 标准库生成方法复制出来用扩展欧几里得算法或者别的什么求个逆出来就是整个私钥了 AI两分钟就弄好了

客户端也填同样的密码，用同样的算法生成 RSA 密钥，来防止 MITM 吗

[Fangliding]

差不多
你说是 rsa 1024 bits 那本身也没什么卵用稍微弄一下就行了

[Exclude0122]

short id 还要留着吗

[Fangliding]

去了吧 一个鉴权密码就好 主要是方便用

[Exclude0122]

总结一下

• 客户端和服务端预共享一个鉴权密码
• 鉴权密码派生出 RSA 公钥私钥
• 服务端把 RSA 公钥发给客户端
• 客户端用 RSA 公钥加密 对称加密用到的密钥 和 鉴权密码，发给服务端

是这样吗

[Fangliding]

服务端用密码生成 privateKey 就是了 客户端也能算出来能做跟那个sha256一样的校验结果 shortid丢掉 服务端客户端都只要这个一个一模一样的参数
还有不知道为什么你客户端竟然在配置 address 和 port 这不是直接继承的tcpconn?

[Exclude0122]

还有不知道为什么你客户端竟然在配置 address 和 port 这不是直接继承的tcpconn?

这是 mc 协议里明文发的 可以填域名

[RPRX]

@Exclude0122 rebase

[Exclude0122]

@Exclude0122 rebase

好了

[RPRX]

对了，还得更名为 XMC，这样比较有辨识度

[Kc2353]

有一个小问题是这似乎不是真正的minecraft，似乎也不太好回落到真MC上，感觉介于XMC与header-Minecraft之间，我倒是觉得目前这个名字合适，毕竟XHTTP，XDNS，XICMP 都是真的通过标准的这些传输数据的
XMC希望还是明确为“XMinecraft”吧

[RPRX]

符合真实的 MC 协议规范就可以用 XMC 这个名字，主要还是一不做二不休，既然有了肯定迟早发展为 XMC

比如如果以后要出个 mod、需要 Xray 代码配合的话，也是直接加到 XMC，那就完全货真价实了

[Exclude0122]

改成 xmc 了

[RPRX]

@Exclude0122 不要只改配置，文件夹和代码里也要改，话说现在这个是标准 MC 规范吧

[Exclude0122]

都改成 xmc 了

是真 mc 协议，原版客户端可以 ping，也可以进服（开启加密后会被踢）

xmc.webm

[RPRX]

感觉有点像一个传输层了，或许本就该设计成传输层无限嵌套

[RPRX]

不过现在 Xray 里的传输层都不带加密，且能配合 TLS/REALITY，而这个带弱加密，所以先这样吧

[RPRX]

误点，@Exclude0122 这个能加个回落吗

[Exclude0122]

可以加回落，但是估计要改 xmc 外面 finalmask 的代码

[RPRX]

那先这样吧，反正 Finalmask 里的东西，以后要 breaking 也没关系