古いPSXゲームのリソースをハックして解凍する方法

「これらのゲームアーカイブを解凍して、中身を確認できたらいいのに」



幸いなことに、今日、ほとんどの開発者はゲームの研究に干渉するだけでなく、その逆も同様であり、プレイヤーがゲームを変更して補足するようにすべてを行います。 ただし、公式のドキュメントがなくても、99％のゲームで開梱用の既製のプログラムを見つけることができます。



この記事を書いて、アーカイブが「アンパッカー」に奪われていない、非常にまれで古いゲームや役に立たないゲームに出会ったとしても、プログラミング言語の最低限の知識でさえ、あなたにとって非常に可能であることを示すことにしました彼は独力で対処し、このゲームを骨に打ち込むことができる最初の人になります。



それ自体では、ゲームアーカイブのデバイスの説明は何の利点ももたらさない可能性が高いため、ゲームアーカイブの研究中に私が取った全体の道筋、私の考え、そして私を行き止まりに導いたエラーについて説明します。

ネクタイ

子供の頃、SquareSoftゲームのファンであり、1月1日にアイドル状態に苦しんでいたという事実から、私は初期のファイナルファンタジープロトタイプに関する情報に興味を持ち、PlayStation用のファイナルファンタジーVIIの日本語版に「ボーナス」ディスクがあることを知って驚いた開発の初期段階でのゲームのスケッチやスクリーンショットなど、あらゆる種類の追加資料が含まれます。

「トレント」からすぐに彼のイメージをダウンロードしてエミュレーターで実行すると、まず、エミュレーターでディスクがひどく遅くなる（新しいハードウェアにもかかわらず）こと、そして次に、日本語のインターフェース全体が壊れてしまうことを発見して、少しがっかりしました。これがメニューです。







それから、開発者が提案したインターフェイスを使用せずに、ディスクをガット化し、その内容を直接調べるというアイデアを得ました。

一次調査

まず、ディスクに一般的に含まれるファイルを調べることにしました。





私が最初に目を引いたのは、NPKおよびLPKファイルの拡張子であり、これらがアーカイブであることを間接的に示していました。



したがって、私の頭に浮かんだ最初のアイデアの1つは、あらゆる種類のユニバーサルアナライザーとアンパッカーを使用することでした。 PSX用に見つけたものをすべてダウンロードし、念のためにPC用にDragon UnPACKerもダウンロードしました。

しかし、キャッチは取るに足りないものでした.STRフォルダー内のファイルはSTRの標準PSX形式のビデオであり、S1Gフォルダーの3つのファイルは、Sona TIM形式用の写真でした。 異なる拡張子でのみ。

NPKとLPKのアーカイブは、予想どおり、ディスクのメインコンテンツを含んでいたが、Final Fantasy VII向けのソフトウェアを含むプログラムでは使用できませんでした。



おそらく、これらのNPKアーカイブに関する少なくともいくつかの情報を探す時間がもう少し熱心になりました。おそらく、それらを取り上げたのは私が初めてではなく、少なくともいくつかの言及が見つかったはずだからです。

結果は非常に面白く、この方法でクエリを作成しようとして、検索ガベージの山を歩いていると、このディスクのコンテキストでこれらのアーカイブへの参照が2つしか見つかりませんでした。







さらに、この記事を書いている時点で、FFゲームを改造するためのソフトウェア専用サイトである両方に関連する、ダウンしていることに関連する両方のリファレンスがありました。



スレッドの1つは、「ああ、モデルを引き裂くのはどれほど良いだろうか」というトピックに関するアイドルディスカッションで、かなり前にホストによって削除されたスクリーンショットの代わりにスタブの束がありました。

しかし、2005年に関連する2番目のスレッドは非常に良いリードを与えました。 その中で、一部のユーザーは、リソースを引き裂くためにこのディスクをクラックするための挑戦を提案しました。



Qhimm（フォーラムの所有者であり、FFの多くのアンパッカープログラムの作成者）は、これらのアーカイブを研究するために爆破されましたが、すべて突然終了しました...



PSXリソースを遮断するソフトウェアの別の開発者（snailrush）が、これらのアーカイブを解凍するためのユーティリティをすでに作成していることが判明しました。 「万歳」のように見え、リンクをたどってユーティリティをダウンロードしますが、すべてがうまくいけば、この記事はそうではなかったでしょう。 一般に、リンクは死んでいて、archive.orgでさえ助けにはなりませんでした。 Snailrushのサイトは、この便利なユーティリティを作成してから数日後、何年もダウンしました。そのページのスナップショットは保存されませんでした。







したがって、私はQhimmによる投稿（私のフォーラムには長年にわたって登場していなかった）のみを持ち、彼がこれらのアーカイブの構造を把握することができました。 そして、これは彼らに特に複雑なものは何もなかったことを意味しました。

自分で掘り始める

HEXエディターでファイルを開く時間です。 すぐに最初の数個の数字にぶつかった。これは、ファイルにヘッダーのようなものがあることを示していた。

ここで、少し余談します。 当初、リソースを掘り下げるための特別な知識は必要ないと言ったという事実にもかかわらず。 「小さな」例外が1つあります。 少なくとも、データをメモリまたはディスクに、最も単純な形式である数値で保存する方法の基本的な考え方が必要です。 つまり、 ビッグエンディアンとリトルエンディアンが何であるかを知る必要があります。



エッセンスをできるだけ簡潔に説明しようと思います。

多くの場合、数字や文字は逆の順序でメモリに保存されます。 たとえば、16進数で「41 BE」のように見え、メモリ自体の「00 00 41 BE」のようなint変数である数字「16830」は「BE 41 00 00」として保存できますが、なぜそうなのかは説明しません（グーグルで検索できます）自分自身）、「コンピュータの方が便利だ」とだけ言います。 したがって、同じ方法で、逆の順序で、データをディスク上のファイルに保存できます。

さらに、一見したところ、ほとんどすべてのファイルは、拡張子やLPK、TZL、FFDに関係なく、最初は非常に類似した構造でした。



intやshortなどのいくつかの数字、シーケンス「DF 10 00 00 00 09」、そして何らかのデータのようなバイトのミッシュマッシュがあります。











すべてのファイルの最初の数値は異なるため、これらは内部ブロックのオフセットまたはサイズである可能性が高いと想定しました。



より詳細な研究のために、私は1つのファイルに集中することを決定し、NPK_WEP.NPKを選択しました。これは、スレッドから、最初にそれを解凍することが可能であり、次に、TIM形式の写真がそこに保存されていることがわかっていたためです



TIMフォーマットについて詳しく見ていくときが来ました。TIMフォーマットについては、中を見ていきます。

幸いなことに、現時点では、公式のSonyのドキュメントが漏えいしているなど、TIMのドキュメントは充実しています。

すぐに朗報です。TIMの標準見出しは「10 00 00 00」です







同時に、すでに開いた形式で利用可能な3つのファイルを16進数で開きます。







うわー、ここにあるすべての「10 00 00 00 09」は、ちょうど私のアーカイブのように、最初は「10 00 00 00 09」です。

偶然ではないようです、ここにあります！ Timファイルは内部にありますが、なぜ自動アナライザーがそれを見つけられなかったのですか？ そして、なぜ「10 00 00 00 09」の直後に混乱があるのですか？

ファイル内で「10 00 00 00 09」を検索して、127個の一致を見つけようとしました。 さらに、「10 00 00 00 09」を持つすべての場所は互いに類似しています。



NPK_WEP.NPKの2番目の場所の例は、シーケンス「10 00 00 00 09」が見つかりました。







ゼロの束の後、ファイルの最初とまったく同じ構造を見ました。



そのため、ここでいくつかの予備的な仮定と結論を立てることができます。

1. 「10 00 00 00 09 09」が実際にTIMファイルの開始を示す署名である場合、アーカイブにはそのようなファイルが127個あります。これは一般に論理的であり、本当のようです。
2. NPK_WEP.NPKアーカイブ自体は、独自のヘッダー（構造を記述する）を持たず、おそらく何らかの形で構造化されたデータの山です。
3. アーカイブ内のTIMファイル（すべて同じ場合）は、ヘッダー「10 00 00 00 09」の後のデータが実際のファイルのように見えないため、何らかの方法で圧縮されます。

ここで、NPKアーカイブの構造をさらに詳しく調べ、10 00 00 00 09以前の数字の意味を調べることにしました。



最初の数字は次のとおりです。

37 00 00 00> 00 00 00 37（HEX）> 55（DEC）オフセット37は既に圧縮データと思われるものの中にあるので、それはスキップしないようです。



2番目の数字は短かったF7 03> 03 F7（HEX）> 1015（DEC）

3番目も短いF6 04> 04 F6（HEX）> 1270（DEC）

これら2つはすでに変位に似ています。これらの場所の領域で何かを見つけてみましょう。



03 F7を探しています：







そしてビンゴ！ キャンペーンは、データブロックが終了する場所です。ゼロからこの場所に移動するためです。

下の行は何ですか？ 36 00 00 00 FD 03 2F 08-圧縮データとは異なりますが、最初と同じヘッダーに非常に似ています。



次に、3番目の変位は何でしたか？ 次のブロックの中央を指しているので、今のところ、これは解凍後のデータのサイズであると仮定します。



しかし今では、最初の数が37（HEX）または55（DEC）であるという仮定があります

どうやら、これはパックされたファイルの終わりまでのサブブロックの数であり、次のブロックごとに1ずつ減少します。この仮定を確認してください。



ブロックの長さを示すオフセットがある場合、前のブロックの終わりの直後に次のブロックを開始しないのはなぜですか？なぜこのすべてのゼロの束？ さらに、0x400は2番目のブロックの始まりを示していません。次のブロックがどこから始まるかをどのように理解するのでしょうか。 一方、0400は非常に疑わしいバイアスであり、滑らかすぎます。 12月はいくらですか？







わあ！ ちょうど1024、これはほとんど偶然ではありません。 オフセット0x800でさらに1024バイトを取得した後の結果を見てみましょう。







これですべてが明確になり、各サブブロックのサイズは1キロバイトになりました。



したがって、NPK_WEP.NPK構造はほぼ完全に解読されます。

ファイル全体は1024バイトのブロックに分割されます。



各ブロックの最初の4バイトは、アーカイブに含まれる1つのファイルの終わりまでのサブブロックの数です。



次の2バイトは、サブブロックの先頭からペイロードの末尾までのオフセットです

さらに2バイト-ほとんどの場合、アンパック後のデータのサイズ（明らかにメモリ内にデータ用のスペースを割り当てるため）。



真実のように見えますが、データ自体がどのように圧縮または暗号化されるかを理解することだけが残っています。

圧縮を扱う

それ以前は、圧縮や暗号化に遭遇したことは一度もなかったので、まったく考えも経験もしていませんでした。



したがって、私は一度に2つの方向で情報を検索し始めました。

最初に、ファイルでどのような圧縮が使用されているかがわからない場合、目でどのように理解するか。

次に、PlayStation全般、またはSquareSoftゲーム、特にFFシリーズで最もよく使用される圧縮の種類。 手がかりは、Qhimmがすぐにファイルを見つけたということでした。



「ファイルが圧縮されているものを目で確認する方法」という一般的な検索から始めて、私が見つけた最も有用なものは次のリストです。

zenhax.com/viewtopic.php?t=27で、目を引きました

lzss

圧縮されていない元のデータの部分。

それは基本的に私が持っていたもののように見えました。

そして、第二に、圧縮データでヘッダーに類似したものは何も観察されなかったため、標準ヘッダーが含まれるすべての種類のzip関連およびその他のメソッドをすぐに除外することができました。



Final Fantasy VIIで使用されている圧縮の検索により、フォールバックサイトwiki.qhimm.comが見つかりました。 このスナップショットは幸いにもWayback Machineで利用できました。



たとえば、FF VIIでは、2種類の圧縮GZIPとLZSが使用されます（一部の特定の亜種LZSS）。 GZipにはヘッダーが必要だったため、すぐにGZipを却下しましたが、LZSSでは、すべてが指し示していたため、より詳細に停止することにしました。

しかし、その後、私は間違いを犯し、それをウィキペディアに入れて（記事を編集するとき、ウィキペディアではなく別のウィキサイトであることに気づきました）LZSSについて読みましたが、問題は80年代の圧縮原理が1つ圧縮の原則を維持しながら、さまざまな方法で実装できることはまったく考慮していませんでしたが、インターネットで説明されているほとんどの記事を含め、教科書では次のように説明されています： 0の場合、次の8ビットが読み取られ、そのまま入力されます。 バッファ（出力）に格納され、1の場合、次の7ビットが読み取られます。その一部はバッファ内でオフセットされ、一部はバッファから読み取られて出力される必要があるデータの長さです。



すなわち すべてが明確で論理的であるが、いまいましいものではなく、私が持っているようなものではなく、さらには、データの先頭が「圧縮されていない」ように見えるべきという考えに対応していません。 （まあ、単にそのような実装では、最初のバイトには1信号ビットと7ビットの非圧縮データが含まれ、その8ビット目は2番目のバイトの最初のビットになるため、すべてのデータは混乱のように見えます。）



アルゴリズムの特定の実装がバッファのサイズに非常に依存しており、教科書に記載されているものが無視できる長さのバッファに適していることをすぐには理解しませんでした。



一般に、2 + 2を追加しようとして無駄に数時間を失ったため、反対側に進み、FF VIIで使用される圧縮の「コード内」の実装のスレッドを探すことにしました。

そして、すぐにgithub.com/cebix/ff7toolsを見つけました。これは、lzssとunlzssを含む、ff7を翻訳するためのPythonユーティリティのセットです。 検証のために、timファイルの1つにlzssを設定することにしました。 どういうわけかこのようになった：







一見-良いことではありませんが、09とその背後のシーケンスをつかみました。これは、アーカイブ内での私のファイルの外観に非常に似ていました。 それから私は写真がいくつかのLZSS実装によって圧縮されていることをほぼ完全に確信しました。



これを行うために、私はwiki.qhimm.comに戻り、「これは彼らのLZSです」についてより詳しく読むことにしました。

注意深く読んで再読した後、パズルが発展しました！ ビンゴ！



形式は次のとおりです。



日付全体はブロックに分割され、その長さは9バイトから17バイトまでさまざまです。

ブロックの最初のバイトは、ブロックの他のすべてのバイトが何であるかを示します。 これはビットレベルでエンコードされます。 1-バイトがそのままバッファーおよび出力に送信されることを意味します。 0-2バイトを読み取る必要があることを意味し、それらはバッファーへの参照になります。 さらに、ビットの読み取りは最後から行われます。

したがって、ブロックの最初のバイトがFF（11111111）である場合、これは次の8バイトをそのまま読み取り、出力（バッファー）に書き込む必要があることを意味します。

そして、すでに私にとって大切になった、10 00 00 00 09の前のDFバイトはビット形式で11011111のように見えます。つまり、それに続く5バイトはそのまま（同じ10 00 00 00 09）読み取られなければなりません。 2バイトの参照（EF F0）があり、再び2バイトをそのまま読み取る必要があります（0C 02）。

もうおもしろい。 リンクの形式は、バッファのサイズに大きく依存します。 この実装では、バッファーは4キロバイトであり、ビット単位のリンクは次のようになります（繰り返しますが、ビットはもう嫌いです！）

OOOO OOOO OOOO LLLL（O =オフセット、L =長さ）

さて、またはビットなしでできるので、OO OL（バイトレベル）、2番目のバイトの最初の4ビットが最初のオフセットバイトになります。これは、最後から読み取る必要があるためです。 しかし、それだけではありません。長さを3つ追加する必要があります。まさにハードコードです。 長さ0、1、2は意味をなさないため、この場合、リンクは読み取られたデータよりも多くのスペースを占有するためです。 したがって、0は3、1は4などです...



理解するのが難しいことを理解しているので、実際の例を使って説明します。



バイトDFは、オフセットの6番目と7番目のバイトがEF F0であることを示しています。

最後の4ビット（長さ）を切り取って反転し、0xFEF-バッファーのオフセット、残りの0 + 3 = 3-長さを取得します。



したがって、リンクは、バッファーから3バイトのオフセット0xFEFを読み取るように指示します。 上にスクロールして、通常のTIMファイルがどのように見えるかを見ると、09の直後に3つのゼロバイトがあり、これらはバッファーからコピーされたものです（明らかに、これらは3つのゼロバイトであり、文字通り「ちょうど」書き下されます）以前のアクション）。



また、その記事では、バッファーから読み取る必要がある実際のオフセットを計算するための複雑な式について説明しました。 これは、作成者が書き込みと読み取りに通常の入出力ストリームを使用することを意図しており、圧縮形式がリングバッファーの使用を暗示しており、何らかの方法でオフセットを変換する必要があるという事実によって説明されました。

しかし、私は勇気があり、「まあ、ナフィグ」、これらの奇妙な式を理解するよりも、自分の場所にリングバッファを実装する方が良いと判断しました。 もちろん、後悔しましたが、同時に「機能しない」理由を理解し始めたとき、その記事の著者よりもはるかに美しい解決策を見つけました。



さらに、この記事では、覚えておく必要のある2つの「トリック」について書いています。バッファへの参照は過去にも未来にも行くことができ、あらゆる種類のハッキングを回避することが提案されました。

バッファの正しい実装で後でわかったように、「ハッキング」は必要ありません。

コードを書く

さて、今のところ、私はEclipseを発見しました（私にとってはJAVAで書くほうが便利だからです）

まず、リングバッファの実装方法を決定する必要があります。 実際のところ、非常にさまざまな方法で実装できることをすぐに理解したので、幸運を試すことにし、apache.commons.collectionsのほぼ標準的なCircularFifoQueueライブラリから同様の実装を選択しました。 これはFIFOバッファであり、自分の中でオフセットを読み取ることができます。 すぐに使用できる他の実装では、ほとんどの場合、オフセットでの読み取りが許可されませんでした。

その結果、コードは次のようになりました（読み取りと削減を簡単にするために、すべてのゴミを捨てました）。

  static CircularFifoQueue<Byte> circularBuffer = new CircularFifoQueue<>(4096); private static void processNPK() { FileInputStream fis = new FileInputStream(new File("NPK_WEP.NPK")); ByteBuffer b1kb = ByteBuffer.allocate(1024); while (fis.read(b1kb.array()) != -1) { int blocksInMegaBlockCount = EndianUtils.swapInteger(b1kb.getInt()); int compressedDataLenght = EndianUtils.swapShort(b1kb.getShort()); int decompressedDataLenght = EndianUtils.swapShort(b1kb.getShort()); while (b1kb.position()<compressedDataLenght) { readLZSBlock(b1kb); } if (blocksInMegaBlockCount == 1) {dumpFile(result);} } } private static void readLZSBlock(ByteBuffer bb){ byte controlByte = bb.get(); for (int i = 0; i < 8; i++) { if (isLiteral(controlByte,i)) { byte b = bb.get(); circularBuffer.add(b); result.write(b); } else result.write(getFromCBuffer(bb)); } } private static byte[] getFromCBuffer(ByteBuffer bb) { byte first = bb.get(); byte second = bb.get(); Integer lowNibble = Integer.valueOf(second & 0x0f); Integer highNibble = Integer.valueOf(((second & 0xf0) >> 4)); int offset = EndianUtils.readSwappedShort(new byte[] {first, highNibble.byteValue()}, 0); byte[] bytesFromBuffer = new byte[lowNibble+3]; for (int i = 0; i < (lowNibble+3); i++) { byte b = circularBuffer.get(offset); circularBuffer.add(b); bytesFromBuffer[i]=b; } return bytesFromBuffer; } private static boolean isLiteral(byte controlByte, int position) { if (((controlByte >> position) & 1) == 1) return true; else return false; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼の作品は次のように説明できます。



1）ファイルは1024バイトに分割され、

2）それぞれについて、int、short、shortが読み込まれます

3）残りはアンパッカーでループされます（readLZSBlock）

4）最初のバイトを読み取り、残りの処理を見つけて、そのまま書き込むか、これがリンクの場合、バッファーから読み取るバッファー参照ハンドラー（getFromCBuffer）に送信します。

5）アーカイブ内の1つのファイルが読み取られると、ディスクにマージされます



実行の結果は次のとおりです。







一方で、それは良いことであり、剣の輪郭が見え、ビューアーでファイルが開かれます。 一方、ニケッタバッファが機能しないことは明らかであり、そこから読み取られたすべてのデータはガベージであることが推測できます。最初はゼロがガベージであり、ファイルの上部がほぼ白であり、バッファがいっぱいになるとガベージになることがわかります色になりました。 同時に、剣の輪郭が見えるようになっています。



バッファを終了する必要があると思っていたので、私はあまり動揺していませんでした。 念のため、ディスク上の他のすべてのアーカイブをプログラムで実行し、NPK_WEP.NPKアーカイブの最初のファイルがtimファイルビューアーで開いた唯一のファイルであることに驚いた。 だから、彼と一緒に始めたのはとてもラッキーだった。



次のステップは、障害が発生した場所を正確に把握することでした。 このため、HEXエディターでTIM形式の説明を手に入れて手動でファイルを調べ始めました。 希望は、ヘッダーで障害がすでに検出されていて、どの値が想定されていて、どの値が実際に書き込まれているのかを見つけることができ、バッファーの状態を知って、いくつか修正することでした。



オフセット0x214で顕著なエラーが見つかりました。 通常のTIMファイルには、その中のデータのサイズに対応するintがあり、デフォルトではTIMファイルは圧縮されておらず、サイズは解像度に依存し、プレイステーションでテレビのフルスクリーンに引き伸ばされた画像の解像度は同じであると考えられます , .



通常のファイルの例を次に示します。







データサイズ00 01 E0 0C。



そして、ここに私のファイルがあります：







通常の番号の代わりに、そこにある種のゴミがあります。



コードを少し変更すると、この場所の処理に関連するデータが得られました。

ファイルから読み取られたオフセットは4092で、長さは3バイトでした。



ここでの時に私のバッファを見てみましょう、あなたは00 01 E0を取得する必要があります







（バッファ全体でも私の画面でintermeddleではありませんが、初めに画像よりもちょうどより多くのゼロがありますので、実際には、これは、終わりである。）



で発見目的のデータをバッファリングすると、混乱しました。

527バイトの「有用な」日付がバッファにプッシュされました。必要なデータは、データ入力の先頭からオフセット15で、バッファの先頭から約3569オフセットで見つかりました。私に発行されたオフセット4092でそれらをどのように考えることができるか、理解できませんでした。また、この記事で18番について言及されていることを思い出して、別のオフセットから加算と減算を試みましたが、意味のあるものは何も得られませんでした。



その結果、カブをひっかいて、元のバッファーの配置が私のものとはかなり異なっていることに気付いたので、記事に戻り、ストリームからの読み取りを使用するときに「実際のオフセット」を取得する方法について説明しました。フォーミュラはひどく見えたので、掘り下げようとせずにそのままコピーして、クリップボードに引っ張るためにいくつかのアドオン車を追加しましたが、結局、私はそのような恐怖を感じました：

  //      int offset = EndianUtils.readSwappedShort(new byte[] {first, highNibble.byteValue()}, 0); //   ( OUTPOS -     ) int realoffset = OUTPOS - ((OUTPOS + 0xfee - offset) & 0xfff); //      " " int realoffset2 = 4096 - OUTPOS + realoffset;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（realoffsetとrealoffset2は確かに短縮できますが、動作するかどうか確信が持てなかったので、デバッグ用にそのままにしておきました。）



そして奇妙なことに、動作しました！







これは停止する可能性がありますが、バッファーの曲線の実装は私に休息を与えませんでした。そして最も重要なことは、オフセットの読み取り時に開発者自身が汚いハックを持たず、オフセット4092を受け取った場合に必要なデータが実際に4092にあることは明らかだったので、バッファーが実際にどのように配置されているかをよりよく理解したかったということです。



私は長い間、どうやってそれが実際に実装されたのかを正確に、そして最も重要なことには理解するために、紙とアレイとリングに多くを描きました。



その結果、次のようになりました。

 public class ByteRingBuffer { private byte[] rBuf; // ring buffer data public int rBufSize = 4096; // ring buffer size public int writeReadOffsetCorrection = 18; public int lenghtCorrectionLZS = 3; private int rBufWrPos = rBufSize - writeReadOffsetCorrection; // position of first (oldest) data byte within the ring buffer public ByteRingBuffer() { rBuf = new byte[rBufSize]; } public byte write(byte bt) { rBuf[rBufWrPos++] = bt; if (rBufWrPos == rBufSize) rBufWrPos = 0; return bt; } public byte read(int offset) { return rBuf[offset & 0xfff]; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単に言えば、バッファは通常のバイト配列でした。読み取りは配列の先頭から行われ、読み取りマーカーは移動しませんでした。唯一のハックは、配列への書き込みの開始点が0ではなく、配列のサイズから18を引いたものであるということでした。

つまり、最初の段階で記録ポイントを18ずらすだけで十分であり、その後、ハッキングなしで静かに読み書きできました。このシナリオでは、配列に記録された15番目のバイトが実際に4092オフセットされました。



さらに、「過去」または「未来」から読み取るためのハックは必要ありませんでした。



一般に18のオフセットが必要だった理由は、圧縮中にバッファがいっぱいになると、すでにバッファ内にあるデータの一部が上書きされるためです。また、次の状況が発生する可能性があります。



1）圧縮対象のデータがバッファで検索されます。

2）調べてください。

3）それらへのリンクが作成され、それらがバッファに書き込まれます。

4）しかし、彼らは本質的に自分自身を書き直している、パート

5）そして、その結果、適切な開梱が不可能になりました。



しかし、ボーナスディスクからの驚きはそれだけではありません。他のアーカイブに移動すると、奇妙な「異常」を発見しました。



データがわずかに少ないスペースを占める1024バイトブロックを覚えていますか？ブロックの残りをチェックし、ゼロだけではない場合に通知を発行するコードがありました。最初のファイル-NPK_WEP.NPKでは、コードのこの部分は機能しませんでしたが、次のファイルではすでに他のほぼすべての一定の警告がポップアップ表示されました。ファイルが正しく解凍されたので、どのような種類の「余分な」データが末尾にあるかを確認することにしました。そして少しのofigel。ためらうことなく、アーカイブからすべての「ガベージ」を別のファイルにダンプするコードを追加しました。これは、このガベージで見つけたものです。





おそらく、RAM内の未割り当ての有用な情報場所は、メモリから「そのまま」ディスクにダンプされ、以前の情報が含まれていました。ソースコードに加えて、コンピューターのメモリに表示されると予想されるごみ、プロセスイメージ（ディスク自体の実行可能ファイルを含む）などがあります。



ディスク上の他のアーカイブの構造はまったく同じか類似しているため、ここでそれらを分解する意味はありません。



念のため、私の「govnokoda」のフルバージョンへのリンク。



それだけです。読んで面白くて、誰かに役立つことを願っています。



PS：本当につまらないものに気づいたら、たくさんのつづりや句読点の間違いをおaびします。それから書いて修正します。