Jump to content

Stupidity was the cause of the downfall


silverton38

Recommended Posts

I knew they weren't manufacturing much at all, and I knew they were prioritizing switches over things like PLMs, but based on this thread I thought they had officially dropped the PLM.  That would have been incredibly stupid, but perhaps not out of character.

Link to comment
Share on other sites

I knew they weren't manufacturing much at all, and I knew they were prioritizing switches over things like PLMs, but based on this thread I thought they had officially dropped the PLM.  That would have been incredibly stupid, but perhaps not out of character.
Killing the PLM seemed like a very pointy attack on their competition IMHO.

Unfortunately they may have risen to the top if they considered themselves partners with UDI, and open sourced some of their products or software. They could have offered the meat of the Insteon comm guts to other manufacturers so others could produce specialty items like analogue input modules, better thermostats, door locks, and smart personal vibrators for those long distance love affairs.

Alexa.... turn ...oh never mind. Somebody must have a good imagination. Smartypants certainly didn't.

Sent from my SM-G781W using Tapatalk



Link to comment
Share on other sites

2 hours ago, MikeB said:

I knew they weren't manufacturing much at all, and I knew they were prioritizing switches over things like PLMs, but based on this thread I thought they had officially dropped the PLM.  That would have been incredibly stupid, but perhaps not out of character.

The PLM was a low priority device for Smarthome as they were focused on the Insteon Hub which has it own interface built in.

Link to comment
Share on other sites

On 4/22/2022 at 6:29 AM, larryllix said:

I found it very promising that a hacker group couldn't even hack the protocol with so much equipment and brainpower at their disposal. His demo was a complete failure but it proved the SmartLabs whitepaper was BS to put hackers off copying their patents. Very common in industry to do that.

Perhaps they will allow their patents to expire and we may see a new and improved Insteon, with backward compatibility to shake up the HA world again.

weird.  i watched a demo maybe 5 years ago at DEFCON and they had free reign over an insteon network - the protocol was simple to control once the hardware to access the network was worked out.  i believe they used an SDR dongle for the wireless band, but noted that it wouldn't be too difficult to create a powerline module.

Link to comment
Share on other sites

On 4/22/2022 at 1:55 PM, Techman said:

Not to worry and no need to panic, It's not over until the fat lady sings.

With Smartlabs/Smarthome now in bankruptcy there exists that part, or all, of the Insteon technology can, or may, be resurrected post-bankruptcy, including support for the existing Insteon Hubs. Michel and his team are on top of this.

Hang in there for a while and let's see how this plays out. Patience is a virtue.

 

 

Mike; I may be interested in investing if you require it. Please contact me privately.

Link to comment
Share on other sites

22 hours ago, fisix said:

weird.  i watched a demo maybe 5 years ago at DEFCON and they had free reign over an insteon network - the protocol was simple to control once the hardware to access the network was worked out.  i believe they used an SDR dongle for the wireless band, but noted that it wouldn't be too difficult to create a powerline module.

If it was the demo I saw they spent most of the demo trying to access the network and then proposed many things they couldn't demo. IMHO it demonstrated a complete failure to control anything. Basically nothing Peter Shipley claimed could be demonstrated in that video.

Link to comment
Share on other sites

2 hours ago, larryllix said:

If it was the demo I saw they spent most of the demo trying to access the network and then proposed many things they couldn't demo. IMHO it demonstrated a complete failure to control anything. Basically nothing Peter Shipley claimed could be demonstrated in that video.

i found and skipped through the talk you're referring to - that's not the talk i saw.  the one i saw was by a fairly clean cut guy, running the talk by himself (though he had a helper), in one of the small rooms upstairs in Paris? - different talk, different people.  he had a laptop, SDR dongle, and a 2x4 with two? retrofit plastic outlet boxes and an incandescent light bulb receptacle screwed to it.  there was a lamp cord and two? dual band switches wired up to the light bulb, all plugged into the wall.  he ran his software on the laptop, enumerated the device(s) (just a bunch of command line text to me, similar to what was shown in the Shipley talk), and then he toggled the light on and off using his laptop.  i think he talked about how useful/not useful it would be to use the technique to cause mayhem or to get access to something important... he thought the enumeration could be useful, but that the wireless range was rather poor for a safely distant enumeration process (like in a car down the street or similar).

i think i remember people in the audience discussing a previous demo that failed (perhaps the Shipley talk).  i don't think this guy and his work were based on Shipley's work, but i do think it was meant to show that the proof of concept was doable fairly easily.  whenever i broached the subject of protocol security with the smarthome folks on Alton, it was treated dismissively, and i think they tended to make public statements to that effect.  that treatment of the subject was not warranted.

what i took away from the talk i saw was that the insteon protocol was inherently insecure, but that it wasn't easier to leverage into unwanted access or vandalism than someone with a rock or basic lock-picking tools... as long as you didn't allow insteon devices to turn off your security system.  kinda the same thing people have learned with Alexa - don't allow Alexa to unlock a deadbolt or open a garage door if you don't want an intruder to just yell their way into your house.  likewise, don't allow an insteon device state change to turn your security measures/monitoring/alerts off.

anyway, i think we're future proof in terms of getting centralized control of an insteon network; even once the smarthome manufactured PLMs and hubs die out, there are inexpensive ways to hack that access back into life. 

it'll be interesting to see what happens to Smarlab's IP.  with freedom to operate, i really think powerline and dual band devices could be a $400M market, as long as someone can make the devices less expensive and smaller without making them unreliable.  securing the protocol would probably be a necessity (if getting devices in many homes is the plan), but i'd want the ability to enable backwards compatibility. 

Link to comment
Share on other sites

4 hours ago, fisix said:

i found and skipped through the talk you're referring to - that's not the talk i saw.  the one i saw was by a fairly clean cut guy, running the talk by himself (though he had a helper), in one of the small rooms upstairs in Paris? - different talk, different people.  he had a laptop, SDR dongle, and a 2x4 with two? retrofit plastic outlet boxes and an incandescent light bulb receptacle screwed to it.  there was a lamp cord and two? dual band switches wired up to the light bulb, all plugged into the wall.  he ran his software on the laptop, enumerated the device(s) (just a bunch of command line text to me, similar to what was shown in the Shipley talk), and then he toggled the light on and off using his laptop.  i think he talked about how useful/not useful it would be to use the technique to cause mayhem or to get access to something important... he thought the enumeration could be useful, but that the wireless range was rather poor for a safely distant enumeration process (like in a car down the street or similar).

i think i remember people in the audience discussing a previous demo that failed (perhaps the Shipley talk).  i don't think this guy and his work were based on Shipley's work, but i do think it was meant to show that the proof of concept was doable fairly easily.  whenever i broached the subject of protocol security with the smarthome folks on Alton, it was treated dismissively, and i think they tended to make public statements to that effect.  that treatment of the subject was not warranted.

what i took away from the talk i saw was that the insteon protocol was inherently insecure, but that it wasn't easier to leverage into unwanted access or vandalism than someone with a rock or basic lock-picking tools... as long as you didn't allow insteon devices to turn off your security system.  kinda the same thing people have learned with Alexa - don't allow Alexa to unlock a deadbolt or open a garage door if you don't want an intruder to just yell their way into your house.  likewise, don't allow an insteon device state change to turn your security measures/monitoring/alerts off.

anyway, i think we're future proof in terms of getting centralized control of an insteon network; even once the smarthome manufactured PLMs and hubs die out, there are inexpensive ways to hack that access back into life. 

it'll be interesting to see what happens to Smarlab's IP.  with freedom to operate, i really think powerline and dual band devices could be a $400M market, as long as someone can make the devices less expensive and smaller without making them unreliable.  securing the protocol would probably be a necessity (if getting devices in many homes is the plan), but i'd want the ability to enable backwards compatibility. 

Definitely not the demo I saw. The one I saw was Peter Shipley and IMHO it was a failure to demonstrate his hacking of the protocol.

I mostly agree with your analysis. Scrambled and difficult, but not hackproof / secure.

Link to comment
Share on other sites

as i understand it, the structure of the packets is not the mystery - nor are the commands - i think fartlabs published that for their development program 

someone posted on a rf device they used to see the packets - a sniffer or wireshark type tool that could be used to break all that down - packet structure and commands should not be a problem (if its legal to construct and send them commercially is out of my league)

michel has always said insteon needs security but it was not in the specs - as i understand it, insteon traffic is sent through all houses serviced by a transformer - an all off command would be interesting... 

these packets are tiny - they isy constructs them and passes them to a plm/c/s/u/whatever (fartlabs device) to deliver - that is where the gotcha is - getting the packets sent - inserting data on a powerline seems impossible to me - but its done - sling made devices to send video over powerlines - not sure how good it was

broadcasting on a frequency seems easier to me

either way - has to have a driver or whatever unix calls it - an interface for a program to pass the data to the operating system - for the operating system to dispatch the packet on the hardware

which is why i asked the question - if an insteon device (say dimmer) gets a packet from an rf delivery, does it repeat that packet on both rf and powerline?  and powerline delivery repeated on rf?  if so, you only need one to work (rf or powerline) to one device to get the hoppin started - until the hoppin count is exhausted 

Link to comment
Share on other sites

Straight out of the developer guide.

"An INSTEON network becomes more robust and reliable as it is expanded because every INSTEON device repeats messages received from other INSTEON devices. Dual Mesh™ communications using both the powerline and the airwaves ensures that there are multiple pathways for messages to travel. Whether by radio or powerline, INSTEON messages get repeated in unison whenever multiple INSTEON devices hear them. This message simulcasting is like an entire chorus singing a melody at once instead of one singer at a time—the ‘music’ is much easier to hear."
 

Link to comment
Share on other sites

The only "security" that the Insteon protocol has is that devices are supposed to only accept commands from a device that is in their link table. 

For example, if a PLM sends a command to turn on a switchlinc, the switchlinc should only accept that command if the PLM's address is in the switchlinc's link table.

But there is a way to add entries into the device link table so it's not much of a stretch to create a tool that add a link and then controls the device.   The "security" is mainly there to prevent your neighbor's devices from controlling yours and vice versa. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      36.5k
    • Total Posts
      367.7k
×
×
  • Create New...