bRO's client asking for PIN Code on log in

[ever_boy_]

yeah, I'm sure about that too. When entering the pin code, you send this 08B8 guy, which is always:
2 bytes for packet ID, 4 bytes for account ID, 4 encrypted bytes for your pin code.

One tip about the encrypting system is that it is fixed for all number at a time. In other words, if you encrypt four 'ones' in a given pin code, they'll have the same encrypted byte, like:
31 31 31 31
If your pin code is 5 6 5 6, the packet would be something like
37 32 37 32 or 31 33 31 33 (I'm guessing the values, the point here is that repeated numbers have repeated encrypted bytes).

[Kurama]

me too :c

edit
maybe the encrypt is based on 08b9 first 4 data.

[iMikeLance]

yeah, I'm sure about that too. When entering the pin code, you send this 08B8 guy, which is always:
2 bytes for packet ID, 4 bytes for account ID, 4 encrypted bytes for your pin code.

One tip about the encrypting system is that it is fixed for all number at a time. In other words, if you encrypt four 'ones' in a given pin code, they'll have the same encrypted byte, like:
31 31 31 31
If your pin code is 5 6 5 6, the packet would be something like
37 32 37 32 or 31 33 31 33 (I'm guessing the values, the point here is that repeated numbers have repeated encrypted bytes).

So you're able to sniff it and send it's data through OpenKore if you know how it looks like when encrypted?

[ever_boy_]

me too :c

edit
maybe the encrypt is based on 08b9 first 4 data.

yeah, that's a possibility... or maybe they're just 4 bogus random bytes =S gotta check that out.

So you're able to sniff it and send it's data through OpenKore if you know how it looks like when encrypted?

No, maybe I didn't make myself clear.

1st time you send your pin code, lets say 5 6 5 6. Here's what it might look like:

08 B8 XX XX XX XX 32 37 32 37

2nd time you send the exact same code:

08 B8 XX XX XX XX 38 31 38 31


even though they're the same code, they randomly change everytime. But, in each given time, the repeated numbers have repeated encrypted codes, which leads me to the following conclusion: each byte is encrypted separately, and they share the exact same encryption code.


edit:
The last time we had something like this happening, rebalance patch was being released. Back then "many" people from bRO's community started doing something to help. Now, there's 600 views on this topic, yet noone except for iMike and EternalHarvest are actually doing something. What's the matter, are you just too shy to say something, or you just come here, gather info, and then head back to your "group", and share information between yourselves?
Well, doesn't matter, just a thought. Let's get back to work.

[Fat4LitY]

On the third and fourth connections they changed again? If so we could find a pattern.

[ever_boy_]

Hmm.. I didnt get that last part. Did you find the formula or not?
So, how many bytes should have in the packet sent by kore?

If you're sure that the "send PIN" packet is 08B8 it should be 10bytes

Well, but when I tried to unpack kLabMouse's packets:

Code: Select all

unpack('H*', $msg));

it showed a huge sequence of.... 40 bytes or maybe more. I think that even if something was a little screwed between his encryption code and our data (since I'm merging both at ServerType0.pm), it shouldn't be something so far from the real thing.

On the third and fourth connections they changed again? If so we could find a pattern.

yeah, I'll try all sort of patterns and combinations, like that.
but anyone could do that too, just turn on wireshark, use a filter for your char server, and start testing.

[Fat4LitY]

How is the expression used to filter only 200.229.50.* as IP destination?


Edit: I've discovered but used 200.229.50.4 (Thor Server).

[ever_boy_]

200.229.50.*

ip.addr == 200.229.50.21 (asgard)

ip.addr: filters by ip address, incoming and outcoming
ip.dst: filters packets whose destination is the assigned ip
ip.src: filters packets whose source is the assigned ip
frame.len: filters packet by length, usually used as > 54, since packet's id start at 55, 56 bytes.



it seems that the 'random' bytes in 08B9 packet do change even when you enter incorrect pin code, which seems to point to some sort of key. that would make the job harder *sigh*

[Fat4LitY]

Putting 0101 PIN:

0 1 0 1
1) 31 35 31 35
2) 31 33 31 33
3) 36 38 36 38
4) 31 33 31 33
5) 38 33 38 33
6) 31 39 31 39
7) 32 38 32 38
8) 35 32 35 32

Put wrong PIN by purpose (1010):
1 0 1 0
9) 39 31 39 31
X) 33 36 33 36

[flashdbest]

Putting 0101 PIN:

0 1 0 1
1) 31 35 31 35
2) 31 33 31 33
3) 36 38 36 38
4) 31 33 31 33
5) 38 33 38 33
6) 31 39 31 39
7) 32 38 32 38
8) 35 32 35 32

Put wrong PIN by purpose (1010):
1 0 1 0
9) 39 31 39 31
X) 33 36 33 36

I noticed that some of them are being repeated. (perhaps it's a list of values instead of being completely random)
anyways can you try searching for those values BEFORE you send the pin? maybe those values are being sent to client first?