It is calculated the same as above - The packet is encrypted by XORing 1/4 of the packet with a key - The Key is calculated by multiplying the length * 0圆6756B65 and adding the check value. 2 Bytes - First Sequence Code 2 Bytes - Second Sequence Code 4 Bytes - User ID Number 4 Bytes - This is a Checksum.
2 Bytes - First Sequence Code \ These are usually the same 2 Bytes - Second Sequence Code / 4 Bytes - This is the user ID of the client user 4 Bytes - These four bytes are ICQ’s weak attempt at security: to get these do the following: check1 = ( data << 24) | ( data << 16 ) | ( data << 8 ) | ( data ) offs1 = Random % length // offset into packet offs2 = Random % 256 // offset into magic data check2 = ( offs1 << 24 ) | !( data << 16 ) | ( offs2 << 8) | !( magic ) check = check1 ^ check2 // XOR the two checksĭata encryption appeared in the fourth version: 2 Bytes - Version Number (not Encrypted) = 04 00 (Major, Minor) 2 Bytes - Random number (Not Encrypted) ***** Everything from this point to the 1/4 mark is encrypted ***** 2 Bytes - Always 00 00 un-encrypted - Since the key is xored to encrypt - whatever numbers are here are the first 2 bytes of the encryption Key. Here is an example: 2 Bytes - This is the Version of the protocol = 03 00 (Major, Minor) 2 Bytes - This is the Function code. The checksum test appeared in the third version. We should note that the very first protocol was not publicly available formally, ICQ was released with the second protocol version. Frankly speaking, the first few versions of the protocol were actually sieve-like.īy the time we had issued ICQ 99b, a fifth protocol version was already in use. Initially, there was no encryption at all, which means data transmission was open. The ICQ protocol combined features of p2p and client-server architectures.
0 kommentar(er)
