养猫之后，家里架起了两台监控摄像头，以供我上下班无缝赏猫。
摄像头本身有ddns功能，但想想看自家的监控摄像头可以被整个网络直接访问到，纵使有密码保护，心里还是觉得很恶心的。所以我在公司都是用vpn连回家里，在家庭内网环境中访问摄像头。
事实上两台摄像头中有一台是几年前买来看家用的，另一台是为了看猫最近新买的高分辨率版。两台摄像头并不是同一厂家出品，外形也很不相同，但神奇的是网页端管理界面竟然迷之相似，我一度以为这是同一集团不同分公司的产品。
后来经过我反复调查，发现这应该是某种现成的套件，各家厂商都在用罢了。
这个网页版管理界面做的可以说非常之 low。不说他杂乱的前端源代码，充满学生气息的界面设计，就连最重要的功能上都是严重缺失的。一个监控摄像头，竟然只有在IE下下载安装插件才能观看有声的实时直播，用 chrome 和手机浏览器都只能接收一张张的截图拼成一个幻灯片来看，声音更是甭想了。
我知道由于浏览器功能或者说 HTML 规则的限制，仅靠前端无法实现接收和播放 rtsp 直播流，但问题是服务器端也是你自家的啊，你做个 flv 直播流，做个 hls 直播流，怎么样都好，现成的库那么多，想让浏览器看个视频直播有什么难的= =
chrome 也真是讨厌，推翻 npapi 插件，又放弃了自家的 nacl 插件，跑去投奔一个不支持 socket 的 webassembly，导致我想自己写一个接收摄像头 rtsp 直播流的 chrome 插件都做不到了。虽然我也可以先写一个代理服务器，把 rtsp 流翻译成 flv 流或 hls 流，再用浏览器插件播放，可那很花功夫啊！我虽然喜欢写代码，但也会嫌麻烦的！
吐槽先放一放，说回到标题来。
从买到监控摄像头的第一天起，我就一直在担心摄像头被黑的问题。虽然我已经层层设防了，但每次进入摄像头的拍摄范围时还是时刻小心。没办法，我就是防人之心很重的人= =
想摄像头不被黑，先得知道摄像头会怎么被黑，然后才有办法防御嘛。再加上网络入侵本来就是一件对小青年很有吸引力的事，所以我开始好奇能不能入侵自己的网络摄像头。
参考这篇文章，我nmap了一下我的两台摄像头，发现并没有像作者遇到的情况那样简单的暴露出telnet端口或其他可疑端口。虽然证明我的摄像头更安全更不容易被人拿去搞ddos，但也让我更难入侵了…
直接登录不成，就从暴露出来的 http 服务器上找找线索吧。于是继续回来研究这个网页版后台。
大概看了一下，发现可能有多个服务器端程序在服务 http 请求：
看 response header 可知，服务器端的静态文件和 asp 脚本是跑在一个 http/1.0 服务器上的，返回的 server header 是厂商自定义的 “IPCamera-Web”。
另一方面，请求服务器上的 cgi 脚本或当请求返回 404 时，返回的 response 表明他的服务器使用 http/1.1 协议，此时返回的 server header 依然是厂商自定义的 “IPCamera-Web”。这个 1.1 的服务器的 200 response 总是会返回 “connection: close” header, 可见人家真的是 http/1.1 的服务器端呢。最后，当服务器请求失败返回 404 或 500 时，response 中不会携带 “connection: close” header，加上没有 content-length，也没有 chunked transfer encoding，仅从传输内容上已经无法判断这个 response 应该从何处结束了。不过从浏览器能正常访问后台页面这一点来看，1.1 的服务器端可能是发送 response 后直接断开了 connection，帮助客户端判断出了 response 的结束。不管怎么说，这最后一点使这个 1.1 服务器的实现显得很业余。业余好啊，说明代码中可能存在的安全隐患多，有助于我入侵系统。
