移动端常见即时通讯数据库设计
钉钉数据库表
表名 | 描述 |
---|---|
conntact | 用户信息 |
usual_contact | 常用联系人 |
org_username | 企业群组 |
DTOrganization | 企业信息 |
Ding | DING消息 |
WKConversation | 会话消息 |
WKChat_V32String | 聊天记录 |
根据WKConversation表关联WKChat_V32String主要步骤可描述为:
-
STEP1:从WKConversation表中查找conversationId字段所对应的值,记为VcId标识会话ID,执行STEP2。
-
STEP2:根据STEP1所得的会话ID关联与相应的聊天内容表。即对VcId进行MD5加密得32位的密文,记为VMD5String。即VMD5String = MD5Encode(VcId) ,其中MD5Encode表示MD5加密算法,执行STEP3。
-
STEP3:拼接表名。在STEP2计算所得的32位密文VMD5String,前添加” WKChat_”前缀后即为所求表名。
钉钉数据来源:逆向开发学习手机取证之钉钉取证分析
QQ数据库表
表名 | 描述 |
---|---|
conversation_info | 会话信息表 |
Friends | 好友表 |
TroopInfoV2 | 群聊表 |
TroopMemberInfo | 群成员信息表 |
TroopMemberCardInfo | 群成员信息表 |
DynamicAvatar | 头像表 |
好友表:Friends
目前好友表存储中好友的qq号,昵称,备注,昵称全拼,时间字段等等有效信息,sql如下所示:
字段名 | 描述 |
---|---|
uin | qq号 |
name | 昵称 |
remark | 备注 |
mCompareSpell | 昵称全拼 |
datetime | 时间 |
未通过的添加好友信息也在该表中
群聊表:TroopInfoV2
群聊表中包含了当前qq号,群qq号,群昵称,群备注,群主qq,时间等字段,sql如下所示:
字段名 | 描述 |
---|---|
uin | qq号 |
troopuin | 群qq号 |
troopname | 群昵称 |
troopRemark | 群备注 |
troopowneruin | 群主qq |
timeSec | 时间 |
陌生人信息:TroopMemberInfo
即同属于一个群但不是好友的关系的sql如下
select memberuin,troopuin, alias, autoremark, friendnick, datetime from TroopMemberInfo where memberuin not in(select uin from Friends)
会话表:conversation_info
会话表有存入所有的会话uin,uin的md5加密大写32字符串得到相应会话聊天记录表
消息记录表
- mr_friend_md5(qq)_New
- mr_troop_md5(qq)__New
好友会话消息记录表:mr_friend__New:其中的”“是好友的QQ号uin的MD5加密32位字符串。
eg:mr_friend_3DAEEB4D801A88F08AF16930B5DB7C60_New
群会话消息记录表:mr_troop__New: 其中的”“是群组的群号uin的MD5加密32位字符串。
eg:mr_troop_62CE79A16BB9C8F8193BF1B043B05D82_New
-1000:文本消息 -2000:图片 -2002:语音
(1)消息都是存在msgData这个字段里面,需要解密,msgData原生字段类型为blob,解密的方式:文本和图片,语音的解密方式是不一样的。
(2)图片,语音解密相对就比较复杂,qq使用了Google的Protobuf
QQ数据来源:析QQ数据库
网易云信
表名 | 描述 |
---|---|
msghistory | 消息表 |
lstmsg | 存储每个会话最后一条消息 |
session_read_record | 会话读取记录 |
message_receipt | 消息回执 |
clear_message_record | 清除消息记录 |
delete_message_record | 删除消息记录 |
send_receipt_record | 发送收据记录 |
sender_nick | 发送人昵称 |
消息表:msghistory
群聊和单聊在一张表,使用sessiontype区分
最后一条消息:lstmsg
记录每个会话最后一条消息
发送人昵称:sender_nick
仅有account和nick来记录用户信息
- 动态建表目前数据库Room不支持
- 字段太多,数据库读写太频繁
- 需求上没有太多本地化的要求