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.

The elevator music was done via UDP. The eavesdropping was done in the 0-20kHz band :)

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.)

I always wondered why in mr robot a few scenes involve ripping a CD with some jpgs.

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.

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.

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)?

-edited because it didn't make sense before

Yes

> to the intended recipient who can decode the steganography

Not just decode, but also decrypt.

You'd probably want to encrypt not just for the secrecy, but so that the noise introduced by the steganography doesn't seem so suspicious.

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.

Pretty sure I've never heard Brian Eno playing in an airport either.

Tragedy.

Google sez: Music for Airports was installed at the Marine Air Terminal of New York's LaGuardia Airport for a brief period during the 1980s.

Elevator music may no longer be a thing, but apparently, airport music still is:

https://www.youtube.com/watch?v=Km0h6Ix3Zcs

I think it's a trope from the second half of the 20th century (mostly the 3rd quarter).

The modern equivalent is probably mall music?

Encryption is in another layer.

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.

You don't even have to change the audio data. Just alter the packet pace slightly to encode the data. That way a cold trace like OP's is useless.

Sounds like a great CTF challenge, will have to explore

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.

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.... :-)

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.

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.