三年前，代洞我接手过一台工业设备的码漏控制板，主控芯片是代洞某国产厂商的ARM内核处理器。板子本身没问题，码漏但配套的代洞OEM引导程序里藏着一处致命的整数溢出——当设备连续运行超过248天，系统时间戳翻转，码漏看门狗直接触发重启，代洞产线停摆整整一个周末。码漏事后查原因，代洞发现那家OEM厂商的码漏代码是直接从老旧的8位MCU项目里移植过来的，时间变量还用的代洞16位无符号整数。

OEM代码漏洞从来不是码漏“有没有”的问题，而是代洞“藏在哪”的问题。这类代码通常由设备厂商外包给方案公司，码漏再经过层层裁剪、代洞拼凑、适配，最后变成谁也说不清完整逻辑的“黑盒”。你问原始开发者，他会告诉你“这模块我测过没问题”；你问集成商，他们会摊手说“我们只负责调接口”。可真正的麻烦在于，OEM代码往往拥有最高权限——它跑在系统最底层，负责初始化硬件、加载操作系统、管理安全启动，一旦出错，上层应用再安全也是白搭。

我见过最离谱的案例是一台医疗监护仪的OEM电源管理模块。代码里写死了电池电量低于5%时强制关机，但没考虑电池老化后实际容量衰减的情况。结果用了两年的设备，明明显示还有15%电量，突然就黑屏了——因为“5%”对应的实际电压值已经高于新电池的15%电量电压。护士半夜推着监护仪跑去找工程师，工程师查了三天才发现是OEM层的阈值判断压根没做温度补偿。

更隐蔽的是那些“看起来没问题”的漏洞。比如OEM驱动里常见的内存池分配策略，开发者图省事直接用了固定大小缓冲区，却忘了DMA传输长度可能超过缓冲区上限。这种问题平时不触发，一旦网络突发流量或外设异常，直接内存踩踏，系统随机死机。你复现不了，因为触发条件太苛刻——可能是某次USB插入瞬间的电气噪声恰好让控制寄存器多读了一个字节。

OEM厂商为了赶工期，很少做代码走查。他们的测试通常只覆盖“正常流程”和“预期异常”，至于边界条件、并发冲突、资源耗尽这些场景，全靠客户现场“帮忙测”。有一次我跟某方案商的技术支持对线，对方理直气壮地说：“我们这代码在别的项目上跑了三年都没事。”我回他：“那是别的项目没遇到我们这种供电环境——你们中断服务函数里居然调用了延时函数，这在我们这分分钟被高优先级中断饿死。”

所以别指望OEM厂商自己发现漏洞。他们没动机，也没压力。真正能逼他们改代码的，只有客户拿着示波器、逻辑分析仪和崩溃日志拍在桌上。可惜多数设备厂商连OEM代码的完整源码都没拿到，只有一堆二进制镜像和零散的配置文档。这种“供应商锁定”的苦果，最后都变成了产线上的停机时间、售后里的退货单，以及工程师深夜加班时骂的那句“这他妈谁写的代码”。

说到底，OEM代码漏洞的本质是信任错配——你付了钱，以为买到了可靠的底层实现，实际上买到的只是“能跑”的版本。而那些没被发现的漏洞，就像埋在混凝土里的钢筋锈蚀，等表面出现裂缝时，整栋楼已经救不回来了。