[Guide] Extracting Parsed Packets in Silkroad

[fanste]

May it be possible, that i send you the file with the headers and you compile it for me?

I have to wait 4 Weeks, than i can get the pro for free (student :-P )

€dit: i uploaded it. Would be nice. (Not necessary anymore HAX-Edit worked too :-P)

€dit2:
There are also some other problems with the code. I testet you "simple loader" which will only inject the dll and wont do any other changes through the dll, but the client keeps crashing.

I know that you wrote somewhere, that you won't do any more tools for tSRO, but im not that asm pro. Maybe you can look after it?

[pushedx]

Originally Posted by fanste

There are also some other problems with the code. I testet you "simple loader" which will only inject the dll and wont do any other changes through the dll, but the client keeps crashing.

Can you run TSRO through Silkroad.exe and load the client without any problems? Is the game fully updated? That's the only thing I can think of as to why that project would crash with the simple Loader and DLL tutorial. There's nothing specific in there that should cause the crash, so I'd think the crash might be from something else.

Or, perhaps the addresses you are using are not correct. I don't have an up to date version, but that could be the issue. I'll try to check your addresses tomorrow if I get time. If not, I'll wait until after the TSRO update since I'll be out of town Monday some of the day.

I know that you wrote somewhere, that you won't do any more tools for tSRO, but im not that asm pro. Maybe you can look after it?

I'm kind of stopping work on stuff for specific SROs and instead moving into more generic tools that work for all versions. The edxTSROMod project will be getting renamed and an update soon that will make it work for (hopefully) all Silkroad versions. Likewise, I didn't post a recompiled version of this analyzer because I'll be making my guide work autoupdate too and compatible with more versions. However, this stuff takes a lot of time and energy, so I'm just trying to get one thing out at a time.

However, I do test all my code on TSRO/ISRO still and I've not had any issues with what you are describing, so I don't think it's the specific code as much as either something with your install or the updates. Just keep messing with it for now to see if you can get it. Good luck!

[fanste]

It seems like the client and the server were sending some invalid packets (seen during the login so far). Could it be, that this is the reason, why it crashes?

Packets look like:

C->S[C1FD][32780]
0C 80 FD C1 59 7B 1B 46 B3 CE 66 81 3B 4A B5 5F 6B 2A

C->S[97A4][32784]
10 80 A4 97 B5 8B 77 14 64 91 24 D6 B2 F0 DF BD CC 94 25 33 6B 4B 76 D8 E9 10

S->C[8549][32790]
16 80 49 85 4E D2 FA F5 69 58 63 25 42 1C 62 DE 2B 3F FE 08 21 EE 19 E8 4F 3E 43
 32 85 61 0B FB 43 F2

Had to patch my little Proxy to be able to read them without a crash... (wireshark shows me the same packets, so its not a failure in the program...)

Originally Posted by pushedx

Can you run TSRO through Silkroad.exe and load the client without any problems? Is the game fully updated?

yes and yes.


€dit: Nothing is wrong here.. Just found yout, that this is the security System of sro :-P

[maxbot]

Originally Posted by fanste

C->S[C1FD][32780]
0C 80 FD C1 59 7B 1B 46 B3 CE 66 81 3B 4A B5 5F 6B 2A

C->S[97A4][32784]
10 80 A4 97 B5 8B 77 14 64 91 24 D6 B2 F0 DF BD CC 94 25 33 6B 4B 76 D8 E9 10

S->C[8549][32790]
16 80 49 85 4E D2 FA F5 69 58 63 25 42 1C 62 DE 2B 3F FE 08 21 EE 19 E8 4F 3E 43
 32 85 61 0B FB 43 F2

Had to patch my little Proxy to be able to read them without a crash... (wireshark shows me the same packets, so its not a failure in the program...)

Those are all encrypted packets.

[fanste]

See my edit Found it already out yesterday.. But thx

[Low_Riders]

whats that good for ?
sry to ask, but i cant read that much lol

[pushedx]

Originally Posted by Low_Riders

whats that good for ?
sry to ask, but i cant read that much lol

It's a method for showing how the client parses packets from the server. Using the guide, a programmer would be able to see exactly how packets are parsed, so they can more easily identify the packet layout.

In other words, rather than people having to spend time on trying to figure out the packet structure for Silkroad, this does it for them. As a result, they only have to figure out what the data is and use it in their own packet based projects.

This is most useful for emu development, bot development, or any other packet based utilities as it cuts down on a lot of work if you were starting from scratch.

[soadmania]

This needs to be updated to l4+.
i tried but stucked. new opcode is 3431. i found it with proxy. i got the MOV DWORD PTR SS:[ESP+C],3431. then i followed the MOV DWORD PTR SS:[ESP+10],7AA410 .


idk what im gonna do now :/

[pushedx]

The guide is more for explaining the concepts behind the approach. The last posted 205 project a few replies earlier is what you should be using to update and actually make a project from since it fixes bugs the original project had.

Here's the modified 205 to work with 210. I deleted the GUI specific stuff and it just uses the console. All you have to do is use OllyDbg to update DLL.h for future updates, that's it! The guides are a "reference" and you can't follow them exactly. You have to just get the idea of what's going on from them instead.

Also, as I mentioned in other threads, eventually I'll be moving all these guides to my generic auto-update framework so they are compatible with all versions, but first I have to get my edxSilkroadLoader project done, update my edxSIlkroadProxy, and work on a few other things. That means I won't be getting around to updating these guides for a while. However, once they are done, then they shouldn't need much more maintenance, but first I have to get the framework they are going to work on done.

[fanste]

I tried it over and over again, also with your last none-GUI version, but the Game keeps crashing during the splash-screen (somewhere in "ntdll.dll"). Maybe it is cuz of win7.. but the iSRO-version is working...
I hope it will work for me too as soon as you were able to build it with your new framework.

€dit:
it's working now with many many modifications... I had to use a third-party DLL-Injector and apply a little modification to the dll so it will start after it got injected. Not perfect and it still crashes when i inject it before i joined the world (and sometimes ingame). But better than nothing

[pushedx]

Originally Posted by fanste

I tried it over and over again, also with your last none-GUI version, but the Game keeps crashing during the splash-screen (somewhere in "ntdll.dll"). Maybe it is cuz of win7.. but the iSRO-version is working...
I hope it will work for me too as soon as you were able to build it with your new framework.

€dit:
it's working now with many many modifications... I had to use a third-party DLL-Injector and apply a little modification to the dll so it will start after it got injected. Not perfect and it still crashes when i inject it before i joined the world (and sometimes ingame). But better than nothing

Really weird. I've not had any other reports of people having trouble with the method on various OSs. I develop on Win7 32bit myself and have tested on Win7 x64 in the past and didn't run into any problems. That method was developed and hihgly tested on WinXP for a number of years. In ever got around to running Vista on my desktop, but I did test it for a while on my x64 laptop.

I'm not sure what's going on in your system that causes the crash, sorry!

I have only one code change suggestion to make to you to see if it helps. Make sure to run in Debug mode and Release mode to see if that makes a difference. I am beginning to think release mode might mess up some of the ASM due to optimizations:

#define _CRT_SECURE_NO_WARNINGS
#include <windows.h>
#include "../common/common.h"
#include "DLL.h"

//-------------------------------------------------------------------------

// Global instance handle to this DLL
HMODULE gInstance = NULL;

// Function prototype
void UserOnInject();
void UserOnDeinitialize();

//-------------------------------------------------------------------------

// Main DLL entry point
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ulReason, LPVOID lpReserved)
{
	UNREFERENCED_PARAMETER(lpReserved);
	if(ulReason == DLL_PROCESS_ATTACH)
	{
		gInstance = hModule;
		// Do not notify this DLL of thread based events
		DisableThreadLibraryCalls(hModule);
	}
	else if(ulReason == DLL_PROCESS_DETACH)
	{
		UserOnDeinitialize();
	}
	return TRUE;
}

// This is the main function that is called when the DLL is injected into the process
extern "C" __declspec(dllexport) void OnInject(DWORD address, LPDWORD bytes)
{
	// Restore the original bytes at the OEP
	DWORD wrote = 0;
	WriteProcessMemory(GetCurrentProcess(), UlongToPtr(address), bytes, 6, &wrote);

	// Call our user function to keep this function clean
	UserOnInject();
}

//-------------------------------------------------------------------------

namespace CC_ExtractSentPacket
{
	DWORD currentOpcode;
	LPBYTE currentBuffer;
	DWORD currentSize;

	void OnProcessDataStart()
	{
		printf("[C->S]%X\n", (WORD)currentOpcode);
	}

	void ProcessData()
	{
		for(DWORD x = 0; x < currentSize; ++x)
		{
			printf("%.2X ", currentBuffer[x]);
			if((x+1)%16==0)
				printf("\n");
		}
		printf("\n");
	}

	void OnProcessDataEnd()
	{
		printf("\n");
	}

	void EnableParseHook();
	void DisableParseHook();

	DWORD codecave_SetOpcode_ReturnAddress = 0;
	__declspec(naked) void codecave_SetOpcode()
	{
		__asm pop codecave_SetOpcode_ReturnAddress
		__asm MOV AX,WORD PTR SS:[ESP + 0x04] // Original code
		__asm mov currentOpcode, eax
		__asm pushad
		EnableParseHook(); // Start hooking writes
		__asm popad
		__asm push codecave_SetOpcode_ReturnAddress
		__asm ret
	}

	DWORD codecave_WriteBytes_ReturnAddress = 0;
	__declspec(naked) void codecave_WriteBytes()
	{
		__asm pop codecave_WriteBytes_ReturnAddress

		__asm mov currentBuffer, eax
		__asm mov currentSize, ebp

		__asm pushad
		ProcessData();
		__asm popad

		// Even though this comes first, we will use EBX and then fix it up
		// afterwards. This is ok since ECX is not disturbed.
		__asm MOV EBX, ECX

		// This line seems to give the client problems when compiled in VS,
		// so we have to rewrite it a little. This might be one of the hardest
		// things to figure out if you were doing this yourself and not
		// too experienced.
		__asm MOV DWORD PTR SS:[ESP + 0x10], EAX

		/*__asm
		{
			mov ebx, esp
			add ebx, 0x10
			mov [ebx], eax
		}

		// Now set our EBX value to what it should be
		__asm MOV EBX, ECX*/

		__asm push codecave_WriteBytes_ReturnAddress
		__asm ret
	}

	DWORD codecave_PostProcessPacket1_ReturnAddress;
	__declspec(naked) void codecave_PostProcessPacket1()
	{
		__asm pop codecave_PostProcessPacket1_ReturnAddress

		__asm pushad
		DisableParseHook();
		OnProcessDataEnd();
		__asm popad

		// We choose this line because it is the easiest to codecave and won't likely change
		__asm MOV EAX, 0x1008 // Remember #s have to be in HEX! 1008 != 0x1008

		__asm push codecave_PostProcessPacket1_ReturnAddress
		__asm ret
	}

	void EnableParseHook()
	{
		// A little trick I came up with to filter out the packets received
		// that make use of this functionality. Not sure if it'll always work,
		// but it "should" since the higher 4 bytes of any C->S packet in the
		// executable will be 0 since they are hard coded into the client!
		DWORD result = currentOpcode & 0xFFFF0000;

		//printf("Result = %i\n", result); // Debugging
		if(result == 0)
		{
			// Let the user know we have an new packet being built
			OnProcessDataStart();

			// Hook the byte writing function
			edx::CreateCodeCave(CC_ExtractSentPacket_Address_1, 6, codecave_WriteBytes);

			// Hook the post build processing function
			edx::CreateCodeCave(CC_ExtractSentPacket_Address_2, 5, codecave_PostProcessPacket1);
		}
	}

	void DisableParseHook()
	{
		// Restore the byte writing function code
		static BYTE patch1[] = {0x8B, 0xD9, 0x89, 0x44, 0x24, 0x10};
		edx::WriteBytes(CC_ExtractSentPacket_Address_1, patch1, 6);

		// Restore the post build processing function code
		static BYTE patch2[] = {0xB8, 0x08, 0x10, 0x00, 0x00};
		edx::WriteBytes(CC_ExtractSentPacket_Address_2, patch2, 5);
	}

	void Setup()
	{
		edx::CreateCodeCave(CC_ExtractSentPacket_Address, 5, codecave_SetOpcode);
	}
}

//-------------------------------------------------------------------------

namespace CC_ExtractPacket
{
	DWORD currentOpcode;
	LPBYTE currentBuffer;
	DWORD currentSize;
	void * packetPtr;

	DWORD lastAddr = 0;

	void OnProcessDataStart()
	{
		printf("[S->C]%X\n", (WORD)currentOpcode);
	}

	void ProcessData()
	{
		for(DWORD x = 0; x < currentSize; ++x)
		{
			printf("%.2X ", currentBuffer[x]);
			if((x+1)%16==0)
				printf("\n");
		}
		printf("\n");
	}

	void OnProcessDataEnd()
	{
		printf("\n");
	}

	void ProcessPacket()
	{
		LPBYTE lpBuffer = (LPBYTE)packetPtr;
		DWORD packetData = *(LPDWORD)(lpBuffer + 0x18 - 4);
		currentOpcode = *((LPWORD)(lpBuffer + 0x18));
		WORD packetLength = *((LPWORD)(lpBuffer + 0x18 - 16));
		if(lastAddr == packetData)
		{
		}
		else
		{
			lastAddr = packetData;
			OnProcessDataStart();
		}
	}

	DWORD codecave_ReadBytes_ReturnAddress = 0;

	__declspec(naked) void codecave_ReadBytes()
	{
		__asm pop codecave_ReadBytes_ReturnAddress

		__asm mov currentBuffer, eax
		__asm mov currentSize, ebx

		__asm pushad
		ProcessData();
		__asm popad

		// Emulate the rest of the function since our codecave overlaps it all
		__asm POP ESI
		__asm MOV EAX,EBX
		__asm POP EBX
		__asm RET 8
	}

	void EnableParseHook()
	{
		edx::CreateCodeCave(CC_ExtractPacket_Address_2, 7, codecave_ReadBytes);
	}

	void DisableParseHook()
	{
		OnProcessDataEnd();

		static BYTE patch[] = {0x5E, 0x8B, 0xC3, 0x5B, 0xC2, 0x08, 0x00};
		edx::WriteBytes(CC_ExtractPacket_Address_2, patch, 7);
	}

	DWORD codecave_HookPacketProcess_ReturnAddress;
	__declspec(naked) void codecave_HookPacketProcess()
	{
		__asm pop codecave_HookPacketProcess_ReturnAddress

		__asm mov packetPtr, ebx
		__asm pushad
		ProcessPacket();
		EnableParseHook();
		__asm popad

		__asm PUSH EBX
		__asm CALL NEAR EAX
		__asm CMP EAX,1

		__asm pushad
		DisableParseHook();
		__asm popad

		__asm push codecave_HookPacketProcess_ReturnAddress
		__asm ret
	}

	void Setup()
	{
		edx::CreateCodeCave(CC_ExtractPacket_Address_1, 6, codecave_HookPacketProcess);
	}
}

//-------------------------------------------------------------------------

// The function where we place all our logic
void UserOnInject()
{
	// Create a debugging console
	edx::CreateConsole("edxAnalyzer Debugging Console");

	// Mutex for the launcher, no patches required to start Silkroad now
	CreateMutexA(0, 0, "Silkroad Online Launcher");
	CreateMutexA(0, 0, "Ready");

	CC_ExtractSentPacket::Setup();
	CC_ExtractPacket::Setup();
}

//-------------------------------------------------------------------------

void UserOnDeinitialize()
{
}

//-------------------------------------------------------------------------

In this code, the changes were:
- Use

__asm MOV EBX, ECX
__asm MOV DWORD PTR SS:[ESP + 0x10], EAX

instead of:

__asm
{
	mov ebx, esp
	add ebx, 0x10
	mov [ebx], eax
}
// Now set our EBX value to what it should be
__asm MOV EBX, ECX

- Call OnProcessDataStart(); before CreateCodeCave in CC_ExtractSentPacket :: EnableParseHook

- Call OnProcessDataEnd() before WriteBytes in CC_ExtractPacket :: DisableParseHook

The first change should not matter since the ASM is the same. However, on the second and third changes, I noticed those fixed a similar crash I have been experiencing on a different project where I am saving the parsed data into buffers but sometimes I crash right after character login. I am still noticing some crashes which trace back to a Silkroad error, so I'm trying to figure out why that is happening.

I don't know why you'd be the only one to experience that with this code though, but that's my only idea for the situation. If I find anything else, I'll let you know!

[fanste]

Your new code is working much better than before. I can use your Loader at startup without any problems anymore.

€dit: (i made a mistake in the dll, thats the real error^^)
It wont crash till now, cuz i do not get a char-list. I will test now if the dll blocks the request-packet or the answer from the server

€dit 1:
wow - the new dll is changing the packet after it was logged to the console. The reason is the first change (ASM part). With the old asm it works (as you wrote in a comment). But it keeps crashing on JoinToWorld [always on S->C packets]

[pushedx]

Originally Posted by fanste

€dit 1:
wow - the new dll is changing the packet after it was logged to the console. The reason is the first change (ASM part). With the old asm it works (as you wrote in a comment). But it keeps crashing on JoinToWorld [always on S->C packets]

Ok, I'll be looking into the method some more then. It seems that it will work 'most of the time', however, there are occasions that it breaks in certain situations. That means the method is not 100% compatible with the client, which is just a downside of any client based patch, since it's not really meant to work that way. I'll spend some more time this week trying to improve it.

[fanste]

That would be great

Maybe it helps you a bit (only tsro packets - no change to login in isro -.-): I realized that it crashes mostly on the 0x385f packet (sometimes on 0x3013 - JoinPacket/CharData). Dunno for what it is. It hooks and dehooks the client, but no data will be logged to the console (but the size is 0x0065)

Order is (opcodes S->C):
0x3809 (unknown till now)
0x303D (Charstats - hp, mp, etc)
0x30BF (ActionPacket)
0x385F (...)

[soadmania]

i have reported that crash error before. it 'sometimes' crashes at char select screen. dont know why but after i reinstall sro and unpack the original client again it works o.o