上海代孕价格多少█微/信 同号█:138★0226★9370█ ████XX代孕正规网█代孕包成功█ ★█代孕包男孩█ ★█
一、说明
这几天都在做设备的协议分析，然后看到有个叫Spvmn的不懂要怎么操作才能触发其操作过程，问了测试部的同事说也没有测试文档，自己研究了一下这里做个记录。
按我现在理解，各厂商有自己的私有协议、ONVIF是世界标准协议、GB/T28181是国标；Onvif Test Tool是ONVIF协议实现的测试工具，而SPVMN是GB/T28181协议实现的测试工具。
二、环境搭建
IPC：首先需要一台支持GB/T28181（或者说有Spvmn配置）的IPC，这个是必然的。
Windows电脑：看spvmn里边的文档说只支持Windows，Linux没试过。
JDK1.5：我使用JDK1.8该问页面一直报错，换成1.5才能成功访问。下载地址点链接。
报错：org.apache.jasper.JasperException: Unable to compile class for JSP
Spvmn工具下载地址：http://7dx.pc6.com/wwb5/SPVMN.zip
下载直接解压到自己想要的目录，该工具本质是一个tomcat，里边部署了一个用于测试的jsp应用。和正常tomcat一样到bin目录点击startup.bat启动即可。
不过要注意，该tomcat默认使用8080端口，然后又启了在5060开了一个监听，所以在启动前要注意确保本机的这两个端口没被占用。
tomcat启动完成后，访问后边的链接，如果一切正常页面应如下图：http://127.0.0.1:8080/SIPStandardDebug/
三、测试操作
3.1 配置IPC上线
使用Onvif Test Tool等工具，我们都是在Onvif Test Tool等工具输入IPC的用户名密码向IPC认证。但Spvmn反过来，是在IPC中输入Spvmn的“用户名密码”，IPC向Spvmn认证。
这认证逻辑存在问题，我们后边再说，这里主要是知道是这样子就可以了。
Spvmn的“用户名密码”，存放在"webapps\SIPStandardDebug\WEB-INF\classes\SSDConfig.properties"中，主要找到这两个节区的信息
找到这些信息后，打开IPC上的Spvmn配置页面，把这些信息复制填到Spvmn页面对应的框中，然后保存启动即可。（Sip服务器就是装Spvmn的那台电脑）
此时回到Spvmn页面，依次点调测辅助面---链路管理，如无意外在弹出页面中即可看到IPC成功上线。
3.2 测试操作
第一步，点击“调测设备类型”选好要进行调测的设备，我们这里是IPC
第二步，在下面的各种操作通过点击选中自己要测试的命令，比如我这里点“向左”
第三步，点选好命令后在左下窗格中即会呈现该命令将会发送的主体报文，点击“发送消息”按钮，该命令即会向IPC发出返回结果呈现在右下窗格中。
当然协议实现除了看有消息返回外，更主要的还是要看IPC是否真的执行了相应的动作。比如我们这里发了“向左”命令，IPC是否真的有向左旋转。
四、Spvmn有可能沦为后门
4.1 原因分析
使用wireshark拦截数据包观察交互过程如下图。
IPC向Spvmn发起注册（REGISTER）请求，Spvmn回复未认证（Unauthorized），IPC通过Digest形式提交用户名密码，Spvmn回复认证成功。而后就都是Spvmn向IPC发送各种命令操控IPC（MESSAGE）。
正如我们向服务器认证，后续请求都得带session向服务器表明身份而服务器什么都不需要带一样；ipc向spvmn认证，那么后续请求上都是ipc向spvmn携带认证信息，而spvmn不会向ipc携带认证信息。（实际看来只有在上线注册时ipc向spvmn带了用户名密码，之后双方就都没带会话信息）
既然不需要认证信息的话，那是不是说，只要IPC开启spvmn，我伪装成spvmn服务器向ipc发命令ipc都会执行。而经过实验发现事实也是如此，测试代码如下可自行使用自己环境进行测试。
View Code
4.2 修复讨论
我们能不能在IPC端设定，只处理来自自身配置好的Spvmn的ip发来的命令？
答案是不可以，因为使用的是UDP协议，IP完全是可以伪造的。
在4.1的代码的请求中我们可以看到有一些应该是spvmn服务器的一些信息，我们可不可以在IPC端通过提取这些信息与spvmn配置页面中的进行比对一致才进行处理？
这应该是可以解决spvmn伪造的问题，但还存在的问题就是倘若spvmn服务器信息泄漏，那么IPC也会被控制；或者说此时spvmn的用户名密码也扮演了IPC用户名密码的角色，这增大了IPC的攻击面。另外在spvmn功能就类似操作系统的telnetd和sshd，攻击者侵入web后配置好spvmn就得到了一个天然的后门程序。
总的也就是说即便我们做了很多限制，由于spvmn是由ipc向spvmn认证的设计，还是降低了IPC的安全性。要根本地解决问题还是要修正spvmn的认证机制。
参考：
一、说明
这几天都在做设备的协议分析，然后看到有个叫Spvmn的不懂要怎么操作才能触发其操作过程，问了测试部的同事说也没有测试文档，自己研究了一下这里做个记录。
按我现在理解，各厂商有自己的私有协议、ONVIF是世界标准协议、GB/T28181是国标；Onvif Test Tool是ONVIF协议实现的测试工具，而SPVMN是GB/T28181协议实现的测试工具。
二、环境搭建
IPC：首先需要一台支持GB/T28181（或者说有Spvmn配置）的IPC，这个是必然的。
Windows电脑：看spvmn里边的文档说只支持Windows，Linux没试过。
JDK1.5：我使用JDK1.8该问页面一直报错，换成1.5才能成功访问。下载地址点链接。
报错：org.apache.jasper.JasperException: Unable to compile class for JSP
Spvmn工具下载地址：http://7dx.pc6.com/wwb5/SPVMN.zip
下载直接解压到自己想要的目录，该工具本质是一个tomcat，里边部署了一个用于测试的jsp应用。和正常tomcat一样到bin目录点击startup.bat启动即可。
不过要注意，该tomcat默认使用8080端口，然后又启了在5060开了一个监听，所以在启动前要注意确保本机的这两个端口没被占用。
tomcat启动完成后，访问后边的链接，如果一切正常页面应如下图：http://127.0.0.1:8080/SIPStandardDebug/
三、测试操作
3.1 配置IPC上线
使用Onvif Test Tool等工具，我们都是在Onvif Test Tool等工具输入IPC的用户名密码向IPC认证。但Spvmn反过来，是在IPC中输入Spvmn的“用户名密码”，IPC向Spvmn认证。
这认证逻辑存在问题，我们后边再说，这里主要是知道是这样子就可以了。
Spvmn的“用户名密码”，存放在"webapps\SIPStandardDebug\WEB-INF\classes\SSDConfig.properties"中，主要找到这两个节区的信息
找到这些信息后，打开IPC上的Spvmn配置页面，把这些信息复制填到Spvmn页面对应的框中，然后保存启动即可。（Sip服务器就是装Spvmn的那台电脑）
此时回到Spvmn页面，依次点调测辅助面---链路管理，如无意外在弹出页面中即可看到IPC成功上线。
3.2 测试操作
第一步，点击“调测设备类型”选好要进行调测的设备，我们这里是IPC
第二步，在下面的各种操作通过点击选中自己要测试的命令，比如我这里点“向左”
第三步，点选好命令后在左下窗格中即会呈现该命令将会发送的主体报文，点击“发送消息”按钮，该命令即会向IPC发出返回结果呈现在右下窗格中。
当然协议实现除了看有消息返回外，更主要的还是要看IPC是否真的执行了相应的动作。比如我们这里发了“向左”命令，IPC是否真的有向左旋转。
四、Spvmn有可能沦为后门
4.1 原因分析
使用wireshark拦截数据包观察交互过程如下图。
IPC向Spvmn发起注册（REGISTER）请求，Spvmn回复未认证（Unauthorized），IPC通过Digest形式提交用户名密码，Spvmn回复认证成功。而后就都是Spvmn向IPC发送各种命令操控IPC（MESSAGE）。
正如我们向服务器认证，后续请求都得带session向服务器表明身份而服务器什么都不需要带一样；ipc向spvmn认证，那么后续请求上都是ipc向spvmn携带认证信息，而spvmn不会向ipc携带认证信息。（实际看来只有在上线注册时ipc向spvmn带了用户名密码，之后双方就都没带会话信息）
既然不需要认证信息的话，那是不是说，只要IPC开启spvmn，我伪装成spvmn服务器向ipc发命令ipc都会执行。而经过实验发现事实也是如此，测试代码如下可自行使用自己环境进行测试。
View Code
4.2 修复讨论
我们能不能在IPC端设定，只处理来自自身配置好的Spvmn的ip发来的命令？
答案是不可以，因为使用的是UDP协议，IP完全是可以伪造的。
在4.1的代码的请求中我们可以看到有一些应该是spvmn服务器的一些信息，我们可不可以在IPC端通过提取这些信息与spvmn配置页面中的进行比对一致才进行处理？
这应该是可以解决spvmn伪造的问题，但还存在的问题就是倘若spvmn服务器信息泄漏，那么IPC也会被控制；或者说此时spvmn的用户名密码也扮演了IPC用户名密码的角色，这增大了IPC的攻击面。另外在spvmn功能就类似操作系统的telnetd和sshd，攻击者侵入web后配置好spvmn就得到了一个天然的后门程序。
总的也就是说即便我们做了很多限制，由于spvmn是由ipc向spvmn认证的设计，还是降低了IPC的安全性。要根本地解决问题还是要修正spvmn的认证机制。
参考：