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

91–100 of 189 posts

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

#91

Post by op00to »

inferiorhuman wrote: post #89
kkielhofner wrote: post #75

Earlier quoted context omitted.

I worked on a WiFi multicast video streaming solution and while it theoretically works as well and is as easy as you describe in practice it can be a complete nightmare. Full disclosure this was a few years ago so things may have improved. I also can’t remember all of the specifics but there was a lot of low-level driver work, firmware tweaks, specific configurations of just about every WiFi param you can think of, e…

Sonic used to offer mbone connectivity (including BBC channels) back when they were an internet service provider and not a web provider. It was pretty nifty but never very user friendly to set up.

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!

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

#92

Post by ajsnigrutin »

sublinear wrote: post #73
unwind wrote: post #68

Earlier quoted context omitted.

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…

> to the intended recipient who can decode the steganography Not just decode, but also decrypt. You'd probably want to encrypt not just for the secrecy, but so that the noise introduced by the steganography doesn't seem so suspicious.

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

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

#93

Post by hot_gril »

mike_d wrote: post #77
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.

Remember that networks introduce latency. It might be tiny but the human ear can detect speakers being _slightly_ off. For example you wouldn't want a wifi speaker in an elevator using a repeater at the top of the shaft trying to match up to a hardwired speaker in a ground floor vestibule.

I don't know much about audio encoding, but do the speakers not have to buffer the incoming packets? Large enough buffer size would introduce drift between speakers even if everything is fine network-wise.

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

#94

Post by hot_gril »

anyfoo wrote: post #63
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.

> Why distribute the music that way Because distributing music over multicast works very well, and it's rather simple in nature: You get audio frames as UDP packets, you play them. Because it's multicast, they reach where they should. > why not just attach it to a radio directly Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. > or some RPi that will pu…

> I'm honestly not convinced I read a less "overengineered" solution so far...

Prerecorded music on an MP3 player sounds like the one simpler solution, though it wouldn't put the elevators in sync with each other or let you control it remotely.

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

#95

Post by anyfoo »

hot_gril wrote: post #93
mike_d wrote: post #77

Earlier quoted context omitted.

Remember that networks introduce latency. It might be tiny but the human ear can detect speakers being _slightly_ off. For example you wouldn't want a wifi speaker in an elevator using a repeater at the top of the shaft trying to match up to a hardwired speaker in a ground floor vestibule.

I don't know much about audio encoding, but do the speakers not have to buffer the incoming packets? Large enough buffer size would introduce drift between speakers even if everything is fine network-wise.

Just make sure they have a large enough buffer, and buffer enough, so that all speakers can play the same frames at the same time (or with the exact delay you want for each specific speaker).

You only care about delay between the speakers, not about what latency any speaker has relative to the source.

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

#96

Post by hot_gril »

lb1lf wrote: post #26
andy_ppp wrote: post #13

Earlier quoted context omitted.

Or the sound of an elevator jamming…

This reminded me of an evil prank I did on some friends of mine when in university - CD burners had just become a thing, and at the local concert venue where we volunteered, a handful of burned CDs soon appeared at the mixing console with various music the engineers liked to listen to while getting ready for a gig. Anyway, I ripped the discs, added a nice 50Hz hum under the music and burned new copies which I then le…

Hey, they should test with separate CDs. Not your fault at all. Ok, maybe a little.

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

#97

Post by hot_gril »

anyfoo wrote: post #95
hot_gril wrote: post #93

Earlier quoted context omitted.

I don't know much about audio encoding, but do the speakers not have to buffer the incoming packets? Large enough buffer size would introduce drift between speakers even if everything is fine network-wise.

Just make sure they have a large enough buffer, and buffer enough, so that all speakers can play the same frames at the same time (or with the exact delay you want for each specific speaker). You only care about delay between the speakers, not about what latency any speaker has relative to the source.

Ah, that works. I also didn't know NTP was precise enough for this. Cool.

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

#98

Post by jahewson »

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.

Surely elevators already come with hardwired speakers?

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

#99

Post by paisawalla »

gambiting wrote: post #58
paisawalla wrote: post #51

Earlier quoted context omitted.

> Would you protect against someone running down the corridor shouting the same thing? ...yes? Do you think hotels aren't protected, to some extent, against any random person putting on a blazer and announcing an emergency?

>>Do you think hotels aren't protected, to some extent How are they protected against that, exactly? You can literally walk up to any fire emergency button on any wall on any floor, press a button and evacuate the entire hotel, why bother with this UDP streaming nonsense?

If a hotel could spend a few hours and definitively prevent misuse of the fire emergency button, they would do that.

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

#100

Post by anyfoo »

hot_gril wrote: post #94
anyfoo wrote: post #63

Earlier quoted context omitted.

> Why distribute the music that way Because distributing music over multicast works very well, and it's rather simple in nature: You get audio frames as UDP packets, you play them. Because it's multicast, they reach where they should. > why not just attach it to a radio directly Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. > or some RPi that will pu…

> I'm honestly not convinced I read a less "overengineered" solution so far... Prerecorded music on an MP3 player sounds like the one simpler solution, though it wouldn't put the elevators in sync with each other or let you control it remotely.

Yes, but if you want to do even as much as not play the music in the middle of the night, now your MP3 player needs a clock. That clock may drift, or it may drop out completely when the power goes out, unless you synchronize that clock over the network. But if you have network on your MP3 player, you may as well let it subscribe to the multicast stream instead of reading the stream from internal storage. If you do not have network, and you want to change the schedule of when your music plays, have fun to send out some maintenance crew to every single one of those devices. And don't forget any...
Post reply on HN