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?