前言
家里有两台不用的路由器，型号分别是水星的MW313R和MW325R，曾经只会php之流的web安全、一些二进制安全知识的时候，想试下能不能对这些路由器做点什么，但感觉这个路由器好像还挺安全的样子，实际上最近几个月才知道，这是c写的后端，而且没有连数据库，常规的方法当然打不通
明明看起来这个系列路由器后台页面写的比较简陋，在网上却丝毫没有关于它们的漏洞，
一个都没有？这让我更加好奇了，所以经过之前的学习，最近终于鼓起勇气尝试尽可能地按已有的水平去分析一下
最后还是穷尽了此时自己知道的办法，从vxwork固件到后端再到js，实在尽力了，只是知道可以绕过次数限制进行爆破，目前其它的东西还没挖出来，谨以此文复盘一下，之后还会回来再试试的
MW325R和MW313R，这些MW3XXR系列的机器，使用着同一套源自于MW300R的系统，下文主要采用MW313R进行研究
固件提取+解包
网络下载
驱动天空www.drvsky.com有固件可以直接下载到，本来，无需焊电路板(可后面还是焊了，等下解释为什么)
解包
刚开始看-Me出来的文件结果，以为加密还是怎么了，因此学习了一阵子镜像是怎么解密并解压到内存，并实际分析以后，才恍然大悟，这不是加密，binwalk对vxworks这一种RTOS的解包就是这样的
可以看到，vxworks后面有好多个LZMA的压缩文件，会直接使用内存的位置来命名文件，binwalk无法去恢复其文件系统的结构和文件名(即使这里面有个jffs2文件系统)。不过这没关系，实际上有一个最大的文件，叫做F114，网上的教程一般就是取出最大的那个二进制文件去分析，这部分一般包含着主要逻辑
全是没有文件名的文件
F114是主要的服务端逻辑所在，而3EA0则是uimage，这两个都比较值得探究一下
UART串口调试
为什么提完固件还去焊uart呢，因为当时发现很多函数没有符号所以想去找点信息，也没有内存分布的知识(vxworks固件加载到内存的过程后面发现确实很奇怪)
总之就是想看看能不能到shell，直接看文件系统得了
首先需要拆开设备，有些设备没有螺丝只能小心的沿边找到缝隙掰开，准备好电表、电焊笔，UART转USB板子，它长这样：
然后最好要有那种塑料板，以防锡掉到桌子上了，不过这里我直接使用路由器自己的塑料外壳，准备不周，但也不是不能用，哈哈
对UART串口每个口的判别
黄色箭头指向的就是串口了
首先准备好电表，黑色的是接COM处，红色笔只要接电压档就好，可以用来测电阻的
（推荐插好电源以后直接操作插座的开关，而不是去插拔设备电源来做断电操作）
注意到有个小三角，暂时不知道那是什么，问了一下做电子信息产业的表哥，他说这个代表pin 1
断电测连通性(蜂鸣档位)
首先不通电，把万用表转到蜂鸣档，然后尝试去测4个口对某个焊点（有的大块金属部件也可以）的连通性，在这里第二个口跟其他的点是有连通性的，说明这是GND
第一个口滴了一声就没了，这就是VCC
记住那个焊点(or部件)的位置，等下还要用
通电测电势差(用20V测，提醒一下这个初中的知识)
然后通电，测量焊点(or部件)跟四个口的电势差：
VCC：3.3V固定
GND：0V
RX：0V(少数案例是3.3V)
TX：于0~3.3V之间变化，等待一段时间(0~10s)就会有了
可以直接推断四个口是什么，并且，顺便得到一个清晰的表格以供下次继续使用：
再度断电操作
这样看来，小三角指向的1口是VCC，下次可以参考
焊接
这里需要买一些杜邦线的公线，先别管那么多，焊上去先
最好先让焊笔包上一层薄薄的锡，然后再伸笔加热焊点周围，最后再滴锡上去，小心假焊情况，最好多焊久点看看锡液体能不能继续漏进去
还有就是第一次使用电焊笔可能会冒烟，这是正常现象，云母第一次遇到高温的现象
请无视下面滴出来的锡，哈哈
Serial串口连接
刚开始由于之前逆向固件得到了一些字符串，比如bootargs的波特率为115200，
导致这里陷入了小的困局，怎么尝试都是乱码
不过，后面一个接一个地尝试，最后得到是57600的波特率可以连上调试串口，真是非常让人意想不到的波特率
进入U-Boot成功，可惜是个阉割shell，不过有mem的dump功能，也有tftp传出指定内存区域的功能，甚至还能查看内存分配区域
tftp的内存转储出来的功能
之前通过简单的逆向了解到，F114这个主要流程的文件，加载基地址是0x80001000
由于转储出来的时候，偶尔会有断联现象，直接传出整个文件失败率极高，所以慢慢分片传出来
tftp -put 192.168.1.100 profile0.bin 80000000 100000
tftp -put 192.168.1.100 profile1.bin 80100000 100000
tftp -put 192.168.1.100 profile2.bin 80200000 100000
tftp -put 192.168.1.100 profile3.bin 80300000 100000
tftp -put 192.168.1.100 profile4.bin 80400000 100000
tftp -put 192.168.1.100 profile5.bin 80500000 100000
...最后，合并传出来的文件，就是80000000-80?00000内存区域的转储
按道理，整个文件被加载进内存，总会有些痕迹可以看到的吧，但这个没有，是一堆混乱布置的内存，而且后面还有些发现证实其布置确实是混乱的
mem的dump功能
这个功能让我看到vxworks系统内存加载的特殊性，它不是一整个elf直接加载到内存中的，
分段1
分段2
显然，这些程序的片段如果是整体加载进内存的，那么其在内存中dump出来的地址与文件中的地址应始终保持固定的偏移量
但这里，并没有，这就尴尬了，说明vxworks加载到内存是分片的，乱序的，dump内存没有用。。。
所以这也解释了为什么，前面通过tftp传出固定内存区域的文件，就不是一个完整的文件
mcb(内存缓存块)
那些大的内存块实际上都装入的是js代码，html代码，没有执行时使用动态内存管理装入的代码，暂时没有查看的价值
逆向分析
IDA8.3也识别不出来，还需要手动指定mipsel 大端序
然后指定完大端序,发现还有坑
假设填写此处加载地址、rom起始地址为默认的0x0，就会这样，很多代码片段的分析出现了引用区域的错误，进而导致ida认为这并不是代码段
(p.s. IDA 7.x版本需要划定一部分区域然后按c->force转成代码，而IDA 8.3会先对整个文件进行是否为代码的扫描所以不用)
这个无从考究，uart串口shell里没写，dump出来的内存也没有指示，但是，最后通过不断尝试和推测，发现在0x80001000处加载是最为正确的
中间有极少数的引用错误不管它，这部分是引用了更高地址存储的数值，可我一直都找不到另一个文件在哪，自然就不知道更高地址的这些数值是怎么回事了
符号表的寻找(失败，只能直接逆向)
要想逆向工程更加顺利，就必须要寻找符号表。
网上主流的寻找符号表方式有三种：
1.binwalk直接识别
这位师傅的文章里的固件没有被压缩，确实可以这样找，但被压缩以后是找不到的。后来甚至binwalk了一下解压出来的所有文件，仍然不行
2.寻找bzero字符串
不行
不仅如此，别的函数也找了一下，没有
基本上可以断定，解压出来的文件不包含任何符号表
uimage(3EA0)
尝试很多次，发现起始地址居然是0x80010000
有些解压逻辑，其实也没有太多作用，唉
主要逻辑(F114)
看来只能在没有符号表的情况下逆向工程了
然后就是使用了一下gpt辅助逆向，知道了一些库函数
a1是soap_auth函数的唯一参数，是一个指针；a1+272存放soap鉴权的内容
其余的逻辑其实没有找到，直到最后发现一件事，
其实后台的功能实现居然基本上全都在前端js上，js负责了鉴权、管理员权限操作等行为，实现了一个参数systool用于执行系统命令，但关于ping、tracert、reboot的交互应该是写死的？这个得再行分析
后端代码的静态编译+加载到内存的随机化+抹掉了符号表，使得进一步的分析好难，断断续续看了好些天于是暂时放弃先，等以后更清楚这个系统再回来看吧
http://ba1100n.tech/stroage/F114.idb
类似版本的分析
实际上唯一一个没有加密的，能够参考的版本，是2010年左右MW300R推出的V1版本，那个里面其实好像有漏洞而且没有被提交，但是年代过于久远，已经没什么人用，而且后面比对了一下发现跟现在分析的固件虽说骨架一样，其实差异挺大的
固件仿真(失败)
有真机，可以直接黑盒，不过由于拿不到root shell，所以还是尝试固件仿真一下吧
这个跟能够被修复的固件仿真不太一样，FAT-plus这里直接就解析不了vxworks，作罢
黑盒测试+js逆向
登录验证(可绕过次数进行爆破？)
这里是唯一一个没有鉴权的操作点，而且我发现一个隐藏的安全问题，鉴权的参数似乎有迹可循？分别使用了不同的密码发起登录，其id生成规律似乎有一些固定模式
如果能够逆向出该参数在前端如何生成，那么我们可以进行无限次数的密码爆破，因为我们可以在下面的接口去尝试是否正确，而无需触发密码尝试次数上限
只可惜直到黑盒开始，时间已经有点紧迫了，目前为止我还没有分析出来qwq
在验证密码的页面执行了这一行代码：
跟踪该方法到class.js
这个是鉴权用的值，也是我们提交的id值：
b是pwd，这个我们无法提取获知，但是如果是重复尝试的话或许可以
最最核心的鉴权算法还是在Query.js上面
比如贯穿全机器的对id认证方式：auth
看这段代码，就知道了其实是这样验证的：
前端收到用户的认证信息(包含密码，上面的”a/b”)->编码、加密为id值->发往后端验证->后端利用存储的真正密码去加密，比对两边的id值是否为真->返回
坏消息是，我们很难绕过其加密算法去完成想做的事情
好消息则是，我们知道密码就等于掌握了一切权限(废话哈哈)
第二个好消息是，我们已经知道了id的算法，可以自己生成id(只需要知道authInfo[3]和authInfo[4]代表什么)
请注意这行代码：
一个猜想：只要爆破id，就不需要经过前面那个认证页面了，估计不会失败十次锁2小时，
这个是每次周期性地更改密钥的时候发生的事情，由换行符\r\n来切分
然后尝试看看是不是真的不限制爆破次数
但是跟踪不到任何字符。。。
那就直接往某些操作上提交几十次错误的id试试
比如这里有个抓到的包，用来ping的
然后在浏览器上退出登录
然后往之前ping包的id灌输乱写的数据，正常来说，10次就会触发锁定2小时，但是
点击了几次，大概就发送几十个包了，虽然的确触发了该错误，但该错误仅仅停留在这个输入密码的页面上
但是我们密码算法就能直接往id提交参数，如果错误了，还会像之前一样返回401，并且附带拼接到密码算法上的一些值(authInfo[3]和authInfo[4]分别对应右边返回的第11行和第12行)
这恰恰说明鉴权逻辑仍然被执行着，在知晓密码算法以后，我们确实可以通过某种方式去绕过爆破的
b就是a，a就是那个函数被传入的密码，把密码拼接到中间，然后用完全已知的securityencode方法，即可生成session号码，再通过
显然这样生成的就是id的值
综上，可绕过后台页面那个限制来进行id的爆破，从而破解后台口令，但我不知道这个算不算是漏洞，而且目前暂没有利用过
敏感操作
鉴权机制
这台机器的鉴权其实做得很好，任何操作前都需要验证”id”参数，而id参数是由一个比较长的字符串进行某种变换得到的，而且该id值实际上是借助密码和每隔大概一分钟变化一次的时间戳，一起计算而成的
不登录的话，其实会发现没有什么可以测的，所有操作都要鉴权，所以接下来假设我们已经有了登录后台的权限
看看有没有越权或者rce什么的
看到这里，当然是希望那边能够实现一些命令拼接什么的，
首先抓包分析一下，原来厂商自己实现了一个systools
没过多久，重放一样的包，却是失效了
所以这个id值会隔一段时间跳变一次，这对抵抗重放攻击来说是个很好的方法
修改密码
实际上，在修改验证密码时使用的是对用户公开的参数，搭配到securityEncode
前言
家里有两台不用的路由器，型号分别是水星的MW313R和MW325R，曾经只会php之流的web安全、一些二进制安全知识的时候，想试下能不能对这些路由器做点什么，但感觉这个路由器好像还挺安全的样子，实际上最近几个月才知道，这是c写的后端，而且没有连数据库，常规的方法当然打不通
明明看起来这个系列路由器后台页面写的比较简陋，在网上却丝毫没有关于它们的漏洞，
一个都没有？这让我更加好奇了，所以经过之前的学习，最近终于鼓起勇气尝试尽可能地按已有的水平去分析一下
最后还是穷尽了此时自己知道的办法，只是知道可以绕过次数限制进行爆破，目前其它的东西还没挖出来，谨以此文复盘一下，之后还会回来再试试的
MW325R和MW313R，这些MW3XXR系列的机器，使用着同一套源自于MW300R的系统，下文主要采用MW313R进行研究
固件提取+解包
网络下载
驱动天空www.drvsky.com有固件可以直接下载到，本来，无需焊电路板(可后面还是焊了，等下解释为什么)
解包
刚开始看-Me出来的文件结果，以为加密还是怎么了，因此学习了一阵子镜像是怎么解密并解压到内存，并实际分析以后，才恍然大悟，这不是加密，binwalk对vxworks这一种RTOS的解包就是这样的
可以看到，vxworks后面有好多个LZMA的压缩文件，会直接使用内存的位置来命名文件，binwalk无法去恢复其文件系统的结构和文件名(即使这里面有个jffs2文件系统)。不过这没关系，实际上有一个最大的文件，叫做F114，网上的教程一般就是取出最大的那个二进制文件去分析，这部分一般包含着主要逻辑
全是没有文件名的文件
F114是主要的服务端逻辑所在，而3EA0则是uimage，这两个都比较值得探究一下
UART串口调试
为什么提完固件还去焊uart呢，因为当时发现很多函数没有符号所以想去找点信息，也没有内存分布的知识(vxworks固件加载到内存的过程后面发现确实很奇怪)
总之就是想看看能不能到shell，直接看文件系统得了
首先需要拆开设备，有些设备没有螺丝只能小心的沿边找到缝隙掰开，准备好电表、电焊笔，UART转USB板子，它长这样：
然后最好要有那种塑料板，以防锡掉到桌子上了，不过这里我直接使用路由器自己的塑料外壳，准备不周，但也不是不能用，哈哈
对UART串口每个口的判别
黄色箭头指向的就是串口了
首先准备好电表，黑色的是接COM处，红色笔只要接电压档就好，可以用来测电阻的
（推荐插好电源以后直接操作插座的开关，而不是去插拔设备电源来做断电操作）
注意到有个小三角，暂时不知道那是什么，问了一下做电子信息产业的表哥，他说这个代表pin 1
断电测连通性(蜂鸣档位)
首先不通电，把万用表转到蜂鸣档，然后尝试去测4个口对某个焊点（有的大块金属部件也可以）的连通性，在这里第二个口跟其他的点是有连通性的，说明这是GND
第一个口滴了一声就没了，这就是VCC
记住那个焊点(or部件)的位置，等下还要用
通电测电势差(用20V测，提醒一下这个初中的知识)
然后通电，测量焊点(or部件)跟四个口的电势差：
VCC：3.3V固定
GND：0V
RX：0V(少数案例是3.3V)
TX：于0~3.3V之间变化，等待一段时间(0~10s)就会有了
可以直接推断四个口是什么，并且，顺便得到一个清晰的表格以供下次继续使用：
再度断电操作
这样看来，小三角指向的1口是VCC，下次可以参考
焊接
这里需要买一些杜邦线的公线，先别管那么多，焊上去先
最好先让焊笔包上一层薄薄的锡，然后再伸笔加热焊点周围，最后再滴锡上去，小心假焊情况，最好多焊久点看看锡液体能不能继续漏进去
还有就是第一次使用电焊笔可能会冒烟，这是正常现象，云母第一次遇到高温的现象
请无视下面滴出来的锡，哈哈
Serial串口连接
刚开始由于之前逆向固件得到了一些字符串，比如bootargs的波特率为115200，
导致这里陷入了小的困局，怎么尝试都是乱码
不过，后面一个接一个地尝试，最后得到是57600的波特率可以连上调试串口，真是非常让人意想不到的波特率
进入U-Boot成功，可惜是个阉割shell，不过有mem的dump功能，也有tftp传出指定内存区域的功能，甚至还能查看内存分配区域
tftp的内存转储出来的功能
之前通过简单的逆向了解到，F114这个主要流程的文件，加载基地址是0x80001000
由于转储出来的时候，偶尔会有断联现象，直接传出整个文件失败率极高，所以慢慢分片传出来
tftp -put 192.168.1.100 profile0.bin 80000000 100000 tftp -put 192.168.1.100 profile1.bin 80100000 100000 tftp -put 192.168.1.100 profile2.bin 80200000 100000 tftp -put 192.168.1.100 profile3.bin 80300000 100000 tftp -put 192.168.1.100 profile4.bin 80400000 100000 tftp -put 192.168.1.100 profile5.bin 80500000 100000 …
最后，合并传出来的文件，就是80000000-80?00000内存区域的转储
按道理，整个文件被加载进内存，总会有些痕迹可以看到的吧，但这个没有，是一堆混乱布置的内存，而且后面还有些发现证实其布置确实是混乱的
mem的dump功能
这个功能让我看到vxworks系统内存加载的特殊性，它不是一整个elf直接加载到内存中的，
分段1
分段2
显然，这些程序的片段如果是整体加载进内存的，那么其在内存中dump出来的地址与文件中的地址应始终保持固定的偏移量
但这里，并没有，这就尴尬了，说明vxworks加载到内存是分片的，乱序的，dump内存没有用。。。
所以这也解释了为什么，前面通过tftp传出固定内存区域的文件，就不是一个完整的文件
mcb(内存缓存块)
那些大的内存块实际上都装入的是js代码，html代码，没有执行时使用动态内存管理装入的代码，暂时没有查看的价值
逆向分析
IDA8.3也识别不出来，还需要手动指定mipsel 大端序
然后指定完大端序,发现还有坑
假设填写此处加载地址、rom起始地址为默认的0x0，就会这样，很多代码片段的分析出现了引用区域的错误，进而导致ida认为这并不是代码段
(p.s. IDA 7.x版本需要划定一部分区域然后按c->force转成代码，而IDA 8.3会先对整个文件进行是否为代码的扫描所以不用)
这个无从考究，uart串口shell里没写，dump出来的内存也没有指示，但是，最后通过不断尝试和推测，发现在0x80001000处加载是最为正确的
中间有极少数的引用错误不管它，这部分是引用了更高地址存储的数值，可我一直都找不到另一个文件在哪，自然就不知道更高地址的这些数值是怎么回事了
符号表的寻找(失败，只能直接逆向)
要想逆向工程更加顺利，就必须要寻找符号表。
网上主流的寻找符号表方式有三种：
1.binwalk直接识别
这位师傅的文章里的固件没有被压缩，确实可以这样找，但被压缩以后是找不到的。后来甚至binwalk了一下解压出来的所有文件，仍然不行
2.寻找bzero字符串
不行
不仅如此，别的函数也找了一下，没有
基本上可以断定，解压出来的文件不包含任何符号表
uimage(3EA0)
尝试很多次，发现起始地址居然是0x80010000
有些解压逻辑，其实也没有太多作用，唉
主要逻辑(F114)
看来只能在没有符号表的情况下逆向工程了
然后就是使用了一下gpt辅助逆向，知道了一些库函数
a1是soap_auth函数的唯一参数，是一个指针；a1+272存放soap鉴权的内容
其余的逻辑其实没有找到，直到最后发现一件事，
其实后台的功能实现居然基本上全都在前端js上，js负责了鉴权、管理员权限操作等行为，实现了一个参数systool用于执行系统命令，但关于ping、tracert、reboot的交互应该是写死的？这个得再行分析
后端代码的静态编译+加载到内存的随机化+抹掉了符号表，使得进一步的分析好难，断断续续看了好些天于是暂时放弃先，等以后更清楚这个系统再回来看吧
http://ba1100n.tech/stroage/F114.idb
类似版本的分析
实际上唯一一个没有加密的，能够参考的版本，是2010年左右MW300R推出的V1版本，那个里面其实好像有漏洞而且没有被提交，但是年代过于久远，已经没什么人用，而且后面比对了一下发现跟现在分析的固件虽说骨架一样，其实差异挺大的
固件仿真(失败)
有真机，可以直接黑盒，不过由于拿不到root shell，所以还是尝试固件仿真一下吧
这个跟能够被修复的固件仿真不太一样，FAT-plus这里直接就解析不了vxworks，作罢
黑盒测试+js逆向
登录验证(可绕过次数进行爆破？)
这里是唯一一个没有鉴权的操作点，而且我发现一个隐藏的安全问题，鉴权的参数似乎有迹可循？分别使用了不同的密码发起登录，其id生成规律似乎有一些固定模式
如果能够逆向出该参数在前端如何生成，那么我们可以进行无限次数的密码爆破，因为我们可以在下面的接口去尝试是否正确，而无需触发密码尝试次数上限
只可惜直到黑盒开始，时间已经有点紧迫了，目前为止我还没有分析出来qwq
在验证密码的页面执行了这一行代码：
跟踪该方法到class.js
这个是鉴权用的值，也是我们提交的id值：
b是pwd，这个我们无法提取获知，但是如果是重复尝试的话或许可以
最最核心的鉴权算法还是在Query.js上面
比如贯穿全机器的对id认证方式：auth
看这段代码，就知道了其实是这样验证的：
前端收到用户的认证信息(包含密码，上面的”a/b”)->编码、加密为id值->发往后端验证->后端利用存储的真正密码去加密，比对两边的id值是否为真->返回
坏消息是，我们很难绕过其加密算法去完成想做的事情
好消息则是，我们知道密码就等于掌握了一切权限(废话哈哈)
第二个好消息是，我们已经知道了id的算法，可以自己生成id(只需要知道authInfo[3]和authInfo[4]代表什么)
请注意这行代码：
一个猜想：只要爆破id，就不需要经过前面那个认证页面了，估计不会失败十次锁2小时，
这个是每次周期性地更改密钥的时候发生的事情，由换行符\r\n来切分
然后尝试看看是不是真的不限制爆破次数
但是跟踪不到任何字符。。。
那就直接往某些操作上提交几十次错误的id试试
比如这里有个抓到的包，用来ping的
然后在浏览器上退出登录
然后往之前ping包的id灌输乱写的数据，正常来说，10次就会触发锁定2小时，但是
点击了几次，大概就发送几十个包了，虽然的确触发了该错误，但该错误仅仅停留在这个输入密码的页面上
但是我们密码算法就能直接往id提交参数，如果错误了，还会像之前一样返回401，并且附带拼接到密码算法上的一些值(authInfo[3]和authInfo[4]分别对应右边返回的第11行和第12行)
这恰恰说明鉴权逻辑仍然被执行着，在知晓密码算法以后，我们确实可以通过某种方式去绕过爆破的
b就是a，a就是那个函数被传入的密码，把密码拼接到中间，然后用完全已知的securityencode方法，即可生成session号码，再通过
显然这样生成的就是id的值
综上，可绕过后台页面那个限制来进行id的爆破，从而破解后台口令，但我不知道这个算不算是漏洞，而且目前暂没有利用过
敏感操作
鉴权机制
这台机器的鉴权其实做得很好，任何操作前都需要验证”id”参数，而id参数是由一个比较长的字符串进行某种变换得到的，而且该id值实际上是借助密码和每隔大概一分钟变化一次的时间戳，一起计算而成的
不登录的话，其实会发现没有什么可以测的，所有操作都要鉴权，所以接下来假设我们已经有了登录后台的权限
看看有没有越权或者rce什么的
看到这里，当然是希望那边能够实现一些命令拼接什么的，
首先抓包分析一下，原来厂商自己实现了一个systools
没过多久，重放一样的包，却是失效了
所以这个id值会隔一段时间跳变一次，这对抵抗重放攻击来说是个很好的方法
修改密码
实际上，在修改验证密码时使用的是对用户公开的参数，搭配到securityEncode
而且该securityEncode也并不是神秘的什么
这可能造成局域网内对修改密码行为的http窃听和解密（因为我们已经知道了加密算法和密钥），但这太鸡肋了
重启
有鉴权没啥问题，而且这里是没有命令注入了，我们只能以固定格式去访问，后端才会认领吧
ping & tracert 带来的rce？
暂时没找到这块逻辑，可惜，不过经过黑盒测试，注入不了命令的
而且该securityEncode也并不是神秘的什么
这可能造成局域网内对修改密码行为的http窃听和解密（因为我们已经知道了加密算法和密钥），但这太鸡肋了
大佬带带我
0day战神带带我呜呜
看iot挖0day技巧，我只看微信公众号”只关于二进制”