I am pretty sure the easiest way is to log packets is to find the code in the client that encrypts the packets and hook it. can't be that hard to find... start at the sockets and work your way up! Same for decryption, hook the client! why do the hard work when you can use the excisting code in the client. lazyness ftw
EDIT: Oh great, that is exactly what you did... nevermind
I'm talking about intercepting the data BEFORE encryption... somewhere the objects/values that are sent to the server must get serialized and encrypted through a function call... for example SendAndEncrypt(Object* myObject). If you find that function and hook it, then you don't have to find the decryption algorithm. And if you want to make a standalone client you can probably extract the encryption algo in asm and use it in your own program. Don't make things harder then they need to be!
(hard part is finding the function(s) that serialize/encrypt)
You know, you just made me want to figure this thing out, let's fire up my disassembler.
Ha. It's the most interesting part - to find encryption algo. Is far as I've discovered - client uses GNET::Octets for storing the encrypted data, but I'm stuck in findning where plain data being encrypted...
I took a little peek under the hood, and I found this
.data:0093A110 class GNET::CompressARCFourSecurity
.data:0093A110 class GNET::CompressARCFourSecurity
these are both RTTI type descriptors
I saw those called pretty close to some ws_32.send calls. Coincidence? I don't think so.
But who cares about those, when you have the objects that get used for sending data. You don't even have to reverse engineer the packet data, nor decrypt it.
and there are lots more, for walking, fighting, etc
Just find the constructor of these objects, add breakpoints, and you can figure the other stuff out yourself I think
ohyeah, receiving data, I don't know exactly how that works, but I am pretty sure it will clear itself up when you dig into these GNET objects. I'm guessing there is actually a callback to these objects when receiving data.
Just throwing in some ideas
EDIT:
I went a little deeper, I chose 1 object, GNET::ChatRoomCreate, and did some debugging, this is what I found.
Code:
005C86C0 [COLOR="Green"]CONSTRUCTOR of chatRoomCreate, gets normal string of the name of the chatroom[/COLOR]
v
sub_5B3B30, [COLOR="Green"]ENCRYPTION starts here, all data that gets send passes through here, this means walking, battling, skills etc
this is a function of a baseclass, either GNET::MARSHALL or GNET::PROTOCOL I know this because ecx gets passed [/COLOR]
v
sub_5B3B70, [COLOR="Green"]this is a function of an object at offset 0AC, this could be the encryption object?[/COLOR]
calls CALL DWORD PTR DS:[EDX] [COLOR="Green"]///these are just here[/COLOR]
v
somefunc [COLOR="Green"]///to show how the data gets at the socket[/COLOR]
v
00431490
{
00431507 |. FFD5 CALL EBP [COLOR="Green"]//copy data into socket to send[/COLOR]
}
BUT I am not sure if there is really encryption going on, no breakpoints hit on the RCFOUR code while I was testing. They might be just serializing the data in some compressed binary format, which would make more sense anyway
pretty easy to find with ollydbg... break on the send call, follow ECX in dump(pointer to the data), set breakpoint on that memory location and find out what writes to that. The line in red does that
mov esi, ecx //ESI = THIS ptr
mov eax, [esi+10h] //go to offset 10 in this instance of the class, dereference pointer
mov ecx, [eax+4] //go to offset 4 from the eax pointer, dereference it, here is the pointer to the data in ecx
push edx ; len
push ecx ; buf //give pointer to data to ws32_send(socket* s,char* buf,uint len);
push eax ; s
call ds:__imp_send
Packet Logger/Proxy 11/24/2007 - CO2 Exploits, Hacks & Tools - 81 Replies After seeing many "proxy" programs abuse trust and/or disappear I decided to make my own. I figured I might as well release it. Use it if you'd like. It runs off a similar system as my Emu I'm working on so you can get a general idea for it's power :o :P
The setup is simple. The config file is filled out as such:
proxy-address = yourip
server-address = 69.59.142.13
proxy-port = 9958
;ignore-id = 1010
;special-id = 1011
ignore-id ignores certain packets (both directions) from being...