2017年5月追记：
我探索这些的目的，是以一个玩家的身份，让 CGSS 变得更好玩。私下里我类比过普罗米修斯，将天火——谱面的制作和玩的能力从“天上”分一点出来。其实，修改 CGSS 去作弊是很简单的，无论是客户端还是 MITM。但是我不会去作弊，也不希望这系列文章的读者们将文章内容用在歪门邪道上，不希望去作弊、破坏平衡性。玩过 LLSIF、SB69、GF(note)、Arcaea 之后，我仍然认为 CGSS 的综合指标（游戏性、操作体验、曲目等等）是行业内翘楚，Cy这次比较用心。那么作弊还有什么意思嘛！对了，我不氪金，不冲分，只是闲暇时间来两局，玩得舒心。
当然，まゆさまが見ています。
（2月21日）
一、声明
The Idolmaster Cinderella Girls Starlight Stage 软件和相关媒体的著作权为 Bandai Namco Entertainment Inc. 所有。本系列文章仅从兴趣出发，研究数据反向过程。在此不会给出完整的反向过程、反向结果和源代码，只给出思路和部分非关键数据。
我相信大牛即使是没有看过我写的这些玩意儿也能上的。
二、一切的起因
我2月15日时开始玩了CGSS，由于加入的第一天正好是一个送 star jewel 的活动的第一天，所以记得比较清楚。
然而，在音游上，我是个手残，至少初始状态下是个手残。开始的一周，在队伍的life值（可以认为是HP）还不高、没“奶妈”（恢复life）卡等因素的共同作用下，打 Regular 难度，终盘都半死不活。你或许会问，多练习不就好了？的确如此，不过运营商怎么赚钱呢？很简单，限制你的练习次数。游戏中有一个叫做体力槽（スタミナゲージ，stamina gauge）的东西，每玩一首歌（“打歌”）就要消耗一定的体力。这个体力是会慢慢涨回去的，5分钟一点；然而一首歌的消耗随难度不同在11点到20点之间。体力槽上限我现在见过的是81点。所以各位可以计算一下，平均多久才能打一首歌。体力可以氪金，或者通过掉落频率较少的物品来补充。——看到这里，想必之前不知道的同学也理解了收钱的方法了吧，和普通网游是差不多的。
但是！我等是有技术的，而不是萌豚，能用技术轰下的阵地就不会用钱砸。于是问题就很明显了，我们要根据已有的数据模拟出一个练手的东西出来。（不要想去伪造 HTTP 请求，破解是有底线的，不说错误的数据肯定会被检测到，就是刷出个全SSR又有什么意思呢？卖？那就和苟活的人没区别了。）
Q: 有没有会嗤笑这个的成品呢？
A: 当然，这些人会：1、对 CGSS 无感的；2、有时间肝（花大量时间打游戏）的；3、有钱氪（课金，中文叫充值）的；4、手巧的。以上几项我一个都不符合，也没什么“本命”（非常喜欢某个角色）一说，所以，既然是数据，我们就用数据的手段来一决雌雄吧！
（注：在修订此文章的3月16日，经过一个月的练习，我的技术已经达到了能几乎FC17星的曲目、23星存活没问题、24-25星试一次的水平。除去队伍强化（从最初一张R其他N，到现在全队至少是R）的因素，技术确实是提高了。离大触还很远，不过比自己进步了许多。看来这和练钢琴是差不多的。）
三、目标分析
CGSS 的玩法属于音游，大致由这些元素构成：
- 歌曲播放；
- 跟着节奏点击操作的质量判断；
- 评分；
- 显示；
- 社交（好友、任务）；
- 扭蛋（抽卡）；
- 卡片管理；
- Communication（类似 gal game 的东西）。
CGSS 有点特殊的地方是有一个 3D Live 的选项，这是通过 Unity 实现的，我们没必要还原这个，按下不表。另外，显示部分可以做得简单一些，因为我们做的是一个模拟程序，而不是对游戏的精确还原。再说了，完全反向所需的精力十分巨大，产出远不如投入（还会被告），根本没必要。除去其他和我们的目的不相关的元素，我们需要实现的有：
- 歌曲播放；
- 点击判断；
- 分数计算；
- 综合显示。
有了明确的目标之后，就开始逐个击破。
判断和显示是要自己写的，而文件是要读取的。在玩的时候，已经下载的歌曲是不会再下载的；因此，先解决歌曲文件和 beatmap（谱面）的位置和读取问题。
四、文件粗略分析
首先将 Android 上的数据拷贝一份。数据在哪里呢？熟悉 Android 开发的同学们应该熟悉 Environment.getExternalFilesDir() 这个 API，映射到的是 /mnt/sdcard/Android/data/{app_id}/files，是各种外部数据的存放位置。我是在浏览文件管理器的时候偶然发现的。看总大小（500M，CGSS 的安装包<50M），应该就是外部数据了。
复制之后结构应该是这样的：
F:\TEMP\root>tree
卷 Software 的文件夹 PATH 列表
卷序列号为 XXXX-XXXX
F:.
└─Android
└─data
└─jp.co.bandainamcoent.BNEI0242
├─cache
│ ├─tmp
│ └─UnityShaderCache
└─files
├─a
├─b
├─c
├─l
├─manifest
├─r
├─s
└─v
注意到一个很特殊的目录 manifest，其他的目录名字都是不明所以的单字母，只有这个非常显眼。打开之后可以发现，目录内有且只有一个文件：
F:\TEMP\root\Android\data\jp.co.bandainamcoent.BNEI0242\files>dir manifest
驱动器 F 中的卷是 Software
卷的序列号是 XXXX-XXXX
F:\TEMP\root\Android\data\jp.co.bandainamcoent.BNEI0242\files\manifest 的目录
2016/02/21 08:42 <DIR> .
2016/02/21 08:42 <DIR> ..
2016/02/16 17:17 1,269,760 cceff7e658530cf7c8bf96901ef77d7e85dd436b
这个文件是一个什么东西？试试用 Notepad++ 打开：
有点经验的同学应该立刻能反应过来：这是 SQLite 3 的数据库格式！而且，从常识上来说，SQLite 是嵌入式数据库的首选，在移动平台上有着广泛的应用，所以出现在这里是可信的。
于是我们就找一个 SQLite 数据库的浏览工具吧。这里我用的是 SQLiteStudio。
翻阅记录，加上一点直觉和对数据的敏感性，能大致判断记录项的意义。然而，最有趣的地方还是在这里：
这说明：
- 这个数据库很可能是货真价实的索引（因为仍在假设阶段）；
- 程序中用的很可能是明文，经过加工后成了现在看到的东西。
五、初步验证猜想
在玩的时候，有些歌曲是第一次运行时就下载了的。在玩的时候注意到这些情况：
- 歌曲的“开始”变成了“下载”，同时试听也没有了。点击“下载”则需要在“数据下载中界面”等待大概半分钟，然后试听就有了，歌曲也能正常玩了。
- 在开始一首歌的时候，有时候会有数据下载，但是一般都是十秒内结束。
- 有少见的情况，有试听，但是开始打歌的时候要等待比较长的时间；不过这都发生在上次歌曲下载没有完成我就强制退出（有时界面会无响应）的时候。
- 一般的打歌过程中，如果不换卡或者显示模式（3D/2D）是不会出现额外的下载过程的；而且明显这些文件是有缓存的。
- CGSS 的“通信中”和“数据下载中”是两个不同的状态。
因此可以判断，在点击“下载”的时候，是下载音频文件，而且包含试听和本体。第一次打歌的时候下载数据的包含谱面和一些其他素材。然后从时间上加以印证：贴吧上有人说过设置中切换音频质量，低质量一首大概 2M，高质量一首大概 3.5M，“不要问是怎么知道的”（其实就是因为ta用了流量，然后看到了账单嘛）。地址我没记下来，不过我记得应该是在偶像大师灰姑娘女孩星光舞台吧里的。这个数据很关键，综合 MP3 的一般大小，假设歌曲采用 MP3 CBR，那么低质量码率大概是 96~128 Kbps，高质量大概是 192~224 Kbps，歌曲时间在2~2.5分钟——这和我的耳朵&手机时间告诉我的相吻合。因此也可以判断，不管对方采用什么样的音频编码，其压缩率应该和 MP3 接近。
虽然歌曲的标题不知道，但是可以注意到歌曲的数量。这个数量怎么得到呢？上图中有一个 song_*，数据库中还有一些 name 值为 musicscores_* 的记录。不过由于这个“score”在当前语境中有多种可能意思：曲谱（即使不太可能）、分数、谱面（我一开始假设谱面是分开存放的，这个文件和音乐强相关，有可能是谱面），暂时还不知道设计者采用这个词的时候是想着哪一种。这里又遇到了一个挫折：（2月16日版的）数据库中的这两条记录数量都超过了发行的歌曲数量，剔除了明显重复的之后也是。（现在再想一想，有可能是预告呢，呵呵。）
但是，峰回路转，不在这么明显的地方验证数量，我们换一个地方。经过一番过滤，我发现了一个突破口：
上面的文件，直接出现了歌名！对灰姑娘曲目有点了解的人，应该能一眼发现熟悉的歌曲。例如，3d_cutt_apple 明显是《アップルパイ・プリンセス》（Applepie Princess，十时爱梨角色CD曲），3d_cutt_twilight 明显是《Twilight Sky》（多田李衣菜角色CD曲）。另外，我们还知道，solo 卡（带有“ソロ”标记的卡）是可以打《お願い！シンデレラ》的 solo 版的——所以 3d_cutt_oneshin 还带一个 solo 的“姐妹”。同时文件名还显示，这些文件用于 Unity3D，很可能是显示的资源包。因此可以做出一个合理假设，这些记录和歌曲相关，而且和歌曲版本也有关系（估计是动作？好像某地提到了“cutter”，但是不知道意思），而且看起来一个文件对应一首（分版本的）歌。我查了一下 CGSS 的歌曲列表（2月21日快照），一共54首（《お願い！シンデレラ》不算 solo 版），刚好和相应记录数量吻合。因此可以判断，不管歌曲有没有下载下来，这个数据库存储的都是完整的、最新的资源列表。
有了以上的关键提示，我们能确定要解析的目标的大概质量和体量（文件大小、内容量）了。但是现在遇到一个问题：文件名全都是莫名其妙的随机串，并不是直白的文件名。
看看，数据库中不是有一个 hash 列吗？有没有可能代码中有个函数用的是这个散列值呢？于是我写了一个小程序，进行了散列值-文件名的交叉比对，结果是我猜错了。（当然，BNEI 的程序员应该不会弄一个这么明显的东西出来。）不过为什么找不到呢？我突然发现，二者长度不相等，数据库中的值是128位的（32×4），文件名是160位的（40×4）。熟悉的同学也应该一眼就看出来了——这不就是 MD5 和 SHA-1 吗？但是知道了又能怎么样，这只是信息摘要，还不知道原始信息是什么呢。（读者可以看着这些值试试，很可能在这里就得出了我后来才得出的结论。）那么二者的功能就很明显了——MD5 用来校验文件完整性，SHA-1 来散列文件名。
走到这一步，对 CGSS 的数据目录结构有了个大体的认知，不过还是没有实际的用处。接下来，就应该推进到文件内容了。