bRO's client asking for PIN Code on log in

[ever_boy_]

Also, are you using XKore 1? If not, have you tried?

Thanks for the reply.
I didn't and I never intended to, unless it's for testing purpose, since botting on visual mode is not of my interest. I'll do it if it's necessary to get any info though.

D = Flag which indicates whether the Pin has been set or not (02 if never set before, 01 if already set)

If so, values for "flag" are different from what is currently in login_pin_code_request handler, and it won't work as is.

Precisely. I gave up on making changes in bRO.pm, and started messing with ServerType0.pm instead. I made some changes and the first result was that it gave me the message: "Your pin code has been changed successfully". Nothing was really changed, just the message though, but it was a progress anyway.

It can help to understand what needs to be done if more complete log of whatever packet switches and lengths (and contents, if you're brave) are sent and received by the client in which sequence.

Here's what I've done so far:

I logged in to my char account in the regular client, and I got this packet from wireshark:

2d 08 0d 02 06 00 00 06 06 00 [char list info] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9 08 a1 75 5d 06 XX XX XX XX 01 00

where the X's are my account ID. I still don't get it why is the 08B9 bound to the 08D2 packet.

Then I entered my pin code, and the packet received was:

b9 08 00 00 00 00 00 00 00 00 00 00

while the sent packet for entering the pin code was:

b8 08 XX XX XX XX YY YY YY YY

where the X's are my account ID, and the Y's are my encrypted pin code digits. One thing about bRO's pin code is that it only accepts 4 digits, not more, nor less.

So, now I know the 08B9 (receive) and 08B8 (send) packets' structure. Need to figure how to arrange this in order to send the pin correctly.

I'm gonna try a few more thing on ServerType0.pm and then post my report.

[EternalHarvest]

I still don't get it why is the 08B9 bound to the 08D2 packet.

They aren't "bound" to each other, it's just a regular TCP stream which may (or not) break on any byte and it's unaware of high-level protocol we're interested in.

So, now I know the 08B9 (receive) and 08B8 (send) packets' structure. Need to figure how to arrange this in order to send the pin correctly.

You need to redefine sendLoginPinCode in bRO using packet switches and structs you need. Maybe there would be a different cipher too. Ideally we refactor it in ST0, but it can come after you'll get things working.

[ever_boy_]

You need to redefine sendLoginPinCode in bRO using packet switches and structs you need. Maybe there would be a different cipher too. Ideally we refactor it in ST0, but it can come after you'll get things working.

Yeah, the idea is either merging, or moving bRO's PIN handler to bRO.pm. I'm just using ServerType0 for convenience, till I get a better picture of how this works. I had never dealt with packet handlers before.

[ever_boy_]

Differences between mRO and bRO (some things may be misinterpreted by me):

mRO's known flags:

0 = PIN has never been entered before
1 = PIN is already defined
2 = PIN code has been changed successfully
3 = Failed to change the login PIN code
4 = PIN code incorrect
5 = PIN Entered 3 times Wrong, Disconnect

bRO's known flags:

1 = PIN is already defined
2 = PIN has never been entered before
8 = PIN code incorrect

- When successfully changing your pin code, the flag stays the same (1), but a 08bf (confirmation?) packet is received. This packet exists in recvpackets and is 8B long.

- When you fail to change your PIN code, no packet is received.

- Upon entering incorrect PIN 3 times in a row, no packet is sent for disconnecting, other than flag 8.

------------------------------------------------------

changed:

Code: Select all

'02AD' => ['login_pin_code_request', 'v V', [qw(flag key)]],

to:

Code: Select all

'08B9' => ['login_pin_code_request', 'x4 a4 v2', [qw(accountID flag)]],

which seems to be more likely to bRO's.

It looks like mRO's user receives a "key" along with the PIN's flag. The same doesn't happen on bRO. We get the Account ID instead.
Also, the AccountID is to be sent together with the ciphered PIN code, intead of some "key", as in mRO.

So, I changed every $args->{key} to $args->{accountID}, so that it could match the new packet handler.


With these changes, if PIN code is not set on config.txt, kore asks me to set a new PIN. When the PIN is set, it keeps telling me that I must set the PINEncryptKey in serverst.txt, even though it's already there.
I guess there must be something wrong here:

Code: Select all

} elsif ($args->{flag} == 1) {
		# PIN code query request.
		return if ($config{loginPinCode} eq '' && !($self->queryAndSaveLoginPinCode()));
		my @key = split /[, ]+/, $masterServer->{PINEncryptKey};
		if (!@key) {
			$interface->errorDialog(T("Unable to send PIN code. You must set the 'PINEncryptKey' option in servers.txt."));
			quit();
			return;
		}
		$messageSender->sendLoginPinCode($config{loginPinCode}, 0, $args->{accountID}, 3, \@key);

	}

but still couldn't figure out what.

[EternalHarvest]

It looks like mRO's user receives a "key" along with the PIN's flag. The same doesn't happen on bRO. We get the Account ID instead.

What about data you're having in position of your "x4", is it unused?

I guess there must be something wrong here:

Dump @key there etc.

[Kaspy]

The differences between mRO and bRO are justified, after all not help repeating much the same as it is implemented and security has broken on another server.

ever_boy_, first of all, try to simulate everything you want to do using the command send and only after working this case, try changing the ServerType send and receive.

I recommend using Microsoft Network Monitor in place in Wireshark, because the Microsoft Network Monitor is more practical and simple for this case.

[ever_boy_]

It looks like mRO's user receives a "key" along with the PIN's flag. The same doesn't happen on bRO. We get the Account ID instead.

What about data you're having in position of your "x4", is it unused?

I first thought so, but coming to think about it now... 4 random bytes (actually the 4th seems to be always 06), they could be a 'key', not sure though.
Anyway, I'm pretty sure there's no "key" being sent by kore, just the account ID and the encrypted pin. Gotta check little by little though.

Dump @key there etc.

Well, yeah, I got to find out how to do that.. tried to use 'print' command but didn't work.]

edit:
Got this tested somehow. The keys are being sent, but still got "invalid specified character, as expected.

Now, got to figure how to build the 'sendLoginPinCode'.

original one in receive:

Code: Select all

$messageSender->sendLoginPinCode($config{loginPinCode}, 0, $args->{accountID}, 3, \@key);

I'm not sure where did these "$type1/$type2/$type3" came from, in send\ServerType0.pm

Code: Select all

 elsif ($type == 3) {

edit2: now I got it, these '$var = shift' in send, are getting the parameters passed from receive, in sendLoginPinCode function.

[Fat4LitY]

Doesn't need to put the PINEncryptKey line on servers.txt for bRO server?

[EternalHarvest]

Well, yeah, I got to find out how to do that.. tried to use 'print' command but didn't work.

Code: Select all

use Data::Dumper;
Log::message(Dumper \$var);

[ever_boy_]

Well, yeah, I got to find out how to do that.. tried to use 'print' command but didn't work.

Code: Select all

use Data::Dumper;
Log::message(Dumper \$var);

it says the same as before: "global symbol @keys requires explicit package name".

edit: got it. thanks.


everything looks "fine", execpt for the accountID, which is shown as: ?ú¬'
is that right?