Synchronizing and thread hijacking

[Lolrapa]

Well, I think this has passed from a coffee chat since I cant fix this f*** sh**

@DarkstaR you told me by chat that I should do this to make it work
1)Freeze tibia's main thread
2)Change the thread's instruction pointer to the address of my cave code
3)Storing orginal data
4)Resume thread
5)After returning from the call, inside my code cave I have to restore the original data
6)Change the instruction pointer to the original location

It sounds perfectly logic, but my code makes it in a different way and I'd like to know whats the difference
I do: (for packet sending)
1) Freeze tibia's main thread
2) Save OutgoingDataLen and AutgoingDataBuffer
3)Write new len and buffer values
4)Create a new thread and ejecute my code cave in it
5)Restore old Len and Buffer values
6)Resume main thread
(this makes tibia crash after many executions)


So, my questions are:
If I open a new thread inside tibia process the new thread and the main thread share the registers or if I modify a register in the new thread it won't modify in the main thread?
(If the register are shared)Then it means that I have to copy and restore every register that SendOutgoinPacket touchs? If so why in't allready that in TibiaSocket's code?


Thanks!!

[Casky]

I'm totally noob about this, but are you sure you have to restore the last Len/Buffer values? Did you try without do that?

[DarkstaR]

I'm totally noob about this, but are you sure you have to restore the last Len/Buffer values? Did you try without do that?

You do, 100%. If Tibia was in the middle of creating a packet, it will resume thinking that the packet is half done and finish creating it, then send a half-built packet.


Make sure there's no other data associated with the packet. For instance, the incoming packet buffer has position and length.

[Lolrapa]

You do, 100%. If Tibia was in the middle of creating a packet, it will resume thinking that the packet is half done and finish creating it, then send a half-built packet.


Make sure there's no other data associated with the packet. For instance, the incoming packet buffer has position and length.

Ok, now that i know about the context switch I can stay cool

SENDOUTGOINGPACKET modifies the incoming packet buffer?

[Casky]

You do, 100%. If Tibia was in the middle of creating a packet, it will resume thinking that the packet is half done and finish creating it, then send a half-built packet.

Oh, that makes totally sense, thank you.

[Lolrapa]

You do, 100%. If Tibia was in the middle of creating a packet, it will resume thinking that the packet is half done and finish creating it, then send a half-built packet.


Make sure there's no other data associated with the packet. For instance, the incoming packet buffer has position and length.

I've been runnung some test and I found that just calling SENDOUTGOINGPACKET changes a random amount of bytes in the memory (from 20 to 17000). There must be another thread changing the memory wile main thread is freezed. I can't find what is making the clinet crash.
If I freeze the main thread during a process that needs synchronization (with the server or something), that wouldn't make the client crash?

[DarkstaR]

I've been runnung some test and I found that just calling SENDOUTGOINGPACKET changes a random amount of bytes in the memory (from 20 to 17000). There must be another thread changing the memory wile main thread is freezed. I can't find what is making the clinet crash.
If I freeze the main thread during a process that needs synchronization (with the server or something), that wouldn't make the client crash?

This isn't a great test because of exactly what you just said: other threads.

A better way to find what is modified is to look at all constants touched by the assembly code of the send packet function.

[Lolrapa]

This isn't a great test because of exactly what you just said: other threads.

A better way to find what is modified is to look at all constants touched by the assembly code of the send packet function.

Ok, there are probably like 10000 but i'll try :P

[DarkstaR]

Ok, there are probably like 10000 but i'll try :P

It's a really small function if you look closely.. Many of the values are debug related (you can tell by the strings around them and safely ignore them). The first value (in the MOV fs:[0]) is also setting up the exception handler, so it can be ignored as well.

[Lolrapa]

It's a really small function if you look closely.. Many of the values are debug related (you can tell by the strings around them and safely ignore them). The first value (in the MOV fs:[0]) is also setting up the exception handler, so it can be ignored as well.

Can you show me how memory writes looks like, I've been looking for things like this MOV ESI,DWORD PTR DS:[A68248] but they seem to be text in memory