bRO's client asking for PIN Code on log in

Wrote new code? Fixed a bug? Want to discuss technical stuff? Feel free to post it here.

Moderator: Moderators

Fat4LitY
Noob
Noob
Posts: 14
Joined: 03 Sep 2012, 17:51
Noob?: No

Re: bRO's client asking for PIN Code on log in

#51 Post by Fat4LitY »

flashdbest wrote:
Fat4LitY wrote: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?
I'm still unaware about how communications are made on Ragnarok, Ever_boy is more aware of how it's maded.

I'm trying to discover wich operation they might have been used to make these sorts everytime. What are clearly to see is that only 0-9 numbers are used and changed (the "3" seems to not change, by the moment), don't know yet if it's a random math operation or some XOR with other packet (like used before).

Need to perform more tests.
satsujin
Noob
Noob
Posts: 3
Joined: 13 Dec 2012, 13:45
Noob?: Yes

Re: bRO's client asking for PIN Code on log in

#52 Post by satsujin »

ever_boy_
i'm from bro community, but i have no idea what you guys are doing, i'm coming here to see how the situation is developing cuz i'd like to go back to botting, but i have no idea whatsoever what u guys are doing, i'd really really like to help but i have no idea how, i'm a noob programmer, but is there any kind of tutorial or something alike that could teach me how to help? or maybe someone could add me on skype and explain things... i dont know, i dont like running around like a headless chicken waiting for a solution
Kaspy
Halfway to Eternity
Halfway to Eternity
Posts: 398
Joined: 08 Jun 2012, 15:42
Noob?: No
Location: Brazil

Re: bRO's client asking for PIN Code on log in

#53 Post by Kaspy »

The case of random values of the PIN would not be the same case Kafra Password?
Image
ever_boy_
Developers
Developers
Posts: 308
Joined: 06 Jul 2012, 13:44
Noob?: No

Re: bRO's client asking for PIN Code on log in

#54 Post by ever_boy_ »

KeplerBR wrote:The case of random values of the PIN would not be the same case Kafra Password?
Actually it doesn't seem anything like kafra's packet.
Sent password packet is 36 bytes long, while sent pin code packet is 10 bytes long. Encryption system must be pretty different too, though it seems much simpler.
satsujin wrote:i'd really really like to help but i have no idea how, i'm a noob programmer, but is there any kind of tutorial or something alike that could teach me how to help? or maybe someone could add me on skype and explain things... i dont know, i dont like running around like a headless chicken waiting for a solution
It's ok. If you start learning now, maybe you can help next time we get something like this. Start with macros, then move on to plugins or anything related to kore's code itself.
flashdbest wrote: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?
read my post bellow, you'll get a better idea of what happens.
Fat4LitY wrote:Putting 0101 PIN:

Put wrong PIN by purpose (1010):
There's no practical difference between, valid, wrong, right, etc. The client will encrypt the PIN code and send it to the server. Then, the server will decide what to do with it, and what kind of answer to send back.
I sent invalid PIN (four repeated numbers) 10 times and got this:
(B9 stand for server's query, B8 stands for client's reply. omitted account info from 08B8 packet)

1
b9 08 4e e3 49 0a
b8 08 38 38 38 38
2
b9 08 14 59 4d 0a
b8 08 31 31 31 31
3
b9 08 38 cd 52 0a
b8 08 35 35 35 35
4
b9 08 e0 10 56 0a
b8 08 32 32 32 32
5
b9 08 8a 04 58 0a
b8 08 31 31 31 31
6
b9 08 6e b5 5e 0a
b8 08 32 32 32 32
7
b9 08 ca dd 5e 0a
b8 08 31 31 31 31
8
b9 08 ca fb 5e 0a
b8 08 31 31 31 31
9
b9 08 21 01 61 0a
b8 08 39 39 39 39
10
b9 08 d2 41 61 0a
b8 08 31 31 31 31

- The 'key' received with 08B9 (assuming it's a key) is stuck with your char account till you send a pin code. Even if you close the game client, the key stays the same.

e.g.:
login account A, gets key 01 01 01 01
close the game client, login account A again, gets key 01 01 01 01
close the game client, login account B, gets the key 02 02 02 02
close game client, login account A, the key will still be 01 01 01 01
back to the account B, you log it in, enter a PIN code, thus getting a new key for account B
back to the account A, still stuck with key 01 01 01 01

Once you get a key, you're stuck with it till you use it. I guess this isn't stored client-side. Good thing is, the game sends us the key, so we don't need to figure out what's gonna be he next key. It's only relevant for the encryption code. Again, assuming that it's a key.
There's somehitng odd about it: How could two different keys generate the same encrypted bytes, for the same PIN code?

e.g:
server sends key 01 01 01 01
client sends PIN 0000
encrypted bytes sent to serevr are 31 31 31 31
server sends key 02 02 02 02
client sends PIN 0000
encrypted bytes sent to server are 31 31 31 31

I've seen this happening in my tests. Looks like it's not a key to me. But I might be wrong.

Also, note that the '3' appears in every byte. Knowing that, only the byte's second digit changes. I'm thinking the encryption is a sum: 30h + ?
PIN code's range is from 0 to 9. 0 to 9 in hexadecimal have the same values in decimal. So... all that matters is knowing how to change 0000 into 1111 or 8888, or something like that, because that's what happens:

you type in PIN code 0000
client encrypts your pin, changing the 0 into another single digit, lets say 8.
then it sums up the encrypted digit with fixed 30h, and thus the byte is ready to be sent: 38 38 38 38

Well, that's my theory.


edit:
I was looking for kafra's packets now, and something is bugging me: when I add something to the storage, wireshark gives me packet 4117, and 4196 when I remove from storage, when in fact they are 0883 and 0802.
Now I remembered that some packets are encrypted (using the 3 hexa keys in bRO.pm). Are the storage add/remove also encrypted when sent? In this case, is the 08B8 packet also encrypted, meaning it is not really 08B8?
Last edited by ever_boy_ on 14 Dec 2012, 01:56, edited 1 time in total.
iMikeLance
Moderators
Moderators
Posts: 208
Joined: 01 Feb 2010, 17:37
Noob?: No
Location: Brazil - MG

Re: bRO's client asking for PIN Code on log in

#55 Post by iMikeLance »

ever_boy_ wrote: edit:
I was looking for kafra's packets now, and something is bugging me: when I add something to the storage, wireshark gives me packet 4117, and 4196 when I remove from storage, when in fact they are 0883 and 0802.
Now I remembered that some packets are encrypted (using the 3 hexa keys in bRO.pm). Are the storage add/remove also encrypted when sent? In this case, is the 08B8 packet also encrypted, meaning it is not really 08B8?
bRO's client and Openkore's bRO Servertype starts packet IDs encryption ONLY after logging into mapserver, so you're safe at charserver (where we're working at).

EDIT: Could it be that this "key" is not a key but some data containing last login result (last failed PIN login, PIN login attempts)?
ever_boy_
Developers
Developers
Posts: 308
Joined: 06 Jul 2012, 13:44
Noob?: No

Re: bRO's client asking for PIN Code on log in

#56 Post by ever_boy_ »

iMikeLance wrote:EDIT: Could it be that this "key" is not a key but some data containing last login result (last failed PIN login, PIN login attempts)?
I don't think so. It changes just too... randomly. Will do some more tests and check for this though.
The fact is, the key changes randomly. So, either these 4 bytes are really the key for encrypting our PIN's digits, or maybe they use the storage encrypt keys, the same way mRO does.

Here:

Code: Select all

$msg = pack("C C v", 0x3B, 0x02, $type).$pass.pack("H*", "EC62E539BB6BBC811A60C06FACCB7EC8");
what does this 0x3B, 0x02 (or 0x0968 in bRO) stand for? I can figure it out everything else looking at the code+sent packet, except for this.


edit:
There seems to be another problem: kore sends char login packet BEFORE sending PIN code packet. So, regardless of PIN packet's content, it would still get disconnected if char login packet is sent before we answer the PIN code request.
I think we should send char login packet (0066) only after receiving 08B9 with flag 0.
So char login (0066) should be a reply to PIN code (08B9) with flag 0, not to char list packet (08D2). How do we do that?
Kurama
Noob
Noob
Posts: 19
Joined: 13 Dec 2012, 17:26
Noob?: No

Re: bRO's client asking for PIN Code on log in

#57 Post by Kurama »

Image
first digit -> second digit

you receive the 08B9 packet with numbers position, but always the first number has the data "30".

now, we just need know what is the numbers positions and then make the packet



ITS NOT ENCRYPTED!
Last edited by Kurama on 14 Dec 2012, 05:11, edited 1 time in total.
EternalHarvest
Developers
Developers
Posts: 1798
Joined: 05 Dec 2008, 05:42
Noob?: Yes

Re: bRO's client asking for PIN Code on log in

#58 Post by EternalHarvest »

ever_boy_ wrote:There seems to be another problem: kore sends char login packet BEFORE sending PIN code packet. So, regardless of PIN packet's content, it would still get disconnected if char login packet is sent before we answer the PIN code request.
I think we should send char login packet (0066) only after receiving 08B9 with flag 0.
So char login (0066) should be a reply to PIN code (08B9) with flag 0, not to char list packet (08D2). How do we do that?
For example, you can cancel character select with "charSelectScreen" hook (using "return" key). Set it when initializing serverType (in sub new), then, in 08B9 handler, unset your hook and call Misc::charSelectScreen again (as usually done in received_characters handler).

If received_characters was done better (with parsing properly separated), it would have been easier to just redefine it, but not currently.
Kurama
Noob
Noob
Posts: 19
Joined: 13 Dec 2012, 17:26
Noob?: No

Re: bRO's client asking for PIN Code on log in

#59 Post by Kurama »

i'll make a private server and check numbers positions
ever_boy_
Developers
Developers
Posts: 308
Joined: 06 Jul 2012, 13:44
Noob?: No

Re: bRO's client asking for PIN Code on log in

#60 Post by ever_boy_ »

Kurama wrote:Image
first digit -> second digit

you receive the 08B9 packet with numbers position, but always the first number has the data "30".

now, we just need know what is the numbers positions and then make the packet

ITS NOT ENCRYPTED!
You're a genius. :shock:


Ok, so these 4 bytes are indeed a key. They're directly bound to the numbers' position. I've noticed that the digits position won't change, no matter what, unless you try and send a PIN code to the server, just the same way as the bytes won't change. This is the proof that the bytes are the hexa representation of the numbers on the PIN code screen.

Now, we gotta figure out HOW do these bytes define the numbers position. They seem to be sent in some kind of order... not totally random.
Here's the bytes I got in my last tries:

16B7920B
FB83C00B
6097C00B
C6AAC00B
37BCC00B
82CBC00B
F3DCC00B
64EEC00B
5903C10B
3F15C10B
3824C10B
C67AC10B
C1BAC10B
5AD3C10B
48E9C10B
16FFC10B
D411C20B
F025C20B
7936C20B
DD49C20B
CD5CC20B
C56EC20B
9883C20B
9996C20B
04A9C20B
07EDC20B
61FFC20B
3A13C30B
D825C30B
153AC30B
804CC30B
025EC30B
DD6EC30B
6382C30B
FCBBC30B
0FD7C30B
940BC40B
D21FC40B
EF33C40B
836BC40B
1B7FC40B
Last edited by ever_boy_ on 14 Dec 2012, 06:21, edited 1 time in total.