ここで説明上、データ構造と言いましたが説明するのは至難の技なので具体的にどんな感じのことを行っているか説明して雰囲気だけつかんで下さい。
最初に行ったのは「開発表制作に不必要なデータを洗い出して解析範囲を狭める」です。
解析範囲を絞ればその分、解析効率は上がりますからね。
例えば、都市名やスタッフロール、搭載兵器関連とおぼしきデータであろうと思われる部分は基本的には開発表になんの関係も無いのでそこら辺は解析しても意味がありません。
そして、残った部分に対してトライ＆エラーやその他、考えられる方法で解析を行い、その結果、無関係な部分をさらにそぎ落として行きます。
これの繰り返しです。
そして、無駄な部分とはいえ、少し解析が進むとこのデータを作り出したプログラマの癖と言うか、ゲーム制作上の手法として「こうしてるだろう」というものが見えてきます。
今回は「全てのデータが４バイト単位でできている」ってのがそれに当たります。
さらに、なぜ４バイト単位かまで予測が付けば、その先の解析の大きなヒントとなります。
すなわち、「本当に全部４バイトか」、「もっと時間をかけて疑うべきか」とかですね。

Ｃ言語で開発を行っている場合、ある程度、自由な大きさの任意な適当なデータサイズを構造体という概念で容易く扱えるので一般化はされていません。
ただ、構造体と言う概念でデータを格納しているだろうという予測が的中していれば解析の手がかりの１つとなります。
ＡＤＰＤＡＴＡ．ＤＬＬの場合、兵器データが０ｘ２Ａ０バイト（６７２バイト）と０ｘ１７４バイト（３７２バイト）単位で生成されていますが、この固まりが構造体です。
まあ、データ集合の固まり具合が構造体と言えるでしょうか。

１．に重複しますが、ようは全てが一回の解析で判明することはほとんどありません。
あとは、不要な部分を取り除いて、必要を思われる部分だけを見渡してさらに見直してみる・・・の繰り返しです。
時には必要な部分までも削ってしまうこともあります。
解析できる前に行き詰まったら、今までの考察が正しかったのか疑わねばなりません。
考察する部分が無くなればトライ＆エラーで新たな情報を取得して再考察します。
そんな感じです。

普通はできません。
ＬＨＡやｇｚｉｐがＬＺ法＋Ｈｕｆｆｍａｎで圧縮していてもＬＨＡで圧縮したものがｇｚｉｐで展開できないことと同じで、あくまでも同じなのは理論であり実装法は別です。
ＬＨＡを直接使用しているなら話は別ですがね。
圧縮理論の推定が正しければそれを紐解くことはそんなに難しいことではありません。
ただし、プロのプログラマでも普段からＬＺ法等を暗記しているのではなくて、ＬＺ法やその他の理論があることと、それを解説している書籍を持っていて、いざ使うときにそれらを参考にするのが普通です。　全てを知り得ているわけではなくて、ある何かを調べる手立てを持ち合せていて重要な部分は解説書に任せておけば良いのです。

ｅＸｃｌｕｓｉｖｅ　ＯＲ（排他的論理和）をこう略します。
さて応用数学ですね。
高校レベルってどこまでやってましたっけ？
工学系の学科へ大学進学された方は知らないとヤバイですね。
ＡＮＤ、ＯＲ、ＮＯＴは分かりますか？

ＡＮＤ 論理積	２つの命題Ａ、Ｂがともに真（１）である時のみ真である論理関数。
ＯＲ 論理和	２つの命題Ａ、Ｂのどちらかまたはその両方が真であるとき真である論理関数。
ＮＯＴ 否定	命題Ａが真（１）の時は偽（０）に、偽（０）の時は真（１）を表す論理関数。
ＸＯＲ 排他的論理和	２つの命題Ａ、Ｂがともに真であるか、ともに偽であるとき真である論理関数。
ＮＡＮＤ	ＮＯＴ　ＡＮＤの略、ＡＮＤの結果をＮＯＴする。
ＮＯＲ	ＮＯＴ　ＯＲの略、ＯＲの結果をＮＯＴする。

とりあえず真理値表でも書いておきますか。

Ａ	Ｂ	ＡandＢ	ＡorＢ	notＡ	notＢ	ＡxorＢ	ＡnandＢ	ＡnorＢ
０	０	０	０	１	１	１	１	１
０	１	０	１	１	０	０	１	０
１	０	０	１	０	１	０	１	０
１	１	１	１	０	０	１	０	０

　例えば
　　Ａ＝本来のデータ
　　Ｂ＝暗号化するキーコード
　　Ｃ＝ＡｘｏｒＢ

でＣが暗号化されたデータとなるわけです。
Ｃ値からＡを得るにはＢが判別すれば逆算できます。
暗号化時にＢを可変にすると更に暗号化されます。

　例題：以下のデータを１バイト単位で加算し、その結果の下位１バイ
　　　　トをこのデータのチェックサムと定義すると。

　データ１：０ｘ１２３４５６７８
　データ２：０ｘ１０２３９８４Ｆ

計算式：	０ｘ１２
	０ｘ３４
	０ｘ５６
	０ｘ７８
	０ｘ１０
	０ｘ２３
	０ｘ９８
＋	０ｘ４Ｆ
−−−−	−−−−−−
	０ｘ０２２Ｅ

チェックサム値は０ｘ２Ｅ

ここで、これをセーブデータと仮定すると途中の値を変更すると、チェックサム値が同じでない値になる確立は２５６分の２５５で、偽データを見破ることができます。
元々は通信データのデータ化けチェック等に用いているが、改ざんデータチェックにも使える。

たぶん、深読みにハマっていらっしゃいます。
私の様な本職がプログラマでも他人のデータを一読して「これは・・・だ！！」などと断言できる訳ではありません（そういうことも偶にはありますが、ほとんど無いです）。
前回書いた通り、明らかに必要のないデータは、先ず目で見て判断が付く範囲です。
日本語表示可能なバイナリーエディタで見れば、都市名やスタッフロールは直ぐにでも分かります。
また、ビジュアルＣ＋＋でＤＬＬを作ると、データとデータの間にムダなブランクを作るらしく、０ｘ００や０ｘＦＦダケで埋められた範囲は除外する項目となると同時にあるデータと次のデータの区分をする指針になります。
後は解析したい内容（今回は開発関連）に注目して、残ったデータの一部を少しづつ書き換えていって、その結果がどう反映されるｏｒ反映されないかで「この辺は無関係らしい」とか「この辺は関係ありそうだ、もう少しこのあたりに重点を置いて見るか」などとやって行くわけです。

基本的に必要な要素を考えましょう。

      Ａ）バイナリーでは人間には読めませんのでバイナリーデータを数字に
      　　変換して読める様にするためのツールが先ず必要です。
      　　いわゆる、ｄｕｍｐ（ダンプ）ツールと言われるのがこれですね。

      Ｂ）ｄｕｍｐデータを更に読みやすくするために数値データを文字デー
      　　タと仮定した場合、それを文字として変換してくれるツールがある
      　　と便利です。

      Ｃ）バイナリーデータを低レベルで簡単に加工でいるエディターがある
      　　と便利です。

      Ｄ）２つのファイルの相違を抜き出せる比較ツールがあると良いでしょ
      　　う。
      　　これはＵｎｉｘやＤＯＳのコマンドでも存在します。

      Ｅ）思いついたキーワードをデータの中から検索してくれるツールがあ
      　　ると便利です。
      　　これは、アリ物のツールで有ったかな？

上記ＡＢＣ、３要素を合わせ持つのが日本語表示可能なバイナリーエディターです。
ただし、日本語表示可能なバイナリーエディターは必ずしも万能ではありません。日本語とは言いましたが日本語文字コードは複数あります。
ＪＩＳ、ＳＪＩＳ、ＥＵＣ、ＵＮＩＣＯＤＥ、半角カナ文字、機種依存文字。
全コードを表示してくれる日本語表示可能なバイナリーエディタなんてたぶん無いでしょう。
また、２バイト文字と１バイト文字が混在すると表示がおかしくなるツールも珍しくありません。
ツールだけに頼る解析は解析限界もしれています。
したがって解析をどこまで行うかによってはこれでは対処できないこともあります。
また、解析にかかる時間も、ツールだけに頼るとムダが多くなることもあります。
この限界を超える解析をしたければ自分で必要なツールをそろえるしかありません。
一番の近道はＣ言語等をおぼえて、必要なデータは自分で抜き出せてたり、自分の思うように変換できたりできるように自分でツールを作ってしまう事です。
急がば回れですね。
別に、アリ物のツールを使うなとは言ってません。
アリ物のツールの限界を越える方法は自分でツールを作るしか無いって事です。
少数のデータ変更だけならバイナリーエディタで事は済みますが、インテリジェントに膨大な量のデータを編集したい場合はエディターでちくちく変えていくことはかなりの苦痛です。
また、タイプミスで全ての努力が無になることは珍しくも無いでしょうし、それを承知で行うことはかなりの忍耐力の消費をともないます。
それと比較すれば、Ｃ言語等で簡単な専用のツールを作り出す方が明らかに寛容です。
バイナリーエディタによるデータの書換えはあくまでも低レベルであることを認識していなければなりません。

メモは取ります。
紙の時もありますし、画面上にエディタを開いて書いて置くこともあります。
作業の２／４は考えてます。
１／４は自作ツールのデバックや機能変更です。
１／４はトライ＆エラーです。
仕事場の空き時間にやってますので機材には事欠きません。
目の前には２０インチモニター２台にＰＣ２台（１台は私物）とＷＳ（ワークステーション）が１台が繋がってます。
３台ともＬＡＮで接続されているのでファイルのやり取りも簡易です。
キーボードは同じものを前後に２つ、その内、キーボード切替え機で１つにしたいです。
マウスは右がＷＳ、左がＰＣ。
そう、私は左手でもマウスが使えます、ちゃんと設定は左効き用に変えてます。

「圧縮理論の推定が正しければそれを紐解くことはそんなに難しいことではありません」とは書きましたし、ウソではありませんが、プログラマ達はもっと手抜きな事が多いです。
圧縮理論うんぬんの前に同じ圧縮を使い回す事が多々あり、しかもその道では誰もが知っている「例題をそのまま」ってのが良くあって、圧縮理論を追いかけたことは・・・・あったかな？・・・・あったよな？
ＬＺ法の場合、ＬＺ７７とＬＺ７８と言う有名どころでは２種類あるのですが、実装の簡易さでＬＺ７７ばかり使われてる様です。
私はそれほど解析はやってない？のでサンプルにはなりませんが聞くところによるとＬＺ７８を見たこと言う話をお目に掛かったことが無く、私も見てません。。
ＬＺ７７とＬＺ７８に関しては「Ｃによるアルゴリズム辞典」に例が載ってます。
手抜きな場合はこのサンプルそのままで圧縮されていることすらあります。

さてＬＺ法はこの辺で逃げといてＨｕｆｆｍａｎどうしよう。
目の前に「データ圧縮ハンドブック」があるんだけど、Ｈｕｆｆｍａｎダケでもけっこうなページあるな。
Ｓｈａｎｎｏｎ−Ｆａｎｏ法とか二分復号木とか分かればかなりはしょれるんだけどそうは行かないみたいだし・・・。

そもそも、ここまでくるまでに越えなきゃならないハードルは結構ある（例えば高級言語が使えるようになるとか）のと、この段階まで来れば自ずと自分で調べて、理解しない限り使えないのでパスしま〜す。
＃ああ、逃げた。
＃お願いです、撃たないで下さい・・・ギャー・・・。

やっぱ、そこに来ますか。
論理回路とはなんぞやと軽く説明しておきます。
先ず、論理回路の内、ＡＮＤ，ＯＲ，ＮＯＴは基本中の基本だと心して下さい。
実はＸＯＲはＡＮＤ，ＯＲ，ＮＯＴの簡単な組み合せなのです。

ＡｘｏｒＢ　＝
　　　（Ａａｎｄ（ｎｏｔＢ））ｏｒ（（ｎｏｔＡ）ａｎｄＢ）
または
　　　（ＡｏｒＢ）ａｎｄ（ｎｏｔ（ＡａｎｄＢ）

良く、このＣＰＵ（とかＭｅｍｏｒｙとか・・・いろいろ）は？？？万ゲートとか言いますが、このゲートってやつがＡＮＤ、ＯＲ、ＮＯＴ（＋ＮＡＮＤ、ＮＯＲ、ＸＯＲ）と言われる基本論理回路の大ざっぱな数を差しています。
コンピュータが０と１の組み合せでできていると言うのもこの辺でイメージできるでしょ？
つまり、コンピュータの中身はこれの組み合せでできています。
この話をすると、ではどうやってメモリーは記憶を行っているのかとか出てきそうですが・・・情報量１ビット（つまり０か１）を記憶する回は例えばＦｌｉｐＦｌｏｐと言われる回路でできているとか・・・・止めよう。
深みにはまりそうだ、質問が来たら考えよう。
まあ、「コンピュータの中身はこれの組み合せでできている」だけおぼえておいて下さい。

で、基本的論理回は基本なので、ＣＰＵのアセンブラ命令に実装するのが簡単、高速、安上り（アセンブラ１命令に対して少ないゲート数で実現−＞だから速い）です。
しかも、種々と便利なんです（この辺は説明するのが難しいんだけど）。
でもって、何でＸＯＲかというと。
１．ＡＮＤ、ＯＲではデータを元に戻せない
２．ＮＯＴは単純すぎて元のデータがあっさり分かってしまう。
３．ＸＯＲはＮＯＴほど単純ではなく、ちょっとだけ複雑でしかも高速
だからです。

ただし、ＸＯＲをかける１回あたりの大きさがあまり大きい（１バイトを越える）とＸＯＲの臭いが読み取れる事があるので、通常１バイト単位でかけますが・・・それを何で？と言われるとかなり説明が長くなるので今回はここでカット。

＞バイナリエディタからカットして、テキストエディタにペーストし、整
　形するなんてことではあるわけないですよね。一体どのような方法で、
　あの膨大な兵器データをお作りになったのでしょう。

この回答は簡単です。
半自動的にＨＴＭＬファイルを作るところまで行うツールを作りました。
流石に、エディタでカット＆ペーストだと不正確で完成もやばそうなのは直ぐに推論できますから力技は即放棄しました。
使用言語はＣでＯＳはＵｎｉｘ、ＷｉｎｄｏｗｓでやるとＷｉｎｄｏｗの設定とかやんないと表示すらできないのでパス。
ＤＯＳ上のＣは今は無いので不可。
男はだまってＧＮＵでしょう。（ウソ）
全てを１回でかたずけることもできますが作業は２回に別けました。

1. ＤＬＬから兵器名を引っぱり出してそれだけのデータベース（テキスト）を作成。
2. ＤＬＬと名前データベースからデータを引き出してＨＴＭＬを作る。

１．の段階ではまだ日本語兵器名とかも残ってたのですが、ＨＴＭＬにもあるように機種依存文字とか日本語兵器名が無い兵器の対処が大変なのでバッサリ削除です。
兵器名は逆さに登録されているので順序は引っ繰り返しました。
兵器名のズレは力技で治しました。
これは、この方が速いと判断したためです。
だから、ＤＬＬが変ると使えません。

２．で問題なのがＳＪＩＳコード。
通常、ＳＪＩＳではソ連の「ソ」とか図表の「表」の時がｆｐｒｉｎｔｆ関数では書けません。
理由はＳＪＩＳ、２バイト文字の２バイト目が０ｘ５Ｃでこれは１バイト文字の「\」＝「￥」と重なるのですがこの文字はｐｒｉｎｔｆ系関数の制御文字とバッティングするからです。

『ＳＪＩＳの危ない文字の羅列一覧』
      ― ソ Ы 噂 浬 欺 圭 構
      蚕 十 申 曾 箪 貼 能 表
      暴 予 禄 兔 喀 媾 彌 拿
      杤 歃 濬 畚 秉 綵 臀 藹
      觸 軆 鐔 饅 鷭

全てＥＵＣとかで書けば良いのですが、ＤＬＬの中身はＳＪＩＳだったので文字の比較はＳＪＩＳにしなければなりません。
つまり、プログラム内に文字コードが複数存在したりします。
これでは間抜けなので文字コード変換関数なり、外部コマンドなりを使う予定でしたが、完成速度優先で、データやプログラムをＳＪＩＳ系とＥＵＣ系に分離して対処。
こう書くと、カッコイイプログラム書いてる見たいですがソースは・・・・ダサイな。
文字にだまされては行けません。
Ｃ言語を書ける人なら、誰でも書けるレベルの簡単なプログラムです。