Live data from Hacker News

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

gkbrk.com

181–189 of 189 posts

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

#182

Earlier quoted context omitted.

Yeah, this is if you just want your playlist on loop 24/7, which seems reasonable in many scenarios.

In the U.S. at least, most jurisdictions will require the music to be shut off in an emergency -- namely, if the fire alarm goes off. Audio sources commonly are required to have a relay/GPIO input that triggers the shutoff, a network command is not good enough (network switches typically not being life safety rated). In this hotel scenario, you have one audio source that can be located in a location that can be conve…

That makes sense, never mind the MP3 player solution then.

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

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

If I was in a position to be concerned, I'd keep Wireshark open and go to the elevator and see if the music was in sync/starting at the same time. If it wasn't, that would send up some red flags for me.

Again, if I were in a position to be concerned - I'd move hotels with Wireshark actively monitoring and verify the network traffic dropped when I left the WiFi range, and also what kind of UDP/network traffic was at the next hotel.

But if I were in a position to be extremely concerned, I'd probably just throw everything away to begin with, including the clothes I was wearing, buy a laptop/ new clothes, and then, after escaping out the back of one of the stores and getting picked up by a random taxi service and driven a good distance, go to a hotel without an elevator and check the Wireshark traffic.

Unless it was some sort of very sophisticated monitoring, I would hope one of these strategies would provide some answers.

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

#184
post #180
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…

>> 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. Radio is still by far the simplest and most fail-safe solution. But not playing an existing radio station. Rather buying a radio transmitter, like the ones used in churches - strong enough to emit FM throughout the hotel, and yet not requiring a radio licens…

I think this might have been a popular solution once, but my guess is that it came with its own set of problems. Hotels often being pretty big (bigger than most churches, which also tend to be relatively open structures), usage of the license free bands from other devices, audible interference (which you don't care about in ham radio or portables as long as you can still understand what's being said, but for music in a hotel even low interference is bad as soon as it's audible)... though admittedly, I have no experience with radio transmitters for that particular use case.

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

#186
post #175
post #161

You can do something similar with ffmpeg -stream_loop -1 -re -i gettysburg.wav -f mp3 udp://239.0.0.1:1234 on one device, and ffplay -i udp://239.0.0.1:1234 on another device. You can also play the stream with ffmpeg doing something like ffmpeg -i udp://239.0.0.1:1234 -f pulse default

I’ve done this to make music remotely on the CLI from my phone SSHd into a VPS, forwarding pulseaudio/JACK and listening to the stream in a browser in the background. fun times

Nice! I assume if it was over the WAN you probably had to unicast it?

I've experimented a tiny bit with the builtin pulseaudio RTP sink/source, but I've not used it extensively. I'm not sure if cutting out ffmpeg would be beneficial.

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

#188
post #179
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…

Sonos, a not so well known CIA front, did it much simpler. They hide their covert up-traffic by claiming to compress their streams to their speakers.

Install Unifi gear and watch the chaos unfold in that CIA operation.

Weirdly, my Sonos/Unifi issues are gone at the moment, but wow is it painful when you hit it.

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

#189
post #186
post #175

Earlier quoted context omitted.

I’ve done this to make music remotely on the CLI from my phone SSHd into a VPS, forwarding pulseaudio/JACK and listening to the stream in a browser in the background. fun times

Nice! I assume if it was over the WAN you probably had to unicast it? I've experimented a tiny bit with the builtin pulseaudio RTP sink/source, but I've not used it extensively. I'm not sure if cutting out ffmpeg would be beneficial.

I wrote a little post about it: https://a.skh.am/2020/08/31/tidal-ios.html

Managed to get the lag down to a usable amount for algorithmic music, but would not be suitable for playing an instrument remotely

Post reply on HN