At least they play music. I once stayed in a Howard Johnsons Motor Lodge in Pittsburgh near CMU, where, at corridor intersections, they had speakers to generate some ambient noise to mask voices from the rooms. Most places that do this use white noise, or water sounds. But this was Pittsburgh. They were playing faint machinery noises - whirr, chunk, etc. At first I thought someone had left a PA microphone open in the boiler room or something, but no, it was deliberate.
I'm surprised public washrooms don't play music or it seems very few do. I bet so many people in stalls wait for someone to start the air dryer or turn on a tap i.e. strategic pooping. It can be a embarrassing disaster with those modern auto shutoff air hand dryers.
The toilets in Japan that have noise-making as a feature do flowing water (or urinating I guess) sounds. Still, if you believed the sound, it might be startling when you wondered how long before the person next to you dehydrated to death from over-urination. Probably like herd immunity, it's something that reaches peak utility only when it's ubiquitous.
On another note, I'm surprised to see so many comments worrying about bathroom noises in what I presume is a male-dominated forum. Do these dynamics exist in men's rooms as well? In my workplace, at least, all manner of sounds accompanying bowel movements are ignored, or, judging by occasional laughs, sometimes even encouraged.
"otohime" is how to pronounce one of the terms of address for the second daughter of the first Kamakura shogun. The Second daughter, hence, the "younger princess".
The Japanese word for sound is also pronounced "oto". So, a device which makes noise to help you be discreet...
Not sure on that, without invoking some vague talk about universal language mumble Chomsky mumble mumble. It could be by chance, but things like the kiki-bouba experiment suggest that the dice loaded, at the very least.
But things that look like cognates with Japanese do exist. Notably そう ("sou") is pronounced the same as English "so" and means roughly the same thing, at least in phrases like "is that so?" and "Make it so, Number One."
I will save everyone else the trouble of slogging through that podcast. They never actually discuss the lack of bathroom music. The lack of music in public bathrooms is mentioned a number of times but its always a jumping off point for another mini-discussion about something else tangentially related to bathrooms or music in public spaces. You can listen to the entire podcast and you will have no better understanding of the lack of music in public bathrooms.
Ugh, one of the offices I used to work in used such a white-noise "noise abatement system". It gave me terrible headaches that cleared up as soon as I started spending less time in that building. A good friend who designs buildings and such features told me this happens to 10-20% of people. The irony was that it was one of the quietest offices I'd ever worked in - nobody talked to anybody else!
Without fail, it makes everyone in the room talk more calmly, at a quieter volume. It's one of my favourite ambient albums ever (if anyone knows more of something quite like this, I'd love to hear suggestions). It even works on children, I work at a youth centre, just playing it over a relatively shitty PA can calm down an over-active morning in 5-10 minutes.
I used to work in an office which used fanless thin clients instead of normal desktop PCs. It was fantastic. Since then, normal offices filled with desktop fans have seemed almost painful to my ears. It makes a real difference by the end of the day.
To me it is the air conditioning fans that are roaring.
Today modern laptops emit almost no sound.
Also noise cancelling headphones was a good investment for me. Strange, that device created for use in helicopters proved so useful in office environment.
The hole in Schneier's story is that you can't just send them any old letter. It has to be a card that you've purchased from them.
It's not much of a revelation: "If I actively purchase a token to have something inoffensive sent to an address, why, the company will send it without verifying that the person who handed over the money is the recipient!".
It's not about getting them delivered for free. It's about targeted anonymous harassment (or a prank, depending on your point of view). See also https://shipyourenemiesglitter.com/ or http://poopsenders.com/ neither of which are free.
I fail to see a significant difference between purchasing an ant farm and using the card to anonymously send the sealed tube of ants to a victim... and just anonymously posting something yourself to the victim.
The difference is that if you're anonymously mailing ants to a person you're doing it out of malice. The bad person is the person directly responsible for sending the ants out.
The company doesn't want to mail ants to the wrong people, but they have no safeguards against it either. They're not acting out of malice, but they're peforming a malign action anyway. They're relying on your good spirit to ensure the ants end up in the right place.
There is no difference to the victim if the company sends the ants directly, or if you receive the ants and then re-post it.
This is one of those ridiculous scenarios that security folks dream up. I imagine Schneier doesn't live in a concrete bunker with a blast door, because a regular door can conceivably be broken open with a sledgehammer. The vast majority of homes do not have a sledgehammer-proof door, because it's not actually a problem. Same with the shipping of ants.
There is no difference to the victim, but there is a difference to the company. In one case they are guilty of shipping live ants to an unsuspecting victim, and in the other case they're not even related to the incident.
It would be possible to send packets to the elevator, but the elevator playing them would be another issue. If there is no authentication at all (as it it just plays all packets it receives on UDP 2046) I would imagine you would get an interesting mix of "valid" elevator music and your own "invalid" music.
On the other hand, those first 8 bytes of the packet may be some authentication/verification scheme which would have to be reverse engineered. Also, it may only play UDP packets coming from 234.0.0.2:2046, which would likely mean you would have to convince the DHCP server to assign you that address instead of its intended host.
Wasn't there an article a while back by a guy who stayed at a "smart" hotel and discovered he could turn the lights on and off in other people's rooms? If that's any indication of how this industry is treating security, I say "play some Skynyrd."
> Also, it may only play UDP packets coming from 234.0.0.2:2046, which would likely mean you would have to convince the DHCP server to assign you that address instead of its intended host.
This does not agree with my understanding.
234.0.0.2 is probably the destination address. I think if a DHCP server gave out an address in this range it would be misconfigured.
In 802.3 and 802.11 I think multicast packets are actually broadcast, so this is why you don't need to join the group.
This is not how multicast traffic works. Yes, 234.0.0.2:2046 is apparently the destination. The receivers probably just listen for this destination address and plays whatever it receives. DHCP server wouldn't matter here.
These multicast packets also aren't L2 broadcast addresses. For more info, see:
Group membership matters in multicast, although I agree probably not in this case. If there's a hub-spoke topology and you a spoofing on a leaf switch which doesn't propagate this could be a fun problem for engineering (looking up and reading about IGMP is left as an exercise for the reader)
Well, it doesn't appear that IP spoofing has been setup too well on the switches, because the switch seems to be doing what either an el cheapo switch will do, or do what Cisco switches do which is take the multicast traffic and flood it out the vlan broadcast domain.
Hell, if that's UDP traffic it doesn't necessarily even look like it requires a response, so you could spoof the source IP address and the server might not even care...
yeah and deliver some badass mixes of The girl from Ipanema. :-)
Though I wonder if he had time to look at the packets long or careful enough. Would have been interesting to inspect all these devices closer too. Were there also other sessions established maybe that could hint at controlling them? E.g. such as volume of the sound? I doubt that the actual elevator would be controlled could be controlled remotely:
> those first 8 bytes of the packet may be some authentication/verification scheme
The server could verify the auth on a per packet basis and only play the sound if it matches. There's no reason you couldn't have an authentication scheme on top of a UDP transport, you just can't rely on the tcp sequence numbering to prevent bad actors from injecting into the stream. But so what, you could implement your own thing. You could go so far as to simulate TCP over UDP if you really wanted to.
It's kind of weird for you to address him/her in the condescending tone, especially when you're not exactly correct.
You seem like someone who would be well served by a perusal of the below wikipedia page. Briefly, these packets are destined for an IP address in the 224.0.0.0/4 IP space, meaning multicast. SRC address is neither important nor verified (and since it's UDP on the same broadcast domain, there's really very little that can be done to stop the packets being processed unless the hotel has a very smart access point. They never do).
> *
It would be possible to send packets to the elevator, but the elevator playing them would be another issue. If there is no authentication at all (as it it just plays all packets it receives on UDP 2046) I would imagine you would get an interesting mix of "valid" elevator music and your own "invalid" music.*
At that point (assuming it's the kind of elevator music that uses low-intensity instrumental versions of pop hits), it would be really fun to get the original versions of the songs they're playing and sync up the position and playback rate.
That would definitely be another interesting read! I'm not a networking guy, but I definitely want to know if it is possible to stop the packets from going to their final IP? Can they be intercepted and replaced with other data?
This feels as exciting as what they do with video feeds in Hollywood movies, i.e. where the hacker puts in her own camera loops replacing live feed.
Probably difficult to intercept the packets, but since they're apparently broadcast over the whole hotel network, it would likely be straightforward to send your own out to be mixed in with the real packets and get some sick elevator glitch muzak going.
With custom equipment I bet you could listen for the packet header and broadcast a colliding signal every time a legitimate one was being sent. Since it's UDP, there would be no retry and neither the sender nor the receiver would be the wiser.
Not necessarily, the speakers could be in a different network, then they do not listen to what he sends directly. if the AP/router knows the multicast source is not in the wifi (and it probably does) it won't accept packets from there and not forward it to other networks.
Since it is multicast seeing the packet doesn't mean the path to a specific receiver goes through your network.
There was another recent post about a hotel that had android devices controlling the lights, in the entire hotel. Which had no auth protection at all. I'd bet money, it would be the same for the elevator music.
This would be the obvious follow up, then you can make your own "elevator music" and send it out. But that probably depends on understanding what's in the first 8 bytes too :-)
I was in an elevator a while ago when there was a ringing followed by a voice trying to sell PPI services (a regular source of spam in the UK). The emergency system was just an embedded phone.
In our university, some guy figured out the phone numbers of the phones in the elevators. Sometimes we'd dial that number and have a random conversation with a random person. Other times we'd dial and just listen in. Caught a few juicy tidbits of conversations between faculty, but nothing major.
In the US too - the reasoning is that it's simple and should work in a power outage as the telephone company usually can power it from the central office. Conversely, VoIP would depend on too many technologies working well to be reliable enough for emergency use.
An interesting thing to think about in elevators is who exactly the elevator phone calls, as well. In large buildings it sometimes rings a location staffed 24/7, like a security desk. In most buildings, though, for better reliability the phone actually rings a dedicated outside answering service for elevator phones. Sometimes this is provided by the manufacturer of the elevator as part of an "all-inclusive" service package, and sometimes they're hired by the property manager, but in a lot of cases the elevator company that does the maintenance programs the elevator phones to call their contracted answering service so as to ensure that they'll be the ones sent out to do the repairs. It's a bit like the plumber leaving you a fridge magnet with their 24/7 line.
At a previous employer (large .edu), we moved to VoIP several years ago but keep several PSTN lines -- including all of the emergency ones, such as for the elevator. We could have moved them to VoIP as well but we figured, in a true emergency, it was one less thing to have to worry about.
Most large cities' building codes mandate auto-start/auto-transfer backup generators for elevators in buildings over a certain height. It is sometimes possible to put critical equipment on a generator backed circuit (such as a 48-port 802.3af PoE switch providing power to phones).
This can be harder to do than it looks at first glance - the electrical cable "snake" that follows elevators up and down their shaft is frequently implemented with only POTS/cat3 grade wiring. Getting a SIP phone to work in one can require a local source of power in the elevator (usually a 120VAC to 12VDC power supply for the phone rather than PoE) and a VDSL2 bridge for 100BaseTX over the old style phone wiring.
Right, I'm talking about a plain analog phone connected to one of the ATAs on a Cisco PBX. I was doing some other work on the rack and remember a cable flag that said "ELEVATOR" :).
We seem to have a similar system in Poland. My friend was coming home once and the elevator started talking to him, trying to sell him some service. Following the moment of surprise, he managed to regain sanity fast enough to catch some of it on video.
Turns out the emergency system on this elevator is too an embedded phone...
Yep. That's standard. In a building with a PBX they are not typically assigned external numbers, but elevator phones are in general just like any other phone in the office. Maybe an automatic dial on going off-hook.
An example of why. I once worked on a team tasked with auditing the phone lines in an office building to identify potential cost savings on lines with outgoing access.
We came across two on the PBX that no one could identify. Numbers not in the internal directory. No tags in the PBX terminal. Rang them repeatedly with no answer.
So we disabled them on the grounds that if they were in use we would soon get a call from someone enquiring why their line was dead. Nothing all week. Went home for the weekend.
You can probably see how this ended, and that's (just one of the reasons) why you don't route them through your PBX.
More like an example of how their provisioning and documentation process is broken, you can absolutely have critical things on SIP (and PoE powered security cameras, etc), just don't forget to document it correctly.
Sure. Absolutely. But if they'd been straight PSTN lines the abject process failure you've correctly described wouldn't have been able to put lives at risk because we'd have had to call the telco who most assuredly would have known what the lines were for, and we wouldn't have been able to shut them off. Safety critical systems need to not rely on humans doing boring, complicated things correctly for long periods of time.
Binwalk is a great tool for finding potential files within a given binary stream: https://github.com/devttys0/binwalk
It has an incredible list of supported file types.
Binwalk is great, I love extracting stuff from big binary blobs of router firmware, or dumping all the memory on a Linux computer with LiME (https://github.com/504ensicsLabs/LiME) and using Binwalk to see what's in there!
I bet the payload is in that NES cartridge. Check the data against the NES cart header list, or just try loading it in NESticle. That's what I would have started with, rather than focusing on the meaningless LAME MP3 data.
Reminds me how surprised I was when I found out that many IP phone installations use multi-cast strictly to distribute on-hold music to all phones, instead of the phones pulling files from a server or storing it locally.
1. Multicast is 1:N so one stream can be played on all phones. Pulling the files from a server would be N:N so your network bandwidth would be consumed unnecessarily due to all the phones streaming the same data. Also, the phones are going to have limited memory so storing music locally is not going to scale well (phone memory is a cost that gets multiplied by N phones).
2. Synchronization, especially for the elevator scenario: if the music outside the elevator door isn't synchronized to the music inside the elevator, it will be rather disconcerting.
BTW, I suspect the streaming audio you saw was "background music" that could be played from the phones speakers. "Ambiance audio" would tie in with #2 synchronization; having adjacent phones playing unsynchronized "ambiance audio" would also be jarring.
Music on hold will be inserted by the PBX (head end), not the individual phones. Inserting "music on hold" by the phone would mean that music would be sent by the PBX to the phone back to the PBX and then to the "on hold" line where having the PBX insert it involves only the link from the PBX to the "on hold" line.
Yeah, it's efficient and easy to update. Was just surprised since applications for multicast crossing subnet borders are fairly scarce, so I guess multicast routing got configured just for that, and is one of these things you don't see mentioned very often. Thanks for the details!
Not hold music - I don't know of a single PBX (IP or otherwise) where hold is accomplished in the phone - but many phone systems can do background music and paging, this would be a great use for multicast.
The story is the journey, and there is no story without suspense. The URL is the dust jacket- some people are going to see the URL even before the title. No one said anything about clickbait. Any URL without the spoiler is better.
Me too. I had a friend who was convinced that he's being attacked when a steady stream of UDP packets started reaching his router for days. Asked him to open it in VLC and it turned out to be local news from his ISP's misconfigiured IPTV service.
It's the same data as the MP3 data he found, just truncated at a different offset. Apparently it doesn't take much to make `file` think it's detecting an NES ROM.
As someone who doesn't really grok either Python or IP programming, I really enjoyed how simple yet educative (and ultimately, funny) this blog post was. Definitely will be trying this exercise the next time I end up at a hotel with a laptop.
I wonder how hard it might be to hijack the stream to have the receivers play your own packets.
Have you tried throwing the raw recording against SoX? Worked pretty well when I had an unknown recording to play for which I had guessed the format. (Which turned out to be IMA-ADPCM with reversed byte ordering)
There are some much nicer and more fun, also arguably less destructive, pranking options:
- text-to-speech output based on a definitive history of elevators
- same for an exhaustive safety lecture that'll probably horrify some guests
- BBC programming interspersed with random bits of Arabic speech
- sound of iPhone ringing using the most common ringtone
- toilet flushing noises
- JFK's "we choose to go to the moon" speech
- "thank you for using the elevator - achievement unlocked! Please visit the hotel's reception desk to collect your prize. Your raffle code is: ID-10T"
- "dear guests: a gentle reminder that floors in our hotel are zero-indexed"
Or given lots of hotels are likely setup the same, write an app that lets people take advantage of this / broadcast their own tunes to these services, so they can choose their own lift music in a Sonos-like way.
If this were an officially endorsed thing, hotels could even stick a Physical Web Beacon (https://g.co/beacons) in the lift, pointing customers to your app.
All that said, I guess my above scenario, headphones may be a simpler option ;).
... I've suddenly realised that if someone were to improvise a two-hour lecture similar to _The Art of Boxing_ from Frog Fractions and upload it somewhere, then I would probably find a way to use it. Somehow.
In many countries, the floors are 0 indexed. I live in Argentina an the usual name for the floor that is at the street level is "Plata Baja" (something like "low floor") and the elevator has usually a button that says "PB". Now it's increasingly common to see a "0" in that button :) . (This makes me slightly happy as a mathematician.)
Moreover, in some places the first underground floor "primer subsuelo" is "-1".
(I've never seen a "1/2" for "entrepisos" :( . I don't know the translation, with autotranslation I get "mezzanine" and "intermediate floor".)
Look at how many elevators have the ground floor as G, and then the second floor is 1. It already happens a lot in lots of places in the world. Of course, it levels out if the building excludes unlucky numbers, like 13 in North America or 4 in China.
Some people are terrified of anything Arabic sounding, especially people speaking Arabic. It is not racism to say that. It would be racism to say that all white or black or whatever people are terrified of anything Arabic sounding.
But there is nothing even remotely racist about saying some people are scared of something that has to do with an ethnic group.
> It would be racism to say that all white or black or whatever people are terrified of anything Arabic sounding.
Exactly! Isn't that what he implied? He didn't say "Here are some pranking options that would work on some people" he made a general assertion "Here are some pranking options" meaning they would work on all people meaning all people are terrified of anything Arabic sounding.
If I throw a banana peel on the ground like the prankster I am, my expectation isn't that everyone is going to slip on it. Most people won't, but I might prank someone if I'm lucky.
More like "there are people who think Arabic speech is scary", he doesn't have to think that himself to know that there are people who think that way and he wants to prank those people therefore I wouldn't say it's racist.
To me it was like "I'd play Arabic speech to scare people" rather than "I'd play Arabic speech to scare some people". I am addressing the statement of course not OP's person.
I did a bunch of multicast programming in the early days of Android, and I discovered that:
- most Android devices back then required a special OS call to tall the wireless chipset to listen to multicast packets at all --- otherwise they'd just ignore them and not wake up;
- in about half the devices, this switch didn't actually work;
- in an astonishing amount of consumer routers, multicast routing doesn't actually work;
- multicast on mobile is so, so, so not worth the effort.
I expect that multicast is way better supported these days. I would be totally unsurprised if it were not.
> I expect that multicast is way better supported these days. I would be totally unsurprised if it were not.
I wouldn't be, how often is multicast really used? Coming from the broadcast era, it seemed like a no-brainer. But the internet is built for n:n communication. Special cases for n:1 cost more in terms of engineering effort than would be saved in bandwidth and processing overhead.
Some IPTV services in the UK use it (at least BT and TalkTalk with their YouView packages and probably off-the-shelf YouView as well). I had a bit of a nightmare trying to get it working with BT TV when I upgraded from their godawful HomeHub to an ASUS router.
Pretty much every time I've upgraded my router firmware I've lost TV service and had to reconfigure it. Apparently multicast is hard, even if you're a networking company!
Waking up the WiFi hardware is not particularly expensive, and there is usually going to be tons of multicast stuff going around any crowded wifi network anyway. So it doesn't seem like this would be a big concern for battery.
Er, if they are transmitting data to a multicast IP address, what's to stop you doing the same?
If they haven't done a check on the IP address that they are receiving the data from, then it would now be trivial to panic people in elevators by recording a fake emergency broadcast.
Not jus that, but what else is that hooked up to? If they are multicasting to your IP address and your IP address isn't the lift, then you can do some IGMP snooping to see what else there is out there. Or you could do a DoS on the lifts to see what happens.
Of course, it might be nothing. But when I get in a lift, I'd hope this sort of thing wasn't possible.
Great network engineering. I think we all need a set of tools that allow us to find if we are being bugged by all the networked smartTV's, printers VOIP phones etc. Not to mention the Amazon Echo. I dig it if someone had a Wireshark/Python app that allowed everyone to listen to with Amazon Echo was sending to Amazon.
He listened to a public stream, there's no indication that they were attempting to secure it in any way. So, legal. Now, if he had done as others have suggested and injected "malicious" packets into the stream, then we'd have a question.
Yes, I know that's the US concept. Around here the view is a little less binary, as the law recognizes a difference between being seen (or even being filmed occasionally, by an handheld camera) and surveillance cameras, which can be used to track your movements.
The hotel could still have them, mind you, but transmitting them in the clear would be a clear violation of the law, which in fact specifically cites the "transmission of the recordings over a network" as something that must be secured.
