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

61–70 of 81 posts

Re: Reverse-engineering the UniFi inform protocol

#61

Post by ImPostingOnHN »

scottlamb wrote: post #54
ImPostingOnHN wrote: post #33

Earlier quoted context omitted.

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

I hear you, but on the other hand, I'd take a bit of interop pain over supporting genocide any day. It looks like with the hints from moonlighter and from https://github.com/keshavdv/unifi-cam-proxy I'll be able to get this to work. Honestly it might be less work than some other cameras that (allegedly) speak RTSP. You'd be shocked how low-quality these implementations are. Never advancing timestamps, setting the RTP…

FWIW, there are multiple other camera brands who don't manufacture in Xinjiang (or China for that matter), like Axis or Vivotek.

Re: Reverse-engineering the UniFi inform protocol

#62

Post by Terretta »

ThePowerOfFuet wrote: post #37
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…

>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).

> Newly-registered domains are not generally an issue with enterprise users.

I take it this means enterprise users are not generally needing to do anything legit-for-work on a newly registered domain.

Enterprise clicks on newly registered domains tend to be (a) being phished or smished or cryptomined or whatever, or (b) someone reading X or Bsky or HN or ProductHunt's vibe code of the date -- things the enterprise would also like to have blocked.

Consider the CloudFlare/Proofpoint/NextDNS/etc. domain block on new domains much like updating one's HN home page to https://news.ycombinator.com/classic …

Re: Reverse-engineering the UniFi inform protocol

#63

Post by baby_souffle »

baconomatic wrote: post #60
stereo wrote: post #59

Nice hack! Would hosting controllers on individual IPv6 addresses on the same VM solve this too?

Yeah IPv6 would solve this because we wouldn't have to go through the proxy at all, since each VM could get their own. Unfortunately IPv6 isn't quite as supported as we'd like.

Ubiquity in general has had garbage support for IPv6 since the beginning.

They claimed most of their customers aren't asking for it when I pushed them on the issue years ago.

Re: Reverse-engineering the UniFi inform protocol

#64

Post by scottlamb »

ImPostingOnHN wrote: post #61
scottlamb wrote: post #54

Earlier quoted context omitted.

I hear you, but on the other hand, I'd take a bit of interop pain over supporting genocide any day. It looks like with the hints from moonlighter and from https://github.com/keshavdv/unifi-cam-proxy I'll be able to get this to work. Honestly it might be less work than some other cameras that (allegedly) speak RTSP. You'd be shocked how low-quality these implementations are. Never advancing timestamps, setting the RTP…

FWIW, there are multiple other camera brands who don't manufacture in Xinjiang (or China for that matter), like Axis or Vivotek.

I've eyed Axis cameras but they're pricy (particularly for large sensors) and don't seem to come in the turret form factor I prefer. E.g. the AXIS M4317-PLVE is a dome and $717 at newegg. Kinda a weird model actually—180/360 degree view which isn't what I'd want. But I haven't found anything that is at a price I'd like to pay myself, let alone recommend to others for home use.

Vivotek's a bit more reasonable but still. The (brand new?) Vivotek VIT04A-W is the closest I've found—1/1.8" sensor, 4MP, turret, $535 on jmac.com.

These Ubiquiti models seem really nice in terms of hardware specs and and very reasonably priced. $200 for a 1/1.8" sensor turret, $479 for a 1/1.2" sensor turret with extra AI features. Same general price bracket as Dahua, I think.

Re: Reverse-engineering the UniFi inform protocol

#65

Post by opengrass »

devilbunny wrote: post #34
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.

I must admit, it's a better choice than a Raspberry Pi.

Re: Reverse-engineering the UniFi inform protocol

#66

Post by moonlighter »

scottlamb wrote: post #51
scottlamb wrote: post #48

Earlier quoted context omitted.

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

> ...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... Actually, yes. I got lazy and just asked Claude Code to write a server, using that as a reference...and it worked. It was able to change the password and h…

There you go! I wrote a proxy server to deal with Unifi cameras and also dewarp their 360 camera streams... and used Claude Code to reverse-engineer most of what's going on. Sniff the entire network traffic between their NVRs and cams via Wireshark/TShark, grabbing the NVR's web socket streams, and also had it write a custom METAL shader pipeline native to Apple silicon to replace ffmpeg which was way too slow to deal with 5K 360 streams and dewarp them. All in a matter of hours. Amazing times ;)

Re: Reverse-engineering the UniFi inform protocol

#67

Post by FireBeyond »

baby_souffle wrote: post #63
baconomatic wrote: post #60

Earlier quoted context omitted.

Yeah IPv6 would solve this because we wouldn't have to go through the proxy at all, since each VM could get their own. Unfortunately IPv6 isn't quite as supported as we'd like.

Ubiquity in general has had garbage support for IPv6 since the beginning. They claimed most of their customers aren't asking for it when I pushed them on the issue years ago.

Yup, absolutely. I'm so annoyed by this. I haven't been able to get either my Comcast IPv6 address pool set up and usable throughout my home network (three switches and two Unifi Pro 6 WAPs, across a few VLANs), nor my HE.net tunnel.

So annoyed.

Re: Reverse-engineering the UniFi inform protocol

#68

Post by ImPostingOnHN »

scottlamb wrote: post #64
ImPostingOnHN wrote: post #61

Earlier quoted context omitted.

FWIW, there are multiple other camera brands who don't manufacture in Xinjiang (or China for that matter), like Axis or Vivotek.

I've eyed Axis cameras but they're pricy (particularly for large sensors) and don't seem to come in the turret form factor I prefer. E.g. the AXIS M4317-PLVE is a dome and $717 at newegg. Kinda a weird model actually—180/360 degree view which isn't what I'd want. But I haven't found anything that is at a price I'd like to pay myself, let alone recommend to others for home use. Vivotek's a bit more reasonable but stil…

Check secondhand. I'm finding quad sensor cams that retailed for $2k purchased off craigslist for $100. Wipe em, flash new firmware, deny all internet access at the network level, and you're good to go

Re: Reverse-engineering the UniFi inform protocol

#69

Post by psd1 »

CptKriechstrom wrote: post #13

Do I miss something? How do you adopt the device in the first place? If you have to SSH into the device and set the inform URL manually could't you just route the request based on the request hostname?

The default inform address is unifi:8080.

Every network I've set up (which is not many) has a dns search suffix handed out by dhcp. So the wap will resolve, e.g. unifi.branch.megacorp.net with zero config needed.

Re: Reverse-engineering the UniFi inform protocol

#70

Post by psd1 »

scottlamb wrote: post #54
ImPostingOnHN wrote: post #33

Earlier quoted context omitted.

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

I hear you, but on the other hand, I'd take a bit of interop pain over supporting genocide any day. It looks like with the hints from moonlighter and from https://github.com/keshavdv/unifi-cam-proxy I'll be able to get this to work. Honestly it might be less work than some other cameras that (allegedly) speak RTSP. You'd be shocked how low-quality these implementations are. Never advancing timestamps, setting the RTP…

> writing uninitialized memory framed as audio packets..., closing file descriptors then writing data to them anyway...

Thanks for the reassurance that I'm not such an incompetent dev as I feel.

Funny how companies tend to be competent at either devices or software, and rarely both. This sounds vaguely like the automotive industry.

Post reply on HN