a few questions for Fr3DBr & kLabMouse

Technology · **Joined:** 06 May 2008, 12:47 **Posts:** 801

First of all, gratz on breaking & implementing bRO's C->S packetprefix encryption system!

If you guys have time to elaborate a bit, I'm kinda curious to learn which methods were used to accomplish this.

Like, kLab did you RE the algo from the client or server files or something?
Or was the method more like capturing the client's outgoing packets and comparing their encrypted packetswitches with the original unencrypted one and trying to find a pattern?
Or a combination of both?
Also, is this a known or a custom algorithm?

Also:
085A - 0883: sync_request_ex (incoming) (41 packets)
0884 - 08AC: dunno_name (outgoing) (41 packets)
So that the +0x29 (41 in dec) is just to answer for example 085A with 0884 right?

Also, each "record" in the the recvpackets.txt now has 4 fields? Seems like I missed that change somewhere.

EternalHarvest · **Joined:** 05 Dec 2008, 05:42 **Posts:** 1811

Technology wrote:

Also, each "record" in the the recvpackets.txt now has 4 fields?

Yeah. Fields: packet switch, length (0 or -1 for dynamic length), unused, unused.

Also, "move" send packet from bRO is called "character_move" in kRO - it should have a common name across all serverTypes (and all the sendMove subs to be replaced with one in Send.pm later).

EternalHarvest · **Joined:** 05 Dec 2008, 05:42 **Posts:** 1811

Code:

+      (map { (sprintf "%04X", $_) => ['sync_request_ex'] } 0x085A..0x0883),
-      '085A' => ['sync_request_ex'],
-      '085B' => ['sync_request_ex'],
-      '085C' => ['sync_request_ex'],
-      '085D' => ['sync_request_ex'],
-      '085E' => ['sync_request_ex'],
-      '085F' => ['sync_request_ex'],
-      '0860' => ['sync_request_ex'],
-      '0861' => ['sync_request_ex'],
-      '0862' => ['sync_request_ex'],
-      '0863' => ['sync_request_ex'],
-      '0864' => ['sync_request_ex'],
-      '0865' => ['sync_request_ex'],
-      '0866' => ['sync_request_ex'],
-      '0867' => ['sync_request_ex'],
-      '0868' => ['sync_request_ex'],
-      '0869' => ['sync_request_ex'],
-      '086A' => ['sync_request_ex'],
-      '086B' => ['sync_request_ex'],
-      '086C' => ['sync_request_ex'],
-      '086D' => ['sync_request_ex'],
-      '086E' => ['sync_request_ex'],
-      '086F' => ['sync_request_ex'],
-      '0870' => ['sync_request_ex'],
-      '0871' => ['sync_request_ex'],
-      '0872' => ['sync_request_ex'],
-      '0873' => ['sync_request_ex'],
-      '0874' => ['sync_request_ex'],
-      '0875' => ['sync_request_ex'],
-      '0876' => ['sync_request_ex'],
-      '0877' => ['sync_request_ex'],
-      '0878' => ['sync_request_ex'],
-      '0879' => ['sync_request_ex'],
-      '087A' => ['sync_request_ex'],
-      '087B' => ['sync_request_ex'],
-      '087C' => ['sync_request_ex'],
-      '087D' => ['sync_request_ex'],
-      '087E' => ['sync_request_ex'],
-      '087F' => ['sync_request_ex'],
-      '0880' => ['sync_request_ex'],
-      '0881' => ['sync_request_ex'],
-      '0882' => ['sync_request_ex'],
-      '0883' => ['sync_request_ex'],

EDIT: fixed array ref

Technology · **Joined:** 06 May 2008, 12:47 **Posts:** 801

EternalHarvest wrote:

Technology wrote:

Also, each "record" in the the recvpackets.txt now has 4 fields?

Yeah. Fields: packet switch, length (0 or -1 for dynamic length), unused, unused.

Also, "move" send packet from bRO is called "character_move" in kRO - it should have a common name across all serverTypes (and all the sendMove subs to be replaced with one in Send.pm later).

hmm "unused", is that the length of the internal nested structs?

@Harvest, I also agree about the common names and moving of all sendWhatever subs in one Send.pm.
It seems like the right thing to do to remove the copy pasting and reach convergence once again.
However, we must be careful not to break backward compability with older(like kRO timeline) and other servertypes.
To do that, we must instead of changing stuff to existing packets in the Send.pm, create a new version of given packet and name that like the one with "_v2" in the back to ensure backward compability with older/other/all servertypes. (even received packets that change their struct should be versioned)
(btw, Fr3DBr, what I'm saying here is unrelated to your patch, just in general an answer to what EternalHarvest said)

Technology · **Joined:** 06 May 2008, 12:47 **Posts:** 801

EternalHarvest wrote:

Code:

+      (map { (sprintf "%04X", $_) => 'sync_request_ex' } 0x085A..0x0883),
-      '085A' => ['sync_request_ex'],
-      '085B' => ['sync_request_ex'],
-      '085C' => ['sync_request_ex'],
-      '085D' => ['sync_request_ex'],
-      '085E' => ['sync_request_ex'],
-      '085F' => ['sync_request_ex'],
-      '0860' => ['sync_request_ex'],
-      '0861' => ['sync_request_ex'],
-      '0862' => ['sync_request_ex'],
-      '0863' => ['sync_request_ex'],
-      '0864' => ['sync_request_ex'],
-      '0865' => ['sync_request_ex'],
-      '0866' => ['sync_request_ex'],
-      '0867' => ['sync_request_ex'],
-      '0868' => ['sync_request_ex'],
-      '0869' => ['sync_request_ex'],
-      '086A' => ['sync_request_ex'],
-      '086B' => ['sync_request_ex'],
-      '086C' => ['sync_request_ex'],
-      '086D' => ['sync_request_ex'],
-      '086E' => ['sync_request_ex'],
-      '086F' => ['sync_request_ex'],
-      '0870' => ['sync_request_ex'],
-      '0871' => ['sync_request_ex'],
-      '0872' => ['sync_request_ex'],
-      '0873' => ['sync_request_ex'],
-      '0874' => ['sync_request_ex'],
-      '0875' => ['sync_request_ex'],
-      '0876' => ['sync_request_ex'],
-      '0877' => ['sync_request_ex'],
-      '0878' => ['sync_request_ex'],
-      '0879' => ['sync_request_ex'],
-      '087A' => ['sync_request_ex'],
-      '087B' => ['sync_request_ex'],
-      '087C' => ['sync_request_ex'],
-      '087D' => ['sync_request_ex'],
-      '087E' => ['sync_request_ex'],
-      '087F' => ['sync_request_ex'],
-      '0880' => ['sync_request_ex'],
-      '0881' => ['sync_request_ex'],
-      '0882' => ['sync_request_ex'],
-      '0883' => ['sync_request_ex'],

Lol, Harvest, your patch sure is cute.

But maybe too cute... Given that it will possibly make grepping a certain packetswitch in kore harder in the future.
Besides doesn't it need [] brackets around the 'sync_request_ex'? I seem to remember that as such it created a reference to an array?

Fr3DBr · **Posted:** 19 Jan 2012, 22:38

This was a merge of all you said technology, but today they applied another updated and randomized it all over again, im studying to see whats different now...

PS: It happened after they noticed another wave of bots, yes they are wanting to take over with then ...

Reversing....
Sniffing...
Comparing...
Testing for an hour, testing for another hour, error, trial, frustration, try again, yay, etc..

Technology · **Joined:** 06 May 2008, 12:47 **Posts:** 801

Fr3DBr wrote:

This was a merge of all you said technology, but today they applied another updated and randomized it all over again, im studying to see whats different now...

PS: It happened after they noticed another wave of bots, yes they are wanting to take over with then ...

Reversing....
Sniffing...
Comparing...
Testing for an hour, testing for another hour, error, trial, frustration, try again, yay, etc..

awch, good luck tough, I'll be going to sleep now.

Btw, so this implies they changed the client executable again?

Fr3DBr · **Posted:** 19 Jan 2012, 23:30

Technology wrote:

Fr3DBr wrote:

This was a merge of all you said technology, but today they applied another updated and randomized it all over again, im studying to see whats different now...

PS: It happened after they noticed another wave of bots, yes they are wanting to take over with then ...

Reversing....
Sniffing...
Comparing...
Testing for an hour, testing for another hour, error, trial, frustration, try again, yay, etc..

awch, good luck tough, I'll be going to sleep now.

Btw, so this implies they changed the client executable again?

Yes they did, for the 2nd time this week =)

EternalHarvest · **Joined:** 05 Dec 2008, 05:42 **Posts:** 1811

Technology wrote:

hmm "unused", is that the length of the internal nested structs?

Yeah, something like that. kLab can elaborate this.

Technology wrote:

However, we must be careful not to break backward compability with older(like kRO timeline) and other servertypes.

Yeah, that's why sendMove along with several other packets isn't refactored yet. I tried to be extra careful here, even added a static packet structure test for kRO.

Technology wrote:

To do that, we must instead of changing stuff to existing packets in the Send.pm, create a new version of given packet and name that like the one with "_v2" in the back to ensure backward compability with older/other/all servertypes. (even received packets that change their struct should be versioned)

Maybe. Also, instead of making any new version, reconstruct() may be used directly.

Technology wrote:

Besides doesn't it need [] brackets around the 'sync_request_ex'? I seem to remember that as such it created a reference to an array?

Yeah, forgot that one.

kLabMouse · **Joined:** 24 Apr 2008, 12:02 **Posts:** 1301

OK. Well this was something like this:
1) Client.exe -> Dump memory
2) Locate Networking Functions
3) Locate Encryption
4) Reverse it, see where it innit's and how it works
5) Make a little .asm file that output's key's to check against perl implementation that FR3DbR made
6) Fail again Because of Numeric Int overload
7) Make a solution using BigInt
8) Fail Again because of Deprecated packets and Packet ID randomizations
9) Diff RecvPackets to get the Randomization, Like I did back in old times, when I was working with our old Developer: heero.
10) Bingo, now it's more stable
11) Find out, that Deprecated packets cause DC and possible Ban. Damn
12) FR3DbR Implements new functions and changed packet ID's. Good to go, wait for next version
13) Make some HEX patterns to locate functions more easy.
14) On new .exe -> Goto Step (1), Repeat only necessary steps.

Openkore.com

a few questions for Fr3DBr & kLabMouse

Who is online