对这几个函数进行了更深一步的逆向和变量名恢复，并且修复了几个结构体（都是临时命名，不代表实际含义）：

逆向过程结合了dump的内存：

这个内存段存储的就是几个json_struct结构体的实例，正好都是16字节一个:

也就是说，它是把一段json平坦铺开，依靠一堆json_struct管理，四个字段分别表示一个键值对的键的类型，在这段json中该键的偏移起点，偏移终点，以及这个键值对的值的数量（子节点），而json字符串自身的地址则由struct_params_ptr_ptr结构体提供。

这个结构体一开始被我命名成了一个指向字符串指针的指针，后来确认它是结构体后，因为只知道个别字段，所以继承了之前的命名，没有贸然改动。

其他的一些dump同样印证了这一猜测。

而skip_child则是用于在json_struct数组中进行跳跃的，当一个json_struct实例的子节点数不畏0时，意味着接下来几个json_struct实例都是它的子节点，它就负责执行跳过。

所以，这里的逻辑就是在json_struct数组的协助下，去json的原文本里查询"did"这个键，但是没找到，所以返回了-9。

查阅了一些资料，did在这种语境下一般是“Device ID”，也就是说，跟它通信的文本缺少did字段。

将dump的json字符串与helper脚本的逻辑进行比对：

脚本里调用的get_miot_did.sh事实上并不存在，可以考虑在脚本里硬编码一个did,尝试补全。

did的格式是官方文档提供的，也很容易找到。

这里我硬编码了一个did,并且搬到了if else以外，这次出现了不同的报错：key not string。

这跟之前的did not string如出一辙，我猜测大概率也是相似的调用逻辑，所以这里可以考虑再硬编码伪造一个key字段。

同样方法，处理key和mac,三元组就被凑齐了，再次发包：

日志可以看出已经在与云端进行通信了。

打开wireshark,尝试抓包，并进一步过滤：