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.
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 who can decode the steganography, it would be a covert listening device.
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.
There's a very simple way around this. Grab any encoding that uses a dictionary, like, I think zip does. Sent tiny zip files with an excerpt of a .wav file or something that needs to be compressed.
The decompressed data is always the same, but the data in the dictionary used is where you store your sneaky bits.
Sure, that's still mildly suspicious. But way less than the actual music data changing all the time.
You could also hide the bits in eg timing of package transmission or omiting an expected package every once in a while, it'll just look like udp dropped a package.
You can use a channel with lots of noise, because you can use error correcting codes to to restore the intended message.
(To elaborate with an example: sometimes a package might already drop randomly, or timings might be slightly delayed anyway.)
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.
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.
I know next to nothing about steganography, beyond the general concept, so please excuse my ignorance if I'm way off base, but couldn't you design the encoding system such that you could encode the same amount of data within the time frame of each loop, with only some portion of the new data containing real data (audio recording)?
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 :)
Basically, you'd use steganography to hide that you send a message. And that message would be encrypted. You can use almost any standard encryption scheme, as long as you remove headers etc. Any ciphertext of a crypto-system worth its salt will be indistinguishable from random noise without the key.
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.... :-)
The best red herring would be to publish a blog post a couple years before you do this, where the author concludes that the traffic is harmless 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!