MUD'yでtelnet.exeに正しいゲームを教える

かつて、珍しいものをプレイすることに決めたので、テキストベースのコンピューターマルチプレイヤーチャットゲームであるMUDに目を向けました。 特定のサーバー用に作成された専用クライアントの助けを借りて、およびtelnetを介してそれらを再生できます。

現在存在するサーバー（https://www.bat.org/）のいずれかを選択すると、Windows用の既定のtelnetクライアントを使用して武装し、...がっかりしました。 いいえ、ポイントはゲーム内にあるのではなく、telnet.exeがこのゲームと対話する方法にあります。 気づくのは悲しいですが、入力した文字（文字名、さまざまなアクションなど）のいずれもコンソール画面に表示されませんでした。 はい、コマンドはEnterキーを押すことで送信されましたが、最小限の対話機能がないため、このようなゲームは事実上不可能になりました（以前に入力した文字を削除するのは特に不便でした。

考え直すことなく、私はパテと...を使用して同じサーバーに接続してみることにしました... うわー ！ 入力した文字が表示されます！

telnet.exeでエコーが機能しないのはなぜですか？ これを修正する方法はありますか？ それを理解しましょう。

プロセスがどのように進んだか、そしてその結果は、カットの下で読みました。 この記事を読む前に、以前の記事をよく理解しておくことを強くお勧めします。 ここでは省略された多くの点について既に説明しています。

最初のステップは、件名を取得することです。 telnetクライアントをインストールし（Win-R-> appwiz.cpl-> Windowsの機能をオンまたはオフにする->「Telnetクライアント」の碑文の横にチェックマークを付け、「OK」ボタンをクリックします）、実行可能なtelnet.exeファイルを「％ WINDIR％\ System32 "他のディレクトリに。

次のステップは、必要なツールを準備することです。 PE ToolsとOllyDbgをダウンロードします 。これは以前の記事で何度も言及しましたが、便利なディレクトリに展開してください。

次に、探索するバイナリに対してASLRテクノロジが有効になっているかどうかを理解する必要があります。 PEツールを起動し、Alt-1を押してtelnet.exeを選択し、「オプションのヘッダー」ボタンをクリックします。



はい、ASLRは有効です。 それをオフにしましょう-0x8140を0x8100に置き換えて（それが以前に説明された理由です-たとえば、 ここを参照 ）、「OK」ボタンをクリックします。

それでは、考えは何ですか？ 私が最初に思いついたのは、アプリケーションがSetAPonsoleMode WinAPI関数を使用してエコーを明示的に「無効化」できることです。 OllyDbgでバイナリを開始し、モジュール間呼び出しのリストを含むウィンドウを開き、この関数への呼び出しがアプリケーションに実際に存在することを確認します。



それらにブレークを置き、F9を押して、ブレークポイントの1つで停止します。



スタックウィンドウの引数を見てみましょう。



ドキュメントを読む：

ENABLE_ECHO_INPUT
0x0004

ReadFile関数またはReadConsole関数によって読み取られた文字は、読み取られるときにアクティブな画面バッファーに書き込まれます。 このモードは、ENABLE_LINE_INPUTモードも有効になっている場合にのみ使用できます

必要なもの！ ただし、もっと簡単な方法があります-この関数を呼び出さないでください：

コンソールが作成されると、ENABLE_WINDOW_INPUTを除くすべての入力モードがデフォルトで有効になります

デバッグを再開しましょう、呼び出しを停止します



エコーが動作するかどうかを確認してください。 いいえ、結果は以前と同じです-入力した文字はコンソール画面に表示されません。

さて、ゲームが名前の入力を要求する瞬間を待ちましょう



、およびOllyDbgでF12（一時停止）を押します。

私たちが今どこにいるかを理解するために周りを見回すことをお勧めします。 開始するには、Alt-Kを押してコールスタックを開きます。



そのため、user32.dllの腸内のどこかにハングアップします。 user32.dllに到達した場所から、 0x0100D0D0にある最も近い「ユーザー」コード（つまり、telnetモジュールに属するコード）にジャンプします。



経験豊富なWindows開発者は、選択された命令GetMessageの実行時にEDIレジスタで最も可能性の高い関数アドレスをすでに理解している必要があります。 しかし、これを個人的に確認しましょう。 このアドレスにブレークを置き、デバッグを再開し、目的の場所に到達するまでF9を押します。



ご覧のとおり、これは実際にはGetMessageです。 この場合の問題は、この関数がEnterキーを押す前に呼び出したコードに制御を戻さないことです。つまり、エコーとはまったく関係ありません。

次に、この時点で他のスレッドが何をしているのかを見てみましょう（もちろん、存在する場合）。 再度、F9を使用してプログラムを実行し、F12を押して「スレッド」ウィンドウを開きます（表示->スレッド）：



赤で強調表示されている（これは今見たばかりの現在のスレッドです）以外は、それぞれをCPUウィンドウで開き（スレッド-> CPUウィンドウで対応する行を右クリック）、呼び出しスタックを確認します。 次の呼び出しスタックを使用してスレッドに注意を向ける必要があります。



ReadConsoleInputは、このケースではすでにより興味深い関数です。 呼び出しにブレークポイントを設定し、デバッグを再開し、... telnetウィンドウにフォーカスを移動するたびに停止します。



近くにスイッチがあることに注意してください。ほとんどの場合、対応するイベントのハンドラーにジャンプします。 デバッガで実行した後、フォーカスが変更された場合、制御がデフォルトのケースに移されることがわかります。



OllyDbgによるコードの分析から判断すると、ここには多くのオプションはありません-デフォルトのケースに加えて、ケース10および1もあります。最初のケースでは、いくつかの命令を実行した後、考慮したデフォルトのケースにジャンプします。 ReadConsoleInput関数の呼び出しからブレークを削除して、ケース1にブレークを入れてみましょう。



デバッグを再開し、名前の入力を求めるメッセージが表示されるのを待ち、「1」を押して、このまさにケースブロックで停止します。



今何ができますか？ これで、bat.org、たとえばsmtp.gmail.comに接続した場合のtelnet.exeの動作を確認できるようになりました。思い出すと、エコーは正しく機能していました。 「トレースの実行」ウィンドウを開き（表示->トレースの実行）、右クリックして、「ファイルにログ」というメニュー項目を選択し、ファイル名を選択してCtrl-F11（トレースイン）を押します。 トレース後、ファイルを閉じ（「トレースの実行」ウィンドウを右クリック->ログファイルを閉じる）、smtp.gmail.com：25の場合も同じことを行います（telnetポートを明示的に指定する場合は、IPアドレスをスペース文字を使用します。つまり、コマンドは「telnet.exe smtp.gmail.com 25」のようになります。

動作の顕著な違いは、アドレス0x0100A2F9から始まります。

bat.orgの場合

アドレススレッドコマンド。 登録とコメント
 0100AB9F 00002EA0 JNZ telnet。0100AED2
 0100ABA5 00002EA0テストバイトPTR SS：[EBP-24]、3
 0100ABA9 00002EA0 JE telnet。0100AED2
 [...]
 0100A2F7 00002EA0テストEAX、EAX
 0100A2F9 00002EA0 JNZショートtelnet。0100A304
 0100A2FB 00002EA0テストバイトPTR DS：[1010740]、10
 [...]

smtp.gmail.comの場合

アドレススレッドコマンド。 登録とコメント
 0100AB9F 00002EA0 JNZ telnet。0100AED2
 0100ABA5 00002EA0テストバイトPTR SS：[EBP-24]、3
 0100ABA9 00002EA0 JE telnet。0100AED2
 [...]
 0100A2F7 000031D4テストEAX、EAX
 0100A2F9 000031D4 JNZショートtelnet。0100A304
 0100A304 000031D4 PUSH EDI;  Arg4 = 01024CA0
 [...]

telnet.exeがbat.orgと通信する場合、0x0100A304へのジャンプは実行されません。 0x0100A2F9の命令から無条件にジャンプしてみましょう。 デバッグを再開し、telnetモジュールに移動してCtrl-Gを押し、表示されたウィンドウにアドレス0x0100A2F9を入力し、Enterを押します。 スペースバーを押して、 JNZ命令をJMPに置き換えます。



F9キーを押し、Telnetウィンドウに「1」を入力して、提案されたオプションのいずれかを選択するか、名前を入力してください。入力した記号が表示されます。



デバッガで実行すると、 SetConsoleCursorPositionやWriteConsoleOutputCharacterなどのWinAPI関数の呼び出しが行われるコードブランチに入ることがわかります。



ではなぜ早くここに来なかったのですか？ ジャンプについての決定が何に依存しているか見てみましょう：



TEST EAX、EAX操作の結果に依存し、前のスクリーンショットに見られるように、値はアドレス0x01010754からEAXレジスターに落ちました。 さて、bat.orgの場合にゼロであった理由を理解してみましょう。

調べるために、アドレス0x01010754にハードウェアブレークレコードを置くことを提案します。 それにジャンプするには、 0x0100A2BDにある命令を右クリック->ダンプでフォロー->メモリアドレス：



指定されたアドレスの最初のバイトを右クリック->ブレークポイント->ハードウェア、書き込み-> Dword。 デバッグを再開し、ゼロが含まれるときにアドレス0x01010754への最後の呼び出しを見つけます。 このアピールはこちらです：



呼び出しスタックを見て、ここで呼び出された場所からプロシージャにジャンプすると、受信データの後続の分析を伴うrecv関数の呼び出しが表示されます。



定数0xFFに注意してください。 telnet 仕様によると、このバイトに続くのは、このプロトコルで使用されるコマンドです。

   以下は、定義されたTELNETコマンドです。 これらのコードに注意してください
   また、コードシーケンスは、すぐに指定された意味を持ちます
    IACが先行します。

      名前コードの意味

       SE 240サブネゴシエーションパラメータの終わり。
       NOP 241操作なし。
      データマーク242同期のデータストリーム部分。
                                 これは常に伴うべきです
                                  TCP緊急通知による。
       243 NVTキャラクターBRKを解除します。
      割り込みプロセス244機能IP。
      出力の中止245関数AO。
       Are You There 246関数AYT。
      文字247の消去関数EC。
      消去行248関数EL。
      先に行く249 GAシグナル。
       SB 250後に続くものが
                                 示されたの副交渉
                                 オプション。
       WILL（オプションコード）251開始を希望することを示します
                                 実行、または確認
                                 あなたは今演奏しています
                                 示されたオプション。
       WO N'T（オプションコード）252実行の拒否を示します。
                                 または実行を続けると、
                                 示されたオプション。
       DO（オプションコード）253
                                 相手が実行する、または
                                 あなたが期待していることの確認
                                 実行する相手、
                                 示されたオプション。
       DO N'T（オプションコード）254
                                 相手のパフォーマンスの停止、
                                 またはあなたがいないことの確認
                                 相手を長く期待している
                                 実行するには、示されたオプション。
       IAC 255データバイト255。

スタックを見ると、「進む」というコマンドを示すバイトシーケンス0xFF 0xF9に直面していることがわかります。 それに関しては、Microsoft Webサイトで次のことが報告されています。

元のTelnet実装は、デフォルトで半二重動作に設定されていました。 つまり、データトラフィックは一度に一方向にしか送信できず、一方向のトラフィックの終わりを示すために特定のアクションが必要であり、トラフィックはもう一方の方向に開始される可能性があります。 [これは、アマチュア無線およびCB無線オペレーターによる「ロガー」および「オーバー」の使用に似ています。）具体的なアクションは、データストリームにGA文字を含めることです。

何らかの理由で、Microsoft telnetクライアントの実装では、このコマンドは0x01010754の内容をゼロ以外の値に戻すことなくエコーに影響します。

これを確認するには、Pythonで小さなサーバーを作成します。

import socket, threading s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('', 1900)) s.listen(1) class daemon(threading.Thread): def __init__(self, (socket, address)): threading.Thread.__init__(self) self.socket = socket self.address = address def run(self): self.socket.send('Greetings!') while True: data = self.socket.recv(1024) if data[0] == '1': data = 'Response' elif data[0] == '2': data = bytearray() data.append(0xFF) data.append(0xF9) self.socket.send(data); self.socket.close() while True: daemon(s.accept()).start() 

このサーバーを起動し、コマンド「telnet.exe 127.0.0.1 1900」を使用して接続すると、コマンド「2」に対する答えが得られるまでエコーが正確に機能することがわかります。

ご挨拶！1Response1Response1Response1Response2ResponseResponseResponseResponseResponseResponse

しかし、それだけではありません！ 実際、他のチームも同様の動作をしています。 たとえば、「操作なし」を示す0xFF 0xF1のバイトシーケンスは、Telnetクライアントのエコーを完全に「無効」にします。

バグ？ 機能？ 彼を知っている人。 主なことは、telnet.exeにMUDで正しいゲームを教えたことです！

あとがき

もちろん、解決策はまだ完全ではありません。 たとえば、Backspaceキーを押しても、カーソルの前の文字は削除されません（ただし、ユーザーが入力したコマンドの「内部」表現は予想どおりに変更されます）。 はい、これは単なる美容上の瞬間であり、我慢することができますが、この記事を始めたのは美容上の不便さでしたよね？

ご清聴ありがとうございました。また、この記事が誰かに役立つことを願っています。