search

Google-Code-Fork / tibiaapi

Automatically exported from code.google.com/p/tibiaapi
MIT License
0 stars 0 forks source link

InjectedDLL OnGetNextPacket #173

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
A few "problems" with r758

1) If you hook OnGetNexPacket before login it'll crash the client upon login.
2) If you unhook OnGetNextPacket the client will crash.
3) The addresses for OnGetNextPacket and RecvStream were including in
Core.cpp because I couldn't get it to work by sending the packets through
the pipe. (I believe the problem is with pRecvStream(?)).
4) Before I changed the OnGetNexPacket parser into multiple switch cases
the client would crash upon floor changes. So far I haven't had any
problems, but it seems to lag the client. Maybe this could be fixed by
putting the parser into it's on function on a seperate thread? (I have no
clue how to do that by the way).
5) Without also hooking Recv, Send didn't seem to work so it was commented
out and therefor we can't check outgoing packets. If someone wants to
retest hooking Send for me then I would appreciate it.

I think that's all the problems I can remember. The reason for this commit
was because the parser for Recv wasn't working right and the packets
weren't being parsed correctly resulting in inefficiency of packet events.
I've tested several packet events and they all seem to be working great
with this method. If you have any questions, concerns, etc. please reply.

Original issue reported on code.google.com by joebingham07@gmail.com on 2 Nov 2009 at 12:01

GoogleCodeExporter commented 9 years ago 
1) I found this is because of the parsing.
2) See #1.
3) My bad, RecvStream is the only address included in Core.cpp. Also I forgot 
to move
the values and such back to Core.h, not a big deal right now.
4) The "lag" is due to how long it takes to return iCmd because of the parsing. 
Is
there anyway to go ahead and return iCmd and let the packet parse in a seperate
function? This wouldn't let the end user block/modify the packet, but I don't 
see any
reason why they would need to anyways.
5) If the Send buffer goes through the same parsing as Recv then it would also 
be
inefficient, correct? If the Send buffer only holds individual packets I'll 
test it
again.

Original comment by joebingham07@gmail.com on 2 Nov 2009 at 5:31

GoogleCodeExporter commented 9 years ago 
Fixed #3, and I left the variables in Core.cpp.

Original comment by joebingham07@gmail.com on 2 Nov 2009 at 7:14

GoogleCodeExporter commented 9 years ago

Original comment by joebingham07@gmail.com on 10 Nov 2009 at 7:08

GoogleCodeExporter commented 9 years ago 
Deprecating hooking OnGetNextPacket and gonna fix the current packet parser.

Original comment by joebingham07@gmail.com on 12 Nov 2009 at 4:47