効かないパッチ、動かないエミュレータ#

ここまでできれば解析自体は簡単なはずでした。

PRNG が生成する値(シード値)をパッチで上書きして、実際にサーモンランのゲーム内容が変更することを確かめて、シード値からどんな WAVE が発生するかがわかればシード値から WAVE 内容を決定するアルゴリズムの解析が進みます。

ところが、パッチを当ててもゲーム内容は変更されないだけでなく、そもそもゲーム開始時に PRNG が動作していないことがわかりました。

これ以上の解析をするには実機では大変なので、エミュレータでテストをしようとしたのですが macOS 向けのニンテンドースイッチのエミュレータは当時ありませんでした。これ以上することもないので、ここで解析は一旦打ち止めになりました。

シナリオコードの問題点#

とはいえ、シナリオコードはシード固定と比較して以下の点で劣りました。

• シナリオコードからシード値がわからない
• 好きなシナリオコードを設定することができない
  • 誰かが公開していなければいけない
• シナリオコード取得にはいちいちクマサン商会の端末を使わないといけない
  • イカリング 3 からコードを発行できれば楽だったはず
• ステージ、キケン度が選択できない
  • プライベートバイトのものであればブキだけは変更できる

なので、例えばプライベートバイトで低キケン度で遊んでいてめちゃくちゃいいシードだったとしても、発行したシナリオコードを使ってステージやキケン度を変えて遊ぶことができないというわけです。

しかもプライベートバイトでは 200%以上のキケン度が指定できないので、実質的にプライベートバイトでは使い物になりませんでした。また、この頃はアプリ開発が忙しかったため、解析に充てる時間はありませんでした。

セーブデータの復号#

とはいえ、セーブデータは暗号化されているのでそのまま直接中身を見ることはできません。ただ、シナリオコードが本当にセーブデータに保存されているかもわからなかったのでスプラトゥーン界隈エンジニアで頂点に君臨するメンバーの一人である shadowninja108 氏にコンタクトをとってみることにしました。

やり取りの結果「セーブデータにシナリオコードがあること」というだけでなく「セーブデータをくれたら復号して渡すよ」とまで言ってくれました。で、試しに送ってみたら本当に復号された JSON が返ってきました。

「セーブデータを復号するツールがあるのか」ときいてみたのですがどうやらプライベート用らしく、一般リリースはしていないのことでした。ここでクレクレくんをしても良かったのですが、未リリースのものでも shadowninja108 氏は言わなくても勝手にくれることが多かったので「何も言わずにツールを送ってこないということは自分でやれということだな」と謎の解釈をしてセーブデータの復号にチャレンジすることにしました。

ただ、ツール自体は頂けなかったものの(そもそもくれと言ってはいないのだが)、SHA256 と MurmurHash が使われていること、セーブデータのヘッダーにキーがあることなどは教えてくれたのでそれを使って自力でセーブデータを復号することにしました。

以下、回想を中止してちょっとだけ技術的な内容。

暗号化#

暗号化に必要なのは読めないようにしたい「平文」と「鍵」と「暗号化方式」の三つです。

それぞれについて大雑把に解説すると以下のようになります。

• 平文
  • 暗号化される前の文章
• 鍵
  • 平文を暗号化する、暗号文を復号する場合に使われる
  • 公開鍵暗号では暗号化と復号で異なる鍵を使うが、今回は共通鍵の場合のみを考える
• 暗号化方式(アルゴリズム)
  • 鍵と平文から暗号文を作る方法
  • 同じ鍵と平文を使えば毎回同じ暗号文が出力される
• 暗号文
  • 暗号化された文章

アルゴリズムとは何だと思われるかもしれませんが、簡単に言えば何かの入力から何かの出力を得るための「手続き」と言い換えることができます。

古典暗号は平文以外の全てを秘密にする必要がありましたが、現代暗号は鍵さえ秘密にしていれば安全なように設計されています。本当に安全かどうかは未証明な P!=NP の真偽などに依存している部分もあるのですが、恐らく正しいと思われているので多分大丈夫です。

暗号がどのくらい安全なのかは「情報理論的安全性」と「計算量的安全性」の二つにわけて考えられます。

ハッシュ化#

暗号化と混同されがちですが、ハッシュ化と暗号化は大きく異なります。

暗号化は暗号文と鍵があれば必ず正しい平文が得られますが、ハッシュはハッシュとハッシュ化アルゴリズムがわかっても正しい平文が得られません。

というのも、暗号化は平文が長くなればなるほど長くなりますが、ハッシュは平文がどんなに長くなっても常に一定の長さになります。

一定の長さの文字列で表現可能な組み合わせは有限なので、計算すると同じハッシュになってしまう異なる平文が存在するわけです。といっても、これだけではわからないかもしれないので簡単な例で説明します。

• 暗号化
  • 鍵(5)
  • アルゴリズム(それぞれの桁にその数を足す)
• ハッシュ化
  • 鍵(なし)
  • アルゴリズム(全ての桁を足し合わせ、一桁の数になるまで繰り返す)

上の条件で計算したものが以下の値になります。暗号文は平文が長くなればどんどん長くなりますが、ハッシュ化はどんなに平文が長くても 1 桁の数になります。

今回の暗号も非常に簡単ではあるものの、暗号文とアルゴリズムがわかっても鍵がわからない限り平文はバレることがない。

MessagePackを解析する#

復号したセーブデータはclientとserverという二つの部分に分けられます。シナリオコードが書き込まれているのはclientなので、弄るのはこちらだけで大丈夫です。

セーブデータはMessagePackという形式で保存されているので、これを JSON と相互変換できればそれで終わりのはずでした。まさか、ここからが本当の地獄だったとは。

MessagePack と JSON の相互変換は様々なライブラリで実装されており、ブラウザでもmsgpack-liteのようなサイトで簡単に実行できます。「え、じゃあもう終わりじゃん」って思うんですが、ここからが長かったです。

復号したセーブデータを上記のサイトに突っ込むと確かに JSON に正しく変換されました。

{
  "Common": {
    "BootCount": 30,
    "ControlOptionHandheld": {
      "CameraSpeedGyroDigital": 8,
      "CameraSpeedStickDigital": 8,
      "IsEnableGyro": true,
      "IsReverseLR": false,
      "IsReverseUD": false
    },
    ...
  }
}

キーとハッシュのマップとかはいろいろあるが、やっぱり長いので割愛します

じゃああとはこの JSON の中身を書き換えて MessagePack に戻して終わりだったはずなのですが、ここで問題が発生します。

型、失われたあと#

MessagePack はバイナリなので厳格なフォーマットが存在します。たった 1 つでも値が違うと異なる意味を持つので(そして多くの場合、意味を持たないデータになってしまう)スプラトゥーン 3 が読み込めるようなフォーマットにする必要があります。その際に大事になるのが型です。

上は正確性に欠けますが、わかりやすいと思うのでそのまま載せておきます。JSON には数値といえばnumber型しかありません。桁がいくらだろうが、負の値だろうが、小数だろうが、全てnumber型です。それに対して MessagePack には数値に対して複数の型があります。

つまり、MessagePack から JSON に変換する際には数値は全てnumber型にすればよかったのですが、逆はそうはいかないわけです。スプラトゥーン 3 がその値を何の型だと認識するかを把握する必要があります。

一度 JSON に変換すると型情報が失われるので、直接 MessagePack を読む必要があります。幸い、MessagePack をそのまま読めるライブラリがあるので中身を見てみることにしました。

array[int(25030), int(25030), int(25030), int(-1)]

すると、例えば支給されるブキは数値型で与えられるのですがニンテンドースイッチではint16として認識していることがわかりました。ランダムブキは-1なためunsignedは使えず、ブキの ID の最大値はたかだか 30000 程度なのでint16で足りるわけです。

このデータを JSON で表現すると以下のようになります。

[25030, 25030, 25030, -1]

ではこれを MessagePack に直すと得られるデータはというと…

array[uint(25030), uint(25030), uint(25030), int(-1)]

なんと本来int(25030)と返らなければいけないところがuint(25030)となってしまいました。これは MessagePack の定義なのか、使ったライブラリが悪いのかはわからないのですが、正の整数値であれば常にuint()を利用するというようになっているようです。ところがスプラトゥーン 3 はブキの ID はint()が与えられるという前提で実装されているのでuintの値を渡すと読み込めずに0に置き換えられてしまいます。なので、何も考えずにセーブデータを復号してから再暗号化すると支給されたブキが緑ランダムと金ランダム以外は全てボールドになってしまいます。

-1 と-2 は負の数なので変換時に正しくint(-1)とint(-2)にそれぞれ変換されます

ライブラリには.int()で初期化するメソッドもあったのですが、それを利用したとしても最終的にバイナリになる際に正の値は.uint()に変換されてしまいました。直接バイナリを指定して書き込むようにすればいいのですが、そのようなイニシャライザがないので詰んでしまいました。

じゃあ、ライブラリ自分で改修すればいいじゃんということで改修したライブラリがNSMessagePackです。まだバグがあるのですが、直接バイナリを突っ込めるようにしています。MessagePack の仕様は公開されているので、これを読んでスプラトゥーン 3 が正しくデータを認識できるように与えられた数値をバイナリに変換するようなコードを書きます。