当智能喂食机停摆……第二篇

书接上一回：https://cloud.tencent.com/developer/article/2073517

从配网代码的回调里面看到，在配网成功后，会通过EsptouchActivity的TCP_SEND和UDP_SEND来尝试向设备投递信息，tcp端口是2003，udp是2002，投递的内容是邮件地址，也就是用户账号

jd-gui里面tcp部分发送代码不能很好的反编译，但也能看个大概，并且可以通过udp的部分做对比参考，看起来并没有特别的封包格式，直接字符串投递过去，设备应该会回显这个email内容，app侧做一个简单对比来确认配置成功。

尝试通过go写这个tcp client 发送我的邮件地址过去设备，一开始没有成功，忘了他代码里面有个特别编码，在邮件地址前后增加两个冒号，添加后发送成功，设备成功回显，并且也有声音提示，抓包这边也开始看到数据包不断往来。

从路由器tcpdump的流量来看，设备想要通讯的域名是juzilink.com，但是一直dns失败，域名不存在，whois查询发现这个域名大概是1个月之前过期了……当前处于赎回宽限期

在路由上做一个域名劫持到我的笔记本之后，可以看到喂食器设备尝试通过udp7000端口进行通讯，并且在失败若干次之后会有类似于重启的操作重刷dhcp

同样的我们拿go做个简单的udp server，看看设备会发什么过来

初步看数据内容比较像经过base64编码，并且有一些拼接封包迹象。选段通过标准base64解密得到一些二进制内容，没有获得有效的信息。但是有意思的是，从udp server这边可以看到发包很频繁（按键触发后1秒1个，3分钟后降到2秒1个，后面会降到最长5秒1个的样子），可能为心跳包（也有可能有会话属性，只是因为我空实现没回包设备无限重试），从上面图也可以推断为心跳包，因为相邻每个包内容只有1个字符变化，怀疑原始数据就是时间戳之类的，而且从这个变化也可能可以反推出base64用的码表顺序。

然而实际上除了这个心跳之外，包括按设备上的按键，都没有触发有明显差异的数据包，更别说从控制中心下行的数据。所以控制中心和设备这侧的问题始终无法解决。

未完待续