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

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.

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

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

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.

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

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

When I worked at a core i2 .edu site, we had all the "hd" mbone tv streams. It was pretty wild considering HD was a "new" thing! Thanks for reminding me of that wonderful time!

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.

> there's nothing that suggests Wi-Fi is involved at all. It rather sounds to me like the author was listening at the Ethernet port that the TV was plugged in

Author here. Everything on the article was received on the guest Wi-Fi network on my laptop without plugging into anything.

> It rather sounds to me like the author was listening at the Ethernet port that the TV was plugged in

Well it's a bit of a mystery to me as well.

The thing is multicast is not anycast, you will not receive multicast traffic unless you specifically ask to join a group.

So, he would have to be actually listening somewhere in between the multicast router and the elevator?

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, and it doesn't take that long to become noticeable. And at some point you'll either start dropping out due to either buffer underflow or buffer overflow. So you do still need to take care about this.

So to work well you do need to resync the audio to the local audio clock using a sample rate converter, or build some custom hardware that lets you sync the playback audio clocks somehow. Or if you want to be sloppy about it, keep close track and stuff or drop individual samples as you drift.

But yeah, this is all more or less 'solved'.

You just need to take a cue from wifi and use beam forming to send separately synced audio to each person.

It basically does not matter if you sync your clocks via NTP and play back accordingly.

Just make sure they have a large enough buffer, and buffer enough, so that all speakers can play the same frames at the same time (or with the exact delay you want for each specific speaker).

You only care about delay between the speakers, not about what latency any speaker has relative to the source.

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.

Yes, it was supposed to be a reference to the show, glad you picked up on it.

Ohw hellow thayre! It’s a pretty good show indeed.

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 left by the CD player.

Yup. Cue frustrated sound engineers trying to debug the ground loop which only manifested itself when the CD was playing.

I never dared admit to the prank, but rather swapped the hum CDs for the originals before someone got a chance to investigate this thoroughly...

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.

Yes, but if you want to do even as much as not play the music in the middle of the night, now your MP3 player needs a clock. That clock may drift, or it may drop out completely when the power goes out, unless you synchronize that clock over the network. But if you have network on your MP3 player, you may as well let it subscribe to the multicast stream instead of reading the stream from internal storage. If you do not have network, and you want to change the schedule of when your music plays, have fun to send out some maintenance crew to every single one of those devices. And don't forget any...

With unicast, the node originating the stream would have n times the traffic, where n is the number of devices pulling the stream. Further from the originating node in the network topology, each edge would transport as many times the traffic as there are listeners whose traffic travels along that edge. That seems very significant.

With broadcast, all the nodes and edges transport the stream only once, but you can only distribute the stream in the same (L3) network, and within that network you transport the stream even through L2 nodes and edges (i.e. network switches, cables, Wi-Fi channels) where there are no listeners at all. You could in theory repeat those broadcast packets into other networks, but you need to set that up more explicitly, and then every node and edge in that network gets the traffic, too.

With multicast, devices and effectively segments can subscribe to the stream, and all nodes and edges transport the stream at most once, and they can do so across network boundaries while retaining the same property, and using a standardized mechanism that is designed to make the traffic only go where it needs to go as much as the topology allows.

anyfoo is correct but it might help to explain the implementation. Multicast IP works in cooperation with IGMP, a protocol that manages "groups" at the IP layer. In a unicast model, a device that wants a stream asks the server for the stream, and the server starts sending the stream to that device. The server maintains n outgoing connections sending n copies of the stream, one for each subscriber.

With multicast, a device that wants to receive the stream uses IGMP to join the group. The IGMP communication is not with the server, but actually with the router serving the subnetwork. Additionally, larger commercial switches usually implement "IGMP snooping" in which the switch "listens in" on IGMP sessions between its clients and the upstream router. The server maintains only one connection and sends only one copy of the stream, to a multicast group address---there are IP ranges reserved for this purpose. The router, and switches which implement IGMP snooping (or layer 3 switches, there are some variations), forward traffic to the multicast group address on any interface on which a client has used IGMP to join the group. Switches without IGMP support will just forward it on all interfaces. The result is that, at each point in the network, only one copy of the stream is handled. This has significant performance benefits for both the server and the network devices.

As the name implies, multicast is much like broadcast except that devices can opt in or out of receiving the broadcast, and network devices can use knowledge of those IGMP sessions to avoid sending multicast traffic on interfaces where no one cares to receive it. That said, multicast traffic going to network segments where it's not used is not especially harmful besides wasting some capacity on that network segment.

Unfortunately multicast is not workable over the internet for reasons which are difficult to overcome, or IPTV and other synchronous media streaming services would be far less costly to run. On an institutional network, though, multicast can be used to great effect. It's a fairly old method as well. In my first IT job we used to install the operating system on workstations by PXE booting them to an imaging tool and then multicasting the disk image across the network... this way we could do hundreds of machines at once at just about disk saturation rate. This kind of thing isn't readily achievable without the use of multicast or broadcast traffic. The tool was Norton Ghost, which has apparently supported this mode of operation since 1998!

Switches can do IGMP snooping so only clients that ask for a specific stream gets it.

It wasn't a doctor's office, it was a casino:

https://www.washingtonpost.com/news/innovations/wp/2017/07/2...

"Someone was able to gain access to their Dr's office's network by accessing the wifi-enabled fish tank thermometer"

I think you're mistaken/misremembering. It was a casino.

https://www.entrepreneur.com/business-news/a-casino-gets-hac...

That's more of an annoyance than a safety issue though. This is definitely one of those YAGNI things where it's not worth worrying about until it becomes a recurring issue, which is highly unlikely.

To what end?