林越用了两天时间，把YDS-7型门锁的技术资料翻了个底朝天。
资料来源很少——YDS是深圳一家小厂的品牌，2019年就转型做安防集成方案了，门锁产品线几乎停产。官网的产品页还在，但固件下载链接全失效了。论坛上能找到的帖子大多是2018年的用户吐槽，抱怨指纹识别率低、APP经常断连。
但林越找到了他需要的东西——一份2017年批次的固件更新说明，藏在某个安防技术论坛的精华区里，发帖人ID叫“弱电老兵”。
说明文档是YDS厂方2017年9月发布的，版本号V1.0.3。更新日志的第一条写着：
“修复管理员密钥同步至云端时的字段冲突问题。”
林越盯着这行字看了很久。
“管理员密钥同步至云端”——也就是说，2017年批次的原厂固件V1.0里，管理员密钥是可以同步到云端的。V1.0.3才修复了这个“字段冲突”。
但云栖里的门锁固件版本是多少？他记得巡检时看过——V1.0。从未更新过。
他掏出平板，连上9号楼的BAN局域网，远程调取了几台门锁的固件信息。全部是V1.0。9年没升级过。
这意味着，云栖里9号楼112户的门锁，至今仍然带着V1.0的“字段冲突”——管理员密钥可以被同步到云端，而物业拥有云端后台的root权限。
换句话说，物业不仅能用管理员卡直接开门，还能通过云端把任何一户的门锁密钥复制到自己手里。而且户主改密码、重录指纹，统统没用——旧密钥永远保留在云端备份里，物业随时可以调取。
“这不叫bug，”林越低声说，“这叫后门。”
他继续往下看那份更新说明。V1.0.3修复的是“字段冲突”，说明V1.0的管理员密钥云同步功能不仅存在，还有某种异常行为。他在论坛里搜了半天，终于找到一个2018年的帖子，发帖人就是那个“弱电老兵”，标题是《YDS-7门锁V1.0固件安全隐患分析》。
帖子里写道：
“V1.0固件的管理员密钥云同步机制存在严重设计缺陷：当物业后台调用‘远程诊断’接口时，系统会将目标门锁的当前有效密钥（含业主最新设置的指纹/密码哈希值）打包上传至云端服务器。该过程无用户端提示，户主完全无感知。云端服务器保留历史密钥副本，即使户主后续修改密码，旧密钥仍可被调用开锁。”
“此外，V1.0固件未对‘远程诊断’接口做频率限制。理论上，物业后台可对任意门锁发起远程诊断请求，获取其当前密钥。整个过程不会在门锁面板上留下任何痕迹，仅在云端日志中生成一条‘diagnostic_request’记录。”
林越把这段话截图存档，又翻到帖子末尾。最后一条回复是2018年4月，有人问：“这个漏洞被修复了吗？”
楼主回复：“V1.0.3已修复。但要升级固件需要物业主动联系厂家。据我所知，很多早期项目都没升级。”
9年了。云栖里的门锁固件一次都没升级过。
是疏忽，还是故意的？
林越关掉帖子，在电脑上新建了一个文档，敲下自己的分析：
YDS-7门锁V1.0固件存在后门——
1.物业可通过“远程诊断”接口获取任意户门锁的当前有效密钥
2.业主修改密码/指纹无效，旧密钥保留在云端
3.全过程无用户端提示，仅云端留有diagnostic_request日志
4.云栖里9号楼112户门锁固件为V1.0，从未升级
5.物业后台（绿岛物业管理系统）拥有云端root权限
结论：物业可以在不接触门锁、不通知业主的情况下，复制任意一户的开锁密钥。换言之，物业手里有所有住户的“万能钥匙”。
他盯着第五行字，忽然想到一个问题——如果物业手里已经有了所有人的钥匙，那为什么失踪者失踪前一个月都“改过门锁密码”？
他翻开老周的失联名单，回忆自己查到的门锁日志。每个失踪者最后一次正常开锁记录之后，都有一个“系统重置”或“密码修改”的记录。比如孙桂兰——
他调出1102室的门锁日志，往前翻到2025年5月。有一条记录：
“2025年05月20日14:32业主修改密码（原密码失效，新密码已生效）”
5月20日。孙桂兰6月17日失踪。中间隔了不到一个月。
如果物业在后门固件的支持下已经掌握了孙桂兰的旧密码，那她改密码之后，物业需要重新通过“远程诊断”接口获取新密钥。也就是说——每次业主改密码，物业都得重新“复制”一次。
他查了云端日志的访问记录。2025年5月20日当天，后台有一条“diagnostic_request”，目标：1102室。
孙桂兰改密码的当天，物业就复制了她的新密码。
然后等了不到一个月，在6月17日凌晨，用管理员密钥开了她的门。监控恰好“故障”。之后她“自愿迁出”。
流程完全闭环了。林越终于看清了整条链路：
第一步：筛选目标——独居、社会关系薄弱、无人关注的业主。
第二步：等待或诱导业主修改门锁密码（可能是物业以“系统升级”为由通知业主改密码）。
第三步：通过后门固件远程复制新密钥。
第四步：梅雨季凌晨，利用监控“自检故障”做掩护，用管理员密钥进入住户家中。
第五步：住户从系统中“自愿迁出”，户籍注销，房产“置换”。
五步。干净利落。不留痕迹——至少不留普通巡查能发现的痕迹。
但云端有“diagnostic_request”日志。这是唯一的尾巴。
林越把文档保存好，关上笔记本。他需要进入物业后台，把那些diagnostic_request日志全部导出来。但这些日志只有管理员权限才能访问——他手里的巡检账号是只读权限，看不到云端日志。
他需要一个管理员账号。
物业后台的管理员账号一共三个：郑承渊一个，工程部主管一个，安保主管一个。工程部主管是郑承渊的人，安保主管是杜鸣。
杜鸣。
林越犹豫了很久。老周说过，杜鸣是2020年才来的，不是最初那批人。他不知道杜鸣是否牵涉其中。但到目前为止，杜鸣是他在物业里唯一觉得“可能可以信任”的人——至少他问的那些问题，杜鸣没有打太极，也没有像郑承渊那样试探。
他决定赌一把。
中午食堂吃饭的时候，林越端着餐盘坐到了杜鸣对面。
“杜哥，问你个技术问题。”
“说。”
“9号楼的门锁固件，你知道是什么版本吗？”
杜鸣嚼着饭想了一下：“V1.0？老型号了。怎么了？”
“厂商2017年就出了更新补丁，修复了好几个安全漏洞。咱们一直没升级。”
“这事儿我知道。”杜鸣放下筷子，“我跟郑经理提过好几次，说应该统一升级固件。他说经费紧张，往后排。后来就没下文了。”
“你知道V1.0有个后门吗？”
杜鸣的筷子停在半空。
“什么后门？”
林越压低声音，把“远程诊断”接口和密钥云同步的事简要讲了一遍。他没提失踪名单和门锁日志——只说了技术层面的漏洞。
杜鸣听完，脸色变了。
“你是说，物业能远程复制任何一户的钥匙？”
“对。而且业主改密码也没用，旧钥匙还在云端。”
“这他妈——”杜鸣骂了半句脏话，压住了。他看了看四周，食堂里没什么人。
“林越，”杜鸣盯着他，“你到底在查什么？”
林越沉默了几秒，然后说：“我能信你吗？”
杜鸣的眼神很直：“你先说说看，我信不信得了。”
林越从口袋里掏出一张纸——五年监控故障与门锁日志的对照表。他把纸推到杜鸣面前，用手指点了点那五行数据。
杜鸣看了三秒钟。
“操。”他说。
举报
