Looking for Encryption function

Page 3 of 4

01/01/2015 17:14 ken12#31

Yeah I detoured the WSASend to get the proper socket.

About the headers, its 2 byte header i think.. or maybe you can consider it as 4-byte

Code:

A0 00 -> Headers
XX XX -> 66 00/ 7E 00 -> Depends upon the use of the skill (Consider as Second Header)

When I send using WSASend nothing happens.. @.@

where's an example how i send

Code:

WSABUF lpBuffers;
BYTE SendBuffer[] = { 0x04, 0x00, 0x2D, 0x00, 0x9A, 0x00 };
Encrypt(&SenderBuffer);
lpBuffers.len = 0x6;
lpBuffers.buf = (char*)SendBuffer;
WSASend(s, &lpBuffers, 1, NULL or (LPDWORD)0x0018FC70, 0, NULL, NULL);

That gives me a no response to the server and get me disconnected..

01/01/2015 19:45 Oriya9#32

Quote:

Originally Posted by Tension

I thought the header would be 4 Bytes long not 2??

Aura uses WSASend so i would use that probably too. Do you have the correct PTR to the socket?

The definition of a "header" can be quite loose at times.
Usually, a header is anything that comes before the actual packet data (not the raw packet) and has a fixed size.
Now, it depends on your definition here, would you say the opcode is part of the header or the actual packet data (not the raw packet)?
I'd say it's part of the actual packet since it's encrypted as well.
To sum it up, the header contains only 2 bytes (it's an unsigned short) for the packet length.

The raw packet can be divided into 2 parts right away. The length and the encrypted packet:
[XX XX] [...]
The decrypted packet can also be divided into 2 parts right off the bat. The opcode and the packet data:
[XX XX] [...]

In my definition both are headers (they're always there, always the same size and always before the actual packet data).
But they're 2 different headers the way I see it. Because the second one comes only after you decrypt the packet.

And a tiny note about WSASend:
After you select a character, the client would start using WSAAsyncSelect to send packets.

01/01/2015 20:07 ken12#33

So you mean Oriya9, it actually uses WSAAsynSelect rather than WSASend? But how come it just passes the call and still proceeds to WSASend?

Edit:
Hm. It sounds crazy but, after the encryption call, it calls the WSAAsyncSelect.. So i guess, your right, but I still dont know why WSAAsynSelect needs to be used.. >.< Maybe i'll try to call WSAAsyncSelect then WSASend()

Code:

1. Encrypt Packet
2. Call WSAAsyncSelect
3. Call WSASend

Good enough?

01/01/2015 22:05 Oriya9#34

Quote:
Originally Posted by ken12
So you mean Oriya9, it actually uses WSAAsynSelect rather than WSASend? But how come it just passes the call and still proceeds to WSASend?

Edit:
Hm. It sounds crazy but, after the encryption call, it calls the WSAAsyncSelect.. So i guess, your right, but I still dont know why WSAAsynSelect needs to be used.. >.< Maybe i'll try to call WSAAsyncSelect then WSASend()
Code:
1. Encrypt Packet
2. Call WSAAsyncSelect
3. Call WSASend
Good enough?

That's correct. :)
It's like that because of how the network library they are using was developed.
If you'd look at all the window handles under the game's process ("game.bin") you'll see another window, other than the actual game window.
That window is being used by the network library to achieve asynchronous socket behavior.
It's not that common in online games but it's still a valid way to achieve this goal.

Just in case it wasn't clear, it's worth mentioning that the encryption is being done pre-WSASend only for the "LoginServer".
After that, all of the packets that are being sent to the "GameServer" are dealt the way you mentioned (Encryption > WSAAsyncSelect > WSASend).

As for sending your own packets. You don't have to use WSAAsyncSelect. You can use WSASend right away.
You just need to encrypt the packet properly. And depending on how you do it, you might need to update the encryption key manually.

01/02/2015 00:15 Tension#35

Quote:

Originally Posted by Oriya9

The definition of a "header" can be quite loose at times.
Usually, a header is anything that comes before the actual packet data (not the raw packet) and has a fixed size.
Now, it depends on your definition here, would you say the opcode is part of the header or the actual packet data (not the raw packet)?
I'd say it's part of the actual packet since it's encrypted as well.
To sum it up, the header contains only 2 bytes (it's an unsigned short) for the packet length.

The raw packet can be divided into 2 parts right away. The length and the encrypted packet:
[XX XX] [...]
The decrypted packet can also be divided into 2 parts right off the bat. The opcode and the packet data:
[XX XX] [...]

In my definition both are headers (they're always there, always the same size and always before the actual packet data).
But they're 2 different headers the way I see it. Because the second one comes only after you decrypt the packet.

And a tiny note about WSASend:
After you select a character, the client would start using WSAAsyncSelect to send packets.

For me a header is like the head of th packed, it contains values like ID, Size, Sequence(if necessary), etc. so the packet would have atleast the size of the header to be sent. Like you've said after the headers comes the actual data of the packet which gets processed.

But the first short of RECV and SEND shouldn't be the size, it's the Packet ID and actually it's and Index for a function-table which handles the packet data.

As example my logger got this on receive:

Code:

[RECV]
Size: 171

05 00 04 00 F2 03 0B 00 41 75 72 6F 72 61 2D 43 68 30 31 00
00 00 00 00 00 00 00 00 00 00 00 32 00 01 00 01 00 01 00 00
00 00 00 01 00 FC 03 0B 00 41 75 72 6F 72 61 2D 43 68 30 32
00 00 00 00 00 00 00 00 00 00 00 00 19 00 01 00 01 00 01 00
00 00 00 00 00 00 06 04 0B 00 41 75 72 6F 72 61 2D 43 68 30
33 00 00 00 00 00 00 00 00 00 00 00 00 1B 00 01 00 01 00 01
00 00 00 00 00 00 00 10 04 0B 00 41 75 72 6F 72 61 2D 43 68
30 34 00 00 00 00 00 00 00 00 00 00 00 00 20 00 01 00 01 00
01 00 00 00 00 00 00 00 F2 03 00
[♣♦‗♥♂Aurora-Ch012☺☺☺☺�♥♂Aurora-Ch02↓☺☺☺♠♦♂Aurora-Ch03←☺☺☺►♦♂Aurora-Ch04 ☺☺☺‗♥]

the 05 00 = 0x0005 is the Packet ID.

same for a sent packet

Code:

[SEND]
Size: 5

0D 02 00 00 00

didn't know that with WSASyncSelect too! thank you :)

01/02/2015 01:58 Oriya9#36

Quote:
Originally Posted by Tension
For me a header is like the head of th packed, it contains values like ID, Size, Sequence(if necessary), etc. so the packet would have atleast the size of the header to be sent. Like you've said after the headers comes the actual data of the packet which gets processed.

But the first short of RECV and SEND shouldn't be the size, it's the Packet ID and actually it's and Index for a function-table which handles the packet data.

As example my logger got this on receive:
Code:
[RECV]
Size: 171

05 00 04 00 F2 03 0B 00 41 75 72 6F 72 61 2D 43 68 30 31 00
00 00 00 00 00 00 00 00 00 00 00 32 00 01 00 01 00 01 00 00
00 00 00 01 00 FC 03 0B 00 41 75 72 6F 72 61 2D 43 68 30 32
00 00 00 00 00 00 00 00 00 00 00 00 19 00 01 00 01 00 01 00
00 00 00 00 00 00 06 04 0B 00 41 75 72 6F 72 61 2D 43 68 30
33 00 00 00 00 00 00 00 00 00 00 00 00 1B 00 01 00 01 00 01
00 00 00 00 00 00 00 10 04 0B 00 41 75 72 6F 72 61 2D 43 68
30 34 00 00 00 00 00 00 00 00 00 00 00 00 20 00 01 00 01 00
01 00 00 00 00 00 00 00 F2 03 00
[♣♦‗♥♂Aurora-Ch012☺☺☺☺�♥♂Aurora-Ch02↓☺☺☺♠♦♂Aurora-Ch03←☺☺☺►♦♂Aurora-Ch04 ☺☺☺‗♥]
the 05 00 = 0x0005 is the Packet ID.

same for a sent packet
Code:
[SEND]
Size: 5

0D 02 00 00 00
didn't know that with WSASyncSelect too! thank you :)

You are right, that's exactly what I was talking about.
What you've shown is the unencrypted packet. And as I've said in the post above, it doesn't have the length.
The length is being added to the new buffer after the encryption.
This is why I said you could say there are 2 headers in the packet.
One which is in the unencrypted packet (the opcode) and the other one which is in the encrypted packet (the length).

[OPCODE] [PACKET DATA]
Turns into:
[LENGTH] [ENCRYPTED PACKET (Opcode + Packet data)]
Obviously the second one is the one that is being sent to the server.

Aaaaaaand... A random factoid:
What you call a "Packet ID" is commonly called an "opcode", which stands for "Operation Code" :)

01/02/2015 02:10 Tension#37

Oh i haven't took a look on the encrypted packets only on the decrypted ones thank you :)

yeah i know that but i prefer ID haha :)

01/02/2015 05:44 ken12#38

Quote:

Originally Posted by Oriya9

That's correct. :)
It's like that because of how the network library they are using was developed.
If you'd look at all the window handles under the game's process ("game.bin") you'll see another window, other than the actual game window.
That window is being used by the network library to achieve asynchronous socket behavior.
It's not that common in online games but it's still a valid way to achieve this goal.

Just in case it wasn't clear, it's worth mentioning that the encryption is being done pre-WSASend only for the "LoginServer".
After that, all of the packets that are being sent to the "GameServer" are dealt the way you mentioned (Encryption > WSAAsyncSelect > WSASend).

As for sending your own packets. You don't have to use WSAAsyncSelect. You can use WSASend right away.
You just need to encrypt the packet properly. And depending on how you do it, you might need to update the encryption key manually.

Yeah there was another windows it has name like "5.x.x.x.x class: Network something"

I did what you mentioned but still it doenst respond, like as if nothing happens.. I've back read your other post, and you mentioned that the call is actually the WSAConnect rather than WSASend, so maybe i should try to detour that function and call it.

Edit:
[Only registered and activated users can see links. Click Here To Register...]
-----
[Only registered and activated users can see links. Click Here To Register...]
I did mimic the args of the WSASend, still no hope of sending packets...
I also mimic the args of WSAAsyncselect

Build packet > Encrypt using the encryption function > Send via WSASend > No response

01/02/2015 07:27 Daifoku#39

Quote:

Originally Posted by ken12

Build packet > Encrypt using the encryption function > Send via WSASend > No response

added the length to the crypted packet ? ~

01/02/2015 08:20 ken12#40

Quote:

Originally Posted by Daifoku

added the length to the crypted packet ? ~

What do you mean the length of the crypted packet?

Here's the photo taken before > after > during sending..

Before the packet is sent this is the structure of the packet with a size of 0xC
the header/OP is 0A 00 -> 0A -> Size of the real packet.
[Only registered and activated users can see links. Click Here To Register...]

This is after passing to the encryption
[Only registered and activated users can see links. Click Here To Register...]

Then before it is sent it changes again.. I guess there is a secondary encryption
[Only registered and activated users can see links. Click Here To Register...]

--> Imma try to explore more

Edit::
I guess I found the second encryption now.. =) Together with the XOR Table..

Edit2:
XOR Table is changing everytime a new packet is encrypted.. @.@

--- Final...

I got it working now. =) Just have to encrypt the packet again, Too bad can't make PE for it >.< I'm just using client's encryption function..

01/02/2015 11:25 Tension#41

Quote:

Originally Posted by ken12

Edit2:
XOR Table is changing everytime a new packet is encrypted.. @.@

--- Final...

I got it working now. =) Just have to encrypt the packet again, Too bad can't make PE for it >.< I'm just using client's encryption function..

The XOR-Function changes the table actually.

Why not? Just use the Crypto-Functions to receive the data instead of the WSASend/WSARecv.
Btw Omdihar posted the XOR-Function so it's not that hard to write a PE :p

01/02/2015 11:44 ken12#42

Quote:

Originally Posted by Tension

The XOR-Function changes the table actually.

Why not? Just use the Crypto-Functions to receive the data instead of the WSASend/WSARecv.
Btw Omdihar posted the XOR-Function so it's not that hard to write a PE :p

Yeah yeah, I got the Xor-Function (Which is a secondary encryption too),

i can just use the function to encrypt my buffer, but the problem is the primary encryption.. It uses some sort of xor table too.. But i've got a prototype and its working fine now..

btw the encryption call

Code:

((int(WINAPI*)(int, int, int, int))lpFunction)(xorTablePtr, bufSize, bufAddr, bufAddr);

01/02/2015 14:56 darkm125#43

Nice work ken ;)

01/02/2015 15:38 ken12#44

Quote:

Originally Posted by darkm125

Nice work ken ;)

Heh. Thanks! =) Currently looking for the recv packet right now. and see if it has the enemy entity or object entity to it. =) Btw if you know it, the list of monsters available around you.

01/05/2015 15:27 ken12#45

I guess I found already the Enemy/World Entity, that returns all NPCs, Mobs, materials and others that surrounds the player accordance to its FOV.

Code:

MOV ECX,DWORD PTR DS:[0x123724C]
MOV ECX, [ECX+0x624]
MOV ECX, [ECX] -> usually starts with 0DF????? -> First Address is the Character Entity. Then proceeding enemy list are located at the first address of the character entity, loops back to starting address which is 0DF????? when all enemies are listed and done. =)

Pointer to Number of Enemies in Map

MOV ECX,DWORD PTR DS:[0x123724C]
MOV ECX, [ECX+0x628] -> Returns # of Enemies in the map


**** Enemy Arrays ****
Enemy Entity Structure....:	[A0 1C 07 01] 00 00 00 00 [2B F4 FF FF] [40 68 70 28]
Args......................:	[A0 1C 07 01] or [60 ED 06 01]	-> Considered as [Enemy/NPC] or [Player]
				[2B F4 FF FF]			-> EnemyID/PlayerID/MaterialID
				[40 68 70 28]			-> Player/Enemy/Material Class Structure

Note:
Class Structure of the Enemy is the same as the PlayerStruct posted by Thr!ce ->> [Only registered and activated users can see links. Click Here To Register...]

Page 3 of 4