bRO's client asking for PIN Code on log in

[Kurama]

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.


Ok, so these 4 digits 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 digits 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

make a private server like poseidon and test =D

[ever_boy_]

make a private server like poseidon and test =D

I don't know how to do that. Can you do this? Meanwhile, I'll be working on how to fix our char_login.

[Kurama]

make a private server like poseidon and test =D

I don't know how to do that. Can you do this? Meanwhile, I'll be working on how to fix our char_login.

i can try. I removed the gameguard and for now i'm looking for packets

[ever_boy_]

Maybe I got a clue:

If you get any of the bytes sequence, and convert them from hexa to decimal, you'll always get 9 digits. Unfortunately, they're repeating each other. But I think this might be something. Maybe I'm just doing it in the wrong order.

e.g.

1B 7F C4 0B -> 0B C4 7F 1B
0x0BC47F1B -> 197426971


edit:
there's this info which might be relevant:

Digit Zero:
30 = 0 times
31 = 59 times
32 = 17 times
33 = 0 times
34 = 0 times
35 = 18 times
36 = 12 times
37 = 9 times
38 = 8 times
39 = 9 times

Digit Zero happens to be in position 31 in 45% of my tries, but NEVER in position 30, 33 or 34. I don't think this is by chance, has to be something to do with the packet's strucutre. You see, the last of the 4 bytes is always 0B. Might have something to do with that...
Other digits behave the same way, except that in a different order.
For example Digit One will occur most of the times in position 33, but never in 30, 31 or 34.
Digit Two will occur most of the times in positions 31 or 33, but never in 30 or 34.
Digit Three will occur most of the times in position 30, but never in 31 , 32, 33 or 34.
and so on...


edit:
now that my last byte changed from 0B to 0C, the pattern changed... Digit Zero started to show up in position 30.

[ever_boy_]

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).

can you give a (really) raw coded example of this?

[EternalHarvest]

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).

can you give a (really) raw coded example of this?

Code: Select all

package Network::Receive::bRO;

sub new {
	...
	$self->{charSelectScreenHook} = Plugins::addHook(charSelectScreen => sub { $_[1]{return} = 1 })
	return $self;
}

sub handler_for_08b9 {
	...
	# if everything is done with pin code stuff, do this:
	Plugins::delHook(delete $self->{charSelectScreenHook}) if $self->{charSelectScreenHook};

	# and do whatever received_characters was about to do:
	if (charSelectScreen(1) == 1) {
		$firstLoginMap = 1;
		$startingzeny = $chars[$config{'char'}]{'zeny'} unless defined $startingzeny;
		$sentWelcomeMessage = 1;
	}
}

[ever_boy_]

And to think that this is your raw... thanks, you're great

So, this goes within the IF where I check that 08B9 was received with flag 0 (meaning it's ok to select the char):

Code: Select all

 Plugins::delHook(delete $self->{charSelectScreenHook}) if $self->{charSelectScreenHook};

It will "unfreeze" the char select screen, and this will resume the logging in actions:

Code: Select all

if (charSelectScreen(1) == 1) {
      $firstLoginMap = 1;
      $startingzeny = $chars[$config{'char'}]{'zeny'} unless defined $startingzeny;
      $sentWelcomeMessage = 1;

right?

I just didn't understand under what circunstances the sub new will call the charSelectScreen.

[EternalHarvest]

So, this goes within the IF where I check that 08B9 was received with flag 0 (meaning it's ok to select the char):
It will "unfreeze" the char select screen, and this will resume the logging in actions:
right?

Right.

I just didn't understand under what circunstances the sub new will call the charSelectScreen.

new() won't call it, it just sets the hook. If you grep openkore for "charSelectScreen", you'll easily find where exactly it is called.

[ever_boy_]

By manually adjusting the values, instead of properly encrypting the packet (till we figure out how to do that), I'm sending the 08B8 packet for testing purposes. Now here's what is happening;

Everything goes as usual till I get received_chars packet (082D), followed by pin code request (08B9);
Instead of replying with char_login (0066), kore waits and answers with pin code packet (08B8);
Imediatly, kore gets disconnected due time out on char select server.

Wireshark shows me that I receive the 08B9 with flag 0 after sending 08B8, meaning that I successfully sent the pin code to the server, but kore doesn't get this packet, even though I got debug mode on for packets sent/received.
What could be wrong?


edit: whether I send 08B8 packet or not, I get disconnected all the same. still trying to figure out why.
it seems that the problem is with the addHook code.

[Fat4LitY]

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!

Clever. So we just need to discover how to turn the packet into 0-9 numbers position?

This could be easily done disassembling the Ragexe (need guy experienced in x86 Assembly)