为什么堂堂微信数据库表名、字段名起的如此随意？

1.微信数据库解密

• 微信数据库在在哪个文件夹

  EnMicroMsg.db的父文件加密规则是md5("mm" + uin)这样就可以准确的获取到db文件的位置.

  uin的获取：/data/data/com.tencent.mm/shared_prefs/auth_info_key_prefs.xml`里面有个uinz字段，直接获取value值，示例如下图所示：

  

• 解密微信数据库：目前只涉及两个数据库EnMicroMsg.db(微信数据涉数据库)和WxFileIndex.db(文件索引数据库)

  解密的密码：md5(手机imei+uin)的32位字符串取前7位，如果imei拿不到就用1234567890ABCDEF代替

2. 好友相关信息

微信的好友相关数据涉及三张表：rcontact，bizinfo，img_flag

• rcontact表存放了该账号涉及的所有账号(微信账号，群账号)的基本信息(eg：微信昵称，备注，原微信号，改之后的微信号，全拼等等)。如下图所示：

  

• bizinfo表存放的是该账号的好友微信号，群账号，这里好友包括已经通过的和添加没通过的，如下所示:

  

• img_flag表存放该账号所有涉及的微信(好友，同属一个群不是好友，添加的陌生人)的头像地址，数据如下图所示：

  

  总结：rcontact表是一张基础表，存放所有的账号基本信息，bizinfo存放是该账号的好友信息或者群组信息，img_flag存放了微信账号对应的头像信息，以下场景有：

  • 获取微信好友信息，查询sql如下：

    select r.username, r.alias, r.conRemark, r.nickname, r.pyInitial, r.quanPin,r.encryptUserName, i.reserved2 from rcontact r INNER JOIN img_flag i  on r.username = i.username where r.type&2=2  and r.username not like '%@chatroom' and i.lastupdatetime > 0
    

  • 获取添加未通过的好友信息，此时有两种情况：1）添加同属一个群的好友。2）添加陌生人。比如说通过微信号，扫码什么。这两种情况在数据库的表现形式是不一样的，添加同属一个群的，在bizinfo表会插入一条username为添加好友的微信号记录，而如果是添加陌生人，则username是一个以@stranger结尾的key，对应的数据如下图所示：

    

    注意：这里如果通过微信号，扫码添加的陌生人，其username是一长串的以@stranger结尾的key，同 时pyInitial，qunPin两个字段存的并不是这个陌生人的微信号

    查询sql如下：

    SELECT r.username, r.alias, r.conRemark, r.nickname, r.pyInitial, r.quanPin, r.encryptUserName, i.reserved2 FROM rcontact r INNER JOIN bizinfo b ON r.username = b.username INNER JOIN img_flag i ON r.username = i.username 
    WHERE r.type  33 and r.type & 2  2 AND r.username  '当前微信号' AND r.username NOT LIKE '%@chatroom' AND b.updateTime > 0
    

  • 获取同属一个群但不是好友的基本信息：

    查询sql如下：

    SELECT DISTINCT r.username, r.alias, r.conRemark, r.nickname, r.pyInitial, r.quanPin, i.reserved2 FROM rcontact r  INNER JOIN img_flag i ON r.username = i.username 
    WHERE  r.username not in(select username from bizinfo) and i.lastupdatetime >0
    ​
    

  项目推荐：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企业级系统架构底层框架封装，解决业务开发时常见的非功能性需求，防止重复造轮子，方便业务快速开发和企业技术栈框架统一管理。引入组件化的思想实现高内聚低耦合并且高度可配置化，做到可插拔。严格控制包依赖和统一版本管理，做到最少化依赖。注重代码规范和注释，非常适合个人学习和企业使用

  Github地址：github.com/plasticene/…

  Gitee地址：gitee.com/plasticene3…

  微信公众号：Shepherd进阶笔记

  交流探讨qun：Shepherd_126

  3.微信群组

  微信群组信息表为chatroom，存放着一些基本信息，数据如下图所示：

  

  注意：微信群组一开始建立显示群昵称是所有好友微信昵称加起来的一个字符串，即displayname字段，但是如果修改了群昵称之后，显示的是修改之后的，这时候需要根据根据群账号chatroomname去rcontact表做关联查询，根据rcontact表的username等于群账号查询出一条记录，此时这条记录的字段nickname即修改后的群昵称，查询sql如下：

  select c.chatroomname, c.memberlist, c.displayname, c.roomowner, c.selfDisplayName, r.nickname from chatroom c inner join rcontact r on r.username = c.chatroomname where c.modifytime > 0
  ​
  

  目前的微信群组的头像在img_flag表没有存储，暂时找不到资源所在

  4.微信聊天数据

  微信的聊天记录是保存在message表中的，数据示例如下图：

  

  msgSvrId：唯一标示一条聊天记录的id，可以作为更新聊天记录数据的条件

  createTime：发送消息的时间

  talker：如果是群账号，说明这条消息是群会话消息，发送人在content内容前面(发送人微信号：发送内容)；如果是好友微信号，说明这条消息是好友会话消息

  isSend：发送或者接收标志。0：接收 1：发送

  type：消息类型 1：文本内容(包括小表情) 3：图片 34：语音 43：视频 47：大表情 49：文件

  436207665：微信红包 419430449：微信转账

  图片，视频，语音， 文件 根据msgId去索引库WxFileIndex的表WxFileIndex2查询

  • 图片查询sql：

    select * from WxFileIndex2 where msgId in(msgIds) and msgType=3 and msgSubType20
    

  • 语音查询sql：

    select * from WxFileIndex2 where msgId in(msgIds) and msgType=34
    

  • 视频查询sql：

    select * from WxFileIndex2 where msgId in(msgIds) and msgType=43 and msgSubType=1
    

  • 文件查询sql：

    select * from WxFileIndex2 where msgId in(msgIds) and msgType=49 and msgSubType = 34
    

  • 大表情查询sql：根据groupId去找到对应的包名，md5即表情的文件名

    select e.md5, e.groupid, m.msgSvrId from emojiinfo e INNER JOIN message m on e.md5=m.imgpath where m.type=47
    

  5.总结

  以上分析师基于Android系统端的微信，且微信数据的撤销删除仍需要研究，待补充，未完待续…….

文章来源于互联网:为什么堂堂微信数据库表名、字段名起的如此随意？