Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gkbrk.com

Post reply on HN
Print view View original

141–150 of 189 posts

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

#141

Post by paisawalla »

Salgat wrote: post #110
paisawalla wrote: post #52

Earlier quoted context omitted.

Hotels are reasonably protected to such an attack. There are almost always cameras in the elevator, and the electronics are typically, to some extent, tamper-resistant.

It's not hard to subtly stick a small flat wireless speaker to the wall, and by the time they notice it the attack is already complete.

1. It's easier to connect to the wifi from across the street, without setting foot on the premises or showing your face on camera.

2. I'm not claiming that all attacks will be mitigated, but that this is an easy win from a cost:benefit analysis.

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

#142

Post by error503 »

ryanianian wrote: post #131
error503 wrote: post #118

Earlier quoted context omitted.

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, an…

Sonos has a remarkably good implementation of all of this. For URL-based streams they buffer and NTP to sync. For live streams (e.g. gaming) they p2p multicast and tweak the wifi params in real-time to minimize drops. The speakers create their own wifi and use MST network heuristics to latency-min route over that versus native wifi or ethernet if you've plugged it in. Sound drops when the wifi spectrum blinks (rarely…

Yeah, Sonos is very much the Apple of this space. A solid, user-friendly implementation of several pre-existing concepts into a cohesive product - no small task. I don't think the technologically important parts of this are patentable though, there's both prior art and the obviousness standard to worry about. But very much like Apple's 'rounded corners' case, they've gone after (IMO) obvious UI functionality for such a system to extract money from their competitors.

If you are just interested in the synchronized Audio-over-Ethernet part, AES67 is the industry standard, and a pretty complete open-source implementation can be found at https://github.com/bondagit/aes67-linux-daemon , though AES67 is itself a composition of existing standards, fundamentally it is mostly composed of SDP for sessions description, RTP for media, and PTP for clock sync, so you can build that out of a variety of implementations too.

For room correction you can look at https://drc-fir.sourceforge.net/ to generate FIR filter coefficients, then you can apply it in realtime with https://github.com/wwmm/easyeffects or https://github.com/HEnquist/camilladsp .

Of course some people just want it to work, then you can shell out for Sonos :p.

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

#143

Post by rerdavies »

error503 wrote: post #118
anyfoo wrote: post #80

Earlier quoted context omitted.

You can use NTP to get the devices' clocks synced up to much better than necessary tolerance, and play back accordingly. And then you "just" have the same problems that you have with purely electrically connected, analogue speakers (which are effectively 100% in sync in terms of receiving the signal): Sound is relatively slow, and so the audio from a speaker that is far away will reach you later than the nearby speak…

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, an…

Just re-sync at the start of each song. Sound propagating through air introduces ~ 1ms of latency per foot. So if tracks drift out of sync by a few milliseconds, it's no big deal.

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

#144

Post by jcrawfordor »

kccqzy wrote: post #138
jcrawfordor wrote: post #65

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

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!

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

#145

Post by twojacobtwo »

matt_heimer wrote: post #124
counttheforks wrote: post #114

Earlier quoted context omitted.

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-a…

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

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

#146

Post by rerdavies »

bigiain wrote: post #133
rhacker wrote: post #107

Earlier quoted context omitted.

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

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

#147

Post by viciousvoxel »

twojacobtwo wrote: post #145
matt_heimer wrote: post #124

Earlier quoted context omitted.

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-a…

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

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

#148

Post by rerdavies »

ryanianian wrote: post #131
error503 wrote: post #118

Earlier quoted context omitted.

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, an…

Sonos has a remarkably good implementation of all of this. For URL-based streams they buffer and NTP to sync. For live streams (e.g. gaming) they p2p multicast and tweak the wifi params in real-time to minimize drops. The speakers create their own wifi and use MST network heuristics to latency-min route over that versus native wifi or ethernet if you've plugged it in. Sound drops when the wifi spectrum blinks (rarely…

The patent actually covers a mechanism for electing a master controller for synching and storing configuration parameters. The actual process of synching audio is not covered. Not that difficult to work around the patent. But definitely easy to trip over the patent if you're not careful.

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

#149

Post by jcrawfordor »

hnthrowaway0315 wrote: post #7

Does that mean someone can hijack the stream and play some end of world audios?

We can't assume that any given hotel network is well-configured, but most enterprise networking equipment verifies the source of multicast traffic against the multicast routing tables. This means that if you simply send packets with a source address matching the real multicast source, the network devices will ignore and not forward them. This reverse-path check is a standardized part of PIM, the most common protocol that network devices use to communicate multicast groups between each other. It's also enabled by default on Cisco devices for local groups and I would assume the same of other vendors.

That said, it's considered a best practice (although not really all that common) to use ipsec or another method to provide cryptographic authentication of multicast packets. The protocol discussed here may do so.

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

#150

Post by jalbertoni »

koolba wrote: post #90
unwind wrote: 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…

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.

Post reply on HN