Hacker News 中文摘要

RSS订阅

逆向工程UniFi信息协议 -- Reverse-engineering the UniFi inform protocol

原文链接 | HN讨论 | 2026-03-10 02:36:40

文章摘要

文章介绍了作者通过逆向工程分析UniFi设备的inform协议，发现虽然数据负载经过AES加密，但协议头部是明文，这为构建多租户路由提供了可能。作者曾运营UniFi托管服务，但因经济性问题难以持续。

文章总结

逆向工程UniFi inform协议——Tamarack的探索之路

背景与挑战

作者曾运营UniFi控制器托管服务，为不愿自建控制器的客户提供云服务。虽然产品需求旺盛，但经济模型存在问题：每位客户需要独立VPS，导致单客户利润仅1-2美元/月，难以持续运营。

关键发现：inform协议结构

UniFi设备通过8080端口定期（每10秒）向控制器发送HTTP POST请求（inform协议）。数据包具有以下特征： 1. 头部明文：前40字节未加密，包含关键信息 2. 加密部分：采用AES-128-CBC加密的payload

数据包头部结构（关键字段）：

| 偏移量 | 长度 | 说明 | |--------|------|------| | 0 | 4B | 魔数"TNBU"（UBNT倒写） | | 8 | 6B | 设备MAC地址（明文） | | 18 | 16B | AES初始化向量 |

技术突破

通过分析发现： - 设备MAC地址在加密前即可读取（字节8-13） - 控制器需要MAC地址来查找对应设备的解密密钥 - 这一设计使得无需解密即可实现流量路由

实现方案

作者开发了约200行Go代码的代理服务： 1. 读取数据包前14字节提取MAC地址 2. 通过MAC-租户映射表路由流量 3. 完整转发原始数据包（保持加密状态）

text 设备 → 代理（MAC识别） → 对应租户控制器

其他端口处理

| 端口 | 协议 | 处理方式 | |-------|--------|-------------------------| | 8443 | HTTPS | 子域名反向代理 | | 3478 | STUN | 共享coturn实例 | | 其他 | | 容器内部或L2层隔离 |

商业价值

该方案使得： - 共享基础设施成为可能 - 单客户成本从4-6美元降至近乎零 - 利润率从1-2美元提升至可盈利水平

设计启示

Ubiquiti将MAC置于明文的初衷是功能性需求（解密前识别设备），却意外为第三方多租户路由创造了条件。这种"无心插柳"的设计展现了协议逆向工程的价值。

本文揭示了通过分析网络协议实现商业模型创新的典型案例，展示了技术细节与商业价值的深度结合。

评论总结

以下是评论内容的总结：

  1. 关于TNBU拼写错误的讨论

    • devmor指出"TNBU"是"UBNT"(UniFi Broadcast Technology)的反写错误，并调侃作者可能有阅读障碍。
    • 引用："TNBU is UNBT backwards" / "You might have a bit of dyslexia"

  2. 界面可读性问题

    • voidUpdate反映在深色模式下难以阅读代码块中的文字。
    • 引用："some of the text is practically invisible" / "cannot read most of the text"

  3. UniFi摄像头协议逆向工程

    • scottlamb希望逆向工程UniFi摄像头的适配协议，以替代官方NVR设备。
    • 引用："has anyone reverse-engineered the UniFi camera adoption protocol?" / "They seem to be about the only option for a reasonably priced...camera"

  4. 开源AP控制器需求

    • mrweasel希望有一个能管理多厂商AP的开源控制器。
    • 引用："want an open source access point controller" / "provision Ubiquity, MikroTik, TPLink and other APs"

  5. 技术问题讨论

    • ctippett提到NextDNS屏蔽新注册域名，并询问MongoDB迁移到FerretDB的经验。
    • 引用："NextDNS blocked it for being newly registered" / "has anyone had success migrating from MongoDB"

  6. 设备适配方法质疑

    • CptKriechstrom质疑为何需要嗅探数据包而不是直接通过SSH设置。
    • 引用："How do you adopt the device" / "couldn't you just route the request"

  7. 资源占用批评

    • opengrass批评控制器内存占用过高，特别是对EOL设备支持差。
    • 引用："Controller uses way to much RAM" / "good luck if a device is EOL"

  8. 多租户方案建议

    • bxbdbehdbdb建议使用多VM方案替代数据包嗅探。
    • 引用："Wouldn't it be simpler to just run multiple VMs"

  9. DNS管理创新想法

    • cheriot提出通过DNS管理客户端的创新方案。
    • 引用："control routing client side" / "manage DNS for customers"

总结呈现了从拼写纠错到技术方案讨论的多角度观点，包括对现有产品的批评和改进建议，以及不同技术实现方式的讨论。