Newbie Spellweaver
- Joined
- Jul 7, 2018
- Messages
- 6
- Reaction score
- 8
Here is a list of packet opcodes, and addrs of packet constructors (for sending) or parsers (for received), dumped from the executable.
It's a pretty simple task tho (there are even plain function names in the kr2100 call table), dont know if someone had done this already.
The recv list (recv-kr2100.txt) looks like this:
You have to look up the call table to get its parser function,
take [1335:TrChangeNameAck] for example, search hex 35-13 in the recv-kr2100\14xxxx-call[xxx].bin, you will get:
The call table struct is:
So locate 14190f838 (the vtable) in the exe, the first member of the vtable is the parser function:
All parser funcs has a unified form, which is XXXXX:rocess(ActorRoot*,u8* packet_content,u16 packet_len).
The send list looks like this:
you have to find the opcode yourself,
take [eTrGetInstallationListReq -> 1406F28AE] for example, look the code around 1406F28AE, you will get:
So 10A7 is the opcode for eTrGetInstallationListReq, the whole 1406F2750 func (before 1406F28AE) is the constructor (packets for sending constructed in stacks).
The send constructor names in 2179 are obfuscated, some can be guessed by its lua call.
Since my interest is to hook these functions internally and make bdo completely offline,not so sure how these works on server/emus (the AES (content) and RABBIT (whole packet) cipher algo can be found in Taiga's code).
Some like @Kirito2105 may have already utilized the information from client executable (but seems he's still trying to jewing rubles with this dying mmo...).
And if someone know those xxxxReq, xxxxAck, xxxxAcks, xxxxNak actual means and how these translate to emu's SMxxxx, CMxxxx naming rules, please tell me.
============================
Notes:
a. About CRijndael/AES'ed pacs:
-In 2100, at least 3 SEND funcs has AES encryption, they are:
GetCreateUserInformationToAuthenticServer(0C9E, 1407A0DB4),
LoginUserToAuthenticServer(0CA0, 14079922A),
LoginUserToFieldServer(0CC1, 1407A11C6).
All these three has a 0x100 key(?) block on the head, maybe relate to RSA2048,
anyone familiar with Cryptography may recognize this easily (I'm not).
For example CMLoginUserToAuthenticServer.cs:
Put RETN on 140A2EEB0 can skip the encryption.
-1409A2CE0 is CRijndael::MakeKey(char const* key, char const* chain, int keylength, int blockSize), see libatc/Rijndael.cpp.
b.
-(After checking some 661 java emu sources) So the packet structures weren't "shuffled" every release as someone said,
just some extra fields may be added.
The 661 emu pac_structs are exactly same as the KR2100 one (the C# code from Taiga missed some fields),
except those 3 which has a 2+0x100+2 AESkey block on the head (u16 AESkey_len = 0x100,char[0x100] AESkey,u16 real_pac_len).
It's a pretty simple task tho (there are even plain function names in the kr2100 call table), dont know if someone had done this already.
The recv list (recv-kr2100.txt) looks like this:
Code:
....
0C9F:TrGetCreateUserInformationToAuthenticServerAck
0CA1:TrLoginUserToAuthenticServerAck
0CA4:TrRegisterNickNameToAuthenticServerAck
0CA6:TrGetWorldInformationsAck
0CA7:TrChangeServerBusyStateAcks
0CA2:TrLoginUserToAuthenticServerNak
0C9B:TrFixedChargeAck
1335:TrChangeNameAck
0CAA:TrMyRoleListAck
....
take [1335:TrChangeNameAck] for example, search hex 35-13 in the recv-kr2100\14xxxx-call[xxx].bin, you will get:
Code:
{
&vtable[]; //8byte x64
word OpC;
word someflags[6];
wchar_t namew[81];
char name[88];
} //0x110
So locate 14190f838 (the vtable) in the exe, the first member of the vtable is the parser function:
The send list looks like this:
Code:
....
eTrListSiegeGuildReq -> 1406E421F
eTrGuildAliianceInfomationReq -> 1406E4770
eTrGuildWebInfoByGuildNameReq -> 1406E539B
eTrGetInstallationListReq -> 1406F28AE
eTrMoveInstallationReq -> 1406F4CC4
eTrVisitableHouseListReq -> 1406F549A
....
you have to find the opcode yourself,
take [eTrGetInstallationListReq -> 1406F28AE] for example, look the code around 1406F28AE, you will get:
So 10A7 is the opcode for eTrGetInstallationListReq, the whole 1406F2750 func (before 1406F28AE) is the constructor (packets for sending constructed in stacks).
The send constructor names in 2179 are obfuscated, some can be guessed by its lua call.
Since my interest is to hook these functions internally and make bdo completely offline,not so sure how these works on server/emus (the AES (content) and RABBIT (whole packet) cipher algo can be found in Taiga's code).
Some like @Kirito2105 may have already utilized the information from client executable (but seems he's still trying to jewing rubles with this dying mmo...).
And if someone know those xxxxReq, xxxxAck, xxxxAcks, xxxxNak actual means and how these translate to emu's SMxxxx, CMxxxx naming rules, please tell me.
============================
Notes:
a. About CRijndael/AES'ed pacs:
-In 2100, at least 3 SEND funcs has AES encryption, they are:
GetCreateUserInformationToAuthenticServer(0C9E, 1407A0DB4),
LoginUserToAuthenticServer(0CA0, 14079922A),
LoginUserToFieldServer(0CC1, 1407A11C6).
All these three has a 0x100 key(?) block on the head, maybe relate to RSA2048,
anyone familiar with Cryptography may recognize this easily (I'm not).
For example CMLoginUserToAuthenticServer.cs:
Code:
public void Deserialize(BinaryReader reader){ var unk2 = reader.ReadUInt16();
var skipped = reader.ReadBytes(0x100); //AES_key
var real_packetlen = reader.ReadUInt16(); skipped = reader.ReadBytes(0x40-2);
Index = (byte)reader.ReadUInt16();
var var1 = Index * 8;
reader.ReadBytes(var1);
Pin = reader.ReadUInt64(); reader.ReadBytes(160 - (var1 + 8));
Cookie = reader.ReadInt32();
var cpu = reader.ReadBytes(0x33);
reader.ReadUInt32();
var gpu = reader.ReadBytes(0x33); var screenWidth = reader.ReadUInt32();
var screenHeight = reader.ReadUInt32(); var v0x1 = reader.ReadUInt16();
var pcData = System.Text.Encoding.Default.GetString(reader.ReadBytes(200));
reader.ReadByte();
var osData = reader.ReadBytes(200); }
Put RETN on 140A2EEB0 can skip the encryption.
-1409A2CE0 is CRijndael::MakeKey(char const* key, char const* chain, int keylength, int blockSize), see libatc/Rijndael.cpp.
b.
-(After checking some 661 java emu sources) So the packet structures weren't "shuffled" every release as someone said,
just some extra fields may be added.
The 661 emu pac_structs are exactly same as the KR2100 one (the C# code from Taiga missed some fields),
except those 3 which has a 2+0x100+2 AESkey block on the head (u16 AESkey_len = 0x100,char[0x100] AESkey,u16 real_pac_len).
Attachments
You must be registered for see attachments list
Last edited: