Packet Tokenizer issue with users of XKore 1

[heero]

Greetings everyone,

I have been busy with real life work that I have hardly checked into Opnekore. I took a look at the issue with Packet Tokenizer that everyone is getting when they managed to get Openkore running using XKore 1 so here is what I have seen so far, btw I am still using the simplest of tools for packet capture (WPE Pro).

Code: Select all

116.93.120.134:4500  x.x.x.x:63557  28  Recv  
0000  71 00 40 C2 01 00 6E 65 77 5F 35 2D 33 2E 67 61    q.@...new_5-3.ga
0010  74 00 00 00 00 00 74 5D 78 86 37 27                t.....t]x.7'

When you receive the packet above that tells your client you have loaded the map, the receive packets change form [packet switch][packet data] it becomes [packet length][packet switch][packet data]. These are just my quick checking of the new pRO Packets. Below are some examples.

Code: Select all

116.93.120.134:10039  x.x.x.x:63589  9  Recv  
0000  09 00 00 83 02 59 8D 02 00                         .....Y...

The packet above is packet 0283 which is account_id packet when a map is loaded, notice there are 9 bytes received (9 Recv) and the number 09 00 at the start of the packet. The math again (9 - 3) - 2 = 4 which is Received Packets - bytes used by packet length (normally 3) - bytes used by packet switch (normally 2). The packet code for account_id is this '0283' => ['account_id', 'a4', [qw(accountID)]], as you can see its 4 for the packet data

Code: Select all

116.93.120.134:10039  x.x.x.x:63558  70  Recv  
0000  21 00 00 95 00 C8 C3 00 00 52 6F 64 61 20 46 72    !........Roda Fr
0010  6F 67 00 00 00 00 00 00 00 09 00 00 00 0F 00 00    og..............
0020  00 25 00 00 C8 08 24 D6 02 00 DA C3 00 00 49 C0    .%....$.......I.
0030  B5 05 6C 02 00 00 20 01 00 00 00 00 00 00 00 01    ..l... .........
0040  00 00 00 00 00 00                                  ......

The packet above has 21 at the start meaning it is 33 bytes long and then see the 4th byte "95 00" (0095) that is the packet for actor_info which has 28 bytes of packet data. So by math again (33 - 3) -2 = 28 which is Received Packets - bytes used by packet length (normally 3) - bytes used by packet switch (normally 2). The packet code for actor_info is '0095' => ['actor_info', 'a4 Z24', [qw(ID name)]], as you can see the packet data contains 28 bytes (a4 and z24 total of 28). Then if you look at the bytes after the 33 bytes you will see this "25 00 00 C8 08" the 25 means its 37 bytes long and the "C8 08" (08C8) signifies the packet for actor_action which has 32 bytes of packet data based on the code '08C8' => ['actor_action', 'a4 a4 a4 V3 x v C V', [qw(sourceID targetID tick src_speed dst_speed damage div type dual_wield_damage)]], its a bit tough for normal users of our forum but the other devs will get the idea.

This is just a quick look I did on my off time. When I get more free time I will consider reprogramming openkore abit (thats if I get any free time again -_-) to address this issue but it may take a while for that so I am posting my findings here for other devs to see and perhaps they can do their own fix on the issue.

This topic is only for developers to commend dont post stuff like asking for this and that here. This is only for people who want to know what is going on with the client. Any post not related to the main topic will be deleted.

[janjajan]

I have a question, so we get the packets and value in bytes, but then how do we know the value corresponds to those packets??

Like this line for example "['actor_action', 'a4 a4 a4 V3 x v C V', [qw(sourceID targetID tick src_speed dst_speed damage div type dual_wield_damage)]]"

[heero]

You dont need to know that part the only thing that needs reprogramming in openkore is that when the packet for map load is sent you switch the packet recognition to handle the 3 extra bytes at the start. You dont need to know what the structure of the packets are they are still the same.

[kali]

Interesting.

Looks like it's not gonna be a simple fix, if that's really the case. The packet parser will need to be rewritten.

[kali]

One quick fix might be to pad the initial packet with three random bytes, and recvpackets lengths increased by three. That way we can still reuse the old packet parsers, the only issue being the last packet sent would be "incomplete" until the next packet arrives (which isn't much of an issue while in the map server since the heartbeat packets fire quite regularly)

[islarky88]

0009 => 0283 => '0283' => ['account_id', 'V', [qw(accountID)]],
0010 => 02EB => '02EB' => ['map_loaded', 'V a3 x2 v', [qw(syncMapSync coords unknown)]],
000E => 01D7 => '01D7' => ['player_equipment', 'a4 C v2', [qw(sourceID type ID1 ID2)]],
000B => 00B0 => '00B0' => ['stat_info', 'v V', [qw(type val)]],

dunno about this one...

0013

[fclose]

0009 => 0283 => '0283' => ['account_id', 'V', [qw(accountID)]],
0010 => 02EB => '02EB' => ['map_loaded', 'V a3 x2 v', [qw(syncMapSync coords unknown)]],
000E => 01D7 => '01D7' => ['player_equipment', 'a4 C v2', [qw(sourceID type ID1 ID2)]],
000B => 00B0 => '00B0' => ['stat_info', 'v V', [qw(type val)]],

Isn't the first 2 bytes are full lenth of each packet segment?
e.g 0009 = 9 bytes (header included)
0010 = 16 bytes
000E = 14 bytes

[janjajan]

I tried to use debug mode, then I found out that for example the character move action, if use with xKore 0, it was sending packet "035F" but with using xKore 1 and I move the character, it was sending "0008" packet to the client. So maybe the packets were encrypted?

[heero]

I tried to use debug mode, then I found out that for example the character move action, if use with xKore 0, it was sending packet "035F" but with using xKore 1 and I move the character, it was sending "0008" packet to the client. So maybe the packets were encrypted?

First off you clearly did'nt understand what I said in the first post so do go back and read again. Second, you are saying xKore 0 sends a different packet to xKore 1, clearly you dont know the meaning of what you said so to explain it. Openkore is an Automated client for RO, the word client here is important. What one client sends is different from what another client sends if the two are not identical. What you said is like saying iRO client is sending this while pRO client is sending another, thats how it is in simpler terms. I know you want to try to contribute but the idea you posted clearly did'nt have much depth since you failed to understand what I first posted. Please do go back and read the first post again.

Interesting.

Looks like it's not gonna be a simple fix, if that's really the case. The packet parser will need to be rewritten.

Its good to see you again kali, we devs dont really need to touch packet parser but instead can just modify xKore.pm to handle the new received packets and cut it from there. After all they just added the size of the packet which now helps us know the length of the actual packet instead of relying on recpackets.txt. I will try to get time later after work if I can and see if I can make a simple fix to xKore 1 just for pRO.

[kali]

I tried to use debug mode, then I found out that for example the character move action, if use with xKore 0, it was sending packet "035F" but with using xKore 1 and I move the character, it was sending "0008" packet to the client. So maybe the packets were encrypted?

First off you clearly did'nt understand what I said in the first post so do go back and read again. Second, you are saying xKore 0 sends a different packet to xKore 1, clearly you dont know the meaning of what you said so to explain it. Openkore is an Automated client for RO, the word client here is important. What one client sends is different from what another client sends if the two are not identical. What you said is like saying iRO client is sending this while pRO client is sending another, thats how it is in simpler terms. I know you want to try to contribute but the idea you posted clearly did'nt have much depth since you failed to understand what I first posted. Please do go back and read the first post again.

Interesting.

Looks like it's not gonna be a simple fix, if that's really the case. The packet parser will need to be rewritten.

Its good to see you again kali, we devs dont really need to touch packet parser but instead can just modify xKore.pm to handle the new received packets and cut it from there. After all they just added the size of the packet which now helps us know the length of the actual packet instead of relying on recpackets.txt. I will try to get time later after work if I can and see if I can make a simple fix to xKore 1 just for pRO.

Ah.

I'm not as interested in botting inasmuch as recreating an alternate client for RO

But yeah, I guess if xKore works with a small fix, that's already a plus.

Are you hanging out on irc?