ソース海賊キットとすべてすべて...
2007年、最も注目すべきプログラムの1つであるSource Pirate Kit （ SPK ）の作成者は、プロジェクトのソースコードと他のドキュメントを完全に失いました。 一部の人にとってのプログラムの目的は、名前から明らかになります（誰かがそれに出くわすこともあります）-Half -LifeおよびHalf-Life 2エンジン（より簡単に言えば-海賊版）に基づくゲームのスタンドアロンバージョンの作成。 プログラムのすべては問題ありませんでしたが、ソースが失われたため、忘却と、少なくとも何らかの形で作業のアルゴリズムを微調整する機能になりました-プログラム全体はモノリシックEXEファイルであり、必要なすべての補助プログラムはリソースに接続され、必要に応じて解凍されました しかし-主な機能はプログラム自体に隠されていました...
開発開始
この悪いニュースを見て、私はプログラミングのアマチュア学生で2年しかいませんでしたが、少なくとも状況の修正を試みることにしました。 当時、私は一般の人々のために働いていませんでした-どこでも公開せずに、「自分のために」プロジェクトをしました。 それに取り組みながら、私は徐々にプログラミングをより深く研究しました-その時点でBorland Delphi 7の環境で書きました（C ++がそのようなタスクに理想的であると叫ばないでください-QtCreatorを使用しても、通常のユーザーインターフェイスを「スケッチ」するのはまだ難しいです） ） 失望や浅瀬などがありましたが、プロジェクトは徐々に成長し、最終的にはネットワークで公開できるようになると州に近づきました...
最初の発行と初期開発
そして今、真実の瞬間が訪れました-2007年後半に、私たちの地域で最も活発な反蒸気運動であるcsmania.ruがあるリソースのプログラムの最初のバージョンを公開しました （今年はリソースが機能しなくなり、明らかに管理者はそれを完全に放棄しました） 私はすぐに多くの妨害やバグに遭遇しました-その当時、私自身はプログラムのテストについて特に心配していませんでした（私がその時にプログラミングを学んだことを忘れないでください）。 これにより、プロジェクトに取り組む追加のインセンティブが与えられました。結局、誰かがバグを見つけた場合、それはまだ誰かがそれを必要としていることを意味します！ それ以来、プロジェクトの作業は本格的になり、徐々に新しい領域をカバーしました-最初にWinAPI、次にアセンブラー（x86）、ネットワークプログラミング、暗号化など、これらの領域に沿った多くのことを学びました...ずっと、最初のプロジェクトぎっしり詰まった束のない単純なプログラムから、最も単純なスクリプト、強力なアーキテクチャ、サードパーティツールからの完全な独立性をサポートする本格的なプログラムに進化しました。すべての機能は、コードのみで実装されました。 名前も変更されました-Source Pirate Kitの代わりに、 Universal Pirate Kitが使用されました。これは、プログラムが非常に柔軟で、あらゆるゲームで動作できるためです-プログラム用のファイルをいくつか正しく作成する必要がありました。
さらなる開発
Half-LifeおよびHalf-Life 2に基づくすべてのゲームはSteamを介して配信されたため、特定の段階で見ることにしましたが、どのように機能しますか？
Universal Pirate Kitの開発段階でさえ、Steamがゲームファイルを保存するために使用するファイル（GCF（グリッドキャッシュファイル、ゲームキャッシュファイル）およびNCF（非キャッシュファイル））を調査および分解しました。 さらなる開発は、そのようなファイルをゼロから作成する試みでした。 このプロジェクトはほぼ完全に実装されました。Steamでさえ、アップグレードおよび作成されたファイルを受け入れました。 確かに、フォーマットは100％解析されませんでした-それは私が克服することができなかった1つのトリッキーなチェックサムを含んでいます。 そのため、Steamはファイルがアップグレードされたことを確認し、それをポンプで送りました...
次のステップは、「Steamがゲームコンテンツをどのようにダウンロードするのか」を理解する試みでした。 この問題に取り組んでいる間に、TCP / IPプロトコルスタックを研究し、WiresharkおよびIDA Proプログラムに精通しました...作業の開始時でさえ、私は別の素晴らしいリソースに出会いました。そのチームもこの問題に取り組みました。 そこで多くの素晴らしい人々に出会い、彼らと非常に緊密に話し合い、一緒にこれらのプロトコルをすべて克服することができました！
新しいプロジェクト
Steamのネットワークプロトコルを研究する過程で、私（私だけでなく）は、公式のクライアントが通信するサーバーと同様のサーバーを少なくとも作成することを考えました。 このアイデアはロシアのコミュニティで非常に温かく受け入れられ、私はそれに取り組むことにしました（プロトコル自体の研究と並行して）。
プロトコルプロセスの途中のどこかで、別のクレイジーなアイデアが浮上しました-「独自のサーバーを記述しているのに、なぜ独自のクライアントを記述しないのですか？ とにかく、それをプレイするには、ゲームを個別に「壊す」必要があります...」
そこで別のプロジェクトが生まれました-SteamLite 。 それは当時の私の創造性の頂点でした-モジュール構造を実装しました（UI、FileFormats_ {GCF、NCF}、GameConvertor、Network、Viewer）。 公式サーバーからファイルをダウンロードし（すべてのファイルではなく、多くがサーバー側で追加の保護で保護されていました）、ファイルのパッチを作成および適用し、ファイルの内容を展開せずに表示（および編集）し、ゲームを自動的に「クラック」することができましたローンチなど、すべてがうまくいきますが、このプロジェクト（およびサーバー開発）は「曲がり」、以下に説明するいくつかの理由により最初の通常リリースに達しませんでした。
グローバルな不幸、紳士...
これらのプロジェクト（これは2007年から2011年まで）に取り組んでいる間、VALVEは何も考えずに座っていなかったため、新しいファイル形式と新しいネットワークプロトコルという私たちのためにムックを思いつきました。 同時に、ゲーム自体の保護はわずかに変化しました-ゲームの本格的な海賊版の作業の主な「沈下」は、その成果を備えたHalf-Life 2：Episode 2のリリースによって引き起こされました。
このすべての結果、新しいファイル形式と新しいネットワークプロトコル（Steam 3）の公式リリースで、私は個人的にすべてを放棄しました-最初からすべてを分解したいという欲求は消えました- プロトコルバッファはどこでも使用され、分析を非常に複雑にしましたネットワークパケット。 そして、私は他のチームが新しいプロトコルの作業を「クローゼットの中」に放棄しなかったことをうれしく思います-現時点ではすべてが機能しているように見えますが、自分のサーバー/クライアントに座っている人はいません...
しかし、実際、その本質は何ですか？
現時点では、Steamサーバーインフラストラクチャ（少なくとも以前のバージョンのプロトコルについて）、サーバーとクライアントの対話プロトコル自体、および使用されているファイル形式についての知識があります。 現在、一部の形式が使用されています-たとえば、BLOBファイル、ContentDescription Record（CDR）、VDF。
現在、このデータも広く利用可能であるため、このようなすべての形式とプロトコルの作業に関するデータを公開したいと考えています。 すべての機能をより詳細に分析し、ロシア語を話すユーザー向けにこのトピックに関する賢明な記事を書きたいだけです。
以下に、公開される記事のサンプルリストを示します。
- Steamプロトコルv2-サーバーコードの構造、説明、分析。
- Steamファイル-さまざまなファイル形式の解析。 いくつかの部分に分割されます（GCF + NCF、BLOB + CDR + CDF）。
これらの記事がコミュニティで必要な場合、公開されます。
PS：プレゼンテーションとコンテンツのスタイルについての合理的な批判を聞いてうれしいです-最初の記事、それらを書いた経験はありません。