Wheres part 2 where you start broadcasting your own elevator music?
Or moaning noises, akin to the treat airline passengers famously enjoyed last year over planes' PAs.
Reverse engineering a mysterious UDP stream in my hotel (2016)
121–130 of 189 posts
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#122Earlier quoted context omitted.
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.
Harder to track down the person. Unless the hotel is logging every packet on its network and paying to archive the TBs of encrypted video streaming data that goes through every day. And it's a purely local network, so not like the NSA can help out.
Edit:
"Unauthorized" computer access is a serious federal crime under the CFAA, and that you did it as a joke is not a legal defense. Famous examples:
(1) https://en.m.wikipedia.org/wiki/Aaron_Swartz
(2) the Florida man who social engineered Twitter (https://en.m.wikipedia.org/wiki/Graham_Ivan_Clark)
(3) the Mirai botnet guys (https://en.m.wikipedia.org/wiki/Mirai_(malware)), etc.
So the penalty will actually be much worse if you get caught.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#123Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#124Earlier quoted context omitted.
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.
Yeah, that's the problem. If the song is known either because its a previously published song or because it repeats then the bits should be the same every time the song is played. If you are adding extra data with steganography then you don't want it easy to detect because someone could make a steganography detector by testing if the same song's data seems to vary for no reason.
I guess you could also build an auto-auto-tune or auto-remix solution so the songs always have justifiable variation without needing fully generated music.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#125The 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.
It probably functions as a fire alarm and PA so having the ability to control the content is important. The hotel already has radio - Wifi.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#126Earlier 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.
If you have a legacy music system and encode it over the network, the data will vary— time bases wont line up, there will be noise, etc, even if it repeats.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#127Earlier 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…
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.
I route multicast across hundreds of routers in dozens of countries over private wires and vpns without problem.
Wireless sure, that can be a pain.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#128Earlier 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.
A fairly typical and simple approach is to set an intentional, fixed delay, say 500ms, to absorb network latency / inconsistency. The sender sends a target playback timestamp ~500ms in the future with each block of audio. Then the actual delay at the playback side can expand or contract as necessary to take up network delay. The lower you make this delay, the more care you need to take on the network side to guarantee timely delivery.
NTP is accurate enough for this, but I think most of the modern protocols in the wild e.g. AES67, AirPlay2 are using PTP. It is both more accurate and in some ways simpler for this use case.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#129Earlier 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…
True, it was definitely simplified. But yeah, in cases where you really care, there's a bunch of options to do it completely/sufficiently in sync. (A true asynchronous sample rate converter, as it would have to be here, might be a bit expensive, but simple interpolation, or even stuffing/dropping, might be sufficient for this particular use case.)
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#130Previously: https://news.ycombinator.com/item?id=26633792
Thanks! Macroexpanded: Reverse engineering a mysterious UDP stream in my hotel (2016) - https://news.ycombinator.com/item?id=26633792 - March 2021 (86 comments) Reverse Engineering a Mysterious UDP Stream in My Hotel (2016) - https://news.ycombinator.com/item?id=16197436 - Jan 2018 (15 comments) Reverse Engineering a Mysterious UDP Stream in My Hotel - https://news.ycombinator.com/item?id=11744518 - May 2016 (181 com…
I thought this story sounded familiar.