Anyone thought of spoofing the IP of the gateway (UDP won't care, right?) and sending your own song around the corridors? Sounds like fun
Reverse engineering a mysterious UDP stream in my hotel (2016)
171–180 of 189 posts
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#172Earlier quoted context omitted.
This is pretty much the simplest feasible way to do distributed audio over IP, and it's commonly implemented by commercial distributed audio amplifiers. The advantage of IP distributed audio is that it functions over the existing IP network, so it avoids the need to wire a high-voltage audio system (which will still require multiple amplifiers in large buildings) or dedicated signal-level wiring to distributed amplif…
I don't think multicast significantly reduces bandwidth usage. Traffic needs to go everywhere anyways. It will probably reduce CPU usage since switches (even dumb ones) can just broadcast the packet at line speed, since it's all in the hardware. There's no need for whatever server is distributing the stream to maintain multiple sockets and copy buffers multiple times.
Switches can do IGMP snooping so only clients that ask for a specific stream gets it.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#173Earlier quoted context omitted.
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)
My memory is a bit hazy on this one - but I used to run the engineering team for a company that did multicast based IPTV for hotels about ~2003 or so and I'm pretty sure the set top boxes used IGMP to control what video streams were sent to them - all devices on the fibre backbone got all the streams but each device in the rooms (connected by copper) could only handle a single stream.
So multicast doesn't necessarily mean that every device gets every packet... I think.
Also probably not worth using IGMP for audio.... :-)
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#174Earlier 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…
This is cold af. Well played.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#175You 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
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#176> 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!
The elevator music was done via UDP. The eavesdropping was done in the 0-20kHz band :)
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#177Earlier quoted context omitted.
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)
My memory is a bit hazy on this one - but I used to run the engineering team for a company that did multicast based IPTV for hotels about ~2003 or so and I'm pretty sure the set top boxes used IGMP to control what video streams were sent to them - all devices on the fibre backbone got all the streams but each device in the rooms (connected by copper) could only handle a single stream. So multicast doesn't necessarily…
It's often UDP/RTP delivery with SAP/SDP for announcement/discovery, then you use an IGMP join to attach to the stream.
The important thing about why you'd use IGMP Multicast instead of unicast is that you get a more assured latency which is important for audio sync.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#178Previously: https://news.ycombinator.com/item?id=26633792
Probably their turn to farm some karma.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#179Earlier quoted context omitted.
okay this is way over my head - but this would have to be steganography hiding in the audio file that could only be run by someone like OP, detecting; downloading; etc the udp data, right?
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.
Re: Reverse engineering a mysterious UDP stream in my hotel (2016)
#180The 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…
>> 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 license. Then the speakers would just be plain speakers with a FM receiver attached - no more wifi/wired infrastructure involved, routers, ability of the speakers to connect to the wifi, ...