解析講義講師：Lear教官 | ||||||||
Lear教官によるデータ解析講義です。adpdata.dllのデータ構造の解き明かしを軸に、質疑応答形式で進む予定です。講義録本文中のリンク（赤字の部分）をたどると、Ｑ＆Ａ集の関連項目にジャンプできます。講義録に戻るときには、ブラウザの機能で戻ってください。みなさんも質問があれば、どんどん談話室に書込んでください。なお、Ｑ＆Ａ集のみ読みたい方は、こちらをどうぞ。 | ||||||||
当然、今まで得てきたコンピュータの知識をフル動員するわけですが作業そのものは単純で地道な作業が多いです。 先ず最初はテキストエディタ、次はバイナリーエディタでファイルをのぞいてみます。 ＡＤＰＤＡＴＡ．ＤＬＬの様にこのレベルで目で見て何か判別できるキーワードがあればかなり楽です。 今回、私の場合はデータ構造の解析から入りましたが、けんこうさんは所謂「トライ＆エラー」で解析していったものと思われます。つまり、直接一部の値を書き換えてゲーム上でどう反映されたかを見てみることを何度も繰り返すわけです。繰り返すと言ってもちょっとした指針を立てて反映が目に付きやすいように工夫をしたり、同じことを繰り返さないように記録を取りながらやってデータをとって行くわけです。 ある程度、データがたまると、データ間で似たような働きをするものを見いだして更にデータの内容を確定して行くわけですね。 かたやデータ構造解析から入った私は、先ず全体を見渡して同じ様なデータの繰り返しを探して全体的にどの部分が関連性ある集合かを見極めて全体の流れをつかみます。 ＡＤＰＤＴＡＴＡ．ＤＬＬを見た人にしか分かりませんが、ＡＤ９８のプログラマはデータ構造をいくつかに分割しています。 兵器名はＤＬＬの最後の方に固めて単一構造にしております。 一挙に１兵器データ１構造体だったら楽だったのですが何かの理由で分離させていますね。 でもって、けんこうさんからもらった別角度から解析した結果を合わせると以外と簡単にデータ内容が予測できてしまうものです。 ちなみに、けんこうさんの解析データと自分のものを掛け合わせて食い違っている部分なんかを再検証したりしていたので解析作業そのものは非常に早かったです。 私の解析ミスもけんこうさんの解析ミスもお互いに補完しているわけですね。 さて、バイナリーエディタで目で見える分には基本的にはトライ＆エラーで行くわけですが、そうでない場合が厄介です。 普通の人？はここで脱落します。 所謂、暗号化等がほどこされているとこれを解かねばなりません。 とはいっても、どこの開発元でも１円にもならない暗号化に時間を大量につかって開発することはまずありえませんからある程度、指針が見えてくれば解け無くもありません。 基本的には下記の３つの内のどれかまたはその組み合せが多いです。 １．は適当な圧縮ツールで圧縮してみて、圧縮効率が悪ければ圧縮データであるとほぼ予測されます。ｌｈａが採用している圧縮論理が手軽で良く使われています。 ２．はトライ＆エラーで割り出します。手でやるのでは無くてツールをこさえて片っ端から試して暗号化前のデータが出てくれば文字データとかが出てきて分かります。 ３．はチェックサムデータを探し出してツールでチェックサムデータを作ってやってチェックプログラムを回避します。 またも専門用語が大量に出てきたのでその都度「これはなんですか？」と聞いて下さい。 説明が詳細になればなるほど分かりにくい専門用語が出てくるでしょう。 例えば１６進数は理解できますか？ これが分からないと話が具体化して例題を上げたりしたときに一発で引っ掛かります。 ってことで分からなければ１６進数の説明しないとね。 その内、１バイトってどんな単位とか、構造体って良くわかいんないってのが来るのかな？と戦々恐々です。 先は長いぜ・・・続けばね。
「解析講義：第１回補足」 解析方法として非常に単純な「トライ＆エラー」は軽く説明しました が、もう一つ代表的な方法があります。 ＡＤＰＤＡＴＡ．ＤＬＬの解析では使えませんがアドベンチャやＲＰＧゲームの様に現状の進み具合を記録しているファイルを解析する方法として差分解析法（っと勝手に銘々）があります。 記録ファイルを探しだし、適当な別ファイル名で保存して置いて、適当に進んだところで元のファイルと比較して変更点を探し出して変更されるフラグにアタリを付けると言うものです。 後は変更された周辺に他のフラグも固まっているだろう適当に予測してトライ＆エラーで実験すればあっと言う間に解析完了と言う感じです。 当然、暗号化されていればそっちを先に解決しなければなりません。
たしかに、解析に一番重要なものは「努力と根性、忍耐力」です。＞Lear教官殿 さっそくの補講ありがとうございました。でも、無理はなさらないでくださいね。 第二回目の講義で私が理解したことは、解析には「膨大な時間がかかりそう」＆ 「豊富な経験が必要そう」です。これは間違ってませんよね？ Lear教官は「まず 解析する範囲を絞り込む」とおっしゃってますが、どこが自分の必要とするデータ であるのか、その見当をつけるだけで一苦労のような気がします ただし、その先には「欲望と経験」が控えています。 解析して「・・・してやる」と言った欲があればこそ解析も進むってもんでしょう。 ろくにＣ言語も知らないひとが解析こうじてプログラマになるときは強者になりやすいです。 Ｃ言語の場合、後になって「こんな便利な関数が実は標準であったのね」みたいに標準で用意されているものすら知らずに自分で作ってしまうことは珍しくありませんから。 そして、やった努力が自分でハッキリと認識できるので病み付きになりやすいです。 強者にならない訳はありませんね。 ある意味では根っからの根性無しにはできません。 他人が用意したツールのみで解析する方は、ある意味で不幸かもしれません。 なにせ、「経験」ってものがあっと言う間に行き詰るからです。 つまり、そのツールの範囲外には絶対に到達しませんから。 得られる経験はかなり限定されます。 解析に必要なツールに、基本的に必要な要素を考えましょう。
Ａ）バイナリーでは人間には読めませんのでバイナリーデータを数字に
変換して読める様にするためのツールが先ず必要です。
いわゆる、ｄｕｍｐ（ダンプ）ツールと言われるのがこれですね。
Ｂ）ｄｕｍｐデータを更に読みやすくするために数値データを文字デー
タと仮定した場合、それを文字として変換してくれるツールがある
と便利です。
Ｃ）バイナリーデータを低レベルで簡単に加工でいるエディターがある
と便利です。
Ｄ）２つのファイルの相違を抜き出せる比較ツールがあると良いでしょ
う。
これはＵｎｉｘやＤＯＳのコマンドでも存在します。
Ｅ）思いついたキーワードをデータの中から検索してくれるツールがあ
ると便利です。
これは、アリ物のツールで有ったかな？
上記ＡＢＣ、３要素を合わせ持つのが日本語表示可能なバイナリーエディターです。ただし、日本語表示可能なバイナリーエディターは必ずしも万能ではありません。日本語とは言いましたが日本語文字コードは複数あります。 ＪＩＳ、ＳＪＩＳ、ＥＵＣ、ＵＮＩＣＯＤＥ、半角カナ文字、機種依存文字。 全コードを表示してくれる日本語表示可能なバイナリーエディタなんてたぶん無いでしょう。 また、２バイト文字と１バイト文字が混在すると表示がおかしくなるツールも珍しくありません。 ツールだけに頼る解析は解析限界もしれています。 したがって解析をどこまで行うかによってはこれでは対処できないこともあります。 また、解析にかかる時間も、ツールだけに頼るとムダが多くなることもあります。 この限界を超える解析をしたければ自分で必要なツールをそろえるしかありません。 一番の近道はＣ言語等をおぼえて、必要なデータは自分で抜き出せてたり、自分の思うように変換できたりできるように自分でツールを作ってしまう事です。 急がば回れですね。 別に、アリ物のツールを使うなとは言ってません。 アリ物のツールの限界を越える方法は自分でツールを作るしか無いって事です。 少数のデータ変更だけならバイナリーエディタで事は済みますが、インテリジェントに膨大な量のデータを編集したい場合はエディターでちくちく変えていくことはかなりの苦痛です。 また、タイプミスで全ての努力が無になることは珍しくも無いでしょうし、それを承知で行うことはかなりの忍耐力の消費をともないます。 それと比較すれば、Ｃ言語等で簡単な専用のツールを作り出す方が明らかに寛容です。 バイナリーエディタによるデータの書換えはあくまでも低レベルであることを認識していなければなりません。
この回答は簡単です。＞バイナリエディタからカットして、テキストエディタにペーストし、整 形するなんてことではあるわけないですよね。一体どのような方法で、 あの膨大な兵器データをお作りになったのでしょう。 半自動的にＨＴＭＬファイルを作るところまで行うツールを作りました。 流石に、エディタでカット＆ペーストだと不正確で完成もやばそうなのは直ぐに推論できますから力技は即放棄しました。 使用言語はＣでＯＳはＵｎｉｘ、ＷｉｎｄｏｗｓでやるとＷｉｎｄｏｗの設定とかやんないと表示すらできないのでパス。 ＤＯＳ上のＣは今は無いので不可。 男はだまってＧＮＵでしょう。（ウソ） 全てを１回でかたずけることもできますが作業は２回に別けました。
兵器名は逆さに登録されているので順序は引っ繰り返しました。 兵器名のズレは力技で治しました。 これは、この方が速いと判断したためです。 だから、ＤＬＬが変ると使えません。 ２．で問題なのがＳＪＩＳコード。 通常、ＳＪＩＳではソ連の「ソ」とか図表の「表」の時がｆｐｒｉｎｔｆ関数では書けません。 理由はＳＪＩＳ、２バイト文字の２バイト目が０ｘ５Ｃでこれは１バイト文字の「\」＝「￥」と重なるのですがこの文字はｐｒｉｎｔｆ系関数の制御文字とバッティングするからです。
『ＳＪＩＳの危ない文字の羅列一覧』
― ソ Ы 噂 浬 欺 圭 構
蚕 十 申 曾 箪 貼 能 表
暴 予 禄 兔 喀 媾 彌 拿
杤 歃 濬 畚 秉 綵 臀 藹
觸 軆 鐔 饅 鷭
全てＥＵＣとかで書けば良いのですが、ＤＬＬの中身はＳＪＩＳだったので文字の比較はＳＪＩＳにしなければなりません。つまり、プログラム内に文字コードが複数存在したりします。 これでは間抜けなので文字コード変換関数なり、外部コマンドなりを使う予定でしたが、完成速度優先で、データやプログラムをＳＪＩＳ系とＥＵＣ系に分離して対処。 こう書くと、カッコイイプログラム書いてる見たいですがソースは・・・・ダサイな。 文字にだまされては行けません。 Ｃ言語を書ける人なら、誰でも書けるレベルの簡単なプログラムです。 |
| SiteTop | |
| |
| (c) ロドリゲス学級ＯＢ会 All rights reserved. 1997-2003 | Last Modified 2003/11/05 02:48:07 |