Google Cast协议v2已经被广泛反向设计,因此已经众所周知。一个很好的例子是Cast v2 Node library repository on GitHub,其中包括cast v2协议的详细描述。
然而,在使用Netty在Java中编写我自己的协议实现时,我意识到auth响应消息比链接存储库中描述的更复杂。
根据存储库,消息应如下所示:
message AuthResponse {
required bytes signature = 1;
required bytes client_auth_certificate = 2;
repeated bytes client_ca = 3;
}
但是,客户端再发送3个字段。他们有指数4,6和7。
字段4是线型VARINT
,据我所知,对于SignatureAlgorithm,支持Cast的设备(Chromecast Gen2和Chromecast Audio)一直受到挑战。
Field 6也是VARINT
类型,但我不知道它代表什么。在测试期间,它总是具有值0.(也许它代表用于签署client_ca
的client_auth_certificate
证书?)
场7是线型LENGTH_DELIMITED
。它绝对不是一个UTF-8编码的字符串,因为打印它会导致无法读取的混乱。但是,打印出来的序列包含client_ca
和client_auth_certificate
中使用的完整地址,所以我认为它与它有关。我已经测试过这可能是证书还是RSA密钥,但两个测试都是否定的。可以找到包含原始字节序列的文件here。
这最终让我想到了我的问题:
你知道6和7代表哪些字段?基于文件结构的猜测也受到高度赞赏。
正如我发现的那样,该协议实际上是开源的,因为Chromium项目包含相应的.proto文件,以支持在启用Cast的设备上进行流式传输。
完整的协议可以在这里找到:https://github.com/chromium/chromium/blob/master/components/cast_channel/proto/cast_channel.proto
因此,AuthResponse消息的结构
message AuthResponse {
required bytes signature = 1;
required bytes client_auth_certificate = 2;
repeated bytes intermediate_certificate = 3;
optional SignatureAlgorithm signature_algorithm = 4
[default = RSASSA_PKCS1v15];
optional bytes sender_nonce = 5;
optional HashAlgorithm hash_algorithm = 6 [default = SHA1];
optional bytes crl = 7;
}