[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 : 990 points
Date : 2023-02-23 16:06 UTC (1 days ago)
(HTM) web link (www.gkbrk.com)
(TXT) w3m dump (www.gkbrk.com)
| mxhdrm wrote:
| Anyone thought of spoofing the IP of the gateway (UDP won't care,
| right?) and sending your own song around the corridors? Sounds
| like fun
| tablespoon wrote:
| I am disappointed he didn't include some of the music he
| captured.
| niels_bom wrote:
| TIL about BibTex, very cool.
|
| https://en.wikipedia.org/wiki/BibTeX
| c0deR3D wrote:
| Is it then possible that one can "decorate" the elevator music?
| At least at a interference level. :p
| 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.
| teepo wrote:
| Reminds me of the film "The Conversation". Check it out if you
| get a chance.
|
| https://www.imdb.com/title/tt0071360/
| flying_sheep wrote:
| This is a piece of good _Hacker_ news. Nice job
| ahepp wrote:
| You can do something similar with ffmpeg
| -stream_loop -1 -re -i gettysburg.wav -f mp3 udp://239.0.0.1:1234
|
| on one device, and ffplay -i
| udp://239.0.0.1:1234
|
| on another device.
|
| You can also play the stream with ffmpeg doing something like
| ffmpeg -i udp://239.0.0.1:1234 -f pulse default
| skhm wrote:
| I've done this to make music remotely on the CLI from my phone
| SSHd into a VPS, forwarding pulseaudio/JACK and listening to
| the stream in a browser in the background. fun times
| erdemozg wrote:
| jaw-dropped.gif
|
| Such a powerful tool... And thank you for letting us know about
| this trick.
| 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!
| amelius wrote:
| The elevator music was done via UDP. The eavesdropping was done
| in the 0-20kHz band :)
| 867-5309 wrote:
| came here to say the same! but then the multicast would make
| less sense.. unless that was a complementary red herring
| varenc wrote:
| 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)
| arethuza wrote:
| 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.... :-)
| bobdvb wrote:
| 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.
| stonegray wrote:
| 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.
| Shocka1 wrote:
| 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.
| 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.
| forgotusername6 wrote:
| 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.
| rhd wrote:
| Sounds like a great CTF challenge, will have to explore
| rurban wrote:
| 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.
| 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.
| mlyle wrote:
| 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.
| counttheforks wrote:
| Elevator music tends to loop.
| matt_heimer wrote:
| 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.
| twojacobtwo wrote:
| 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
| viciousvoxel wrote:
| Yes
| jalbertoni wrote:
| 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.
| eru wrote:
| 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.)
| srcreigh wrote:
| I always wondered why in mr robot a few scenes involve
| ripping a CD with some jpgs.
| 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.
| eru wrote:
| 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.
| 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 :)
| rhacker wrote:
| 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.
| bigiain wrote:
| Pretty sure I've never heard Brian Eno playing in an
| airport either.
| rerdavies wrote:
| 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
| eru wrote:
| The modern equivalent is probably mall music?
| sublinear wrote:
| I think it's a trope from the second half of the 20th
| century (mostly the 3rd quarter).
| 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)
| Maxburn wrote:
| I thought this story sounded familiar.
| navigate8310 wrote:
| Probably their turn to farm some karma.
| jaimex2 wrote:
| Wheres part 2 where you start broadcasting your own elevator
| music?
| AbusiveHNAdmin wrote:
| Or moaning noises, akin to the treat airline passengers
| famously enjoyed last year over planes' PAs.
| 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?
| tragomaskhalos wrote:
| Or record and broadcast yourself saying "this elevator is going
| directly to HELL" in a spooky Vincent Price voice!
| cyclotron3k wrote:
| Or David S Pumpkins music every time the doors open
| 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
| ObviousHumanGPT wrote:
| No one is going to use UDP to bug a room. They're going to encode
| the audio over prerecorded noise and broadcast on 500/600mhz, i.e
| pretend it's a stage microphone that a musician left on in their
| bag.
| 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
| hummus_bae wrote:
| [dead]
| pajko wrote:
| The port might be a reference to room 2046:
| https://m.imdb.com/title/tt0212712/
| 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 many scenarios.
| burntwater wrote:
| 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.
| hot_gril wrote:
| That makes sense, never mind the MP3 player solution
| then.
| ibz wrote:
| >> 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.
|
| Radio is still by far the simplest and most fail-safe
| solution. But not playing an existing radio station. Rather
| buying a radio transmitter, like the ones used in churches -
| strong enough to emit FM throughout the hotel, and yet not
| requiring a radio license. Then the speakers would just be
| plain speakers with a FM receiver attached - no more
| wifi/wired infrastructure involved, routers, ability of the
| speakers to connect to the wifi, ...
| anyfoo wrote:
| 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.
| 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.
| kccqzy wrote:
| 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.
| Hikikomori wrote:
| Switches can do IGMP snooping so only clients that ask for
| a specific stream gets it.
| anyfoo wrote:
| 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.
| jcrawfordor wrote:
| 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!
| berjin wrote:
| It probably functions as a fire alarm and PA so having the
| ability to control the content is important. The hotel already
| has radio - Wifi.
| 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?
| [deleted]
| indus wrote:
| piped music, tap-in and listen.
| 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?
| jcrawfordor wrote:
| 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.
| pvaldes wrote:
| Come play with us Danny,
|
| but only broadcasted in the room 147
| 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...
| AbusiveHNAdmin wrote:
| [dead]
| 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...
| andy_ppp wrote:
| This is cold af. Well played.
| dylan604 wrote:
| being in similar situations of hunting down the source of
| a hum, i hope you rot in hell ;-)
| leviathant wrote:
| oh my god.
| jojobas wrote:
| I'd have a second stream playing looped rickroll.
| 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.
| gambiting wrote:
| Sure, and to circle all the way back to the original
| point several posts up - why is this a deterrent to
| someone pulling a fire alarm but not for someone sending
| a fake UDP broadcast? The penalty will be exactly the
| same.
| password11 wrote:
| Harder to track down the person. Unless the hotel is
| logging every packet on its network and paying to archive
| the TBs of encrypted video streaming data that goes
| through every day. And it's a purely local network, so
| not like the NSA can help out.
|
| Edit:
|
| "Unauthorized" computer access is a serious federal crime
| under the CFAA, and that you did it as a joke is not a
| legal defense. Famous examples:
|
| (1) https://en.m.wikipedia.org/wiki/Aaron_Swartz
|
| (2) the Florida man who social engineered Twitter
| (https://en.m.wikipedia.org/wiki/Graham_Ivan_Clark)
|
| (3) the Mirai botnet guys
| (https://en.m.wikipedia.org/wiki/Mirai_(malware)), etc.
|
| So the penalty will actually be much worse if you get
| caught.
| 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.
| Salgat wrote:
| 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.
| paisawalla wrote:
| 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.
| Salgat wrote:
| The difficulty isn't in connecting to their wifi, but
| rather reverse engineering this bizarre backdoor just to
| project your voice in the elevator.
| 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.
| kccqzy wrote:
| 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.
| anyfoo wrote:
| 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...
| gkbrk wrote:
| > 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.
| Galanwe wrote:
| > 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?
| jhugo wrote:
| > 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.
| 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.
| error503 wrote:
| 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'.
| anyfoo wrote:
| True, it was definitely simplified. But yeah, in cases
| where you really care, there's a bunch of options to do
| it completely/sufficiently in sync. (A true asynchronous
| sample rate converter, as it would have to be here, might
| be a bit expensive, but simple interpolation, or even
| stuffing/dropping, might be sufficient for this
| particular use case.)
| rerdavies wrote:
| 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.
| error503 wrote:
| 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.
| ryanianian wrote:
| 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), but I have never
| encountered the speakers being out of sync or noticing an
| echo effect.
|
| And the speakers can use your phone's mic to scan the
| soundscape of a room to acoustically balance the sound
| when you set them up. I particularly like how consistent
| the sound volume is room-to-room even with very different
| speaker setups.
|
| IIRC they've patented their specific mechanism. So ya,
| it's solved, but it may be expensive to license.
|
| (Not affiliated with Sonos, I just have a bunch of them
| and like them a lot.)
| error503 wrote:
| 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.
| rerdavies wrote:
| 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.
| 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.
| error503 wrote:
| 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.
| 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.
| hackmiester wrote:
| Wow... that is certainly a historical artifact.
| skylanh wrote:
| BUSINESS TECHNOLOGY; "Peering Out a 'Real Time' Window",
| By Peter H. Lewis, Feb. 8, 1995
| https://www.nytimes.com/1995/02/08/business/business-
| technol...
|
| The article also indicates Internet Multicasting's "Geek
| of the Week", there's an archive at:
| https://town.hall.org/radio/Geek/ Transcripts available
| at http://opentranscripts.org/sources/geek-of-the-week/
| thefourthchime wrote:
| Yeah same. Multicast can work on wired LANs. Any kind of
| wireless or routing and it breaks pretty quickly.
|
| At least a while back. I haven't touched it in years.
| ta1243 wrote:
| 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.
| 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-24 23:02 UTC)