QQProtect进程简单分析
首先，本分析只供抛砖引玉，本人并非专业安全人员，分析可能有疏漏。并且由于程序代码量巨大，只能挑关键部分分析，不排除有暗中留后门的可能。
安装包为我手头有的QQ，我没有去专门试tim的QQProtect，但我认为两者不会有区别。
那么，先说结论，单就ReadProcessMemory这个函数的调用来说，有问题的可能性不大，其写法更像一个基于特征码的杀毒软件。可能在以前QQ盗号盛行的年代会对账号安全有一定帮助。当然相同技术只是换一个关键字也是有检测用户行为的能力，不过鉴于他的检测范围不包括堆和栈，这种应用场景比较受限，可能性不大。
包含了虚拟机检测，众多其他公司软件的检测，这里可能会有一些问题。我没有细究，不知道有没有人接上。
另外，抛开TX的作风不谈，这个程序运行在SYSTEM权限下，并且还有驱动加持，拥有系统的最高权限，结构又极度复杂，包括了自动更新，扫码，服务器通信等非常多功能，在最高权限下跑这种复杂任务还是比较让人担心的（提权漏洞等）。（虽然包括了扫码，但是扫码登录又不依赖这个程序,不知道是不是简单的代码复用导致的。甚至qq进程脱离了QQProtect也是能正常工作的，只是需要一些方法让他不主动退出。）
关于读内存部分的程序结构：
程序某处通过vtable调用接口，启动监控线程。由于这里vtable的存在，我没办法反向追过去。但这并不是刻意为了隐藏行为，只是一种典型的程序写法。
创建了两个线程，按照日志中的名字，分别叫为MonitorThread和DubiousMonitorThread。（进程监视线程和可疑进程监视线程）
这两个线程分别运行，但是似乎共用了一套关键字，使用消息与某处进行通信（扫描哪些进程是由发过来的消息决定的）。
线程中有三种扫描，起名为ScanCode，ScanMemPatch，还有一种还没分析功能，起名ScanUnknownThing。
ScanCode中有两种扫描，一种起名CloudProcess，一种LocalProcess。ScanMemPatch函数结构看起来与ScanCode相似，看名字可能是扫描hook用的。
CloudProcess我没有细致分析，名字是他的日志中写的。大概操作似乎是计算模块Hash，文件名等，可能会发往服务器分析。这个函数中不包含读取其他进程内存的操作。
LocalProcess中包括对目标进程枚举模块，并使用关键字扫描模块内存的操作。这里的模块内存指PE文件头，.code，.data，.bss等区段，不包括堆、栈。对于浏览器，文档编辑器等，这些区段由于空间大小固定，一般不会放需要动态加载的东西（网页内容，文档等），即有敏感信息的可能比较小。但是用户名，密码等短长度内容有可能出现。
在扫描内存时，会先读取64K内存，之后每次以63K为长度进行遍历。开头1K的内容一直保留在buffer中参与后续计算。不知道为何如此设计。扫描算法疑似KMP。
如果发现有关键字，会结束目标进程（疑似）。
流程图，蓝底部分为本分析中的流程。字很小，不知道图片会不会糊掉。左下角为入口的VTable，之后流程从左上到右下。
以上是静态分析，由于静态分析找不到调用源，所以找不到关键字。下面是动态调试。
环境win10 vmware，似乎程序里面有检测虚拟机的字眼，但这部分我没有去专门研究。
动态调试这里，需要解决几个问题，一个是程序通常是以服务运行的，所以很难抓到启动流程，另外程序有个自校验。
解决方案是先把自校验爆破掉，然后程序开头写一个死循环。任务管理器里选择启动服务之后附加调试器，手动跳出死循环。通过修改日志函数（TXLog_DoTXLogVW），删除了日志级别的限制，并把日志通过DebugString打印至调试器。这种方法的话只能看服务启动时的日志。打不开QQ，要能打开qq，就不能在入口点加死循环。但是可以先正常启动服务，然后附加。这时候可以启动qq看之后的日志。两者正好互补。
启动阶段日志内容：运行时候的我懒得再去截了，没什么特殊东西。
https://pastebin.com/jyxrz8wM
在代码中，如果开启了监视线程，则一定会打印这句话。但是我没有抓到。并且断点也没有命中。所以一定程度上说明这个功能可能是云端关掉了。无从分析。（不排除我操作不对没抓到的可能）
但是抓到了另一些有趣的内容：
涉及到多个进程和对应的公司名，浏览器，网易云音乐，百度网盘，wps等等，不知道是干什么的。希望能有个解释。
最后，附上idb文件。涉及到的主要逻辑在QQProtect.dll里，做了标注，一些结构体也分析了一下。有几个调用程序里面直接压栈传了个大结构体，ida分析不动，我好像也没改对。
https://pan.baidu.com/s/1dpwHN7hxplBRDBzyyVF_jQ
x6sx
