NW.js 有一个或两个上下文，使用时要多加小心。
| 文章存档 | 技术乱炖 | 二维空间 | 所思所想 | English |
|
NW.js 有一个或两个上下文，使用时要多加小心。
以前我写过钢壳都市雷吉欧斯中的告白台词。今天我又看到了一出打动人的浪漫戏，《老虎和兔子》（Tiger and Bunny）第15集。嗯，这集本身是一个插曲，但也是主线剧情的关键转折点之一。
注意：本文有（严重）剧透。
中文版本见这里。
Recently CRI Middleware updated their latest ACB archives’ format, and they seemed to have updated encryption of HCA files as well. As a result, the old toolsets can do nothing on the updated files. After about 20 hours of research I finally found what they changed on the decryption. Might be the first in the world, again. This is what’s called “highlight” in reverse engineering. XD
The final answer is somewhat simple: transform the decryption key, and use the transformed key to initialize the decryption table. The formula is key' = key * ((uint64_t)(k2 << 16) | (uint16_t)(~k2 + 2)) where key is the input key and k2 is a secondary key stored in the higher 16 bits of “field alignment” field, in each ACB/AWB file.
This article is about the way and thoughts of finding this transformation. It is roughly recorded in time order. I hope this materials may help someone in the future.
My result is based on various people’s works. Without thoses pieces, the whole puzzle cannot be completed. So a big thank you for everyone involved.
Be noted again: the contents in this article must not be used for commercial purposes.
English version can be found here.
近日 CRI ACB 格式更新，连带着 HCA 加密“升级”，旧轮子全员阵亡。在经过二十多个小时的研究后，我找到了关键的修改，搞定了解密。可能又是全球第一个呢。做反向，最激动人心的就是这样的时刻。XD
最终的答案很简单，就是在解密之前，进行密钥变换，并二次初始化解密表：key' = key * ((uint64_t)(k2 << 16) | (uint16_t)(~k2 + 2))，其中 k2 保存在每个 AWB 中的字段对齐的值的高16位。
这篇文章讲的是我找出这个变换的过程，包括思路和操作，基本上按照时间顺序记录。希望在未来会对某人有所帮助。
总的来说，这次的成果是建立在众人的工作基础上，没有这些碎片，就无法拼成完整的拼图。在此要向各位致谢。
再次强调，本文内容不可用于商业用途。
因为这7个月（或许可以说是一年多）以来的种种事情，虽然有一些破碎的文字，但是没有写文章的动力，所以博客更新断了很多。雪球滚到后面，甚至都不想再打开来写了。
到现在情况稳定了一些。所以决定继续更新，并尽量将之前只有些许句子的东西写完。发布时间将仍然按照记录的时间，所以可能之后见到的一些更新是来自今年二月、三月等等的文章，首页可能就没太大的变化。还是 RSS 好啊。
* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）
这篇文章讲一下土豆的物理。物理我没完全做好，但是至少做到了可以接受的程度。一些改进的想法我放到了代码注释中，有兴趣的人可以尝试实现一下。
* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）
这篇文章讲解土豆的摄像机数据。
10月更新：近日在测试玩具的时候，发现 Unity 是直接支持 F-Curve 的（见 KeyFrame 的文档），而且其构造函数已经清楚地说明了值的意义。是我孤陋寡闻了。
* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）
有了前两篇文章打下的基础，终于到了最重要的一个部分，就是动作数据在两套骨骼之间的变换。
这里要特别感谢丧丝，他在转换烧笋（CGSS）到 PES（实况足球）的时候想出了这个方法的大概，不过“还是很模糊，不知道是怎么做出来的”。我不过是将其证明了而已。方法的核心也是非常之简单。
后面讲土豆骨骼和 MMD 骨骼的异同，以及如何（与 TDA 式）做到较好的兼容。这部分其实不看也行，如果你比较熟悉 MMD 的话。比如标准 T-pose 变换为其他样式的初始姿态（比如 TDA 的±34°），这一步也可以通过 PMX Editor 搞定，不过我还是想程序一步到位。反正我不熟，所以大致地讲一些经验，能有原理就最好。
对了，还有 IK。
* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）
在这篇文章里，我讲一下土豆的模型网格（mesh）和骨骼（skeleton）。虽然贴图是我后来才加上去的，不过考虑到叙述顺序，还是放到这里一起讲。
* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）
最近做了一点微小的工作，提取了土豆的模型和动作，并（可选地）转换到了 MMD 系的格式。为什么是 MMD 呢？虽然它的功能十分简陋，但是毕竟是当今最大的爱好者所使用的、较为开放的平台。
下面这个系列文章的目录。
以后可能做（做了以后找时间写）也可能鸽的：
代码位于 GitHub。
我肯定不是第一个完成这事儿的人，因为早就有列表了。上面标称是“トレス”（trace，临摹），但那精度怎么看都像是直接提取的。还有，我前几天玩 VRChat 的时候，就发现有人把土豆的剧场都做进去了：入口、几个房间、舞台（甚至还有一周年的舞台！），一些模型（能看到有bba的限定泳装，说明是不久前弄的)。在游戏中搜索“iDOLM@STER”就能找到。因此我推测有一个十分便捷的工具或者方法，能将 asset bundle 里的模型整体地提取出来或者以其他方式使用，但是我还不知道。我没去 XeNTaX 看过，不过那地方高手云集，应该也有人做了。
我已经将工具公布了。我并不会像某位仁兄一样拿着别人的成果到国内某视频站上不加来源（我开始还以为是他自己完成的，结果我还没问他就自己爆料了还行），吊人胃口，然后在私人群里二次配布（无论有没有获得初次提取者的授权）。以上属于二级信源，并没有完全确认。我写这个系列有两个目的，一个是科普，另一个就是狠狠打脸。这些数据的版权万代肯定是不会下放的。所以各位也自己注意点。
相关测试视频：
《超能力女儿》（ひなまつり）的ED，《鮭とイクラと893と娘》。附带一些科普和私货。
应该是好几个月之前了，MLTD 用了新的加密额外的混淆和保护（AppGuard；不过仍然被大佬脱壳了），这次会检测程序完整性。因此之前取密钥的方式（中间人）就不能用了。可能以后真得要去hook系统 API，dlopen 什么的，或者自建沙箱。
关于它的网络部分，我已经没精力去做了。对我来说，双线作战，还要还原 D2D1，还有 Vanishing，工作量已经不小。还有一些内部因素。应该不会像以前那样能用整个晚上来跟踪和分析 ARM 汇编了。仔细想想开的项目全是个人项目，而且有些相当硬核，开得越多战线越长，渐渐就被拖垮了。啊好像草菇的网络也好久没去维护了。总之已经退出了第一线数月。
然而我的兴趣不是在查询和计分上。我又不打分，别人打不打我无所谓。而且就为了在游戏中打出高分的假需求，集成现有的 API，这种活儿太无聊了。一般用户希望拿到的是一个好用的工具，比如app，这对于他们来说是最容易理解和使用的。不过我是想去开辟可能性的，开发用户应用的就踩着我的肩膀前进吧。哦对还有，我大概是老古董了，对智能手机有着本能的抗拒。
MilliSim 其实也逐渐成在往通用引擎上走，就跟 osu Framework 那样。但是我在尽量解耦，也一直在想 MilliSim 的意义是什么。从一开始对谱面的系统感兴趣，做来做去发现也就是那么一回事；现在逐渐又想看小姐姐跳舞了，而且就算是音游也会有相应的 BGA；于是又在想我为什么想看小姐姐跳舞，音游这个载体（是音游，自然前景要有谱面，和背景是什么关系呢）对我来说是不是过时了。这样下去会成艺术指导吗？变来变去什么时候是个头呢？
可笑，虽然能把计算机系统看得很清楚，但是对未来和目标（假如是唯一的话）却根本看不见。
这篇文章本来想复用以前的 FFmpeg+SDL2 以及 FFmpeg+OpenAL 两篇。但是所用的语言不同，所以设计有差异；FFmpeg 的 API 更新（用的是3.4，当前最新的版本）也要求使用新的 send/receive 解码模型。这次的代码是从零开始一步一步写的，比起以前没搞懂，凭着模糊的直觉复制粘贴去做的那两篇，算是有所长进。我终于敢说，整个流程弄清楚了。
这个工程的考虑就不只是网上的那些“简单的播放器”的那么一点了，我本来也没想把它做得多“简单”，只是写得尽量简明。目标是一个成熟、稳定的库，就得十分注意正确性、鲁棒性和效率。编写过程中也碰到了一些困难，所幸都解决了。
文章分为六个部分。第一部分讲基本概念；第二部分讲视音频解码；第三部分讲同步控制；第四部分讲解码输出；第五部分讲工程中用到的一些细节的设计思路；最后一个部分讲一些对比和想法和现状讨论。（原本放在首页的大段文字都放在了文章最后部分，不想让“摘要”看起来太乱。）
代码位于 GitHub。
为什么要在 WSL 上运行呢？因为今天在虚拟机里测试的时候偶然发现，云音乐的 Linux 客户端无视了大部分播放限制，比起 Windows 客户端要不知高到哪里去了。——这是一条新的路，不是俗套的本地代理。我一直是挂着代理用云音乐，但是毕竟代理有速度（勉强能接受）和隐私两个问题；还有一个无法下载封面的副作用。
发现了这个有意思的东西之后，我首先测试这是不是因为网络连接方式的不同导致的。如果两个客户端的内部逻辑是一样的，那么在不在虚拟机内应该不会影响可播放与否。除此之外就可能是客户端的逻辑不同了。不管是哪一种，都需要 WSL 来测试。WSL 和主机是共享端口和硬件的，所以不存在虚拟硬件，也不存在桥接，在服务器看来和其宿主是一样的。正好作为实验组。
为了验证猜想，同时也是解决代理带来的问题，我决定在 WSL 上运行云音乐客户端。
摸索试验花了五个小时（包括本文开始写作之后），大概有了一套理论，不过仍然有暗坑。使用注意。