a few questions for Fr3DBr & kLabMouse
Moderator: Moderators
-
- Super Moderators
- Posts: 801
- Joined: 06 May 2008, 12:47
- Noob?: No
a few questions for Fr3DBr & kLabMouse
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.
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!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
-
- Developers
- Posts: 1798
- Joined: 05 Dec 2008, 05:42
- Noob?: Yes
Re: a few questions for Fr3DBr & kLabMouse
Yeah. Fields: packet switch, length (0 or -1 for dynamic length), unused, unused.Technology wrote:Also, each "record" in the the recvpackets.txt now has 4 fields?
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).
-
- Developers
- Posts: 1798
- Joined: 05 Dec 2008, 05:42
- Noob?: Yes
Re: a few questions for Fr3DBr & kLabMouse
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'],
-
- Super Moderators
- Posts: 801
- Joined: 06 May 2008, 12:47
- Noob?: No
Re: a few questions for Fr3DBr & kLabMouse
hmm "unused", is that the length of the internal nested structs?EternalHarvest wrote:Yeah. Fields: packet switch, length (0 or -1 for dynamic length), unused, unused.Technology wrote:Also, each "record" in the the recvpackets.txt now has 4 fields?
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).
@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!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
-
- Super Moderators
- Posts: 801
- Joined: 06 May 2008, 12:47
- Noob?: No
Re: a few questions for Fr3DBr & kLabMouse
Lol, Harvest, your patch sure is cute.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'],
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!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
Re: a few questions for Fr3DBr & kLabMouse
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..
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..
-
- Super Moderators
- Posts: 801
- Joined: 06 May 2008, 12:47
- Noob?: No
Re: a few questions for Fr3DBr & kLabMouse
awch, good luck tough, I'll be going to sleep now.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..
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!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
Re: a few questions for Fr3DBr & kLabMouse
Yes they did, for the 2nd time this week =)Technology wrote:awch, good luck tough, I'll be going to sleep now.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..
Btw, so this implies they changed the client executable again?
-
- Developers
- Posts: 1798
- Joined: 05 Dec 2008, 05:42
- Noob?: Yes
Re: a few questions for Fr3DBr & kLabMouse
Yeah, something like that. kLab can elaborate this.Technology wrote:hmm "unused", is that the length of the internal nested structs?
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:However, we must be careful not to break backward compability with older(like kRO timeline) and other servertypes.
Maybe. Also, instead of making any new version, reconstruct() may be used directly.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)
Yeah, forgot that one.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?
Re: a few questions for Fr3DBr & 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.
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.