SendPacket To server.

[klusbert]

Okay today when I wake up I started studying tibia in olly. I was trying to learn more about the sendPacketfunction, I noticed that before every call to the sendPacket() there was some other calls.

I will show you here:

// this is for player speech in main channel.

  PUSH 96h  //packetType
  CALL 0524A50h // a function that adds packettype into networkstream
  PUSH EBX  // I know this is a byte value so I can assume that 524D70h is the function to add byte values to the stream
  CALL 0524D70h
  PUSH EDI  // same here I know this is a string.
  CALL 0525290h
  PUSH 1h  // this is always 1
  CALL 0525740h

  PUSH 0A1h
  CALL 0524A50h  //yet again to add packetype
  PUSH ESI
  CALL 05250D0h this is new? But I know this is a uint32 value becouse this creatureID
  MOV EAX,DWORD PTR DS:[9A5A54h]
  PUSH EAX
  CALL 05250D0h yep same function as above   attackCount
  PUSH 1h
  CALL 0525740h

I was just playing around with this and did not gave so much time, I just wanted to see if it would work and it did.

Updated it, fixed the problem with esp thanks to Sketchy also some other fixes. Now it should work properly

[Sketchy]

Two things which you probably figured already. The AddPacketType function does a bit more than just that, it also resets the buffer position back to the start after the type ID (ie: position 9) and nullifies the packet header structure, to be more accurate I would call it something along the lines of ResetPacket. The parameter for SendPacket also isn't always 1, it's a boolean value to tell SendPacket to encrypt the packet with XTEA which will be true for all packets except the two login packets which will pass 0 instead.

For the stack cleaning you will want to add 4 to ESP for the packet type, another 4 for each additional value you add to the packet and finally another 4 for the SendPacket parameter. So assuming you clean the stack a single time after you call SendPacket the calculation should be something like "4 + (packet.Length * 4)" where the packet array also contains the packet type like it currently does in your code.

[klusbert]

Thanks man! I will do some more research some day, this helps!

[klusbert]

Updated fixed the problem with esp, and some other fixes.
I think it should work now.
Big thanks to Sketchy

[Sketchy]

No problem.

One thing I forgot to mention is using CreateRemoteThread runs the risk of conflicting with the client's main thread which may be attempting to send a packet at the same time causing undesirable results. Ideally you would want some sort of synchronisation between the two threads to prevent such conflicts, this would be the next thing I suggest looking into. A simple idea which Dark used in TibiaSock is to suspend the main thread and backup the packet data & position then create your thread, then restore the original data & position and resume the thread.

[klusbert]

yeah i was already thinking of this, but I want to see if I can manage to do it without freezing the thread. but first I want to create a cave to send packets to client. And as it is right now you will need 5 addresses to get this to work. that's too much so I want to improve that too.

but honestly what do you think about this method? I am pretty proud of it, but I want some professional opinion:-)

[Sketchy]

One idea is to use a locking mechanism on both threads so it blocks the other while it is creating and sending a packet. What I'm thinking is to create the lock object within the Tibia process, I'd suggest using critical sections for performance reasons. Then hook the reset/add packet type and send packet functions to instead call their own code caves, the reset/add cave acquires the lock then calls the original function while the send cave calls the original function then releases the lock. You should also call these two code caves inside your packet generation cave instead of the original functions too, or at the very least acquire the lock at the start and release at the end. The issue here is hooking the functions, I would suggest a trampoline hook where you overwrite the start of the function with a jump to your code cave where at the end you reimplement the instructions you overwrote and simply jump back to the first unmodified instruction in the original function. This gets a bit more tricky with send packet though since you need to release the lock after the original function returns, in this case you should do two code caves where the first one calls the second which implements the overwritten send packet instructions and jumps to the original code, then at the end of the first one you release the lock. Sorry if this sounds confusing, hopefully the following pseudo-code helps.

CreatePacket()
{
	push type
	call AddPacketType()
	.......
	push encrypt
	call SendPacket()
}

AddPacketType(type)
{
	jump ResetCave()
	
	OrigInstruction:	// First non-overwritten instruction
}

SendPacket(encrypt)
{
	jump SendCave1()
	
	OrigInstruction:	// First non-overwritten instruction
}


// Everything after this should be in your allocated memory, I'd do it in a single allocated block
AddCave(type)
{
	push &section	// Should be the address of your critical section structure
	call EnterCriticalSection()
	
	// Overwritten instructions from AddPacketType here
	jump AddPacketType.OrigInstruction
}

SendCave1(encrypt)
{
	push encrypt // Must re-push encrypt parameter back onto stack
	call SendCave2()
	
	push &section
	call LeaveCriticalSection()
	
	retn
}

SendCave2(encrypt)
{
	// Overwritten instructions from SendPacket here
	jump SendPacket.OrigInstruction
}

// I'd store this after your code caves so you don't have to consider the structure size, just allocate plenty of memory. To create it you should be able to remote thread InitializeCriticalSection with the address of the section as the parameter
CRITICAL_SECTION section

I haven't tried this but it should work fine and it's probably the most efficient way of synchronising the two threads I can think of since they will only take the lock while sending a packet, and you also don't have to mess around with any extra addresses other than getting the address of the critical section APIs but they're no problem to get with a simple GetProcAddress within your application. If you do decide trying this, or anyone else, I'd also suggest initialising the critical section before hooking either function and then hook SendPacket first to avoid the risk of the main thread taking indefinite ownership of the section if you hook AddPacketType first.

And about this method of creating packets in general, I like it. Using its own send function is definitely a great thing to do so you don't need to mess with encryption and what not, and using its own functions for setting up the buffer is also better than doing so yourself since you ensure data is properly added and don't have to mess about figuring out how the buffer works. Of course you still have the issue of having to make sure the data you do add properly follows the protocol but as long as you are careful with it you should be fine. I do feel a few things in your implementation could be a bit better designed, namely the CodeCaveHelper class to work on adding specific instructions rather than you specifying every byte to add, but that's all just personal preference in what I'd want if I were designing it really and you still working and experimenting with it. And yeah you should definitely feel proud for experimenting with new or different approaches

[klusbert]

Thanks again, I'll have a look as soon I get some free time again