iRO Login: 128.241.92.36:6800
Local: 192.168.1.70
The following packet patterns have been observed while starting to fool around with the client against a server. Packets start with a u16 to determine the command type.
Notation for the flow of some of these packets, which may look like U->L
to denote "User to Login server", uses the following symbols:
U
- User, the player's clientL
- Login serverC
- Character serverM
- Map serverTODO: Implement a visual structure like http://blockdiag.com/en/nwdiag/packetdiag-examples.html
This is the first packet sent from the client once launched, providing the username/password credentials.
TODO: Determine what the MD5 and other hashing schemes look like
Offset | Type | Notes |
---|---|---|
0 | u16 | Packet type, 0x0064 |
2 | u32? | UNKNOWN, example value 18 .. maybe version of client or protocol, because it's the "first" value provided in this entire conversation |
6 | [char; 24] | username, null terminated |
30 | [char; 24] | password, null terminated |
54 | u8 | UNKNOWN, example value of 1 |
Example Data:
Response when you already have a session started.
Offset | Type | Notes |
---|---|---|
0 | u16 | 0x0081 |
2 | u8 | Reason for disconnect, check values here until the project structure stabilizes |
Example Data:
If you send an invalid username or password, it returns the following
Offset | Type | Notes |
---|---|---|
0 | u16 | Packet type, 0x0ae0 |
2 | [u8; 28] | UNKNOWN |
Hex:
Which may be a success message, paired with some kind of session or encryption key
TODO: At this point, the user has authenticated, and they should probably have their session logged somewhere to be allowed to use the character servers.
Offset | Type | Notes |
---|---|---|
0 | u16 | Packet type, 0x0a4d |
2 | u16 | Packet length (success + server list total) |
4 | u32 | Login ID1, example: ca ae 97 fa |
8 | u32 | Account ID, example: 1d bb 5d 00 |
12 | u32 | Login ID2, example: 00 00 00 00 |
16 | [u8; 4] | Last login IP, unused, all zeroes |
21 | 26 bytes | Last login time, unused, all zeroes |
20 | u8 | Gender?, 0 = male, 1 = female |
47 | [u8; 16] | Some kind of session identifier or encryption key? Example: TPZMgc02C0iARyrU |
63 | u8 | UNKNOWN, zero |
64 | … | Server list as separate packets (see next section) |
Once authenticated, the server returns a list of character servers available for connecting to. The quirk here is that only the last two octets of the IP address and port are provided– so the assumption is that all of this runs on the same subnet and the IPs are very similar. If you wanted to host in a different configuration, I'm not sure how you'd accomplish it at this time.
Offset | Type | Notes |
---|---|---|
0 | [u8; 4] | IP of character server |
4 | u16 | Port of character server, example: 0x1194 (4500 in decimal) |
6 | [char; 20] | Server name, null-terminated, like Cerberus\0... |
26 | u16 | Population, example: 0x0615 (1557 in decimal) |
28 | u32 | UNKNOWN, all zeroes, could be status of realm being up/down or open/closed and other flags |
The pattern appears to repeat based on the number of servers within the single packet, and will require some "peek"ing at the data to determine if there are more or not on the client-side.
After character selection, this was the first packet that was sent to the character server after connecting.
Offset | Type | Notes |
---|---|---|
0 | u16 | Packet type, 0x0065 |
2 | u32 | Account ID |
6 | u32 | Login ID1 |
10 | u32 | Login ID2 |
14 | u16 | UNKNOWN, all zeroes |
16 | u8 | Gender, 0 = male, 1 = female |
After the server receives the 0x0065 packet, this is the response passed to the client, starting with an echo of the account_id from the previous packet.
NOTE: It does not appear to follow the structure of all other packets seen so far, as it does not contain a header specific to the command.
Offset | Type | Notes |
---|---|---|
0 | u32 | account_id |
Offset | Type | Notes |
---|---|---|
0 | u16 | Packet type, 0x082d |
2 |
33 bytes of content after header.. so maybe gender at the end
Client sent this packet once, which caused returning of a list of characters
zeny?
equipment?
job_id?
deletion status.. maybe?
From OpenKore: https://github.com/OpenKore/openkore/blob/master/src/Poseidon/RagnarokServer.pm
Offset | Type | Notes |
---|---|---|
0 | u16 | 0x0b72 |
2 | u16 | Packet length |
4 | … | .. Start of character info .. |
4 | u32 | character_id |
8 | u32 | base experience |
12 | u32 | UNKNOWN |
16 | u32 | UNKNOWN |
20 | u32 | UNKNOWN, 0x1b wr4ck, 0x88 gh0st, 0x00 gn1me |
24 | u32 | UNKNOWN |
28 | u32 | UNKNOWN, 0x04.. 0x06.. 0x01 |
32 | u32 | UNKNOWN |
36 | u32 | UNKNOWN |
40 | u32 | UNKNOWN |
44 | u32 | UNKNOWN |
48 | u32 | UNKNOWN |
52 | u16 | stat points.. 0x02 for wr4ck, 0x04 for gh0st123, 0x30 for gn1me123, 0x01 for Evilynn |
54 | u32 | current hp |
58 | u32 | UNKNOWN |
62 | u32 | max hp |
66 | u32 | UNKNOWN |
70 | u32 | current sp |
74 | u32 | UNKNOWN |
78 | u32 | max sp |
82 | u32 | UNKNOWN |
86 | u32 | UNKNOWN, 0x96 for wr4ck, 0x96 for gh0st123, 0x96 for gn1me123.. same for Evilynn |
90 | u32 | hair style? 0x11 for wr4ck, 0x11 for gh0st123, 0x16 for gn1me123 |
94 | u16 | UNKNOWN |
96 | u32 | Base level |
100 | u32 | UNKNOWN |
104 | u16 | UNKNOWN |
106 | u16 | UNKNOWN, 0x02 for gh0st123, 01 for wr4ck, 01 for gn1me123.. base level? already exists above.. |
108 | u32 | Hair color palette, see below |
112 | [char;24] | Character name, null-terminated, ex: gn0me123\0 |
136 | [u8;6] | Stats.. STR/AGI/VIT/INT/DEX/LUK |
142 | u16 | Slot number.. 1-30 (0x00-0x1e).. might be a u32? |
144 | u16 | rename?? |
146 | [char;16] | Map filename, null-terminated, ex: iz_int.gat\0 |
162 | u8 | Marked for deletion flag? |
163 | 15 bytes | UNKNOWN |
178 | u8 | Gender? 0x00 = female, 0x01 = male? |
179 | .. | .. Next character, up to 3 total per packet .. |
Hair color pallettes:
Current List..
.. after asking for "more pages"? might be getting this as well… might be related to rows or something, 3 per row?
Previous List..
This suggests that there is pagination, as we received 11 more requests for character details. To try to prove this, I will check the client, as if there's a limit of 3 per packet of response.. we should see (11+1)*3 = 36 character slots visible in the client? 30 slots visible,
I have characters in the slots..
1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|
gn0me123 | gn0me555 | |||
wr4ck | Evilynn1234 | LOCK | ||
Rest are locked.. |
This packet looks to be forwarding the user to the map server with details about which character, map, and ip/host?
Offset | Type | Notes |
---|---|---|
0 | u16 | 0x0071 |
2 | u32 | character_id |
6 | [char;16] | Mapfile name, example: iz_int.gat\0 |
22 | [u8;4] | Map server IP |
26 | u16 | Map server port |
I'm not sure what triggers sending these, but once the server received them it would immediately reply with the same content.
Offset | Type | Notes |
---|---|---|
0 | u16 | 0x0187 |
2 | u32 | account_id |
Request to delete a character? Maybe?
Response to 0x0827 like "Successfully queued for deletion"
This looks encrypted.. and may involve coordinates
From the eAthena packet reference.
Request to delete a character.
Character ID: The unique identifier for a character.
Mail Address: The e-mail address used for verification.
Request connection to map server.
Account ID: Unique account identifier.
Character ID: Unique character identifier.
Login ID1: Session data.
Login ID2: Session data.
Sex: Account gender.
Finished loading map.
// Send client tick.//
Client Tick: Length of time online in milliseconds?