Telnet and echo - who is right, who is wrong

In the comments to the previous article , we had a bit of a controversy over whether the “set localecho” team helped solve the lack of echo problem when interacting with the bat.org server. I stood on the fact that this team would not do anything to correct the situation considered, and said this for a reason — for the purpose of one of the comments I decided to check once again that I was right in this matter. Having done all the necessary actions (running telnet.exe, pressing Ctrl-], entering the "set localecho" command and double-pressing the Enter key), I was once again convinced that I was right. What, then, are the others so confidently saying?

I asked to send me the binary of the “working” telnet client and the version of the OS on which it was launched, in lichku. After making sure that the OS versions are the same (Windows 7 SP1 x64 was used), I turned my attention to the telnet client itself. The hashes matched. When I started the “working” binary user, according to the user k0ldbl00d , I was surprised to find that it doesn’t work on my computer either.
')
Maybe it's in the environment where telnet.exe is running? The original executable file was taken from the "% WINDIR% \ System32" directory, so I launched my telnet client from there, and ... I found that the "set localecho" command was working correctly in this situation. And if you copy the same executable file to any other directory and use it already, then, despite the fact that the basic functionality of telnet.exe will continue to work, the teams will no longer perform what is required of them.

What's the matter? Let's go.

How was the process, and what came of it, read under the cut. Before reading this article, I also strongly recommend that you familiarize yourself with the previous ones , since they have already explained many of the points outlined here.

First, my opinion fell on the absence of "greeting" messages in the case of running telnet.exe in a directory other than "% WINDIR% \ System32":

In case of correct operation (run from "% WINDIR% \ System32")


In case of incorrect operation (run from “C: \”)


Well, let's set the breakpoints on the instructions that refer to the given strings. But before doing this, let's turn off ASLR . This cannot be done using the method used in the previous article (editing the “DLL flags” field in a binary), since the normal replacement of executable files in the “% WINDIR% \ System32” directory is almost impossible . Therefore, I propose to disable ASLR for the entire system. Click Win-R -> regedit -> climb in “HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management” -> create or edit an existing option called “MoveImages” to make it equal to zero. After that, we reboot the system and enjoy the disabled ASLR.

Run telnet.exe, located in the directory "% WINDIR% \ System32", in OllyDbg , stop at Entry Point and look for "Welcome to" in the list of found OllyDbg lines that are referenced by the instructions in the "telnet" module. We see the message “Item not found” and start thinking in the direction of dynamically loading rows from third-party resources.

Press F9, wait for the start of the telnet client and again look for the same line:



Press Enter, pre-selecting the line that was just found, and see the instructions that refer to the lines from the "greeting" messages:



Let's put the hardware breakpoint on the record at 0x01029C40 , restart the application and see where these lines come from. The breakpoint is triggered here:



As you can see, we are somewhere in the depths of the WinAPI function LoadString (yes, this is obviously not noticeable, but, most likely, LoadStringBaseEx is called just from it). We jump to the nearest user code, which in this case is located at 0x0100C788 , and we see that the same calls are located nearby for getting other lines:



Let's see a little Above and make sure that LoadString was actually called in these places:



Let's find out from which module telnet.exe takes these strings. We set the breakpoint at 0x0100C62A , restart debugging and see that the argument responsible for the module name in the WinAPI function GetModuleHandle is zero:



According to the documentation, in this case GetModuleHandle returns, in essence, the handle of the current process file:

lpModuleName [in, optional]

[...]

If this parameter is NULL, GetModuleHandle returns the calling process (.exe file)

If you press F8 twice, we will see that this is true:



Further, this handle is used in all the LoadString calls we have encountered . For example,



But what is the problem then? If LoadString takes strings from the same file, how can changing their working directory affect the success of their extraction?

First, let's take Resource Hacker and see if it finds STRINGTABLE in telnet.exe:



As you can see, it is not. But what is it? Where do these lines come from then? Are loaded into the same module at run-time? Let's restart debugging and see if they are in the process memory at the start of the application. Press Ctrl-F2 in OllyDbg, press Alt-M to open the “Memory” window, select the first line with the left mouse button, press Ctrl-B and search for the “Welcome” Unicode line. This and other lines are really in the process memory at this stage:



Let's see where this memory area was from. Press Alt-M and see:



Now it is clear - this is MUI . If you create a directory called “en-US”, for example, in the root of the C drive, put the telnet.exe.mui file there and start the previously incorrectly working telnet client, we will see that now the “set localecho” command behaves absolutely correctly.

But wait. Even if telnet.exe could not display any lines, how could this affect the very result of executing the same “set localecho”? After all, one thing is not something to withdraw, and quite another thing is not to respond to the command entered by the user properly.

Let's put a bryak on the call to the line "Microsoft Telnet>", which is the "invitation" to enter the next command. Such instruction is located at 0x0100BEAA :



Press Ctrl-] in the telnet window, run through the application being debugged with F8 and stop at the next call to the WinAPI function ReadConsole :



Enter the “set localecho” command and study what happens after reading a line from the standard input stream.

First, the program checks the correctness of the ReadConsole function (the return value is non-zero, the number of bytes read is greater than zero, etc):



Some time later, we get into a loop in which the first character of the command entered by the user (in our case, 's') is checked for equality with the first characters of commands such as, for example, “quit” or “set”:



If you start debugging from another place that does not contain the “en-US” directories with the necessary .mui-file, then we will see that the lines with the names of the commands will be empty! This suggests that even they are stored in the telnet.exe.mui file. And you can verify this by searching for the corresponding lines in the process memory:



Consequently, in the absence of a .mui file, the telnet client could not even understand what kind of command the user entered, since rows for comparison were not loaded.

Why it was necessary to carry out even these lines in the .mui-file is a mystery for me personally. Perhaps Microsoft did not know how far the internationalization of their products would go (for example, “enable local echo”), or maybe they just wanted to have a single place where absolutely all the lines used in the program would be stored.

Afterword

Sometimes even the slightest change in the conditions in which the application under investigation is executed can affect the most unexpected lines of conduct. Do not be lazy to recheck all possible options and be attentive to any changes in the logic of the application.

Thank you for your attention, and again I hope that the article was useful to someone.