Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering the UniFi inform protocol

tamarack.cloud

Post reply on HN
Print view View original

41–50 of 81 posts

Re: Reverse-engineering the UniFi inform protocol

#41

Post by ThePowerOfFuet »

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:…

Here's that YouTube link without the creepy Google tracking component:

https://youtu.be/URam5XSFzuM?t=279

Re: Reverse-engineering the UniFi inform protocol

#43

Post by baconomatic »

cheriot wrote: post #42

This is very cool. I wonder if there's a way to control routing client side and remove the list of mac addresses. Eg manage DNS for customers (upsell ad blocking!) and CNAME the unifi entry to a customer specific vhost.

Thank you! DNS-based adoption works well for this. You point the unifi hostname at the tenant's subdomain and the Host header handles routing from there. We also have a DHCP Option 43 generator for setups where DNS isn't practical.

Re: Reverse-engineering the UniFi inform protocol

#44

Post by baconomatic »

roywashere wrote: post #40
baconomatic wrote: post #27

Earlier quoted context omitted.

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?

You definitely can once the device has a hostname set in set-inform. The MAC proxy is just for initial adoption where a device may only know the IP. Such as when you use DHCP Option 43.

Re: Reverse-engineering the UniFi inform protocol

#45

Post by bastawhiz »

slacka wrote: post #39
bastawhiz wrote: post #22

Earlier quoted context omitted.

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?

I don't disagree. The idea seems to be that newly registered domains are far more likely to be malicious (and not present on domain blocklists yet).

Re: Reverse-engineering the UniFi inform protocol

#46

Post by glottis »

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:…

Im using a g3 flex with frigate without use of unifi protect, works fine.

I think newer models like g4 flex dont support this thou.

Re: Reverse-engineering the UniFi inform protocol

#47

Post by andrewaylett »

I'm glad the payload was usable and the author has fixed their problem, it's an interesting challenge.

However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from.

Neither is necessary, though, given inspection does appear to work.

Re: Reverse-engineering the UniFi inform protocol

#48

Post by scottlamb »

moonlighter wrote: post #38
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)?

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…

Thanks!

> 1. Connects to the camera via SSH (default credentials) 2. Configures the Inform URL (TCP 8080)

Not what I expected but okay. Looks like there's a `set-inform` command. It looks like it opens a TLS connection, doesn't check the certificate, and tries to opens a websocket:

    GET /camera/1.0/ws HTTP/1.1
    Pragma: no-cache
    Cache-Control: no-cache
    Host: ...
    Origin: http://ws_camera_proto_secure_transfer
    Upgrade: websocket
    Connection: close, Upgrade
    Sec-WebSocket-Key: ...
    Sec-WebSocket-Protocol: secure_transfer
    Sec-WebSocket-Version: 13
    Camera-MAC: ...
    Camera-IP: ...
    Camera-Model: 0xa601
    Camera-Firmware: 5.0.83
    Device-ID: ...
    Adopted: false
    x-guid: be9d8e45-62a8-ae84-8b23-71723c7decaf
I might try accepting the websocket but I have a feeling I'll get stuck about there without knowing what the server is supposed to send over it. I'm debating if I'm willing to buy a Unifi Protect device or not.

...then again I did a search for a couple strings and ran across https://github.com/keshavdv/unifi-cam-proxy . It's the opposite direction of what I want (makes a standard camera work with Unifi Protect) but maybe contains the protocol details I'm looking for...

Re: Reverse-engineering the UniFi inform protocol

#49

Post by blacklion »

myself248 wrote: post #36
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.

Does it support seamless roaming of clients between group of APs?

Last time I've tried, it was not supported by any open source solution.

Re: Reverse-engineering the UniFi inform protocol

#50

Post by burgreblast »

andrewaylett wrote: post #47

I'm glad the payload was usable and the author has fixed their problem, it's an interesting challenge. However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from. Neither is nec…

I don’t get this comment. Inspection does work but the suggested alternatives don’t.

Having the client register their IPs isn’t tenable for most folks. What’s my IP at the shop? (No idea) Will it change? (Yes) now it’s broken.

Seeing where folks log in from isn’t nearly the same as where their UniFi networks are located. (Store vs home.) Broken.

So neither of the those are robust approaches whereas the author’s solution is bulletproof and simply works in all cases.

No offense, but why suggest “other approaches” that have such major holes? Why not just cheer on the solution that works all the time?

Post reply on HN