Recently spent a few days tracking the "QQ Chat record viewer 5.3 Chinese military version", finally the chat record storage method to find out. People don't laugh at me, just curious, hehe.
1. Chat Record storage mode
The QQ chat record is saved in the Msgex.db file. Earlier versions were saved in Msg.db, and the file structure was different now, so we didn't analyze it.
MSGEX.DB adopts storage structured storage. Learn more about storage composite documents consult the Microsoft documentation and we don't go into the details.
You can use the Docfile View tool with VC to view the contents of the file, you can see the file structure is as follows:
|----MsgEx.db
| |----C2CMsg
| |----QQ号码
| |----Data.msj
| |----Index.msj
| |----IMInfo
| |----info.dat
| |----Matrix
| |----Matrix.db
| |----SysMsg
| |----10000
| |----Data.msj
| |----Index.msj
| |----DiscMsg
| |----GroupMsg
| |----MobileMsg
|---------TempSessionMsg
The message content is stored in the DATA.MSJ below each number through the INDEX.MSJ index. The message content is encrypted and must be decrypted to see it.
2. Decryption method
Message content is encrypted using Blowfish packet. Each 8 byte is a grouping. Key keys are generated by QQ numbers, and the specific algorithms are discussed later.
Decryption method:
A. Take the first 8 bytes, decrypt through Blowfish, get decryptkey;
B.decryptkey with the back 8 byte xor, the result is again Blowfish decryption;
C. The first set of results is obtained by XOR the Decryptkey with the first 8 bytes;
D.decryptkey with the back 8 bytes xor, repeat b,c two steps;
E. Final decryption of all data is complete.
Finally, there is a set of 8 bytes that cannot be decrypted, which is actually redundant data that appears to be used as a checksum.
3. Specific steps
When decrypted above, the Blowfish key is a global public key key. Key to be generated by QQ number, the specific steps are:
A. The QQ number is MD5 transform, get Md5key
B. Take matrix.db data and decode it. Briefly describe the structure of the Matrix.db file:
MATRIX.DB uses block storage, each record contains type, name length, name, content length, content of several fields. Represented by data structures are:
struct Record{
char rType;
short nLen;
char Name[nLen];
int rLen;
char Content[rLen];
};
The initial content is also stored through encryption. Decryption method is very simple: the length of the low byte and high byte XOR, get key, the content and key to XOR, the result. Decrypt the name and content separately. After decryption will see STL, TIP, CRK, CPH, Cah and other fields, do not know what the meaning of specific, interested students can study their own. We're going to use the Crk field, which is 32 bytes long (if the local chat record is encrypted, it may change, never tried). The resulting CRK field is used as a pdata.
C. Blowfish decryption of pdata with Md5key to obtain global key key
4. Conclusion
All of the above discussion is that the local chat record is not encrypted. If you choose to encrypt, no password is sure to solve the drop, the guys don't bother.