Guide L2 Packet Opcode Lists

[Zeeyo]

Pictures are worth more than words. This one doubles as a hyperlink.

 

Additionally, you can view individual packet opcode summaries, such as this for RequestBR_GamePoint:

 

(also accessible from a protocol version's overview)

 

The lists are made for NA L2, which should be fine for NA/EU/RU servers. Neither PTS nor Korean protocols are included. So if you are looking for (e.g. KR-only) 597, 598, 599, 19, 21 or similar ones, you're out of luck.

[vampir]

Very nice job! You are getting those packets from client directly?

[kyosume]

Beautiful!

[Ghost]

Excellent work. Any way you can suck up the structures as well?

[Zeeyo]

Very nice job! You are getting those packets from client directly?

Technically, yes and no. Yes, these opcode mappings were generated automatically. No, because I did some manual validation, as in certain protocol versions, there have been some issues (the generator was being updated, so older lists of older protocols had some opcodes incorrectly skipped/assigned, or doubly assigned some opcodes). I also tried to synchronize packet names with reality, so a few might not exactly match what's in that exact client – the name would come from a later client (see the large explanation below), because the original name is misleading due to changes to logic.

 

For packets that never had a name (some private store packets) had their names assigned manually. 'DummyPacket's that to this day serve a very specific purpose had a name assigned based on how equivalent packets for other features were named.

 

And the biggest letdown you may notice, is the missing SendPrivateStoreBuyBuyList (replaced with SendPrivateStoreSellList).

 

Excellent work. Any way you can suck up the structures as well?

NOT THIS AGAIN.

Look. The strings are manually maintained by NC employees. So if someone forgets to update some packet, e.g. 'RequestPartyMatchConfig' for like 3 years after it's structure and logic has been already changed to 'RequestListPartyWaiting', it does not mean that packet still is 'RequestPartyMatchConfig' for these additional 3 years.

 

The same applies to structure strings, EXCEPT it seems that on updates, NC omits certain fields ON PURPOSE. That's why usually the structure presented for widely used packets like ItemList, CI, UI and similar will be outright wrong.

 

E.g. with CI and UI, it is often that you see something like this:

• You start with some baseline protocol version (some fields may be omitted)
• A protocol version update arrives, which does not specify CI/UI structure change
• In reality, you find out new fields have been added, and not necessarily at the end of the packet
• Another protocol version update arrives, which does specify new fields in CI/UI, but omits those you already found
• In reality, you find out that the omitted fields are still there
• Another protocol version update arrives, which specifies even more new fields in CI/UI, but those you found are still nowhere to be seen
• In reality, you find out that omitted fields are there, and not all new fields are specified AGAIN
• Another protocol update; both omissions are nowhere to be found, but new fields have arrived
• This goes on and on with various packets…

So really, NC with its project-based workflow and employee migration between them (some employees simply leave) DOES NOT CARE to maintain those structure strings properly (sometimes, that also applies to packet names).

 

Since there is no way to automatically check whether the structure string is up-to-date (esp. if 'x' is involved), I'd rather not present them. Yes, for a fair amount of "simpler" packets, that would work. But that can easily cause people to believe that those strings are actually correct, and fall right into a trap.

 

 

If someone would like, I could try to jog my memory and check up my validated structs against NC (client) structs to give you at least 10 packets over various protocol versions, where the client struct is just wrong (and continues to be wrong for extended amounts of time).

Edited July 4, 2015 by Zeeyo

[DEV HazoR]

Very Helpfull...Congrats.!

[Sdw]

Wrong client structure ? I would love to see that.

 

Since its net pro related, do you handle packet obfuscation ?

[Szakalaka]

No matter how packts are encrpyted they will be decrypted before being added to network queue

[Ghost]

Technically, yes and no. Yes, these opcode mappings were generated automatically. No, because I did some manual validation, as in certain protocol versions, there have been some issues (the generator was being updated, so older lists of older protocols had some opcodes incorrectly skipped/assigned, or doubly assigned some opcodes). I also tried to synchronize packet names with reality, so a few might not exactly match what's in that exact client – the name would come from a later client (see the large explanation below), because the original name is misleading due to changes to logic.

 

For packets that never had a name (some private store packets) had their names assigned manually. 'DummyPacket's that to this day serve a very specific purpose had a name assigned based on how equivalent packets for other features were named.

 

And the biggest letdown you may notice, is the missing SendPrivateStoreBuyBuyList (replaced with SendPrivateStoreSellList).

 

 

NOT THIS AGAIN.

Look. The strings are manually maintained by NC employees. So if someone forgets to update some packet, e.g. 'RequestPartyMatchConfig' for like 3 years after it's structure and logic has been already changed to 'RequestListPartyWaiting', it does not mean that packet still is 'RequestPartyMatchConfig' for these additional 3 years.

 

The same applies to structure strings, EXCEPT it seems that on updates, NC omits certain fields ON PURPOSE. That's why usually the structure presented for widely used packets like ItemList, CI, UI and similar will be outright wrong.

 

E.g. with CI and UI, it is often that you see something like this:

• You start with some baseline protocol version (some fields may be omitted)
• A protocol version update arrives, which does not specify CI/UI structure change
• In reality, you find out new fields have been added, and not necessarily at the end of the packet
• Another protocol version update arrives, which does specify new fields in CI/UI, but omits those you already found
• In reality, you find out that the omitted fields are still there
• Another protocol version update arrives, which specifies even more new fields in CI/UI, but those you found are still nowhere to be seen
• In reality, you find out that omitted fields are there, and not all new fields are specified AGAIN
• Another protocol update; both omissions are nowhere to be found, but new fields have arrived
• This goes on and on with various packets…

So really, NC with its project-based workflow and employee migration between them (some employees simply leave) DOES NOT CARE to maintain those structure strings properly (sometimes, that also applies to packet names).

 

Since there is no way to automatically check whether the structure string is up-to-date (esp. if 'x' is involved), I'd rather not present them. Yes, for a fair amount of "simpler" packets, that would work. But that can easily cause people to believe that those strings are actually correct, and fall right into a trap.

 

 

If someone would like, I could try to jog my memory and check up my validated structs against NC (client) structs to give you at least 10 packets over various protocol versions, where the client struct is just wrong (and continues to be wrong for extended amounts of time).

 

I've got absolutely 0 knowledges when it comes to reverse engineering, was hoping it was possible, too bad it isn't.

[Zeeyo]

Wrong client structure ? I would love to see that.

I have opened this thread in the morning to check up on what's new, but I'll have to go soon. Please check this post later today, I will edit it to include cases that I have already stumbled upon.

 

Since its net pro related, do you handle packet obfuscation ?

Yes. That's why you have these special 'constant' opcodes in protocol definitions, e.g.

	<protocol id="54" alias="Infinite Odyssey" category="IO">
		<version date="2015-04-22">24</version>
		<primary>
			<constant>0x12</constant>
			<constant>0xB1</constant>
			<constant>0x11</constant>
			<constant>0xD0</constant>
		</primary>
		<secondary count="269">
			<constant>0x70</constant>
			<constant>0x71</constant>
		</secondary>
		<definitions dir="infinite_odyssey" />
	</protocol>

As these are known to not participate in CM opcode shuffling. Plus, without this obfuscation, NP would be pretty much useless.

 

No matter how packts are encrpyted they will be decrypted before being added to network queue

I honestly have no clue what you are talking about.

 

I've got absolutely 0 knowledges when it comes to reverse engineering, was hoping it was possible, too bad it isn't.

While doing manual validation, I do take note of what are the client-known structures of certain packets (due to the aforementioned reasons, I only include them as found in the latest client). See the XML comments in this file.

[Rootware]

What's about the packet structure? You plan to add structure of packets?

[Zeeyo]

What's about the packet structure? You plan to add structure of packets?

I do plan to do that eventually. After all, the reason I made the opcode site was because the incremental loading in NP meant that without actually using NP (or checking out and using ctrl+shift+r) it becomes somewhat hard to follow which opcodes and structures are used for a specific protocol version.

 

For now, you can just browse the NP source for structure XMLs. But beware: most packets in HF folder were validated from non-builder perspective, and the rest were filled in from l2j sources (which means they are most likely wrong).

Most new packets in valiance folder were generated from GDL & later non-incremental loading XML files. THERE WERE ISSUES with opcode assignment, so some definitions are lost or incorrect (I still have the file in legacy format, but I never actually re-validated them).

Most new packets in ertheia folder were generated from korean Ertheia non-incremental loading XML file. Same issues as with Epeisodion (a.k.a Valiance).

 

Right now, I am finishing up with validating C4 packets (though there are still a few left to validate from C2). After that, I'll move to GF, though I will try my best to investigate C5 (due to so many pledge features originally implemented there) to Gracia P2 while dealing with GF.

 

After that, I plan to review HF, legacy GoD, GDL and kr Ertheia files. Only then would I publish the structures in a format similar to how this opcode website works.

Edited July 5, 2015 by Zeeyo

[MasterBlaster]

Great tool, browsed the source, looks solid! Thanks for this very useful information. Are you able to extract opcodes directly from engine.dll?

[Rootware]

I do plan to do that eventually. After all, the reason I made the opcode site was because the incremental loading in NP meant that without actually using NP (or checking out and using ctrl+shift+r) it becomes somewhat hard to follow which opcodes and structures are used for a specific protocol version.

 

For now, you can just browse the NP source for structure XMLs. But beware: most packets in HF folder were validated from non-builder perspective, and the rest were filled in from l2j sources (which means they are most likely wrong).

Most new packets in valiance folder were generated from GDL & later non-incremental loading XML files. THERE WERE ISSUES with opcode assignment, so some definitions are lost or incorrect (I still have the file in legacy format, but I never actually re-validated them).

Most new packets in ertheia folder were generated from korean Ertheia non-incremental loading XML file. Same issues as with Epeisodion (a.k.a Valiance).

 

Right now, I am finishing up with validating C4 packets (though there are still a few left to validate from C2). After that, I'll move to GF, though I will try my best to investigate C5 (due to so many pledge features originally implemented there) to Gracia P2 while dealing with GF.

 

After that, I plan to review HF, legacy GoD, GDL and kr Ertheia files. Only then would I publish the structures in a format similar to how this opcode website works.

 

And how are you validates the packet structure? By L2J forks?

[Szakalaka]

I honestly have no clue what you are talking about.

 

What i was talkin about was how L2 manages the packets internally. It listens with one thread which is responsible for writing the data buffer, then decrypting it and adding to "NewtorkQueue" (thats how its called inside game) which parses the packet and calls appropriate handler for it :)

 

Does it work only for clean client with default encryption? And do u sniff it with external sniffer or you are inside process?

Edited July 5, 2015 by Szakalaka