Live data from Hacker News

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

gkbrk.com

111–120 of 189 posts

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

#112

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.

I think it's a trope from the second half of the 20th century (mostly the 3rd quarter).

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

#113
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!

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

#114
post #90
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…

Even better than a canned audio file would be machine generated music. Otherwise you could detect that the “same” song is being transmitted with slightly different bits. Or you could have an extremely long audio file so the repeat situation doesn’t occur.

Elevator music tends to loop.

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

#115
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

More than a red herring, the multicast could be valuable because it obscures who's actually listening. Everyone on the network is receiving these packets so there's no way to single anyone out. Seems like a great move for spy software, 100% plausible deniability. (but I really doubt that's happening here)

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

#116
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.

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…

Yeah same. Multicast can work on wired LANs. Any kind of wireless or routing and it breaks pretty quickly.

At least a while back. I haven't touched it in years.

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

#117

Earlier quoted context omitted.

Right, that protects the hotel from liability, but it does nothing to protect the hotel from such false alarm happening in the first place.

The threat to the perpetrator -- of 90 days prison time and a permanent criminal record of being a mischief-maker -- prevents people from pulling the alarm. Same way sheepdogs herd sheep.

Sure, and to circle all the way back to the original point several posts up - why is this a deterrent to someone pulling a fire alarm but not for someone sending a fake UDP broadcast? The penalty will be exactly the same.

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

#118
post #80
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.

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, and it doesn't take that long to become noticeable. And at some point you'll either start dropping out due to either buffer underflow or buffer overflow. So you do still need to take care about this.

So to work well you do need to resync the audio to the local audio clock using a sample rate converter, or build some custom hardware that lets you sync the playback audio clocks somehow. Or if you want to be sloppy about it, keep close track and stuff or drop individual samples as you drift.

But yeah, this is all more or less 'solved'.

Post reply on HN