[Guide] Using Windows Detours to Redirect Silkroad to a Proxy

[pushedx]

This is the second guide in a three part series. The first part is the "A Simple Silkroad Proxy Reference" guide, which sets up a simple 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. The third and final guide will show how to use a clientless with the proxy and illustrate the power of the design.

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: . Since I am focusing on development tools and not end user tools, I will stick with this method for now.

This guide also makes use of . 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 function 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
edxLabs

[.1337]

and what this helps for?

[maxbot]

Originally Posted by .1337

and what this helps for?

Do you ****** read at all ? Basically, it redirects SRO to any address and port you want. It works like ... uhm ... redirect IP option from Testosterone.

[Shadowz75]

i am using another detour function, but this isnt working

#include <winsock2.h>
#include <stdio.h>
#include <windows.h>
#include "Detours.h"

#pragma comment(lib, "Detours.lib")
#pragma comment(lib, "ws2_32.lib")

typedef int (WINAPI * tconnect)(SOCKET s, const sockaddr *name, int namelen);
tconnect oconnect;


int WINAPI myconnect(SOCKET s, const sockaddr *name, int namelen)
{
	MessageBox(NULL,NULL,NULL,0);
	sockaddr_in si;
	memcpy(&si, name, sizeof(sockaddr_in));

	USHORT ServerPort = ntohs(si.sin_port);
	
	if(ServerPort == 15779 || ServerPort == 15778)
	{
		si.sin_addr.S_un.S_addr = inet_addr("127.0.0.1");
		return oconnect(s, (sockaddr*)&si, sizeof(sockaddr_in));
	}
	
	return oconnect(s, name, namelen);
}

BOOL WINAPI DllMain(HMODULE hDll, DWORD dwReason, LPVOID lpReserved)
{
	switch(dwReason)
	{
		case DLL_PROCESS_ATTACH:
		{		
			oconnect = (tconnect)DetourFunction((PBYTE)GetProcAddress(GetModuleHandle("ws2_32.dll"), "connect"), (PBYTE)myconnect);
			
		}
	}

	return TRUE;
}

[pushedx]

Originally Posted by Shadowz75

i am using another detour function, but this isnt working

I never could get the other style of Detours working correctly. That's why I used the style shown in my example. Take a look at the other examples in the Detours SDK folder for more examples and make sure you are also using Release mode (for the lib and project)! Good luck!

[pushedx]

Here's a package of CSRO, JSRO, ISRO, TSRO, and KSRO precreated detour files so you don't have to create them yourself.

All you have to do is copy the "silkroad.exe_edx.dat" and "sro_client.exe_edx.dat" into your Silkroad folder and you can either edit them normally by selecting the sro_client/Silkroad files from the DataFileCreator or just load up the proxy and set the right login server IP.

Eventually, the proxy will be able to use some predefined addresses so you don't have to retype the login server each time. But it is just a Lite version after all.

[BurnerGR]

I am gonna say what I have to say pretty simply:

******* "A"

#Thanks added

[babaluceala]

Hi, I have some problems trying to make sro working again.

15779 port is closed by my ISP and I tried to use detour this way:
original ip: 121.128.133.26(->30)
original port: 15779
new ip: 121.128.133.26(->30)
new port: 1119(open port from my ISP)

I tried to use it together with edx sro proxy, but I noticed that the proxy create the local server on those ports and try to connect to sro servers on the original port (15779).
Is there any way to make sro working on other ports? Or i'm doing it all wrong?

One more thing. My sro version is .213. Can I update sro if i change the port?

*off topic. Drew check your inbox

[bot90210]

15779 is the port the servers listen on, can't really not connect to it.

[babaluceala]

My intention is to make the server send the packets on any other port i want. Not to make the server listen on other ports.

[theoneofgod]

Originally Posted by babaluceala

My intention is to make the server send the packets on any other port i want. Not to make the server listen on other ports.

You want to change the way their servers work......

[serdel]

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.

Could you elaborate on this paragraph a little? What do you mean Silkroad security? Does client check CRC while running or something? I've been looking through source and I've been wondering what they are for.

[pushedx]

Originally Posted by serdel

Could you elaborate on this paragraph a little? What do you mean Silkroad security? Does client check CRC while running or something? I've been looking through source and I've been wondering what they are for.

The Silkroad security system involves setting up blowfish and a packet count and crc byte embedded in the packets themselves. If the packet count byte or crc byte is incorrect for any packet, you will get disconnected. Likewise, you need the blowfish correctly setup to decrypt the encrypted packets to be able to modify them.

The initial Silkroad security process involves using the Diffie-Hellman key exchange. In the picture on that page, Alice is the server and Bob is the client. Normally, the client generates the value b, which I referred to as the 'security seed'.

However, when I wrote the Silkroad Security API, I did not understand this entire process, so I hard coded the 'b' value in my API (well it's configurable, not hardcoded, but not dynamically generated) so everything would 'work'.

If you do not make the client use a value of 0x33 for the 'b' value, the security api will fail the handshake process. That is just a limitation of that api version. It is possible to avoid this altogether by using a classic man in the middle attack on the D-H exchange, which is was SR33, edx33, edxSilkroadProxy are meant to do, but the API itself has to be rewritten to support generating the 'server' and 'client' aspects of the exchange whereas the current API only supports a known 'b' value 'client' aspect.

Hopefully, that makes more sense!

[zefros]

My intention is to make the server send the packets on any other port i want. Not to make the server listen on other ports.

[onlyforsourcethx]

"You have been disconnected from the server".
This is a message that I see at the end of loading the splash screen.
Any advice?

I guess it's because of outdated opcodes but I'm not sure.