到祸了
下单之后,过了大概三天,摄像头到祸了,成色新啊,很新啊。
拆机过程还挺简单,摄像头头部有个卡子,螺丝刀捅一下前面板之后前面板饰板会掉下来,之后镜头旁边有四颗长螺丝,拧下来之后能看到镜头和主板一体的组装,还有一条拉出来的线连接到后面板的网线和 12V 5525 圆头(网线还只接了两对双绞线,经典市电 over RJ45)

主板拆开后发现有两个空焊盘,经过查询发现同款主板还有带 SD 卡接口,凤凰端子和同轴输出等的 SKU,应该就是干这些个用的,值得关注的就是右上角四个空点和 SPI-NAND。由于拿到设备的当时没有 SPI-NAND 的底板或探针,所以只能先尝试从升级包提点东西。
原厂固件 TV
拿到设备固件之后,首先要做的是看一看有没有现成的能拿到命令执行的漏洞,但不幸的消息是,由于架构过于奇怪,而且固件版本卡的刚刚好,没有能用的漏洞。他这个系统素质还贼低(x1),默认是个固定的 IP,还得给他专门找一路由器进入网页打开 DHCP。打开 DHCP 后发现系统有个 SSH 开关,然后发现他这个 SSH 素质奇低(x2,只是开始),进去以后是个受限的厂商 Shell,有种 ChromeOS 的美,里面只有几个命令和一个 shell 指令,这个指令输入后要求你输入某华域控账号,然后扫码获取验证码才能进入 shell,显然我们不可能有这个东西,这条路就此堵死。
Serial Experiments Lain
那还能怎么办呢?只能通过万用表测一下四个空焊盘进行一个 Serial Experiments Lain,首先用通断档找到地线,然后切电压档找 VCC,然后就是 RX TX 测试环节,测出的线序上面图片中有。拿到串口之后先测试 115200 速率,成功轻松秒杀,但是看到 uboot 启动之后无法打断启动进程,于是只能开始对固件寻宝。
固件寻宝工
《Unix 痛恨者手册》
实际上,Unix文档的最佳形式往往是针对程序的目标代码运行strings命令。通过strings,你可以获得该程序所有硬编码的文件名、环境变量、未文档化的选项、晦涩难懂的错误信息等完整列表。
首先对着固件来一发 strings,发现有一些神秘变量,例如 dh_keyboard,于是直接把固件丢给 Kimi V3 和深度寻宝求索,要求它们利用 C-SKY 的工具链中的 objdump 反汇编并重建启动流程控制流,查看如何终端启动,修改启动参数。不得不说国内模型就是高素质,完全没有安全盾,让干啥就干啥,这太棒了。
AI 大哥首先寻到了如何中断启动:在 uboot 启动流程初期抠 * 键可以中断启动(素质怎么这么低 x3),同时给出一秒时间按别的键中断启动(这些搞芯片的怎么都喜欢用这些神人魔法按键,全志还有抠 2 进刷机模式),进入 uboot 之后试图设置 bootargs 启动,但应用还是没有接受到新的启动参数。于是继续丢给 AI 重建控制流,AI 发现默认状态下 bootargs 完全不起作用,于是进行了新一轮的深度寻宝。AI 重建控制流寻宝一番之后得出结论,默认情况下会读取 bootargParamsV2.txt 中的参数,并且有另一个魔法变量,mdcmdline,设置为 0 后内核会从 uboot 给出的环境变量启动(素质怎么这么低 x5),当同时设置 dh_keyboard 和 mdcmdline 为 0 并且进行一个 init=/bin/sh 之后,终于见到了系统的 shell,但这时还有两个问题,一个是设备的网口没有出来,另一个是设备每两分钟就会重启,疑似是有看门狗在大狗叫。
于是继续交给 AI 进行寻宝,它发现这个设备的安全启动流程有问题,只有 uboot 对内核和刷写时有签名校验,前一阶段引导器加载 uboot 时只有 CRC 校验,这时候之前买的探针也到了,于是让 AI 出了一版改指令直接让 RSA 验证 return,并且把固件里启动狗的功能也短路掉的固件,用 sNANDer 备份全盘之后直接进行了一个写的刷,干掉了自欺欺人牌安全启动(素质怎么这么低 x6)。
备份时一开始是人手按着探针读取,然后发现只要一松手就会掉线,在轮回几圈失败之后,从周围寻了一根宽橡皮筋绑在了拆下来的板子和探针上,制作了一个简易治具。由于橡皮筋的稳定性非常的好,因此读取时几位寻宝大能均躲在电脑一米以外,直到读取完成。
我中了嵌入式老兵的十年月读?
刷写完成之后,RSA 验证被成功干掉了,但是还是有狗会两分钟咬死 shell 并重启,继续丢给 AI 深度寻宝,让 AI 修改内核添加打印看门狗调用点的内容,拿到偏移后交给 AI,发现内核中负责读取加密模块的 mtdblock_d*ro 内核模块尝试读取 /etc/SigFilePartition 21 次,如果全都失败则直接给到用户一个 hang,让设备重启,于是对这个调用入点进行短路(素质怎么这么低 x7)。由于 RSA 校验已经被干掉,直接 tftp 传入内核启动。之后发现设备倒是不重启了,在打印重启点之后一段时间直接 hang 死。于是继续寻宝,发现这个东西触发重启后会直接进入死等状态,继续 patch 移除该功能,终于拿到了一个稳定不重启的 shell。但是 shell 中有一个🐎都没了的 busybox,没有 dd 等命令,只有可怜的几个小垃圾指令,甚至 bash 都是残缺不全的(素质怎么这么低 x8)。
但这只是噩梦的开始,之后尝试挂载 /usr 分区,因为网络和 SD 卡的内核模块在里面,如果不恢复只能靠串口慢慢敲字。直接命令行执行挂载发现系统会报错:This is a reliablve partition ,can't be mounted(浙江某企业工程师这个英语是真差,错别字多麻了)于是发现系统的内核 secboot 挂载钩子在启动时会读取 /etc/SigFilePartition 检测是否挂载的是受保护分区,如果是则阻止挂载。而系统自己的挂载会通过之前的内核模块更早的执行,早于钩子应用的时间,因此可以挂载。继续 patch 内核,干掉这个挂载钩子检测,成功挂载上了 usr 分区。(素质怎么这么低 x9)
接下来就是给他移植全功能 coremark 和 busybox,通过 tftp 命令传出原厂的 busybox,提取系统调用号,发现这个内核并没有使用主线里的系统调用号表,而是不知道谁改出来的 i386-classic 系统调用号表(他素质怎么这么低 x10),移植之后 tftp 传入设备,发现设备还有在 ELF .dhsec 段存储的 RSA1024 签名验证,内核的 exec 系统调用会拦截没有签名的二进制程序(鸿蒙&UOS:嗨嗨嗨来了老弟,你素质怎么这么低 x11)。
于是继续修补内核,对这个检查继续进行短路并 tftp 启动,终于拿到了能正常使用的环境。太恶心了
结语
只能说这个玩意的恶心程度甚至高于那些加壳的桌面程序,嵌入式老兵十年的损招全用到一个地方去了,没加壳比加壳还恶心,还得一个一个拔插桩。如果是前 AI 时代手工处理,不知道要死多少脑细胞。下一步看看能不能让这个设备启动主线内核吧,不过那是后话了。