密码吧 关注：219,272贴子：821,967
既然改变ip地址之后会有内容改变，那完全否定了之前的误触的猜测，内置的无意义测试文本也排除了，因为会随着网络的连接情况而动态变化
但由于依然是常用字，所以我还是不太想认为是编码错误解读问题，所以在其他方向上进一步猜测
楼主提到了荣耀手机查找，应该是荣耀的手机丢失定位云服务，这样的话ip地址变化连带着内容变化也很好解释了，ip地址可以反推手机所在的地理位置，这是和手机定位服务直接相关的
但剩下还有几个问题
1.为什么全是常用字
2.为什么是SIM拔卡触发的，为什么内容随着IP地址变化
3.为什么都是48个汉字96字节
4.为什么会通过短信发送给106...这个号码？荣耀手机丢失云服务会发送短信给运营商吗？没卡了还发送短信不是注定失败？
由于缺乏更多的技术信息，以下均为猜测居多
问题2的解答，既然短信内容和ip地址和手机定位服务有关，手机定位服务是需要实时更新手机的地理位置了，通常是通过运营商的定位，如果无法通过运营商定位（即SIM卡被拔出），就会尝试使用网络定位，所以就会跟着ip地址一起变动。
问题1的解答，由于某种bug，手机定位服务本来应该用二进制数据进行数据上传，但是在上传过程中，内存指针错误指向了某个常用字库里，比如系统UI，天气，亦或者就是地名字库，地名字库当然大部分都是常用字了，甚至有可能不存在地名字库，而是地名是通过常用字库里的字进行拼成的，但二进制数据和常用字库之间并没有官方设定的稳定映射，于是就生成了一大堆莫名其妙的汉字
问题3的解答，既然确认是手机定位服务导致的，那服务上报给服务器的数据包应该是具有固定的格式和大小，或者至少其中一部分关键状态信息块是固定长度的。这可能包含了设备ID、时间戳、位置坐标、网络状态信息、事件代码（比如拔卡）等，也有可能和短信的长度限制140字节有关。
问题4的解答，考虑到发送的内容毫无意义，而且拔掉SIM卡后发送短信本身就没意义，而且还在不断进行的发送失败，重新尝试发送的死循环，所以这里应该是一个非预期的死循环错误，在这种情况下，手机上传自身位置等信息应该只会通过有效的渠道，有网就用网，而不是都SIM了还在发短信。我认为可能是函数错误调用或者状态混淆了，比如本来应该用数据上传的数据被错误调用了短信发送的模块，因此本来应该正常的状态信息也因为模块错误调用变得毫无逻辑，如果手机定位服务正常运行的话，应该看不到手机发送短信的才对。
综上所述，个人推测应该是手机定位服务在上传数据的时候，通过可用的WiFi网络得到了定位等信息，这些信息随着网络的变化而变化，但在往云端上传的时候由于bug错误调用了模块变成了短信，而本来应该直接送给服务器的二进制数据也被短信的机制强制跳过了编译映射成了常用字库，所以出现了一连串的无意义汉字，而本身短信是错误调用的，实际上也发不出去，所以就卡死在了这个循环里一直重复发送。
PS1：即使如此，还是有很多不合理之处，比如手机定位应该首先使用GPS数据而不是ip地址，手机到底是什么bug会把数据上传用短信方式发送，用于数据上传的内存指针为什么会指向字库？这两个几乎毫不相干。推测里全用bug涵盖过去了，但什么bug这么厉害？
PS2：以上推理存在大量证据缺失，依赖猜测，关键技术分析不足，所以只能算是一个勉强自圆其说的解释，看来我比起deepseek只高于承认自己会猜，不会用各种术语包装自己，但也给不出比他靠谱多少的答案
但由于依然是常用字，所以我还是不太想认为是编码错误解读问题，所以在其他方向上进一步猜测
楼主提到了荣耀手机查找，应该是荣耀的手机丢失定位云服务，这样的话ip地址变化连带着内容变化也很好解释了，ip地址可以反推手机所在的地理位置，这是和手机定位服务直接相关的
但剩下还有几个问题
1.为什么全是常用字
2.为什么是SIM拔卡触发的，为什么内容随着IP地址变化
3.为什么都是48个汉字96字节
4.为什么会通过短信发送给106...这个号码？荣耀手机丢失云服务会发送短信给运营商吗？没卡了还发送短信不是注定失败？
由于缺乏更多的技术信息，以下均为猜测居多
问题2的解答，既然短信内容和ip地址和手机定位服务有关，手机定位服务是需要实时更新手机的地理位置了，通常是通过运营商的定位，如果无法通过运营商定位（即SIM卡被拔出），就会尝试使用网络定位，所以就会跟着ip地址一起变动。
问题1的解答，由于某种bug，手机定位服务本来应该用二进制数据进行数据上传，但是在上传过程中，内存指针错误指向了某个常用字库里，比如系统UI，天气，亦或者就是地名字库，地名字库当然大部分都是常用字了，甚至有可能不存在地名字库，而是地名是通过常用字库里的字进行拼成的，但二进制数据和常用字库之间并没有官方设定的稳定映射，于是就生成了一大堆莫名其妙的汉字
问题3的解答，既然确认是手机定位服务导致的，那服务上报给服务器的数据包应该是具有固定的格式和大小，或者至少其中一部分关键状态信息块是固定长度的。这可能包含了设备ID、时间戳、位置坐标、网络状态信息、事件代码（比如拔卡）等，也有可能和短信的长度限制140字节有关。
问题4的解答，考虑到发送的内容毫无意义，而且拔掉SIM卡后发送短信本身就没意义，而且还在不断进行的发送失败，重新尝试发送的死循环，所以这里应该是一个非预期的死循环错误，在这种情况下，手机上传自身位置等信息应该只会通过有效的渠道，有网就用网，而不是都SIM了还在发短信。我认为可能是函数错误调用或者状态混淆了，比如本来应该用数据上传的数据被错误调用了短信发送的模块，因此本来应该正常的状态信息也因为模块错误调用变得毫无逻辑，如果手机定位服务正常运行的话，应该看不到手机发送短信的才对。
综上所述，个人推测应该是手机定位服务在上传数据的时候，通过可用的WiFi网络得到了定位等信息，这些信息随着网络的变化而变化，但在往云端上传的时候由于bug错误调用了模块变成了短信，而本来应该直接送给服务器的二进制数据也被短信的机制强制跳过了编译映射成了常用字库，所以出现了一连串的无意义汉字，而本身短信是错误调用的，实际上也发不出去，所以就卡死在了这个循环里一直重复发送。
PS1：即使如此，还是有很多不合理之处，比如手机定位应该首先使用GPS数据而不是ip地址，手机到底是什么bug会把数据上传用短信方式发送，用于数据上传的内存指针为什么会指向字库？这两个几乎毫不相干。推测里全用bug涵盖过去了，但什么bug这么厉害？
PS2：以上推理存在大量证据缺失，依赖猜测，关键技术分析不足，所以只能算是一个勉强自圆其说的解释，看来我比起deepseek只高于承认自己会猜，不会用各种术语包装自己，但也给不出比他靠谱多少的答案
