Looking for Encryption function

Page 2 of 4 1 2 34
11/08/2014 23:47 Daifoku#16
Any idea what bufferTwo is for ?

you can use
Code:
bufferTwo_0 = 0x00; // (uint8_t*)(((uint32_t)bufferTwo) - ((uint32_t)buffer))
and it is still working fine.
((uint32_t)bufferTwo) - ((uint32_t)buffer) seems to be always zero.
11/08/2014 23:49 ​Tension#17
actually it's a copy of the buffer. AuraKingdom uses alot of techniques to confuse the reverser.
11/10/2014 02:14 Daifoku#18
Mh, I somehow fail to replace one Packet with another.

Creating a new Buffer (myNewBuffer) and passing it as parameter :
Code:
bool __cdecl xorPacketHook(uint8_t *xorTab, int bufSize, uint8_t *buffer, uint8_t *bufferTwo)
{
...
int myNewBufSize = 17;
uint8_t myNewBuffer[] = { 0x95, 0x00, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

return XORPacket(xorTab, myNewBufSize , myNewBuffer);
}
I don't get a DC but my packet gets rejected.

If i just loop and replace one by one, it is working:
Code:
bool __cdecl xorPacketHook(uint8_t *xorTab, int bufSize, uint8_t *buffer, uint8_t *bufferTwo)
{
...
int myNewBufSize = 17;
uint8_t myNewBuffer[] = { 0x95, 0x00, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

for (int i = 0; i < myNewBufSize ; i++){
	buffer[i] = myNewBuffer[i];
}
//passing buffer
return XORPacket(xorTab, myNewBufSize , buffer);
}

Any Idea ? remark: porbably just a silly mistake with pointers.. I am not good at cpp :D
11/10/2014 08:53 AlainProvist#19
You should try a dynamic allocation (or a global static table at least) for your table instead of a static table. I didn't gave a look into all of this but from what I see in your code, the table will just go out of scope when returning the hooked function and will be overwriten by the next function's stack.

Anyway, I'm really not sure it will be sufficient enought... The packet buffer is supposed to be containined in a bigger structure that is probably mandatory. So juste XORing a new packet buffer won't really help you to actually send a new custom packet...
11/29/2014 16:28 ​Tension#20
Okay the first packet getting sent is encrypted with RSA.

For encryption it uses:
Code:
RSA_eay_private_encrypt
you can get it from OpenSSL, the padding is 1 which is:
Code:
RSA_padding_add_PKCS1_type_2

call could look like:
Code:
push 1
push offset rsa
push offset to
push offset from
push len
call RSA_eay_private_encrypt
rsa.h says that the RSA struct looks like this:
Code:
struct rsa_st
	{
	/* The first parameter is used to pickup errors where
	 * this is passed instead of aEVP_PKEY, it is set to 0 */
	int pad;
	long version;
	const RSA_METHOD *meth;
	/* functional reference if 'meth' is ENGINE-provided */
	ENGINE *engine;
	BIGNUM *n;
	BIGNUM *e;
	BIGNUM *d;
	BIGNUM *p;
	BIGNUM *q;
	BIGNUM *dmp1;
	BIGNUM *dmq1;
	BIGNUM *iqmp;
	/* be careful using this if the RSA structure is shared */
	CRYPTO_EX_DATA ex_data;
	int references;
	int flags;

	/* Used to cache montgomery values */
	BN_MONT_CTX *_method_mod_n;
	BN_MONT_CTX *_method_mod_p;
	BN_MONT_CTX *_method_mod_q;

	/* all BIGNUM values are actually in the following data, if it is not
	 * NULL */
	char *bignum_data;
	BN_BLINDING *blinding;
	BN_BLINDING *mt_blinding;
	};
The KeyPair is from the first packet you receive.
The packet is structured like this:
Code:
typedef struct tagKEYBUFFER {
int keypart_a_size;
int keypart_b_size;
unsigned char* keypart_a;
unsigned char* keypart_b;
};
so this packet:
Code:
00 01 00 00 02 00 00 00 C8 75 2F F4 1D BC 76 06 9B 54 E2 E2 93 E1 56 D0 8E C9 91 BC 91 7F A4 C0 3E C2 61 02 80 A5 39 20 62 65 61 C9 06 AD 94 B4 EB 3D 07 93 27 A3 B7 03 FB 23 07 E7 58 76 A6 EE 9A 95 BE 5C 8C 3D D9 8F 15 FF FE C4 0F 7D 1A 77 EE 3F FF AD F8 BF 79 0F 67 9B 38 D7 A0 19 69 81 60 89 70 45 87 96 16 3B 44 A9 1F 04 8A 84 2D 7C 50 12 10 8E 53 57 0C 46 FE 12 7E 6C 83 14 A2 D9 53 50 3C B9 5A 12 76 46 C4 EB EE F4 10 9B 1A 1F 96 D4 2C 66 AD C0 29 0B 08 74 B9 46 12 FC 90 7D CE D5 0D 3C C2 37 32 60 8D 9C 47 83 82 95 DA EC 9C E2 BE 35 6C E2 65 49 AB 50 F1 00 A6 B9 88 FE CE BC E3 6C E6 63 AD FB 91 9E 94 B6 1D 96 DA 04 01 1B 19 50 8F C7 7B 4E 82 2E E2 36 3F 0D 78 1E FF 62 1F 2D E5 1A 0F EE 86 42 B9 76 EB C6 37 C9 A6 87 C8 2E 17 EA B5 8C 43 C1 D2 74 1E 80 FF 59 D0 4A 73 97 D2 9A D2 21 FF FF
has 2 parts, the first one is 0x100 bytes long the second 0x2 bytes.
To make it a bit more complicated they've flipped the buffer which means that it starts with:
Code:
21 D2 9A D2
and ends with:
Code:
F4 2F 75 C8
i'm trying to figure out how the OpenSSL shit works and creating a packet generator. One thing i know that it's generated with random bytes but i have to take a deeper look in it.


Regards.
11/29/2014 17:47 Daifoku#21
Uhm, my first packet from WSASend is a bit different from yours.
Maybe it helps ~V

Code:
typedef struct P_0x0001{
size_t header;
size_t Session_size;
unsigned char* Session;
size_t AuthenticationMethod_size;
unsigned char* AuthenticationMethod;
size_t VersionNumber_size;
unsigned char* VersionNumber;
};
[Only registered and activated users can see links. Click Here To Register...]
11/29/2014 19:33 ​Tension#22
There is one packet which gets sent before yours, it's the crypto-packet which contains the salt of the XorTable, it has 256 Bytes.

Still wondering how the packet gets generated... when following the code i land in
Code:
int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo, int lock);
which says:
Quote:
/*
* (Based on the rand(3) manpage: )
*
* For each group of 10 bytes (or less), we do the following:
*
* Input into the hash function the local 'md' (which is initialized from
* the global 'md' before any bytes are generated), the bytes that are to
* be overwritten by the random bytes, and bytes from the 'state'
* (incrementing looping index). From this digest output (which is kept
* in 'md'), the top (up to) 10 bytes are returned to the caller and the
* bottom 10 bytes are xored into the 'state'.
*
* Finally, after we have finished 'num' random bytes for the
* caller, 'count' (which is incremented) and the local and global 'md'
* are fed into the hash function and the results are kept in the
* global 'md'.
*/
i hope that i can reconstruct the RSA Crypto for the first packet, it would help alot i think.


Edit:
found out that it has something to do with the bn_mod_exp function, hope that it works soon
:)

Edit2:
Seems like that the crypto is virtualized... Atleast i know that after the padding no extra random values are added, but there are some tables(2-3) and i have no idea how they get generated..

Code:
/*
r = result table
a = salt
p = keypart B
m = keypart A
*/
int BN_mod_exp(BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m, BN_CTX *ctx);
11/30/2014 18:10 Daifoku#23
I'm no help with that :x have to take a closer look at it on monday :)
but i can point out some things that i noticed.

That was your constructed packet:
Code:
00 01 00 00 02 00 00 00 C8 75 2F F4 1D BC 76 06 9B 54 E2 E2 93 E1 56 D0 8E C9 91 BC 91 7F A4 C0 3E C2 61 02 80 A5 39 20 62 65 61 C9 06 AD 94 B4 EB 3D 07 93 27 A3 B7 03 FB 23 07 E7 58 76 A6 EE 9A 95 BE 5C 8C 3D D9 8F 15 FF FE C4 0F 7D 1A 77 EE 3F FF AD F8 BF 79 0F 67 9B 38 D7 A0 19 69 81 60 89 70 45 87 96 16 3B 44 A9 1F 04 8A 84 2D 7C 50 12 10 8E 53 57 0C 46 FE 12 7E 6C 83 14 A2 D9 53 50 3C B9 5A 12 76 46 C4 EB EE F4 10 9B 1A 1F 96 D4 2C 66 AD C0 29 0B 08 74 B9 46 12 FC 90 7D CE D5 0D 3C C2 37 32 60 8D 9C 47 83 82 95 DA EC 9C E2 BE 35 6C E2 65 49 AB 50 F1 00 A6 B9 88 FE CE BC E3 6C E6 63 AD FB 91 9E 94 B6 1D 96 DA 04 01 1B 19 50 8F C7 7B 4E 82 2E E2 36 3F 0D 78 1E FF 62 1F 2D E5 1A 0F EE 86 42 B9 76 EB C6 37 C9 A6 87 C8 2E 17 EA B5 8C 43 C1 D2 74 1E 80 FF 59 D0 4A 73 97 D2 9A D2 21 FF FF
but
Code:
00 01 00 00 02 00 00 00 C8 75 2F
belongs to the Recv Packet you get, after sending the first WSASend packet.
I don't see how this is related to the cryption of the first sendpacket, i mean ... you already crypted it at that time ;-)

my Log (3 packets) :
[Only registered and activated users can see links. Click Here To Register...]
11/30/2014 18:47 ​Tension#24
I think we can write in german.

Das erste Packet das man bekommt sind zwei Teile für bn_mod_exp.
Die ersten beiden DWORDs sind lediglich die Größen der beiden "Tables", laut meiner Analyse in Olly ist der erste Table der Modulus Wert und der zweite Wert der Exponent (was ich aber komisch finde).

Danach werden 0xF8 zufällige Bytes generiert und am Ende unser Salt rangehängt. Anschließend wird dieses mit der bn_mod_exp Funktion verschlüsselt.
Das BN steht für BigNumber und mod exp für Modulus Exponent.
Die "allgemeine" Formel lautet:
Code:
(a^p)%m;
nun weiß ich nur nicht wie dieses angewendet wird, ob DWORDs, WORDs oder BYTEs verwendet werden etc. Ich hab nur eine Funktion gefunden die ich "GenTable" genannt habe welche diese Parameter hat:

Code:
void GenTable(unsigned char* OutTable, unsigned char* InTable, const unsigned char* CryptoTable,  const int len);
OutTable steht halt für den OutPut, InTable ist ein Table welcher meiner Vermutung nach im Virtualisiertem Code generiert wird und CryptoTable ist KeyPart A.
Das allgemein DWORDs verwendet werden schließe ich nicht aus da der Parameter len den Wert 0x40 und 0x40*4 = 0x100 was der Größe der Table entspricht.

Ich muss mich da noch ein wenig tiefer reinfressen aber hoffe das es klappt.

Edit:
Vielleicht finde ich ein Weg zum Re-Produzieren.

Hab den Random-Buffer durch 0x00 ersetzt und das Salt komplett auf 0x11 gesetzt das sieht dann so aus:

Code:
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x11, 0x11, 0x11, 0x11, 0x11
und der Table nach dem Verschlüsseln immer so:
Code:
0xAD, 0x34, 0x5C, 0xC1, 0xC9, 0xAA, 0xD5, 0x2F, 0xF2, 0x05, 0xF6, 0x36, 0x68, 0x34, 0x86, 0xE8, 0x22, 0x7B, 0x52, 0x65, 0x15, 0x7A, 0xB8, 0xD9, 0xB0, 0x2E, 0xEC, 0xFB, 0xE9, 0xDA, 0x44, 0x93,
0x0C, 0x7A, 0x47, 0xA8, 0xD7, 0x28, 0xFF, 0x1A, 0x3E, 0xB3, 0x01, 0x46, 0xE7, 0x64, 0x15, 0x85, 0x36, 0xCF, 0x78, 0xCD, 0x26, 0xCA, 0xF7, 0x89, 0xEE, 0x4A, 0x6A, 0x23, 0x52, 0x77, 0x22, 0x50,
0x3E, 0xA6, 0x3F, 0xCA, 0x80, 0x37, 0xC8, 0x02, 0x3C, 0x8C, 0xF0, 0xFC, 0x2B, 0xF4, 0x4F, 0x5C, 0x69, 0x6D, 0xAF, 0x12, 0x98, 0xD1, 0xFB, 0x5B, 0xA6, 0x7D, 0x79, 0x86, 0xA9, 0xF3, 0x0E, 0x47,
0x83, 0x35, 0xEA, 0xA0, 0x5F, 0x53, 0x9A, 0x20, 0xBC, 0x18, 0x04, 0x7D, 0x7F, 0x20, 0x67, 0xE1, 0x90, 0x79, 0x58, 0x5E, 0xC1, 0x92, 0xA5, 0x37, 0xA1, 0xE6, 0x94, 0xF1, 0xEF, 0x84, 0xAD, 0xFD,
0xC7, 0x95, 0x68, 0xC5, 0xB0, 0x61, 0x24, 0x53, 0x76, 0x07, 0xE9, 0x7C, 0x93, 0xD5, 0x75, 0xDD, 0x39, 0xC3, 0x8E, 0x6A, 0x1A, 0x1C, 0xE5, 0x56, 0xD0, 0x76, 0x8C, 0x31, 0x29, 0x24, 0x21, 0x2E,
0x21, 0x67, 0xF5, 0x6D, 0x7E, 0x4A, 0xD0, 0x53, 0x03, 0x4C, 0x66, 0xEE, 0x9F, 0x42, 0x3B, 0x89, 0x17, 0x05, 0xAD, 0x12, 0xE1, 0x05, 0x82, 0x18, 0x10, 0x8A, 0x66, 0x3E, 0xD9, 0xE3, 0x9F, 0x53,
0x0A, 0x70, 0x19, 0xA0, 0x53, 0x47, 0x20, 0xAD, 0xBA, 0x11, 0xDD, 0x4E, 0x0E, 0x3B, 0x3A, 0x03, 0xC8, 0x78, 0x3F, 0xCF, 0xC7, 0x31, 0xE7, 0xB2, 0x61, 0x1D, 0xD8, 0x5D, 0xAB, 0x3B, 0x57, 0x10,
0x11, 0xCB, 0x97, 0x89, 0xEA, 0x83, 0x98, 0xC0, 0xD6, 0x31, 0x7F, 0xD0, 0xBB, 0xA9, 0x93, 0x20, 0x83, 0xB9, 0x82, 0x91, 0xCF, 0x03, 0x8D, 0xEA, 0xD4, 0x10, 0x5A, 0x82, 0xBD, 0x58, 0x57, 0xC2
11/30/2014 19:32 Daifoku#25
Okay, habe anfangs wohl einiges verwechselt. Ich sollte mich erst mit Olly beschäftigen und dann meinen Senf dazu geben :D

der Parameter len wird vermutlich das fl sein, welches in der OpenSSL Dokumentation genutzt wird. Ich muss jetzt erstmal meinen uni kram machen :D morgen such ich mir mal die Stellen in Olly zusammen :)

Code:
 int RSA_padding_add_PKCS1_type_2(unsigned char *to, int tlen, unsigned char *f, int fl);
Quote:
Originally Posted by https://www.openssl.org/docs/crypto/RSA_padding_add_PKCS1_type_1.html
RSA_padding_add_xxx() encodes fl bytes from f so as to fit into tlen bytes and stores the result at to. An error occurs if fl does not meet the size requirements of the encoding method.
11/30/2014 19:56 ​Tension#26
Das mit dem Padding kann man ignorieren, es werden sowieso zufällig Bytes erstellt und die letzten 5 Bytes sind nur wichtig welche dem Salt entsprechen.

Code:
00D5F356   .  52            PUSH EDX                                 ;  what?
00D5F357   .  8B57 14       MOV EDX,DWORD PTR DS:[EDI+0x14]
00D5F35A   .  8B7C24 14     MOV EDI,DWORD PTR SS:[ESP+0x14]
00D5F35E   .  53            PUSH EBX                                 ;  ctx
00D5F35F   .  50            PUSH EAX                                 ;  m
00D5F360   .  8B4424 34     MOV EAX,DWORD PTR SS:[ESP+0x34]
00D5F364   .  52            PUSH EDX                                 ;  p
00D5F365   .  50            PUSH EAX                                 ;  a
00D5F366   .  57            PUSH EDI                                 ;  ret
00D5F367   .  FFD1          CALL ECX                                 ;  bn_mod_exp
Code:
00D5F370   .  57            PUSH EDI                                 ;  &ret
00D5F371   .  E8 EAF4FFFF   CALL game.00D5E860                       ;  BN_num_bytes
Code:
00D5F38A   .  52            PUSH EDX                                 ;  to
00D5F38B   .  57            PUSH EDI                                 ;  a
00D5F38C   .  E8 6FF9FFFF   CALL game.00D5ED00                       ;  BN_bn2bin
sind so die Kernfunktionen, der Rest ist scheiß egal.

Code:
00D67240  |.  8B4C24 18     MOV ECX,DWORD PTR SS:[ESP+0x18]
00D67244  |.  8B5424 10     MOV EDX,DWORD PTR SS:[ESP+0x10]
00D67248  |.  51            PUSH ECX
00D67249  |.  56            PUSH ESI
00D6724A  |.  52            PUSH EDX
00D6724B  |.  E8 70FDFFFF   CALL game.00D66FC0

00D66EDA   .  57            PUSH EDI
00D66EDB   .  51            PUSH ECX
00D66EDC   .  56            PUSH ESI
00D66EDD   .  52            PUSH EDX
00D66EDE   .  E8 2D030000   CALL game.00D67210
Die Funktionen haben noch was mit dem einen CryptoTable zutun.
12/31/2014 15:38 ken12#27
Anyone knows why I can't send a packet? I mean it sends correctly but it doesnt execute. Maybe there is some check in the server before it gets executed?
12/31/2014 17:06 ​Tension#28
I'd need more information to help you. What kind of packet? how do you send it? etc.

So i've got myself to take a look again into the game.bin.
What i've figured out:
you may know that the packetheader contains 2 shorts, ID and Type.
After tracing a bit i've figured out that the first short (ID) is just a function index.
But the problem is, that the Function-Table is dynamic so i'd need some more time to find how it actually works.
12/31/2014 19:49 ken12#29
Here are the packets..

Code:
** SKILL PACKET
format = A0 00 XX XX ID ID TG TG TG TG 00 00
Definition :
A0 00 -> Headers
XX XX -> 66 00/ 7E 00 -> Depends upon the use of the skill
ID ID -> 2 Byte Skill ID (ranges from 0000 - FFFF)
TG TG TG TG -> 4 Byte TargetID/PlayerID
00 00 -> Free bytes
Size = 0xC

** Teleport Packet 
format = 04 00 2D XX XX 00
04 00 -> Headers
2D -> unknown
XX XX -> 2 Byte Map ID
00 -> Free byte
Process of sending the packet..

1. Function call that takes 2 args -> This call is use to Encrypt the packet without having to look for the whole xor table or what...
2. After encryption I send it using either send() or WSASend()

After that sending i'll get no response. So I think the AK have other checks or something..
01/01/2015 16:49 ​Tension#30
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?
Page 2 of 4 1 2 34