2017年5月追记：
我探索这些的目的，是以一个玩家的身份，让 CGSS 变得更好玩。私下里我类比过普罗米修斯，将天火——谱面的制作和玩的能力从“天上”分一点出来。其实，修改 CGSS 去作弊是很简单的，无论是客户端还是 MITM。但是我不会去作弊，也不希望这系列文章的读者们将文章内容用在歪门邪道上，不希望去作弊、破坏平衡性。玩过 LLSIF、SB69、GF(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位的密钥，而且可能会被拆分成两半。