VitaでZAVASやりたくて（６）
このへんからは殆ど思い出せずに再検証しながらなのですごくペースダウンします。
さて前回はZAVASのゲームディスクにはどうやらプロテクトがかかっているぞという推測をしたのでした。
何を根拠にそう推測できるのかというと、エラーセクタのデータにある特徴が見られるためです。
今回はそれについてまとめておきます。
激しくややこしいので今回は完全に自分用の備忘録。
まず読めたデータを眺めると次の点に気が付く。
ZAVASのフロッピーは2D形式。基本は1トラック0x1000バイト（標準的には256バイトが16セクタ）だが、ZAVASではちょっと長めのセクタを使って1トラック0x1400バイト記録されている。（吸出し時のログからわかる）
問題のトラックはそれ以上の0x1800バイト読もうとして失敗している。最後らへんのセクタだけ毎回おかしい。さすがに1トラックにそんなに記録できるはずがないので、トラックを1周して（周回して）トラックの境界をまたいだおかしなデータを読んでいる状態のはず。
エラーセクタは毎回読めるデータが変わる。ただしデータの規則性については保っているように見える。（同じデータが連続する等）
上記から推測されるのは、エラーセクタは意図的にエラーになるよう細工されていて、読めるデータが変わるのは毎回少しだけ読める位置がずれているためではないか？
それを確認するにはいくつか勉強が必要。
理解に必要なお勉強
フロッピーディスクの物理フォーマット
プリアンブルなどの制御用信号やMFM方式でどのようなビット列が記録されるか等の理解が重要になる。
同期がとれずにビットずれが起こるとどう読めるか
d88形式のフォーマットについて
勉強が終わったら次へ。
実際に読めたデータ
エラーセクタの一つはこうなっている。
左が1回目に読めたもの右が2回目に読めたもの。（青字部分は相違点）
赤枠はセクタヘッダで、ステータスは「B0（データCRCエラー）」。
変なのが読めてCRCが合わずにエラーになってるという事。
セクタ番号も「F7」とかなってて明らかに変だが、「F7」自体はちゃんと読めた数値のはずなのでここは意図的に変な値を入れているはず。
先に述べた通り、ここで読めたデータはトラックの境界をまたいで次のセクタの微妙な情報が読まれたものと推測される。
データを観察すると途中SYNCと思われる12個の（ほぼ）同じ数値の並びが見て取れる。
（少し上にもそれらしいのがあるが数が微妙に違ってSYNCかどうか判然としないのでひとまず無視）
黄色枠で囲んだところはアドレスマークのように思える。
2つあるがどちらも先頭から3バイトは同じ数値になっているので、プリアンブルの「C2 C2 C2 FC」ではなく、IDフィールドの「A1 A1 A1 FE」とデータフィールドの「A1 A1 A1 FB」が化けたものだと推測される。
つまり、ここには正しいアドレスマークが記録されているが、ビットずれを起こして「86 86 87 F8」のように化けているのではないか？ということ。
検証してみよう。
「A1 A1 A1 FE」はMFM方式では次のように記録される。（「A1」に関してはミッシングクロックと呼ばれる特殊加工がある点に注意する）
凡例）「16進 = 2進 -> MFMでのビット列」
A1 = 1010 0001 -> 0100010010001001
FE = 1111 1110 -> 0101010101010100
※厳密には1ビット目は不定だけどデータが0続きじゃないのは分かってるので0で決め打ち
A1 A1 A1 FE = 1010 0001 1010 0001 1010 0001 1111 1110
-> 0100010010001001010001001000100101000100100010010101010101010100
これがビットずれを起こすとどう読めるか試してみると、
0100010010001001010001001000100101000100100010010101010101010100
もし、6ビット目（太字のビット）からデータとして読めた場合、クロックビットを取り除いてデータビットだけにすると、（要するに1ビット飛ばし）
1000 0110 1000 0110 1000 0111 1111 10…
これは「8 6 8 6 8 7 f …」と読めて1回目のデータと合致する。
また、3ビット目から読めた場合は、
0001 0100 0001 0100 0001 0100 0000 000
これは「1 4 1 4 1 4 0 …」と読めて2回目のデータと合致する。
ここまでの結果を見ると、黄色枠はアドレスマークが化けて読めていると考えてまず間違いないものと思われる。
1回目に読めたデータは正常なデータの6ビット目から読めたものと考えて良さそうなので、読めたデータの後続部分もクロックビット（奇数ビット）ではなくてデータビット（偶数ビット）が読めているはずである。これを踏まえてもう少し復元してみる。
読めたデータは「86 86 87 F8 08 03 D4 0B」なのでデータビットの列は、
1000 0110 1000 0110 1000 0111 1111 1000 0000 1000 0000 0011 1101 0100 0000 1011
これが本来記録されていたデータのデータビットの列と同じ並びになるはず。
6ビットずれているので、
?? ???? 1000 0110 1000 0110 1000 0111 1111 1000 0000 1000 0000 0011 1101 0100 0000 1011
これが本来のデータのはずで、改めて4ビットずつを読み直すと、（??の部分はひとまず放置する）
???? ??10 0001 1010 0001 1010 0001 1111 1110 0000 0010 0000 0000 1111 0101 0000 0010 11??
これは「? ? 1 A 1 A 1 F E 0 2 0 0 F 5 0 2」と読める。
「？ A1 A1 FE 02 00 F5 02」というのは次のセクタのIDフィールドである。トラックをまたいで先頭トラックにループしてると思っていたがまだそこまでは行ってなかったようだ。
画像の下の方に見切れてるが、さらに次のセクタのアドレスマークらしきものが見える。
「68 68 7F 80 80 00 40 CD」これも確認してみる。
0110 1000 0110 1000 0111 1111 1000 0000 1000 0000 0000 0000 0100 0000 1100 1101
ここは本来「A1 A1 ..」のように読めるはずなのでずれ具合を確認すると、3ビット目（太字）から読み直せば良さそう。
??01 1010 0001 1010 0001 1111 1110 0000 0010 0000 0000 0000 0001 0000 0011 0011 01??
これは「? A1 A1 FE 02 00 01 03」と読めて、このトラックの先頭セクタを指している。
やはり想定した通りループして読めているのが分かる。
また、次のセクタもエラーセクタになっていて、同様に確認すると、やはりこちらもトラックの先頭がループして読めているのが分かる。（詳細は長いので省略）
なお、確認したアドレスマークの少し上にあるプリアンブルと思しきエリアを見ると、GAPのサイズが標準より小さいように見える。たぶんこの辺削って容量を稼いでるのかな？
上記の検証から、当初の推測通りトラックを1周する形でおかしなデータが読まれている事はほぼ間違いなかろう。
毎回違ったデータが読めるのは、本来なら読めたデータに対応するはずのSYNC（化けていたアドレスマークの手前にある）が無視されて（SYNCの役割ではなく単なるデータの一部として読まれて）、その付近でのデータの位置決めが不安定になるためだと考えられる。
というわけで、ZAVASでは恐らくこれを利用したプロテクトをかけているものと思われるのだが、はてさてどうやって調べたものか。
俺たちのプロテクトをめぐる冒険の旅まだ始まったばかりだ！（つづく）
（例によって全然覚えてないので次はだいぶ時間かかる予定）
この記事が気に入ったらサポートをしてみませんか？