bRO's client asking for PIN Code on log in

[iMikeLance]

raw packet size - 29. Just add some null data at the end of it's unpack string.

[ever_boy_]

add some null data

using 'a', right?

I added this to Receive.pm:

Code: Select all

return 'a4 V9 v V2 v14 Z24 C6 v2 x4 a4' if $_ == 124;

changed charBlockSize to 124 in servertype.txt, and now it shows correct info when loading the chars. but it's still saying "invalid specified char".

edit:
this also works, with the same results:

Code: Select all

return 'a4 V9 v V2 v14 Z24 C6 v2 x4' if $_ == 124;

[ever_boy_]

there are these 'sendLoginPinCode' and 'login_pin_code_request' in ServerType0.pm.
since bRO.pm uses ServerType0 as 'base', it will get these subs from ServerType0?

[Kaspy]

Code: Select all

return 'a4 V9 v V2 v14 Z24 C6 v2 x4' if $_ == 124;

You need to find the last 4 bytes, they must be important.

there are these 'sendLoginPinCode' and 'login_pin_code_request' in ServerType0.pm.
since bRO.pm uses ServerType0 as 'base', it will get these subs from ServerType0?

Yes

[ever_boy_]

Code: Select all

return 'a4 V9 v V2 v14 Z24 C6 v2 x4' if $_ == 124;

You need to find the last 4 bytes, they must be important.

If kore is able to properly load the char list, why would the remaining bytes be of any importance (I really don't know that)?

I sniffed the packets using wireshark, and I noticed that, when inserting your Pin Code in the regular client, you send '08B8' packet to the server.
But when you choose your char using openkore, it doesn't send this packet, thus getting the error message "invalid specified character".

there are these 'sendLoginPinCode' and 'login_pin_code_request' in ServerType0.pm.
since bRO.pm uses ServerType0 as 'base', it will get these subs from ServerType0?

Yes

In this case, why isn't kore using these subs? You see, there's this in ServerType0.pm:

Code: Select all

sub login_pin_code_request {
	my ($self, $args) = @_;
	my $done;

	if ($args->{flag} == 0) {
		# PIN code has never been set before, so set it.
		return if ($config{loginPinCode} eq '' && !($self->queryAndSaveLoginPinCode()));
		my @key = split /[, ]+/, $masterServer->{PINEncryptKey};

meaning that, if this sub was being used, it should at least ask for a Pin Code, but that's not happening.

[ever_boy_]

This is what I added to receive\bRO.pm:

Code: Select all

sub new {
	my ($class) = @_;
	my $self = $class->SUPER::new(@_);
	
	my %packets = (
+		'08B9' => ['login_pin_code_request', 'v V', [qw(flag key)]], #8
		'0097' => ['private_message', 'v Z24 V Z*', [qw(len privMsgUser flag privMsg)]], # -1
		
		[tons of packets here]
	);

	foreach my $switch (keys %packets) {
		$self->{packet_list}{$switch} = $packets{$switch};
	}
+	my %handlers = qw(
+		login_pin_code_request 08B9
+	);
+	$self->{packet_lut}{$_} = $handlers{$_} for keys %handlers;

	return $self;
}

edit: changed the handler from account_id to login_pin_code_request. still got the same error, but I think it makes much more sense, as seen in ServerType0:

Code: Select all

		# mRO PIN code Check
		'02AD' => ['login_pin_code_request', 'v V', [qw(flag key)]],

[iMikeLance]

edit: changed the handler from account_id to login_pin_code_request. still got the same error, but I think it makes much more sense, as seen in ServerType0:

Code: Select all

		# mRO PIN code Check
		'02AD' => ['login_pin_code_request', 'v V', [qw(flag key)]],

You shouldn't do this as 02AD length is 8b and 08B9 is 12b. Also 08B9 is received AFTER inputing pin code and selecting your char.

[ever_boy_]

Also 08B9 is received AFTER inputing pin code and selecting your char.

It's a bit confusing here. BEFORE entering the pin, I get the 08B9 packet together with the char list info. At this point, it contains my account ID:

b9 08 45 4e 7e 05 XX XX XX XX 01 00

exactly 12 bytes (from the regular client).

But AFTER inputing the pin code, the 08B9 shows up again (not with char list info this time), the same 12 bytes, but they're all null (00) except for the packet's ID.

So, since this is received after the pin code is inserted, it can't be login_pin_code_request... is it account_id then?
'08B9' => ['account_id', 'x4 a4 x2', [qw(accountID)]], # 12

edit: now I see it fits: 4 null bytes, 4 bytes for account ID, 2 null bytes.

And the reason why kore is not asking for the Pin Code, is it because the packet handler for the pin code is not set in receive\bRO.pm?

But... if kore is not inserting the pin, how come it gets an unknown switch from a packet which shouldn't be received yet (08B9)?

[ever_boy_]

Main thing now is: how do we tell kore to send the pin code before sending char_login?

I ran some tests and I came up with this about packet 08B9:
AA AA BB BB BB BB CC CC CC CC DD XX

A = Packet's ID
B = random number
C = Account ID
D = Flag which indicates whether the Pin has been set or not (02 if never set before, 01 if already set)
X = null byte (maybe part of the flag)

This only shows at the end of 082D packet, before entering the pin code. Once you enter your Pin Code, the packet shows up again, but only null bytes.

[EternalHarvest]

I realized that this package has already cataloged in rRO.pm ... I believe that, at least in this regard, has already been implemented in the rRO. If that's right, just take what you have and include the rRO in the archives of bRO.

rRO currently supported only with XKore 1 (due to complicated malware bundled with the client), so this packet may have more important stuff for other modes.

You need to find the last 4 bytes, they must be important.

If kore is able to properly load the char list, why would the remaining bytes be of any importance (I really don't know that)?

There may be something important, but as well there may be just some additional information about your characters.

meaning that, if this sub was being used, it should at least ask for a Pin Code, but that's not happening.

Strange.

And the reason why kore is not asking for the Pin Code, is it because the packet handler for the pin code is not set in receive\bRO.pm?

No, that's not the reason. All handlers from Receive.pm and ServerType0.pm should be inherited.

AA AA BB BB BB BB CC CC CC CC DD XX

"DD XX" is just a two-byte 'v' for unpack, probably.

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. We would need to redefine flag values for bRO, or maybe it's something completely different from what was on mRO (or wherever login_pin_code_request was used) so you'll need your own handler. By the way, does mRO still use that pin code thing?

When you're receiving that packet for the second time, it probably just means (by this fact alone, or by contents if that's the only case when flag=0) that client should go on with connecting. That's not hard to implement.

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. Also, are you using XKore 1? If not, have you tried?

Maybe kLabMouse can tell something about that, after all, he added login_pin_code_request back then.