Reverse-engineering the UniFi inform protocol • Hacker News Board

Re: Reverse-engineering the UniFi inform protocol

#31

Post by ImPostingOnHN » Mon, Mar 09, 2026, 4:57 PM UTC

scottlamb wrote: post #30

ImPostingOnHN wrote: post #28

Earlier quoted context omitted.

If you want to bypass Unifi Protect, what sort of "adoption" are you thinking of? AFAIK, "adoption" is a Unifi Protect thing. Otherwise it's just a device on your network that you can configure Frigate etc. to connect to and pull streams.

Changing the credentials for web access (firmware upgrade, janky jpeg-based live stream, etc.) and ssh access from the default ubnt:ubnt. Surprisingly, I don't see a page for this in the web UI, and the `password` command in the CLI is ineffective. I haven't looked around the filesystem. Setting where it sends the video stream. Configuring video settings, zone detections, etc. I found a video going through them here:…

You want to change the credentials of the camera, so Frigate can log into it while it is connected to your Unifi network?

I did that for 5 different cameras yesterday, you're saying Unifi's cameras doesn't allow user management? That sucks!

> No, it connects to you!

I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?

Re: Reverse-engineering the UniFi inform protocol

#32

Post by scottlamb » Mon, Mar 09, 2026, 5:03 PM UTC

ImPostingOnHN wrote: post #31

scottlamb wrote: post #30

Earlier quoted context omitted.

Changing the credentials for web access (firmware upgrade, janky jpeg-based live stream, etc.) and ssh access from the default ubnt:ubnt. Surprisingly, I don't see a page for this in the web UI, and the `password` command in the CLI is ineffective. I haven't looked around the filesystem. Setting where it sends the video stream. Configuring video settings, zone detections, etc. I found a video going through them here:…

You want to change the credentials of the camera, so Frigate can log into it while it is connected to your Unifi network? I did that for 5 different cameras yesterday, you're saying Unifi's cameras doesn't allow user management? That sucks! > No, it connects to you! I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?

> I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?

Right, that's the expectation of Frigate, my own Moonfire NVR, and basically every other NVR out there. Ubiquiti decided to think different.

Re: Reverse-engineering the UniFi inform protocol

#33

Post by ImPostingOnHN » Mon, Mar 09, 2026, 5:06 PM UTC

scottlamb wrote: post #32

ImPostingOnHN wrote: post #31

Earlier quoted context omitted.

You want to change the credentials of the camera, so Frigate can log into it while it is connected to your Unifi network? I did that for 5 different cameras yesterday, you're saying Unifi's cameras doesn't allow user management? That sucks! > No, it connects to you! I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?

> I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)? Right, that's the expectation of Frigate, my own Moonfire NVR, and basically every other NVR out there. Ubiquiti decided to think different.

Well thanks for the heads-up to avoid their cameras.

Re: Reverse-engineering the UniFi inform protocol

#34

Post by devilbunny » Mon, Mar 09, 2026, 5:13 PM UTC

opengrass wrote: post #25

Controller uses way to much RAM compared to OpenWISP and good luck if a device is EOL. Lots of $10 USG-3P's out there.

FWIW, the USG-3P is listed as supported by OpenWRT.

Re: Reverse-engineering the UniFi inform protocol

#35

Post by [deleted] » Mon, Mar 09, 2026, 5:15 PM UTC

baconomatic wrote: post #27

bxbdbehdbdb wrote: post #26

I don't quite get the reason for sniffing the packets. Wouldn't it be simpler to just run multiple VMs on one host to be multi tenant?

It would definitely be simpler, however the routing issue still stands. You would need to have a public IP for every VM, which is getting less practical. The MAC-based proxy makes it so we only need one IP and we can worry about the routing within our platform instead.

[deleted]

Re: Reverse-engineering the UniFi inform protocol

#36

Post by myself248 » Mon, Mar 09, 2026, 5:35 PM UTC

mrweasel wrote: post #11

It seems like a pretty tall order, but I really want an open source access point controller daemon that knows how to provision and manage a wide variety of APs from different manufacturers. So you'd have one services that can provision Ubiquity, MikroTik, TPLink and other APs and manage the clients.

Alternately, run OpenWRT on the APs themselves, and then you just need one provisioning protocol.

Re: Reverse-engineering the UniFi inform protocol

#37

Post by ThePowerOfFuet » Mon, Mar 09, 2026, 5:41 PM UTC

bastawhiz wrote: post #22

paulddraper wrote: post #14

Earlier quoted context omitted.

What does an admin do about NextDNS blocks?

If you subscribe to the mindset of "new domains are likely to be bad" you just deal with a steady stream of allowlist requests from your users until the end of time. There will be new domains until the end of time, and site owners shouldn't be doing anything extra (imo) to justify their existence to admins. If you use a firewall voluntarily and that firewall blocks sites that are legitimate, that's on you, not the si…

>If you subscribe to the mindset of "new domains are likely to be bad" you just deal with a steady stream of allowlist requests from your users until the end of time.

Newly-registered domains are not generally an issue with enterprise users. However, they are overrepresented in malicious traffic due to domain-generation algorithms (DGAs).

Re: Reverse-engineering the UniFi inform protocol

#38

Post by moonlighter » Mon, Mar 09, 2026, 5:45 PM UTC

ImPostingOnHN wrote: post #31

scottlamb wrote: post #30

Earlier quoted context omitted.

Changing the credentials for web access (firmware upgrade, janky jpeg-based live stream, etc.) and ssh access from the default ubnt:ubnt. Surprisingly, I don't see a page for this in the web UI, and the `password` command in the CLI is ineffective. I haven't looked around the filesystem. Setting where it sends the video stream. Configuring video settings, zone detections, etc. I found a video going through them here:…

You want to change the credentials of the camera, so Frigate can log into it while it is connected to your Unifi network? I did that for 5 different cameras yesterday, you're saying Unifi's cameras doesn't allow user management? That sucks! > No, it connects to you! I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?

Unifi cams don't stream RTSP, they stream FLV v1 (FlashVideo) on 3 streams over plain TCP on port 7550, one per quality channel. And yes, they stream that TO the NVR who adopted them only... then the NVR recodes and sends RTSP (configurable).

For the adoption stage, UniFi cameras broadcast on UDP port 10001 using a proprietary TLV (Type-Length-Value) protocol. The Protect console listens on this port and picks up new cameras immediately. 4 bytes `\x01\x00\x00\x00` sent as UDP broadcast to `255.255.255.255:10001`

The response then contains these fields:

  | Hex Code | Field | Data |
  |----------|-------|------|
  | `0x01` | MAC Address | 6-byte hardware address |
  | `0x02` | MAC + IP | Combined MAC and IPv4 address |
  | `0x03` | Firmware Version | String |
  | `0x0B` | Hostname | String |
  | `0x0C` | Platform (Short Model) | String |
  | `0x0A` | Uptime | 64-bit integer |
  | `0x13` | Serial | String |
  | `0x14` | Model (Full) | String |
  | `0x17` | Is Default | Boolean (adopted vs unmanaged) |

After discovery, the Protect console: 1. Connects to the camera via SSH (default credentials) 2. Configures the Inform URL (TCP 8080) 3. Camera registers with the controller

So conceivably at step 2 you could use your own modified URL to point to your own NVR and then grab the FLV streams from there.

Re: Reverse-engineering the UniFi inform protocol

#39

Post by slacka » Mon, Mar 09, 2026, 6:03 PM UTC

bastawhiz wrote: post #22

paulddraper wrote: post #14

Earlier quoted context omitted.

What does an admin do about NextDNS blocks?

If you subscribe to the mindset of "new domains are likely to be bad" you just deal with a steady stream of allowlist requests from your users until the end of time. There will be new domains until the end of time, and site owners shouldn't be doing anything extra (imo) to justify their existence to admins. If you use a firewall voluntarily and that firewall blocks sites that are legitimate, that's on you, not the si…

Sounds like a massive waste of your time for NextDNS admins and a poor UX for end users. If your security relies on trusting old domains, then you need to rethink your security. Also, I bet it's just as easy for you to accidentally whitelist a bad actors as to blacklist a good one. What am I missing here?

Re: Reverse-engineering the UniFi inform protocol

#40

Post by roywashere » Mon, Mar 09, 2026, 6:04 PM UTC

baconomatic wrote: post #27

bxbdbehdbdb wrote: post #26

I don't quite get the reason for sniffing the packets. Wouldn't it be simpler to just run multiple VMs on one host to be multi tenant?

It would definitely be simpler, however the routing issue still stands. You would need to have a public IP for every VM, which is getting less practical. The MAC-based proxy makes it so we only need one IP and we can worry about the routing within our platform instead.

but it is http! why can't you do virtual hosting on a reverse proxy?