3DSのステートを更新後も開くために
Azaharの統合ではステートをインストールごとに署名しました。その制限を保ちながら、アプリの更新だけで読み込めなくならないよう互換性の基準を分けました。
1.9.0でAzaharを接続し、Nintendo 3DSとNew Nintendo 3DSが加わりました。自分でダンプして復号したゲームを取り込み、更新やDLCはCIAで個別に管理します。操作には2本のスティックとZL、ZRが加わり、文字を求められたら端末のキーボードを開きます。AndroidはJIT、iOSはインタープリターで実行します。
3DSのステートはゲーム内セーブと違い、実行中の機械をコア内に復元する資料です。外部の任意のファイルをそのまま復元処理に渡すことはできません。2026年10月19日、インストールごとに別の鍵で署名し、認証後にだけ開く方針を決めました。別の端末や再インストール後には開けませんが、ゲーム内セーブは端末間で移せます。
最初の識別値にはアプリやコンパイラーの変更まで含まれていました。PS1を登録する共通ヘッダーの変更だけでも3DSの再開を拒む構造でした。同じ端末に残るステートが無関係な変更で開けなくなるのは、インストールの保護と互換性を結び付けすぎていたためです。
1.10.0では保存形式の識別値をAzaharのソースとパッチ、実行環境、JIT構成、保存形式番号に結び付けました。コンパイラーと他のアプリコードは外し、インストールごとの署名は維持します。iPhoneの1.9.0ステートも、同じコアのソースのときだけ読める互換枠を設けました。更新のために認証を緩めてはいません。
同じインストールならアプリ更新後も中断データとステートを開けます。コアのソースや保存形式自体が変わる場合は別で、先にゲーム内でセーブしてください。端末を越えてステートを移す便利さよりも認証済みの資料だけを渡す保護を守り、通常のアプリ更新でプレイを止めない基準に分けました。
あわせて読みたい開発の話
- 開発の話v1.10.0クローズドベータテスト
BIOSファイルなしで入れるPlayStationディスク
複数BINを1本にまとめ、CHDや複数ディスクを扱う方法と、基準となる最も遅いAndroid端末で確認してJITを使わなかった判断を紹介します。
- 開発の話v0.5.1初期開発
セーブデータをファイルで保管
Google Driveを接続しなくても、セーブデータを書き出して保管したり、別の端末に移したりできます。