CGSS 核心反向过程实录 | 三、解密方法确认

文章目录
  1. 1. 一、声明
  2. 2. 二、转折:密钥,目标锁定

索引

2017年5月追记:

我探索这些的目的,是以一个玩家的身份,让 CGSS 变得更好玩。私下里我类比过普罗米修斯,将天火——谱面的制作和玩的能力从“天上”分一点出来。其实,修改 CGSS 去作弊是很简单的,无论是客户端还是 MITM。但是我不会去作弊,也不希望这系列文章的读者们将文章内容用在歪门邪道上,不希望去作弊、破坏平衡性。玩过 LLSIFSB69GF(note)Arcaea 之后,我仍然认为 CGSS 的综合指标(游戏性、操作体验、曲目等等)是行业内翘楚,Cy这次比较用心。那么作弊还有什么意思嘛!对了,我不氪金,不冲分,只是闲暇时间来两局,玩得舒心。

当然,まゆさまが見ています。

(3月3日8时-12时)


一、声明

The Idolmaster Cinderella Girls Starlight Stage 软件和相关媒体的著作权为 Bandai Namco Entertainment Inc. 所有。本系列文章仅从兴趣出发,研究数据反向过程。在此不会给出完整的反向过程、反向结果和源代码,只给出思路和部分非关键数据。

我相信大牛即使是没有看过我写的这些玩意儿也能上的。

二、转折:密钥,目标锁定

找到了 HCA 之后怎么办呢?我知道这个文件很可能是加密过的,但是加密方法未知,所需的解密参数未知。这样一个东西,怎么撬开呢?想起上次说过,ADX 文件是支持简单的 XOR 加密的。但是,即使如此,那3×16字节的密钥也无法暴力破解啊。

这里来一个小插曲。在3月8日晚间有了初步结果之后,对村长吐槽说暴力破解应该是不行的。

村长:“你应该用Q-Learning……今天刚学……trial&error……试错和暴力破解是两个概念啊”

我:“但是你反馈没用啊,密钥是在一个空间内随机分布的,没有收敛性”

村长:“如果无反馈怎么破解”

所以,想尝试用优化算法来干这事的就别想了。

又是 vgmstream 的周边给予了一个转折。在它的一个 feature request 中,有用户提到了加入 HCA 解码器的请求,并附上了一个 MEGA 链接,说是在日本某个公告板找到的。

还好,这个 MEGA 链接还没挂,我就赶快来了一份。其中有 Google 翻译翻译过的 readme,关于参数设置部分是这样的:

Decode The default option
  Volume = 1 (times)
  Bit mode = 16 (bit)
  Loop count = 0 (times)
  Keys that are used in the decryption key = 30DBE1ABCC554639 ※ PSO2
Is.

虽然有着浓厚的机翻味道,但是懂还是能懂的。数一数,唔,这个密钥是64位的。可信度如何呢?按照附带的调用示例,我试着输出了一下这个文件的信息:

C:\Users\MIC\Desktop\cgss-crack\_vgmt_acb_ext_8a79c100465ec1c6ffbfdb45cf86af36bf6425cf\acb\awb>hca -i song_1004.hca
song_1004.hca 偺僿僢僟忣曬
僐乕僨僢僋: HCA
僶乕僕儑儞: 2.0
僠儍儞僱儖悢: 僗僥儗僆 (2僠儍儞僱儖)
僒儞僾儕儞僌儗乕僩: 44100Hz
僽儘僢僋悢: 5260
愭摢柍壒僽儘僢僋悢: 0
枛旜柍壒僒儞僾儖悢丠: 727
價僢僩儗乕僩: CBR (屌掕價僢僩儗乕僩)
僽儘僢僋僒僀僘: 0x02AA
comp1: 1
comp2: 15
comp3: 1
comp4: 0
comp5: 128
comp6: 128
comp7: 0
comp8: 0
埫崋壔僞僀僾: 尞桳傝埫崋壔 仸惓偟偄尞傪巊傢側偄偲弌椡攇宍偑偍偐偟偔側傝傑偡丅

关注的重点是,这些输出看上去是合理的!这时候千万不要因为乱码而笑话,有点常识的人都知道,前文提到这个程序是来自日本公告板的,常量字符串就很可能是用 Shift-JIS(CP932)编码的,这样在一个 CP936(GBK)编码的控制台中输出,乱码并不奇怪。后来我重新编译了一下,有了可读的输出:

D:\Source\C\hca\bin\Debug>hca -i C:\Users\MIC\Desktop\cgss-crack\_vgmt_acb_ext_8a79c100465ec1c6ffbfdb45cf86af36bf6425cf\acb\awb\song_1004.hca
C:\Users\MIC\Desktop\cgss-crack\_vgmt_acb_ext_8a79c100465ec1c6ffbfdb45cf86af36bf6425cf\acb\awb\song_1004.hca のヘッダ情報
コーデック: HCA
バージョン: 2.0
チャンネル数: ステレオ (2チャンネル)
サンプリングレート: 44100Hz
ブロック数: 5260
先頭無音ブロック数: 0
末尾無音サンプル数?: 727
ビットレート: CBR (固定ビットレート)
ブロックサイズ: 0x02AA
comp1: 1
comp2: 15
comp3: 1
comp4: 0
comp5: 128
comp6: 128
comp7: 0
comp8: 0
暗号化タイプ: 鍵有り暗号化 ※正しい鍵を使わないと出力波形がおかしくなります。

翻译过来是这个样子的:

D:\Source\C\hca\bin\Debug>hca -i C:\Users\MIC\Desktop\cgss-crack\_vgmt_acb_ext_8a79c100465ec1c6ffbfdb45cf86af36bf6425cf\acb\awb\song_1004.hca
C:\Users\MIC\Desktop\cgss-crack\_vgmt_acb_ext_8a79c100465ec1c6ffbfdb45cf86af36bf6425cf\acb\awb\song_1004.hca 的标头信息
编解码器: HCA
版本: 2.0
声道数: 双声道 (2声道)
采样频率: 44100Hz
区块数: 5260
开头静音区块数: 0
末尾静音区块数?: 727
码率: CBR (固定码率)
区块大小: 0x02AA
comp1: 1
comp2: 15
comp3: 1
comp4: 0
comp5: 128
comp6: 128
comp7: 0
comp8: 0
加密类型: 带密钥的加密 ※若使用的(解密)密钥不正确,则输出的波形是不正常的。

说一下这个“静音区块”是怎么回事。在 ADX 的说明中也说过,为了对抗已知明文攻击(known-plaintext attack),ADX 的一些静音区块(半字节全零的区块)可能是不加密的。可以猜想 HCA 在头尾也嵌入了一些,如果加密方法“继承”了一点的话。


总之,虽然没仔细看这个解码器的源代码,但是就看着它的输出,可以假定这个解码器对当前版本的 HCA 是有用的。在这个假设的基础上,继续假设它的输入也是合理的、必需的、形式正确的。也就是说,我要寻找的东西,是且只是一个64位的密钥,而且可能会被拆分成两半。

分享到 评论