Reverse engineering a mysterious UDP stream in my hotel (2016)
111–120 of 189 posts
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#112Earlier 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.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#113Would have been more entertainig if he had broadcast his own UDP music. Perhaps the 8bits were some checksum to prevent such hackery?
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#114Earlier 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.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#115> 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
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#116Actually 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…
At least a while back. I haven't touched it in years.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#117Earlier 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.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#118Earlier 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…
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'.