如果您是华立运营或者翻译：本文自带日语翻译。在向世嘉方提出时，请优先考虑审核而不是修改。如果可以的话，请在向世嘉方面提出时，同时带上本文章的 URL（作为原文参考）。如果能让世嘉方面看到玩家们对于此文章提出观点的支持，可能可以改变一些东西。有劳您了。
セガスタッフの皆様へ：
本手紙の日本語翻訳は、「maimaiでらっくすプレイヤーによりセガフェーブ株式会社と華立科技有限公司へのお願いについて」というタイトル以降に記載されております。ご確認の際は、お手数ですがブラウザのテキスト検索機能にて当該タイトルを検索いただけますと幸いです。
また、本書簡には貴社の技術ご担当者様にとって有益となり得る内容も含まれております。可能でございましたら、本書簡のリンクを関連部署・ご担当者様へもご共有いただけますと大変ありがたく存じます。ご協力のほど、何卒よろしくお願い申し上げます。
对于一般读者：作者没有收益，如果点赞或转发此文章，将是对于解决问题极大的帮助。我们迫切需要让世嘉侧看到一些数字，来让他们动起来。此篇请愿的编写参照了一些来源未知的研究，请自行辨别真假。
舞萌DX玩家致世嘉Fave和华立的一封信 (中文版)
致长年以来运营舞萌DX的世嘉 Fave 公司和华立科技有限公司的相关人员：
您好。
我是熊谷凌，一个《舞萌DX》的忠实玩家。非常感谢您长期以来对《舞萌DX》稳定运营所付出的努力。
然而，我注意到，在近期《舞萌DX》发生了不少的恶意攻击事件。根据我们对事件的分析，有一些攻击者利用了贵司系统的缺陷，对正常游玩《舞萌DX》的玩家的账号进行了恶意攻击。并且，这些缺陷跟违法机台有一定联系。
您或许会认为这是运营不当，认为运营没有做到安抚玩家的职责；或者认为这是玩家的作弊事件，想要在几个月后根据条件筛查并封禁玩家的账号。
然而，我们想要让您知道一点——这并不是华立方面的运营能够解决的问题，并且华立方面的运营实际上对于目前的状况回天乏术。华立公司迫切需要来自世嘉Fave株式会社的合作。并且，我认为这类的攻击并不属于玩家作弊。目前的攻击已经严重影响到了玩家的正常游玩，在我看来，玩家是没有理由进行会妨碍自己游玩的作弊的。
类似于这样的，基于系统缺陷的攻击并不是第一次。根据前几次华立方面采取的措施，不难推测华立方面可能并没有解决问题所需要的能力或者许可。如果真是这样的话，我们由衷希望世嘉方面能和华立方面进一步合作解决目前的问题，而不是令一方独自决断。
为了保证游戏的良好环境，除了游戏运营正在努力，玩家们也在尽力调查。根据玩家侧对于违法机台和以往黑客攻击的一些调查，我们了解到攻击原因来自于贵司《舞萌DX》和《中二节奏》都在使用的 AuthLite 系统的缺陷。
由于贵司 AuthLite 和标题服务器进行通讯时，使用的用户ID是固定不变的，攻击者可以利用已有代码，于违法机台对数据库进行扫描，从而得到所有用户的账号信息。通过这样的方式，攻击者可以使用任一用户的身份进行登录，从而篡改服务器数据，影响该用户的正常游玩。
想必华立方面已经注意到了这一点，但是根据前述的推理，他们可能并没有能力施行对于此类攻击的对策。我们也由衷希望世嘉方面能够了解到这一点，并支持华立方面的工作。
我在作为玩家的同时，也是一个业余后端开发者。我深切理解到对数据库本身进行修改的困难性，但目前如果不进行关于此方面的修正，恐怕会影响到更多的用户。因此，我想在这里提出一个可行的解决方案，希望能为世嘉方面的修正提供一定参考。
考虑到不可能修改用户ID本身的值，不妨在服务器向机台返回用户ID时，对用户ID做一次可逆的、基于密钥的变换。
首先，不妨考虑使用 HMAC-SHA256 或 AES-CMAC 算法，利用当日的日期（在第二天的维护时间之前仍算作前一天）及一些由世嘉方面决定的“盐”数据生成一份 256 位的“tweak”数据。密钥相关数据和算法不应向华立方面共享。
由于该数据的生成算法不具备副作用或状态，因此可以在每次请求时算出，这样不仅不需要使用任何额外用于存储该数据的空间，还因为可以直接复用代码而无需使得 AuthLite 服务器和标题服务器耦合。
接下来，我们定义一个强伪随机函数（PRF），其利用“tweak”数据、接下来提到的 Feistel 变换的当前轮数和当前加密中的数值的低 16 位，返回一个 16 位的强随机值。在函数中，我们同样利用 HMAC-SHA256 或 AES-CMAC 算法生成一个子密钥，并取结果的低 16 位。
例如，以下是上述两个函数的可能的伪代码定义。
接下来，在服务器返回用户ID时，我们将 32 位的用户ID分成左右两半（各 16 位），并对其做数轮 Feistel 变换。假设我们将进行 N 轮变换。为了兼顾服务器性能与安全性，我建议 N = 10。
首先，我们令 L 为用户ID的高16位值，R 为用户ID的低16位值，使得 current_round = 0，并令 current_round 最终为 (N - 1)。
对于每一轮，我们令 F = PRF16(master_key, current_round, R, tweak)，令 newL = R, newR = L xor F，然后令 L = newL，R = newR，完成两边的交换。最终，我们将低16位和高16位使用 (L << 16) | R 拼接起来，并返回加密后的值。
机台侧无需进行任何解密，可以直接将返回的 ID 用于请求。
在服务器处理用户ID时，只需进行上述变换的逆运算，即可算出原始的用户ID。以下简单介绍逆运算的方式。
使用加密运算中提到的 N 值。使得 current_round = N - 1，并令 current_round 最终为 0。令 L 为加密值的高16位值，R 为加密值的低16位值。
对于每一轮，我们令 F = PRF16(master_key, current_round, L, tweak)。令 newR = L，newL = R xor F，然后令 L = newL，R = newR，完成两边的交换。最终，我们同样将低 16 位和高 16 位拼接，就可以求得原来用户 ID。
以下是上述算法的伪代码。
这样，服务器将不会向机台泄露任何敏感信息，而机台也无需进行任何变更。
这样一来，用户ID的值会变得毫无逻辑，并且每天都会变更，我认为可以很好地防御黑客攻击。
需要注意的是，贵司的《头文字D》也在使用 AuthLite 系统。然而《头文字D》没有《舞萌DX》的黑客攻击问题，不需要应用此变换。所以，在返回用户ID时，可能需要对游戏类型进行检查。此外，该修复只应在中国大陆区域应用。
我对相关加密的安全性进行了一定程度的研究，也收到了来自其它技术人员的指摘，最终确定此方案是目前最可靠且最容易实装的。想必您肯定会想要考虑其它方案，然而其它方案的安全性和简便性很可能并不如此方案，并且可能会导致贵司的游戏服务器面临再度被攻击的风险。
即使此方案的技术细节在这里被公开，只要世嘉方面不泄露密钥就不会影响其安全性。考虑到我们已经尽自己所能最大限度地提供了实现参考用的技术细节，请务必考虑使用我们提出的方案。非常感谢您的理解。
我们深刻理解，这样的解决方案即使并不用变更数据库，也会导致《舞萌DX》和《中二节奏》标题服务器逻辑的大规模变更。然而，如果不尽快解决这个问题，玩家的游戏体验会受到严重负面影响，因而可能对贵司未来的发展造成不利影响，这是所有人都不希望看到的。
因此，我们在这里诚恳地向所有相关人士请愿。请务必在近日重新考虑应对黑客攻击的方案。
非常感谢您的理解。同时，再次感谢所有相关人员对此游戏做出的努力。
舞萌DX的全体玩家
敬上
maimaiでらっくすプレイヤーによりセガフェーブ株式会社と華立科技有限公司へのお願いについて (日本語翻訳)
長い間「maimai でらっくす」というタイトルを運営してくださっているセガフェーブ株式会社ならびに華立科技有限公司の関係者の皆様へ：
こんにちは。
熊谷凌と申します。私は「maimai でらっくす」の忠実なプレイヤーの一人です。長年にわたり「maimai でらっくす」の安定した運営にご尽力いただいておりますこと、心より感謝申し上げます。
しかしながら、近頃「maimai でらっくす」において数多くの悪意ある攻撃事件が発生していることに気付きました。私たちの分析によれば、一部の攻撃者が貴社システムの脆弱性を悪用し、正しく「maimai でらっくす」をプレイしているプレイヤーのアカウントに対して不正な攻撃を仕掛けています。さらに、これらの脆弱性は違法筐体とも一定の関係があると考えられます。
もしかすると、このような事態について「運営の不手際」や「プレイヤーの不正行為」と捉え、数か月後に条件を満たしたアカウントを停止するという対応を検討されているかもしれません。
しかしながら、私たちが強調したいのは――この問題は華立様側の運営のみで解決できるものではなく、現状においては華立様側の運営が手を尽くしても限界があるという点です。華立様には、セガフェーブ株式会社からの協力が切実に必要です。そして、今回の攻撃はプレイヤーの「不正行為」には該当しないと私は考えております。現在の攻撃はすでにプレイヤーの正常なプレイ体験を深刻に損なっており、プレイヤーが自ら進んで自分の遊びを妨げる行為をする理由は存在しません。
このようにシステムの脆弱性を突いた攻撃は今回が初めてではございません。過去の事例で華立様が取られた対応から推測するに、華立様には問題解決に必要な能力や権限が十分に備わっていない可能性があります。もしそうであるならば、セガ様と華立様がさらなる協力関係を築き、問題解決にあたっていただきたいと切に願います。どちらか一方に負担を押し付けることは望ましい姿ではありません。
良好なゲーム環境を維持するために、運営の努力のみならず、プレイヤー側も調査を続けています。プレイヤーによる違法筐体や過去のハッキング事件の調査から、攻撃の原因は貴社「maimai でらっくす」および「CHUNITHM」で使用されている AuthLite システムの脆弱性にあることがわかりました。
AuthLite がタイトルサーバーと通信を行う際、ユーザーIDが固定値で使用されているため、攻撃者は既存のコードを悪用して違法筐体上からデータベースを走査し、すべてのユーザーアカウント情報を取得できてしまいます。その結果、攻撃者は任意のユーザーになりすましてログインし、サーバーデータを改ざんすることで、そのユーザーの正常なプレイを妨害できるのです。
華立様におかれてはすでにこの点に気付かれていると思いますが、前述の推測のとおり、この種の攻撃に対抗する手段を実行する能力がないのではないかと考えられます。私たちは、セガ様にもこの事実を十分にご認識いただき、華立様の取り組みを支援していただけるよう心より願っております。
私はプレイヤーであると同時に、アマチュアのバックエンド開発者でもございます。データベースそのものを修正することがいかに困難であるかは、私自身も深く理解しております。しかしながら、この分野に関して何らかの修正が施されないままでは、より多くのユーザーの皆様にご迷惑をおかけする結果となる恐れがございます。つきましては、誠に僭越ながら、私から一つの実行可能な解決策をご提案申し上げ、世嘉様におかれましてご検討の一助となればと存じます。
ユーザーIDそのものの値を直接変更することは困難であると考えられますため、サーバーが筐体にユーザーIDを返却する際に、秘密鍵に基づく可逆的な変換を適用する方法をご提案いたします。
まず、当日の日付（翌日の定期メンテナンス開始時刻までは前日として扱う）と、世嘉様が独自に決定される「ソルト」データを用い、HMAC-SHA256 または AES-CMAC のいずれかのアルゴリズムにより、256 ビット長の「tweak（トゥイーク）」データを生成いたします。なお、鍵関連の情報や生成方法につきましては、華立様とは共有されないことが望ましいと存じます。
この生成方式は副作用や状態を持たず、毎回のリクエスト時に再計算が可能でございます。そのため、追加の記憶領域を必要とせず、また既存コードの再利用によって AuthLite サーバーとタイトルサーバーを密結合させる必要もございません。
次に、この tweak データを利用し、さらに後述の Feistel 変換のラウンド数および現在処理中の値の下位16ビットを組み合わせて、16ビットの擬似乱数値を生成する強力な疑似乱数関数（PRF）を定義いたします。本関数においても HMAC-SHA256 または AES-CMAC を用い、生成結果の下位16ビットを利用する形となります。
以下に、上記の概念に基づいた擬似コード例を示しております。
続きまして、サーバーがユーザーIDを返却する際の手順でございます。32 ビットのユーザーIDを高16ビット（L）と低16ビット（R）に分割し、Feistel 構造による複数ラウンドの変換を実施いたします。性能と安全性の両立を鑑み、ここではラウンド数 N = 10 を推奨申し上げます。
暗号化の流れは以下の通りでございます：
L をユーザーID の高16ビット、R を低16ビットとし、current_round を 0 に設定いたします（最終ラウンドは N - 1 となります）。
各ラウンドにおいて F = PRF16(master_key, current_round, R, tweak) を算出いたします。
newL = R、newR = L xor F を計算し、L = newL、R = newR として左右を交換いたします。
上記を current_round が N - 1 に到達するまで繰り返します。
最終的に (L << 16) | R により再構成された 32 ビット値を返却することで、暗号化済みのユーザーIDを得ます。
筐体側では復号処理を一切行う必要がなく、そのまま返却された ID を利用可能でございます。
一方、サーバー側においては、上記の逆変換を施すことで元のユーザーID を復元できます。逆変換の概要は以下の通りでございます：
current_round を N - 1 に設定し、最終的に 0 となるまで逆順で処理を行います。
暗号化値の高16ビットを L、低16ビットを R といたします。
各ラウンドで F = PRF16(master_key, current_round, L, tweak) を算出いたします。
newR = L、newL = R xor F を計算し、L = newL、R = newR として左右を交換いたします。
current_round が 0 に到達するまで繰り返し、最後に (L << 16) | R をとることで、元のユーザーIDを得ることが可能でございます。
以下に、この逆変換を含むアルゴリズムの擬似コードを示しております。
この方式を導入いただくことで、サーバーは筐体に対して一切の機密情報を漏洩することなく、また筐体側にも改修を必要としない形で処理が可能となります。
その結果、ユーザーID の値は一見無作為なものとなり、かつ日次で変更されるため、ハッキング攻撃に対して極めて有効な防御策となると確信しております。
なお、貴社の「頭文字D」も AuthLite を使用しておりますが、「頭文字D」には「maimai でらっくす」のようなハッキング被害は発生していないため、本変換を適用する必要はございません。したがって、ユーザーID返却時にゲームタイトルを判定する処理が必要になると考えられます。また、本修正は中国本土地域のみに適用すべきものです。
私は関連する暗号技術の安全性について一定の調査を行い、また他の技術者の方々からのご指摘も頂戴いたしました。その結果、本提案の方式こそが、現時点において最も信頼性が高く、かつ実装も比較的容易であると判断いたしております。
もちろん、貴社におかれましては他の選択肢についてもご検討なさることと存じます。しかしながら、他の方式では本提案ほどの安全性と簡便性を兼ね備えることは難しく、結果として貴社のゲームサーバーが再び攻撃の危険に晒される可能性も否めません。
また、本提案の技術的詳細をここに記載しているとはいえ、セガ様におかれて鍵情報を厳格に管理していただける限り、その安全性が損なわれることはございません。私どもは実装のご参考となるよう、可能な限りの技術的情報を提示させていただきました。誠に恐縮ではございますが、ぜひとも本提案の採用をご検討賜りますよう、心よりお願い申し上げます。
もちろん、この解決策はデータベース構造を変更せずに済むとはいえ、「maimai でらっくす」と「CHUNITHM」のタイトルサーバーロジックに大規模な変更を伴います。しかし、早急に解決策を講じなければ、プレイヤーのゲーム体験は深刻に損なわれ、結果的に貴社の将来的な発展にも不利益を及ぼす恐れがございます。それは誰にとっても望まない事態です。
以上の理由から、私たちはここに心よりお願い申し上げます。どうか近日中に、ハッキング攻撃への対応策を再度ご検討ください。
ご理解に心より感謝申し上げるとともに、本タイトルに携わるすべての関係者の皆様のご尽力に改めて御礼申し上げます。
maimai でらっくす 全プレイヤー一同
敬具
