問題タブ [reverse-engineering]

ゲーム用の自動ボットを作成する予定です。

トリッキーな部分は、プロトコルをどのようにエンコードしたかを理解することです...ボットを実行させるのは簡単です。キャラクターを実行させ、wiresharkで何をするかを記録するだけです。ただし、環境の解釈はより困難です...アイドル状態の場合、毎秒約5パケットを受信するため、大量のガーバージが発生します。

私の計画：ゲームはTCPで実行されるため、freecap（http://www.freecap.ru/eng）を使用して、ゲームを自分のマシンで実行されているプロキシに強制的に接続します。このプロキシがパケットインジェクションに対応できるようにするか、キャプチャされたパケットを再送信できるサーバーが必要になります。このようにして、サーバーが送信するものを再作成していじくり回し、プロトコルエンコーディングを理解することができます。

1. パケットインジェクションを可能にするプロキシをどこで入手できるか、またはパケットインジェクションを実行できる場所を誰かが知っていますか（ワイヤレスなどの場合のようにハードウェア経由ではありません！）
2. キャプチャされたパケットを再送信する（つまり、接続を再生する）サーバー/プロキシを見つけることができる場合はどこにありますか。
3. パターンマッチングのためのより良いツールや方法論はありますか？複数のメッセージからパターンを強調できるものは素晴らしいでしょう。

または、ここでこれを解読するためのより良い方法はありますか？おそらく分解戦略（winsock関数をフックしてそこから分解を開始することによる）？私はこれまでこれを行ったことがないので、よくわかりません。または、他のアイデアはありますか？

私は、平文でサーバーにパケットを送信するために使用されるWindows exeアプリを持っています。このアプリ (クライアント アプリと呼びましょう) は間違いなくクローズ ソースですが、巧妙なハッカーがバイナリを 16 進編集し、スクランブルされたパケットを送信するようにしました。

さて、明らかに、これらのパケットは解読可能な方法でスクランブルされています (そうでなければ、サーバーはそれを理解できません)。サーバー、および応答のスクランブルを解除できる (スクランブルされている場合)。

hex-ed クライアントは、実行するために追加の dll を必要としましたが、古いクライアントには必要ありませんでした。どういうわけか、16 進数のクライアントがその dll をロードすることができ (client.dll と呼びましょう)、その dll の機能は、から送信されたすべてのパケットを再ルーティングするいくつかの Windows API にフックすることによって、スクランブリング/スクランブル解除を実装することであると想定しています。 client.exe プロセス。

これがどのように機能するかを理解し始める方法と、スクランブリングをリバースエンジニアリングする方法について私に指示できる人がいれば、それは本当にありがたいです.

どのような情報を提供すればよいかわかりませんが、不足しているものがある場合は返信してください。詳細を投稿します。バイナリが必要な場合は、喜んで提供します。

関係者向けのバイナリ ダウンロード:

http://dl.getdropbox.com/u/46623/client.dll

http://dl.getdropbox.com/u/46623/newClient.exe

http://dl.getdropbox.com/u/46623/originalClient.exe

リソース ファイルが必要なため、これらは実行されません。それらは約 3 GB であり、大きすぎてどこにもアップロードできません。有罪 =) を保護するために名前が変更されていますが、おそらく dll の名前は保護されていません...

リバース エンジニアリングがどこで使用されているかを自問します。私はそれを学ぶことに興味があります。しかし、それを履歴書に記載できる/すべきかどうかはわかりません。

新しいチーフに、私を邪悪なハッカーだと思わせたくありません。:)

• それで、それは価値がありますか？
• 私はそれを学ぶべきですか、それとも他の場所に力を注ぐべきですか?
• そこに良い本やチュートリアルはありますか? :)

Pro*C/C++実行可能ファイルを逆アセンブルする方法はありますか?

たとえば、いくつかのパターンの逆アセンブリをテストすることにより、既にコンパイルされたファイルのアルゴリズムを識別する手法を知っている人はいますか?

私が持っているまれな情報は、ライブラリに Byte[] の内容を解凍する (エクスポートされていない) コードがあるということですが、それがどのように機能するかはわかりません。未知の方法で圧縮されていると思われるファイルがいくつかありますが、ファイルには圧縮ヘッダーやトレーラーが含まれていないように見えます。暗号化はないと思いますが、解凍方法がわからない限り、私には何の価値もありません。

私が持っているライブラリは、低容量ターゲット用の ARM9 バイナリです。

編集:これは可逆圧縮であり、バイナリ データまたはプレーン テキストを格納します。

以前の雇用主では、基本的にDLLとヘッダーファイルだけのサードパーティコンポーネントを使用していました。その特定のモジュールはWin32で印刷を処理しました。しかし、コンポーネントを作成した会社が破産したため、見つけたバグを報告できませんでした。

そこで、自分でバグを修正してデバッガーを起動することにしました。いつものように、ほとんどどこにでもデバッグ防止コードを見つけて驚いたIsDebuggerPresentが、私の注意を引いたのはこれだった。

一見したところ、2回呼び出されたルーチンを踏んだだけで、その後はバナナになりました。しばらくして、ビットをいじる結果は常に同じであることに気付きました。つまり、jmpeaxは常に命令に直接ジャンプしましたmov eax, 0x310fac09。バイトを分析すると、DLL内のいくつかの呼び出しの間に費やされた時間を測定するために使用され0f31た命令がありました。rdtsc

だから私のSOへの質問は：あなたの好きなデバッグ防止のトリックは何ですか？

DllEntryPoint、FuncX 以外に 1 つの関数をエクスポートするネイティブ C dll があります。FuncX の戻り値の型が void でパラメーターがないため、FuncX が呼び出し元とどのように通信するかを調べようとしています。C# ハーネスから呼び出すと、AccessViolationException - Attempted to read or write protected memory が発生します。

クライアントアプリケーションがdllから値を送受信するためのバッファを割り当てる可能性があるという予感があります。これは有効な予感ですか？

何らかの理由でクライアント アプリケーションが実行されないため、クライアント アプリケーションをデバッグできません。そのため、クライアント アプリケーションを起動してプロセスにアタッチできません。ただし、IDA Pro で逆アセンブルすることはできますが、できればそこでデバッグしてみる方法がわかりません。

同様の質問hereおよびhereで説明されているように、コードをリバース エンジニアリングから保護したいと考えています。

私の状況は、Simucalが彼の (優れた) 回答で説明しているとおりです。

基本的に、ソース盗難の標的になる唯一の可能性は、ドメインに関連する非常に具体的でエンジニアリングが難しいアルゴリズムを持っている場合であり、それによって競合他社に有利になります. これは、アプリケーションのごく一部のリバース エンジニアリングを試みることが費用対効果の高い唯一の機会です。

私はまさにこの状況です。特定のドメインにとってエレガントで価値のある、設計が難しいアルゴリズム。

微調整と開発に何ヶ月も費やした結果、非常にコンパクト (約 100 行のコード) で洗練されたものになりました。コードのこの特定の部分をリバース エンジニアリングから保護するか、少なくとも合理的に困難にしたいと考えています。

このシナリオは、C# で記述されたリッチ クライアント アプリケーションであり、コードのこの部分をデプロイする必要があります。Web サービスから実行することはできません。

コードを抽出してアンマネージ ネイティブ バイナリに書き直すことは、パフォーマンス上の理由 (および境界を越える問題) のため、オプションではないと思います。

最初は単純な難読化を行いたかったのですが、コードのサイズが小さいため、これでは十分な保護が得られないと思います。

理想的には、アプリケーション全体を保護したいと考えていますが、通常の難読化ツールやサード パーティのパッカーを使いにくくしていると思われる主な問題が 2 つあります。

1. アプリケーションはプラグイン インターフェイスを提供するため、一部のアセンブリ (およびインターフェイス/クラス) を難読化してパックしないでください。

2. エラー レポートを受け取ったときに、実際のスタック トレースを取得できるようにしたいと考えています。これは、実際のコードへのマッピングの難読化によって実現できる可能性があります。

これらの問題はさておき (これについてもご意見をいただければ幸いです)、コードのごく一部をリバース エンジニアリングから保護するにはどうすればよいでしょうか? 誰かがコードを変更したりハッキングしたりすることは気にしませんが、理解しにくくリバース エンジニアリングしたいと考えています。