1 Attachment(s)
[C++] Using Detours for packets redirection to a proxy
Using Detours for packet redirection to a proxy
This guide shows how to create your own hook and detour to use that proxy (or any other for that matter) with the client.
Note: While this article for the Silkroad, the concepts still apply to any game and you only need to make a couple of changes for it to work in other games
There is not that much code across the three projects in this guide, but some of the concepts are advanced. It took a lot of trial and error to come up with a detour method I was finally happy with, but this is definitely the approach I'll be using in the future due to its flexibility.
Attached is the complete project and workspace as well as a binary build. The two additional zip files, isro_dat and tsro_dat, are predefined detour files for ISRO and TSRO. To use them, extract them into your ISRO or TSRO folder and use the "DataFileCreator.exe" to select either sro_client.exe or Silkroad.exe to load the addresses.
Using Windows Detours to Redirect Silkroad to a Proxy
I. Purpose
The purpose of this guide is to show one advanced method of using Windows Detours to redirect Silkroad (or any other executable) to your own proxy. The methods shown here closely resemble what was used for edx33, but this version has some nice additions to it to make it more reusable.
In the previous guide, A Simple Silkroad Proxy Reference, I showed one specific proxy implementation. However, we do not yet have an easy way of making the client connect to the proxy. This guide will allow us to finally achieve that goal. Once we learn the basics of the approach, we can then extend it to other games as well since the method is pretty generic.
This guide will only cover detouring the connect API function, but if you go through the Windows Detours samples, you will see how you can detour any API really with only a minimal amount of work. You should be mindful of the Detours license though before you commit to using it on any projects!
II. Requirements
For the hooking, this guide makes use of the AppInit_DLLs registry key hook. This type of hook is not the best type of hook to use when you are creating programs to redistribute that are not developer tools due to the way the hook works. You can mess up your system if you are not careful, so do not play around with the registry unless you know what you are doing! For a brief reference on the registry key, take a look at this article: Working with the [Only registered and activated users can see links. Click Here To Register...]. Since I am focusing on development tools and not end user tools, I will stick with this method for now.
Quote:
Originally Posted by Microsoft
The AppInit_DLLs value is found in the following registry key:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWindows
All the DLLs that are specified in this value are loaded by each Microsoft Windows-based application that is running in the current log on session.
The AppInit DLLs are loaded by using the LoadLibrary() function during the DLL_PROCESS_ATTACH process of User32.dll. Therefore, executables that do not link with User32.dll do not load the AppInit DLLs. There are very few executables that do not link with User32.dll.
Because of their early loading, only API functions that are exported from Kernel32.dll are safe to use in the initialization of the AppInit DLLs.
The AppInit_DLLs value has type "REG_SZ." This value has to specify a NULL-terminated string of DLLs that is delimited by spaces or by commas. Because spaces are used as delimiters, do not use long file names. The system does not recognize semicolons as delimiters for these DLLs.
Typically, only the Administrators group and the LocalSystem account have write access to the key that contains the AppInit_DLLs value.
This guide also makes use of [Only registered and activated users can see links. Click Here To Register...]. It is advisable to download and install the entire SDK to better understand the power of the library, but the required files needed for this guide are included. There are a few caveats to know about the detours library before using it.
First, the library itself does not seem to work in Debug mode. You have to compile and test in Release mode. Next, if the executable is packed or utilizes 3rd part protections, there’s a good chance the detours will not work correctly. For the best results, you need to work on an unpacked and unprotected client. Finally, some antivirus may detect certain changes as malicious. The reason for this has to do with how some malware detours specific functions to take advantage of a computer. While you should not have any serious problems detouring connect, if it just doesn’t work, check to make sure your antivirus is not blocking the application due to the changes!
Finally, this guide does include a GUI based program, so a Visual Studio 2008 version above Express Edition is needed to compile that. Included are the binaries once again and that specific tool should not need to be recompiled again unless you wanted to add more features.
III. Theory
The first bit of theory that needs to be mentioned in this guide is the DLL injection. As mentioned previously, this guide will use the AppInit_DLLs registry key hook. Basically, Windows will automatically inject any DLL that is located in this path to any process that links to User32.dll. This is a pretty powerful injection method, but can also be misused so you have to be careful. If you happen to inject a DLL that crashes the current process and are unable to unhook the DLL, you will have some annoying work to do to fix everything. Because of this, I must urge people to be really careful with this because as I’ve already seen with edx33, most people don’t read the Readme’s on how to properly use it. They expect to be able to delete files and have it remove automatically and that is not the case!
For your own programs, you might consider just using the Injected DLL and Loader guide to accomplish this task in practice. The detour code would simply go into the injected DLL and you would not have to worry about the otherwise intrusive registry injection method. However, if you wanted to run something alongside another product that has its own loader, you won’t be able to, which is why for development the registry hook is superior. There are many other ways to go about DLL injection, but that is not the purpose of this guide. There are plenty of resources online to search through!
The new bit of theory for this guide has to do with Windows Detours and how we will creatively use them to achieve our task. For full information on what the Detours library provides and an overview, have a look at the Windows Detours site first. Pretty much, the library does all of the hard work for us and all we have to do is utilize the SDK with the specific API functions we wish to detour and we’re set!
Once we have the ability to detour the connect function, we have to consider what we want to do with it. If you take a look at how the [Only registered and activated users can see links. Click Here To Register...] works, we pass it a socket, the address to connect to, and the size of the structure. The format the address is in for an IPv4 address is pretty simple. The first two bytes are the port and the next 4 bytes are the IP address.
If we process the port and the IP address byte by byte, we can determine which address the client is connecting to and then change it if we want. Our whole system is built on simply redirecting connections from an original address to a new proxy address. For our proxy, we will always be running on localhost.
The creative part to the solution presented in this guide is a way to be able to detour any EXE and reroute any access address using the same DLL. To accomplish this, I’ve created a small data driven system as well as an accompanying tool to make the file creation easy. This approach is what I took on my edxMiddleMan project (not publicly released) but this specific implementation is much better! I will be updating that project using this approach later.
So just to recap, we need a way to inject a DLL into a process. We already know one but we will learn another one that is more suitable for development tools. Once we have our DLL injection method, we will use Windows Detours to easily detour the connect API function. In the new detour function we will write, we will use our detouring logic to determine which addresses need to be rerouted to new addresses. Once that is done, we are ready to test!
The last thing to mention is that since Silkroad has its own custom security, I’ve added in a hard coded check to patch the security bytes in ISRO and TSRO so we can test our proxy easily. For a real program, you’d have that logic somewhere else, but for the sake of this guide, I just placed it in the detour DLL. You could even use a similar approach that the detour logic uses to load the patches from a file if you wanted to. There’s a lot to choose from.
IV. Implementation
The Hook project is really simple and well documented. It explains the process of using the registry injection method. As mentioned before, you need to be careful with this method!
The Detour is our custom DLL that detours connect. The code is easily adaptable to another DLL as long as you remember the rules of DLLMain. A few functions taken from our Common.cpp/h have been embedded into the project so if you do use the code in another guide’s setup, you will need to remove it.
The DataFileCreator is a small tool that will let users specify the detouring addresses. Using the tool is pretty simple. A user first selects the executable that will be detoured. This is so the program can create the data file in that directory, which is required for the hooked DLL to work correctly on that EXE. From there, the user specifies the target IP and port and which IP to remap to. For the original IP, the user can use 255 to specify a wildcard address and -1 for any port. This kind of logic allows for a more powerful detouring process when there are many world servers like Silkroad has and only a few Login servers (not that you need to detour the world servers in Silkroad!)
In addition, the tool does automatic loading and saving based on the EXE file you choose. The file is stored in a binary format though, so you need to use the tool to edit the data files. The reason a binary format is used is to make loading the data in DLLMain as easy as possible. Here are two screenshots of how ISRO and TSRO should look using the data file tool:
You would first create those files and then start the edxSilkroadProxy. For ISRO, the default login server is already set so for TSRO that’s all you have to change. Once you change the login address through the GUI, you can just login! Remember to use the debug version of the proxy so you can see the packets to be sure it is working correctly. If you don’t see any packets, then something is not right.
V. Conclusion
Well, that about wraps up this guide. With all three of these projects and our proxy, we now have a complete solution that is similar to edx33/SR33! There is not that much code here and there’s a fair amount of comments so you should be able to follow through it. Remember that these guides are oriented towards making developer tools, so if you want to make an end user tool, you might need to change up a few things here and there.
You can use this code for other applications as well. The Windows Detour library is very powerful and an invaluable programming tool to use. Since this guide covered using clients alongside the proxy, the next guide will cover using a really simple clientless! Stay tuned for more.
© Drew “pushedx” Benton
