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