"Security" systems that run on windows are amazingly bad. It's as if they're coded by the same people who write embedded industrial control/automation software. No I don't want to install a 3 year old Sun JRE to run your software. Here's a great writeup on "why we have stuxnet":
http://www.metzdowd.com/pipermail/cryptography/2016-March/028762.html I usually do embedded cross-development under Linux, typically with some hacked-up ancient version of gcc and obtuse command-line utilities that fail with cryptic error messages until you've spent several hours hacking around with them. This time though I had to use Windows because getting the drivers going under Linux just wasn't working. So I go to the web site of the $20B global hardware vendor that makes this stuff and download their SDK tools. "We've detected that you've got A/V running. You should disable this in order to run our tools. Are you sure you want to continue?". Yeah, I'm not doing that, so I click continue. "I said, WE'VE DETECTED THAT YOU'VE GOT A/V RUNNING AND YOU REALLY NEED TO DISABLE IT. Waiting for A/V to be disabled". OK, so I'll disable A/V. At which point Windows goes to about Defcon 2 and starts screaming about the imminent collapse of civilisation, but I don't have any choice. So the install starts, except it won't install in $Program_Files because that has, you know, security applied to it. It wants to create its own public directory off $SystemRoot and install to that. OK, so I'll allow it to do that. Now Windows Firewall is throwing up warnings about tclsh groping around on the Internet (they install a complete Cygwin environment, presumably because their Windows SDK is all scripted in Tcl). So I allow that, and various other things that I get warnings about. It then proceeds to download and install a 2-year-old version of Java, which apparently is needed by their SDK. After that, it reaches out to about a hundred-odd HTTP URLs, downloads binary blobs from them, and installs them. I tried setting up a tunnel to an HTTPS equivalent but it only does HTTP. Finally, it's finished. The app starts up and requests elevation to Administrator. Then it starts grabbing more binary blobs from HTTP URLs and installing them. All that was just from watching what was happening, I didn't do any further checking to see what other horrors lurked beneath the surface, but given what I'd seen so far it was bound to be pretty bad. I think we need to treat any embedded device developed via this vendor as pre- compromised. And that includes the aerospace and military ones. Peter. On Mon, Mar 28, 2016 at 3:52 PM, Josh Reynolds <j...@kyneticwifi.com> wrote: > I'm dying here. Every single system I can find is shit or costs an arm > and a leg, to the point where I'm considering starting a company to > make a better system. I just need an embedded, web based, IP access > control system. It needs to be able to control the individual door > access controllers to electronic striker or maglock to the keypad. POE > here is best. If it requires software running on a windows PC then I > don't want anything to do with it, even for those of you who are like > "put it in a vm"... no. Those resources are reserved for properly > functioning operation systems (and LXC containers!). > > I've got 3 doors at one location, then 2 more doors at 2 other locations. > > If it has a mobile app, that's even better. > > I've installed a couple of HID Global and DoorKing systems in the past > and nothing about this is hard, but the chinese systems are only made > for a single location. > > Any suggestions? >
