[HN Gopher] Reverse engineering a mysterious UDP stream in my ho...
___________________________________________________________________
Reverse engineering a mysterious UDP stream in my hotel (2016)
Author : nop_slide
Score : 509 points
Date : 2023-02-23 16:06 UTC (6 hours ago)
(HTM) web link (www.gkbrk.com)
(TXT) w3m dump (www.gkbrk.com)
| niels_bom wrote:
| TIL about BibTex, very cool.
|
| https://en.wikipedia.org/wiki/BibTeX
| thimkerbell wrote:
| 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.
| flying_sheep wrote:
| This is a piece of good _Hacker_ news. Nice job
| kibwen wrote:
| _> But what was this audio? Was this a sneakily placed bug that
| listened to me? [...] I can't believe I spent time for this. It's
| just 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!
| 867-5309 wrote:
| came here to say the same! but then the multicast would make
| less sense.. unless that was a complementary red herring
| blueberrychpstx wrote:
| 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?
| unwind wrote:
| 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.
| koolba wrote:
| 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.
| sublinear wrote:
| > 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.
| ajsnigrutin wrote:
| 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 :)
| jessaustin wrote:
| Previously:
|
| https://news.ycombinator.com/item?id=26633792
| dang wrote:
| Thanks! Macroexpanded:
|
| _Reverse engineering a mysterious UDP stream in my hotel
| (2016)_ - https://news.ycombinator.com/item?id=26633792 - March
| 2021 (86 comments)
|
| _Reverse Engineering a Mysterious UDP Stream in My Hotel
| (2016)_ - https://news.ycombinator.com/item?id=16197436 - Jan
| 2018 (15 comments)
|
| _Reverse Engineering a Mysterious UDP Stream in My Hotel_ -
| https://news.ycombinator.com/item?id=11744518 - May 2016 (181
| comments)
| graiz wrote:
| Would have been more entertainig if he had broadcast his own UDP
| music. Perhaps the 8bits were some checksum to prevent such
| hackery?
| maxloh wrote:
| What will the elevator speaker do if it received 2 music
| packets instead of 1?
| lagniappe wrote:
| It's UDP, so it'd probably take it, or at most silently
| discard one, by my guess
| t0bia_s wrote:
| Site is blocked by NextDNS.
| radicality wrote:
| Which rules? Works for me on Nextdns. I have the "NextDNS Ads &
| Trackers", and "Adguard DNS" blocklists enabled, and I think
| also enables every non-beta feature under Security.
| t0bia_s wrote:
| Energized Blu Go
| dark-star wrote:
| this could use a "(2016)" in the title....
| dang wrote:
| Added. Thanks!
| RektBoy wrote:
| Time for new elevator music :)
| ValtteriL wrote:
| I wonder what brand of elevators were using this scheme
| pfoof wrote:
| The question is: why? Why distribute the music that way, why not
| just attach it to a radio directly, or some RPi that will pull
| the stream, or just have it prerecorded.
|
| Despite its simplicity, seems to be overengineered.
| anyfoo wrote:
| > Why distribute the music that way
|
| Because distributing music over multicast works very well, and
| it's rather simple in nature: You get audio frames as UDP
| packets, you play them. Because it's multicast, they reach
| where they should.
|
| > why not just attach it to a radio directly
|
| Because you lose control of what's being played, and there are
| probably not many "elevator music" radio stations.
|
| > or some RPi that will pull the stream
|
| Because then every location that plays the music has to pull an
| individual stream, quickly saturating the bandwidth for no
| reason, instead of just subscribing to the multicast stream.
|
| I also would not say "some RPi" is less engineering, and less
| maintenance, than the current solution that likely uses an off
| the shelf multicast audio system.
|
| > or just have it prerecorded
|
| Because you lose control of what's being played without a
| significant replacement step, when you could just play a
| multicast stream instead.
|
| > Despite its simplicity, seems to be overengineered.
|
| I'm honestly not convinced I read a less "overengineered"
| solution so far...
| hot_gril wrote:
| > I'm honestly not convinced I read a less "overengineered"
| solution so far...
|
| Prerecorded music on an MP3 player sounds like the one
| simpler solution, though it wouldn't put the elevators in
| sync with each other or let you control it remotely.
| anyfoo wrote:
| 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...
| hot_gril wrote:
| Yeah, this is if you just want your playlist on loop
| 24/7, which seems reasonable in some scenarios.
| snickerbockers wrote:
| those suggestions all seem way more over-engineered than just
| using multicast packets
| moffkalast wrote:
| Science isn't about why, it's about why not!
| jcrawfordor wrote:
| 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 amplifiers. It also tends to be more reliable as
| the IP network is more robust to issues like crosstalk and poor
| connections that can turn into frustrating troubleshooting on
| analog systems.
|
| "Some RPi that pulls the stream" is exactly what this system is
| except it uses multicast for significantly reduced bandwidth
| usage and the receivers are presumably commercially-supported
| distributed audio equipment. No hotel wants to be doing patch
| management for embedded Linux devices.
| kalmi10 wrote:
| This sounds like an easy way to keep the players in sync. That
| is important if you have multiple players nearby each other on
| the same corridor.
| 0xDEF wrote:
| What is the historical reason we don't have true multicast on the
| Internet when it works fine on local networks?
| Dowwie wrote:
| The digital equivalent of a beach metal detector enthusiast
| matzf wrote:
| Metal detector _ists_!
|
| Ah no, oops, you had it right, force of habit ;)
| TomK32 wrote:
| Spring is coming up, the perfect time to re-watch
| Detectorists.
| hackernewds wrote:
| "Metal detectives" perhaps?
| penguin_booze wrote:
| "Did you find gold?"
|
| "Oh for fuck's sake".
| boucher wrote:
| I'm not sure if the habit is because of the show or not, but
| I wanted to note for anyone who might be reading that
| "Detectorists" is a really charming British show that I
| highly recommend.
| ornornor wrote:
| Ohw hellow thayre! It's a pretty good show indeed.
| matzf wrote:
| Yes, it was supposed to be a reference to the show, glad
| you picked up on it.
| dagurp wrote:
| Pub?
| hnthrowaway0315 wrote:
| Does that mean someone can hijack the stream and play some end of
| world audios?
| ChrisMarshallNY wrote:
| Sounds possible, but you'll have to deal with address
| contention.
|
| Play some good old Rammstein, to make your elevator journey
| more pleasant.
| clbrmbr wrote:
| Maybe send unicast replies at a high rate to the transmitter
| so as to crash it or at least show down it's stream so you
| can take over?
| andy_ppp wrote:
| Or the sound of an elevator jamming...
| lb1lf wrote:
| 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...
| hot_gril wrote:
| Hey, they should test with separate CDs. Not your fault
| at all. Ok, maybe a little.
| bdhcuidbebe wrote:
| [flagged]
| srejk wrote:
| I'm pretty sure 50Hz is electricity, not gas.
| lb1lf wrote:
| Back in the nineties, it was a prank.
| ChrisMarshallNY wrote:
| I attended the 1989 MackHack[0]. I had the Oscar The
| Grouch trash can hack.
|
| I also wired all our Macs to run the Energizer Bunny
| hack. That was fun. It would have gotten me fired, a few
| years later, though.
|
| [0] https://www.washingtonpost.com/archive/business/1994/
| 06/27/t...
| dylan604 wrote:
| being in similar situations of hunting down the source of
| a hum, i hope you rot in hell ;-)
| marcodiego wrote:
| " There was obviously data in this packet and file should know
| when it sees MPEG Audio data, so I decided to write another
| Python script to save the packet data with offsets. This way it
| would save the file test1 skipping 1 byte from the packet, test2
| skipping 2 bytes and so on. Here's the code I used and the
| result."
|
| Wouldn't binwalk do just that?
| thesh4d0w wrote:
| There's a lot of those types of things in this. Why write a
| python script to receive the packets, when he just talked about
| using wireshark?
| WirelessGigabit wrote:
| So either the elevator is on the same network, or they
| misconfigured the broadcast to all networks instead of the one
| needed.
|
| First one being much worse as it shows a failure to understand
| network segregation.
| monocasa wrote:
| Eh, the sound system on the elevator being hooked up to the
| guest and entertainment network isn't really a sin in my eyes.
| jvm___ wrote:
| As long as it's segregated that way. Someone was able to gain
| access to their Dr's office's network by accessing the wifi-
| enabled fish tank thermometer.
|
| I forget if the details of how exactly they accessed it, but
| it was an example of an Internet of Things device making a
| security hole in a network.
| duskwuff wrote:
| It wasn't a doctor's office, it was a casino:
|
| https://www.washingtonpost.com/news/innovations/wp/2017/07/
| 2...
| shanebellone wrote:
| "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...
| [deleted]
| jameshart wrote:
| Until someone on the guest network starts broadcasting audio
| into the elevators
| monocasa wrote:
| To what end?
| bheadmaster wrote:
| Chaos!
| monocasa wrote:
| Rain will go up, cats will chase dogs, and the elevators
| will play acid jazz instead of smooth jazz.
| JUNGLEISMASSIVE wrote:
| [dead]
| Salgat wrote:
| 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.
| paisawalla wrote:
| Personally, even the remotest possibility of someone
| broadcasting "evacuate your rooms, there is a fire/active
| shooter in the building" seems worth spending a few hours
| protecting against.
| interstice wrote:
| This feels like one of those hypothetical attack vectors
| that has probably never happened.
|
| Although I could be wrong!
| paisawalla wrote:
| There are certainly people out there who are motivated to
| trigger false alarms in hotels:
| https://profootballtalk.nbcsports.com/2017/01/22/police-
| appr...
| gambiting wrote:
| ....why? No, honestly, why? Would you protect against
| someone running down the corridor shouting the same
| thing?
| petertodd wrote:
| It's a lot more official if it's coming from the elevator
| speakers. It's also a lot harder to track down who did
| it.
| [deleted]
| paisawalla wrote:
| > _Would you protect against someone running down the
| corridor shouting the same thing?_
|
| ...yes?
|
| Do you think hotels _aren 't_ protected, to some extent,
| against any random person putting on a blazer and
| announcing an emergency?
| gambiting wrote:
| >>Do you think hotels aren't protected, to some extent
|
| How are they protected against that, exactly? You can
| literally walk up to any fire emergency button on any
| wall on any floor, press a button and evacuate the entire
| hotel, why bother with this UDP streaming nonsense?
| password11 wrote:
| > _How are they protected against that, exactly? You can
| literally walk up to any fire emergency button on any
| wall_
|
| Cameras near fire alarms and it's a crime in the U.S. to
| give a false alarm.
| gambiting wrote:
| Right, that protects the hotel from liability, but it
| does nothing to protect the hotel from such false alarm
| happening in the first place.
| password11 wrote:
| The threat to the perpetrator -- of 90 days prison time
| and a permanent criminal record of being a mischief-maker
| -- prevents people from pulling the alarm.
|
| Same way sheepdogs herd sheep.
| paisawalla wrote:
| If a hotel could spend a few hours and definitively
| prevent misuse of the fire emergency button, they would
| do that.
| Salgat wrote:
| It'd be far more trivial to put a wireless speaker in an
| elevator than it would be to reverse engineer this.
| paisawalla wrote:
| 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.
| snickerbockers wrote:
| it's not the elevator it's, a speaker inside the elevator.
| nobody's hacking any elevators with this.
| gloyoyo wrote:
| Yes, you could zap any devices near-by
| malfist wrote:
| > shows a failure to understand network segregation
|
| Why? It's highly likely they just don't care. Which is fine.
| It's an elevator speaker.
| outworlder wrote:
| It's also highly likely that they do not care about more
| things if they do not care about this.
|
| Sure it's an elevator speaker and probably you can't do much
| (probably! 'simple' devices are packing ever more hardware).
|
| But something is _sending_ those packets. What 's that? Can
| it be hacked? What else can that device/server see? Are there
| other devices sharing the network with customers?
| anyfoo wrote:
| It's multicast, not broadcast (which means the networks could
| still be separated, among other things), and it's not too
| surprising that the network for the entertainment system
| carries this (by today's standard) low bandwidth stream.
|
| Yeah, with a better/better configured switch it could not reach
| the individual client unless it subscribed to the multicast
| stream, but again, who cares about that low bandwidth stream...
| you should not trust any hotel network anyway, those audio
| packets won't do extra harm.
| yencabulator wrote:
| Multicast, uh, finds a way.
| ww520 wrote:
| Actually the multicast audio is a pretty good system. There're
| multiple elevators. Broadcasting makes it simple to sync up the
| music on them. Using a Wifi speaker has much lower cost than
| adding a wired speaker to a moving elevator. It's also simple and
| low cost to add extra WiFi speakers in other areas of the hotel,
| creating an ad hoc PA system.
| jahewson wrote:
| Surely elevators already come with hardwired speakers?
| mike_d wrote:
| Remember that networks introduce latency. It might be tiny but
| the human ear can detect speakers being _slightly_ off.
|
| For example you wouldn't want a wifi speaker in an elevator
| using a repeater at the top of the shaft trying to match up to
| a hardwired speaker in a ground floor vestibule.
| anyfoo wrote:
| 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
| speaker.
|
| You can mitigate that by adding a precise delay to the far
| away speaker... but of course that does not work if you're
| standing on the other side. Nevertheless, as said, that
| problem is regardless of whether your speaker is network-
| connected or not.
| thfuran wrote:
| You just need to take a cue from wifi and use beam forming
| to send separately synced audio to each person.
| 9dev wrote:
| Modern wifi speakers can be configured with variable drift
| for the playback to mitigate this very issue :)
| joshvm wrote:
| Does network latency dominate over speed of sound?
| Propagation time is about 3ms / metre in open air.
| anyfoo wrote:
| It basically does not matter if you sync your clocks via
| NTP and play back accordingly.
| hot_gril wrote:
| I don't know much about audio encoding, but do the speakers
| not have to buffer the incoming packets? Large enough buffer
| size would introduce drift between speakers even if
| everything is fine network-wise.
| anyfoo wrote:
| 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.
| hot_gril wrote:
| Ah, that works. I also didn't know NTP was precise enough
| for this. Cool.
| kkielhofner wrote:
| I worked on a WiFi multicast video streaming solution and while
| it theoretically works as well and is as easy as you describe
| in practice it can be a complete nightmare.
|
| Full disclosure this was a few years ago so things may have
| improved. I also can't remember all of the specifics but there
| was a lot of low-level driver work, firmware tweaks, specific
| configurations of just about every WiFi param you can think of,
| etc.
| inferiorhuman wrote:
| Sonic used to offer mbone connectivity (including BBC
| channels) back when they were an internet service provider
| and not a web provider. It was pretty nifty but never very
| user friendly to set up.
| op00to wrote:
| 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!
| inferiorhuman wrote:
| Wikipedia had this quote from Mick Jagger:
| I wanna say a special welcome to everyone that's, uh,
| climbed into the Internet tonight and, uh, has got
| into the M-bone. And I hope it doesn't all
| collapse.
|
| What a time to be alive.
| jawadch93 wrote:
| [dead]
| larsonnn wrote:
| SPOILER ALERT:
|
| did you play it reverse? I bet there is some hidden message...
| peterleiser wrote:
| "To win the game, you must kill me, John Romero!"
|
| https://www.youtube.com/watch?v=k2IcSsoPLnI
| [deleted]
___________________________________________________________________
(page generated 2023-02-23 23:00 UTC)