拖延症晚期，一枚小菜鸟终于完成对炫舞梦工厂APP的分析。该直播APP采用TCP协议，TCP连接建立之后，首先进行基础连接认证，认证通过之后，进行帐号认证，完成即可进行获取角色信息、进入房间等各类操作。发送数据先进行ProtoBuf序列化，接着采用CRC32循环加密，添加包头（包括命令号以及长度、校验位等）之后，发送，接受到的数据反之。本文主要阐述逆向中遇到的难点及思路、基础连接认证过程、数据包的序列化过程、CRC32循环加密过程以及重要数据包的分析过程等，旨在提供APP逆向中，TCP通信协议的一般性分析研究方法，如果有更好的思路或者经验交流，欢迎联系。

        本文使用到的工具有：JEB2.3.13、GDA3.53、IDA7.0、雷电模拟器、炫舞梦工厂APP。

        一般来说，一个好的切入点可以让我们事半功倍。接触到APP之后，首先进行了流程分析。开启android monitor，进行登录操作。通过分析日志以及调用方法堆栈，发现一条日志信息很可疑：

其中，is_force_ver_up表示是否强制更新，正好对应了手机上面要求强制更新。通过JEB逆向app之后，搜索相关信息：handleCEventVideoInitConnectionResponse，发现如下：

有理由相信，z即为所需的日志类。有这么一个入手点，就好办很多。一般app都会对日志类进行重写，并且在发布版本时，关闭部分信息的输出。采用xposed对z类所有方法进行hook，打印出日志信息，可以发现，日志输出了很多有用的信息。

通过对日志信息的分析，搜索日志标签：NetConnection，分析发现com.h3d.qqx5.framework.d.g即为app的网络操作类，在该类中，进行了连接之后的基础连接认证，以及后续的数据包的发送接收等操作。也发现了具体的发送数据包的函数

与此同时，日志也明确告诉TCP连接的IP和端口，方便抓包分析。

找到发包函数，即有了突破点。一层一层向上追溯即可找到调用层次。

        该APP代码做了混淆，对于分析协议的过程中十分不利。我的思路为跟踪方法过程，并及时进行重命名，重命名的过程中，我的命名规则是：原方法名_现方法名，之所以保留原方法名，是方便后续的hook操作。比如上述发包函数，在我对此方法详细分析之后，其效果如下：

可读性增强很多，慢慢由点及面，从日志入手，各处分析，最后零零散散，即可大致分析出整体app通信流程。

通过抓包分析以及对反编译之后的代码分析，关键认证代码在com.h3d.qqx5.framework.d.g.b.a：

得知建立连接之后基础连接认证流程，对比数据包进行分析：

protocal：

接收到的数据包第一个四字节为长度，所有整数均为大端存储，第二个四字节无意义，下文的send以及recv同理。之后列出来的数据包都是从第九个字节开始。

从long_1到long_2依次计算其sha-256值，直至结果与数据包返回的long_key_sha-256值相同，此处将符合条件的值命名为long_key

puzzle：

verify：

至此，tcp基础连接认证成功！可以进行后续操作。

这部分是最让人难受的一部分，因为一直以为是谷歌的protobuf，尝试套上去解数据包，结果死活不行。app解数据包这儿流程又比较复杂，加上混淆，理解了好久才理解明白流程。

以CEventQueryVideoAccountInfo该事件的发送以及接受处理为例说明

首先，java有一个类，即为CEventQueryVideoAccountInfo类，

通过代码，可以得知该类的功能为CEventQueryVideoAccountInfo，该类的属性虽然被混淆，但是根据日志，我们可以还原各个属性的真实含义。

首先，先设置各个属性的值，接着进行序列化。序列化之后的数据如下：

序列化完成之后，进行加密，加密之后添加包头

整数型压缩与解压算法和加密与解密算法随后给出

接下来先讨论返回的数据

java同样定义了返回的数据类

收到数据：

与发送数据正好相反

客户端拿到数据之后，首先获取clsid号，接着在一个hashmap中寻找对应的类，找到之后，通过反射获取类的所有属性，从而完成解析。

解析之后数据如下：

需要注意的是，并不是所有的数据结构类都会重写toString()方法帮助我们理解各个属性的真实含义，同样有很多类是没有重写该方法的。因此，我们需要尽可能重命名我们知道真实含义的每个值，方便以后遇到没有重写toString()方法时，对其属性的含义完成猜测和验证。

1. 压缩解压算法如下：

2. 加密解密算法：

        在数据序列化一节已经以QueryVideoAccountInfo为例进行了阐述。在抓包之后，想要完成对数据包的详细分析，我采用xposed和jeb分析相结合的方法。我们已经知道，数据包开头即为clsid号，对应了一个java类，我们可以在JEB的disassembly页面直接搜索相关的十六进制或者十进制的值来定位关键类，同时，我们也可以通过xposed，在其序列化和反序列化的入口，拦截这个类，打印其方法名，从而得到其具体位置。

假设我们现在有一个数据包，其clsid为D1 A0 00 00。我们想要找到其实现类。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！