a few questions for Fr3DBr & kLabMouse

Forum closed. All further discussion to be discussed at https://github.com/OpenKore/

Moderator: Moderators

Message
Author
Technology
Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

a few questions for Fr3DBr & kLabMouse

#1 Post by Technology »

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.
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

EternalHarvest
Developers
Developers
Posts: 1800
Joined: 05 Dec 2008, 05:42
Noob?: Yes

Re: a few questions for Fr3DBr & kLabMouse

#2 Post by EternalHarvest »

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
Developers
Developers
Posts: 1800
Joined: 05 Dec 2008, 05:42
Noob?: Yes

Re: a few questions for Fr3DBr & kLabMouse

#3 Post by EternalHarvest »

Code: Select all

+		(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
Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

Re: a few questions for Fr3DBr & kLabMouse

#4 Post by Technology »

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)
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

Technology
Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

Re: a few questions for Fr3DBr & kLabMouse

#5 Post by Technology »

EternalHarvest wrote:

Code: Select all

+		(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?
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

Fr3DBr
Developers
Developers
Posts: 60
Joined: 05 Oct 2011, 09:21
Noob?: No
Location: Brazil

Re: a few questions for Fr3DBr & kLabMouse

#6 Post by Fr3DBr »

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
Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

Re: a few questions for Fr3DBr & kLabMouse

#7 Post by Technology »

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?
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

Fr3DBr
Developers
Developers
Posts: 60
Joined: 05 Oct 2011, 09:21
Noob?: No
Location: Brazil

Re: a few questions for Fr3DBr & kLabMouse

#8 Post by Fr3DBr »

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
Developers
Developers
Posts: 1800
Joined: 05 Dec 2008, 05:42
Noob?: Yes

Re: a few questions for Fr3DBr & kLabMouse

#9 Post by EternalHarvest »

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
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: a few questions for Fr3DBr & kLabMouse

#10 Post by kLabMouse »

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.

Locked