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

Reverse engineering a mysterious UDP stream in my hotel (2016)

gkbrk.com

Post reply on HN
Print view View original

131–140 of 189 posts

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#131

Post by ryanianian »

error503 wrote: post #118
anyfoo wrote: post #80

Earlier quoted context omitted.

You can use NTP to get the devices' clocks synced up to much better than necessary tolerance, and play back accordingly. And then you "just" have the same problems that you have with purely electrically connected, analogue speakers (which are effectively 100% in sync in terms of receiving the signal): Sound is relatively slow, and so the audio from a speaker that is far away will reach you later than the nearby speak…

Kind of. The bigger problem you will have if you try this is that the audio is not clocked by the system clock, and the audio clock is almost always free-running (and even if it were derived from the system clock, NTP et al don't generally discipline the clock itself, just the OS's presentation of it). So in the case of a long running playback (or continuous, as in this case), you will drift out of sync over time, an…

Sonos has a remarkably good implementation of all of this.

For URL-based streams they buffer and NTP to sync. For live streams (e.g. gaming) they p2p multicast and tweak the wifi params in real-time to minimize drops.

The speakers create their own wifi and use MST network heuristics to latency-min route over that versus native wifi or ethernet if you've plugged it in. Sound drops when the wifi spectrum blinks (rarely), but I have never encountered the speakers being out of sync or noticing an echo effect.

And the speakers can use your phone's mic to scan the soundscape of a room to acoustically balance the sound when you set them up. I particularly like how consistent the sound volume is room-to-room even with very different speaker setups.

IIRC they've patented their specific mechanism. So ya, it's solved, but it may be expensive to license.

(Not affiliated with Sonos, I just have a bunch of them and like them a lot.)

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#132

Post by cyclotron3k »

tragomaskhalos wrote: post #113
graiz wrote: post #21

Would have been more entertainig if he had broadcast his own UDP music. Perhaps the 8bits were some checksum to prevent such hackery?

Or record and broadcast yourself saying "this elevator is going directly to HELL" in a spooky Vincent Price voice!

Or David S Pumpkins music every time the doors open

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#133

Post by bigiain »

rhacker wrote: post #107
ajsnigrutin wrote: post #92

Earlier quoted context omitted.

This would work if the elevator music was a never-repeating stream. With most elevator music, it's a few minutes of a "song" playing on repeat 24/7, so if you recorded a few repetitions of the "song", you'd probably see also repeated packets on the network. If the music was repeating but the stream was different all the time, then steganography could be the reason :)

I haven't actually heard elevator music as much as people say it exists. In fact I don't think I've every been on an elevator that had music.

Pretty sure I've never heard Brian Eno playing in an airport either.

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#134

Post by rhd »

unwind wrote: post #68
blueberrychpstx wrote: post #67

Earlier quoted context omitted.

okay this is way over my head - but this would have to be steganography hiding in the audio file that could only be run by someone like OP, detecting; downloading; etc the udp data, right?

Today (but perhaps slightly less in 2016, not sure) you could easily imagine a microcontroller (or FPGA) with a microphone that bugs you, but encodes that audio (using steganography) onto a canned audio file of elevator music, and then sends the result over the network "in the open". To a casual observer snooping the relevant network, it would probably (as here) look as elevator music, but to the intended recipient w…

Sounds like a great CTF challenge, will have to explore

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#135

Post by hackmiester »

inferiorhuman wrote: post #101
op00to wrote: post #91

Earlier quoted context omitted.

When I worked at a core i2 .edu site, we had all the "hd" mbone tv streams. It was pretty wild considering HD was a "new" thing! Thanks for reminding me of that wonderful time!

Wikipedia had this quote from Mick Jagger: I wanna say a special welcome to everyone that's, uh, climbed into the Internet tonight and, uh, has got into the M-bone. And I hope it doesn't all collapse. What a time to be alive.

Wow... that is certainly a historical artifact.

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#136

Post by stonegray »

867-5309 wrote: post #84
kibwen wrote: post #27

> But what was this audio? Was this a sneakily placed bug that listened to me? [...] I can’t believe I spent time for this. It’s just elevator music. Joke's on you, it's a bug listening to you in your room while using steganography to merely appear to be elevator music!

came here to say the same! but then the multicast would make less sense.. unless that was a complementary red herring

The best red herring would be to publish a blog post a couple years before you do this, where the author concludes that the traffic is harmless elevator music.

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#137

Post by kccqzy »

ww520 wrote: post #66

Actually the multicast audio is a pretty good system. There're multiple elevators. Broadcasting makes it simple to sync up the music on them. Using a Wifi speaker has much lower cost than adding a wired speaker to a moving elevator. It’s also simple and low cost to add extra WiFi speakers in other areas of the hotel, creating an ad hoc PA system.

There's nothing in the article that suggests that Wi-Fi is being used on the elevator. In fact I'd say most likely the elevator is using a wired Ethernet connection. It's just that the broadcast domain for the L2 network includes both the wired elevators and guest Wi-Fi.

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#138

Post by kccqzy »

jcrawfordor wrote: post #65
pfoof wrote: post #57

The question is: why? Why distribute the music that way, why not just attach it to a radio directly, or some RPi that will pull the stream, or just have it prerecorded. Despite its simplicity, seems to be overengineered.

This is pretty much the simplest feasible way to do distributed audio over IP, and it's commonly implemented by commercial distributed audio amplifiers. The advantage of IP distributed audio is that it functions over the existing IP network, so it avoids the need to wire a high-voltage audio system (which will still require multiple amplifiers in large buildings) or dedicated signal-level wiring to distributed amplif…

I don't think multicast significantly reduces bandwidth usage. Traffic needs to go everywhere anyways. It will probably reduce CPU usage since switches (even dumb ones) can just broadcast the packet at line speed, since it's all in the hardware. There's no need for whatever server is distributing the stream to maintain multiple sockets and copy buffers multiple times.

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#139

Post by anyfoo »

kccqzy wrote: post #137
ww520 wrote: post #66

Actually the multicast audio is a pretty good system. There're multiple elevators. Broadcasting makes it simple to sync up the music on them. Using a Wifi speaker has much lower cost than adding a wired speaker to a moving elevator. It’s also simple and low cost to add extra WiFi speakers in other areas of the hotel, creating an ad hoc PA system.

There's nothing in the article that suggests that Wi-Fi is being used on the elevator. In fact I'd say most likely the elevator is using a wired Ethernet connection. It's just that the broadcast domain for the L2 network includes both the wired elevators and guest Wi-Fi.

Unless I misread, there's nothing that suggests Wi-Fi is involved at all. It rather sounds to me like the author was listening at the Ethernet port that the TV was plugged in (making this less of an issue, as some people in this thread thought). But this is not entirely clear to me...

Re: Reverse engineering a mysterious UDP stream in my hotel (2016)

#140

Post by anyfoo »

kccqzy wrote: post #138
jcrawfordor wrote: post #65

Earlier quoted context omitted.

This is pretty much the simplest feasible way to do distributed audio over IP, and it's commonly implemented by commercial distributed audio amplifiers. The advantage of IP distributed audio is that it functions over the existing IP network, so it avoids the need to wire a high-voltage audio system (which will still require multiple amplifiers in large buildings) or dedicated signal-level wiring to distributed amplif…

I don't think multicast significantly reduces bandwidth usage. Traffic needs to go everywhere anyways. It will probably reduce CPU usage since switches (even dumb ones) can just broadcast the packet at line speed, since it's all in the hardware. There's no need for whatever server is distributing the stream to maintain multiple sockets and copy buffers multiple times.

With unicast, the node originating the stream would have n times the traffic, where n is the number of devices pulling the stream. Further from the originating node in the network topology, each edge would transport as many times the traffic as there are listeners whose traffic travels along that edge. That seems very significant.

With broadcast, all the nodes and edges transport the stream only once, but you can only distribute the stream in the same (L3) network, and within that network you transport the stream even through L2 nodes and edges (i.e. network switches, cables, Wi-Fi channels) where there are no listeners at all. You could in theory repeat those broadcast packets into other networks, but you need to set that up more explicitly, and then every node and edge in that network gets the traffic, too.

With multicast, devices and effectively segments can subscribe to the stream, and all nodes and edges transport the stream at most once, and they can do so across network boundaries while retaining the same property, and using a standardized mechanism that is designed to make the traffic only go where it needs to go as much as the topology allows.

Post reply on HN