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

151–160 of 189 posts

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

#151

Post by error503 »

rerdavies wrote: post #143
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…

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.

That is one solution, and in some scenarios it might not even be noticeable, but it's basically conceding the problem and accepting a guaranteed audio dropout at the end of every 'song', since for this to work you need some dead time to ensure all buffers are drained and start the new stream.

The simplest model is a source that generates a continuous audio stream, and a sink that plays it back; adding the idea of songs complicates the model, and in some use cases might be totally inappropriate. For elevator music, sure it likely doesn't matter, and maybe you can hide it in a crossfade or something with enough metadata, but this is probably part of a system where you put audio into one device connected to the network, that might include live stuff like PA announcements, and it comes out a bunch of other ones, not a dedicated elevator music system.

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

#153

Post by burntwater »

hot_gril wrote: post #103
anyfoo wrote: post #100

Earlier quoted context omitted.

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

Yeah, this is if you just want your playlist on loop 24/7, which seems reasonable in many scenarios.

In the U.S. at least, most jurisdictions will require the music to be shut off in an emergency -- namely, if the fire alarm goes off. Audio sources commonly are required to have a relay/GPIO input that triggers the shutoff, a network command is not good enough (network switches typically not being life safety rated).

In this hotel scenario, you have one audio source that can be located in a location that can be conveniently tied into the fire alarm relay panel. Stop the audio there and you've stopped it everywhere.

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

#154

Post by leviathant »

lb1lf wrote: post #26
andy_ppp wrote: post #13

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

oh my god.

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

#155

Post by teepo »

thimkerbell wrote: post #10

I was once in a shopping center parking lot where what sounded like a private conversation was being broadcast at an al fresco dining establishment on one side. It makes you think.

Reminds me of the film "The Conversation". Check it out if you get a chance.

https://www.imdb.com/title/tt0071360/

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

#156

Post by Galanwe »

anyfoo wrote: post #139
kccqzy wrote: post #137

Earlier quoted context omitted.

There's nothing in the article that suggests that Wi-Fi is being used on the elevator. In fact I'd say most likely the elevator is using a wired Ethernet connection. It's just that the broadcast domain for the L2 network includes both the wired elevators and guest Wi-Fi.

Unless I misread, 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 (making this less of an issue, as some people in this thread thought). But this is not entirely clear to me...

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

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

#157

Post by Salgat »

paisawalla wrote: post #141
Salgat wrote: post #110

Earlier quoted context omitted.

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.

The difficulty isn't in connecting to their wifi, but rather reverse engineering this bizarre backdoor just to project your voice in the elevator.

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

#158

Post by jhugo »

Galanwe wrote: post #156
anyfoo wrote: post #139

Earlier quoted context omitted.

Unless I misread, 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 (making this less of an issue, as some people in this thread thought). But this is not entirely clear to me...

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

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

Most likely a dumb cheap switch that doesn't snoop on IGMP (or a less dumb switch that wasn't configured to snoop on IGMP) was upstream of both the OP and the device in the elevator. So the frames were being flooded since the switch doesn't know any better, and then normally ignored by OP's network stack since they didn't join that multicast group, until something like tcpdump/wireshark enables promiscuous mode.

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

#159

Post by srcreigh »

jalbertoni wrote: post #150
koolba wrote: post #90

Earlier quoted context omitted.

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.

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