Jump to content

dexterash

Members
  • Content Count

    661
  • Joined

  • Last visited

Everything posted by dexterash

  1. What if the firmware has been repacked with a malware version of webplugin? It's not uncommon: http://www.zdnet.com/article/amazon-surveillance-cameras-infected-with-malware/
  2. Nor is the situation white or black only. We've got a bunch of "grey" between...
  3. Or... Maybe IP systems require a little more attention than analog ones. You know, honestly, the whole world runs on IP and we've got billions of interconnected embedded systems... Yet, the Internet doesn't need a reboot every 12 hours
  4. Actually the Plug'n'Pray function on some NVRs with PoE might make the install simpler than analog cabling. If not interconnected or linked to something else. Reliability, as I said before, it's almost the same. The fun begins when the interconnection with other systems starts. No doubt about that!
  5. In the connected world we live in, if an isolated IP home system fails, I think there are or could be bigger problems. Securing or making a small system functional is not a greater deal than setting up a NAS or SmartTV or other smart devices. If that fails, the first thing I would be concerned is the misconfiguration (that can lead to serious data leak/loss/forever gone and privacy problems) of my home network. Well, we might even say that an IP System that works flawlessly increases the chances that our network is well configured and our data/privacy is somehow ok.
  6. ^What a stupid post. Since when H.264/H.264 cameras use MJPEG?!?!
  7. Well, that rant went off the records... off the chart ... and off the peaks! If someone follows the same rules on IP as with standard analogic, there shouldn't be more problems. When people are mixing IP Cameras with other devices on the same network, without proper segmentation/ isolation/ firewalling, there could be problems. The same goes if cheap switches are used, low-quality power sources, bad design, low-quality installers (no harm intended) & etc. Failure-wise speaking, of course there are more [theoretical] failure points in IP devices, but I've never seen an IP device go "boom" by itself (nor an analogic one, of course). We've got either manufacturing problems (well, both on analogic and IP), or "user/external" interference. Yes, the stack overflow or memory leak can be a problem. But if it's a design problem, could and should be fixed via update(s). Of course, there could be a 0.000001 % case that can't be traced. But the same could happen with a DSP on an analogic camera and start to perform weird in 0.000001 % freaky light. Yes, temperature can be a problem - but same goes for analogic too. In both cases, should someone powerup an IP Camera and an analogic one and leave them like this for (mhm) years, they shouldn't have any problem. It might have a problem if the filesystem becomes corrupt due to a freaky power on/power off/power on etc thingy, but the same can happen to an analogic camera too. But real problems might come up when starting to connect/interconnect. But there are different types of problems that have their own fixes, since each technology is more or less prone to different errors than the other. <----> BUT! IP conflicts are stupid kiddos problems. That's why LAN networks need to be designed in a way to prevent that. Same goes for DDoS (which, of course, can be a real threat if you put the camera on the same VLAN as the PC you use for watching 4k porn , for example). Firmware in IPCameras might need upgrade (of course, here we should mind compatibility across vendors), but so might the analogic DVR. And since you can't use the analogic without a digital device that has a firmware or software running on it... we can say the analogic might require upgrades too. Oh, btw, CVI cameras can be firmware-upgraded. And we can go on for ages about this. Nothing is perfect nor fool proof. And I think every case or every install has and should have it's own, personalised solution. [for example, why put 4K cameras when all you need is a 1fps, low-resolution recording of an entry?]
  8. First thing first: upgrade the firmware and do a complete reset of the devices. Are you using default 80 ports? Are you sure there isn't a bot/automated system trying to connect to your camera (other than you) that messes things up?
  9. In my honest opinion, anything that goes through a 3rd server (as in no-direct IP connection) is a potential threat and a privacy problem. And, also, a proof of laziness or lack of knowledge. Well, what do you think? https://krebsonsecurity.com/2016/02/this-is-why-people-fear-the-internet-of-things/ http://foscam.us/forum/foscam-dialing-out-to-suspect-hosts-t17699.html https://www.pentestpartners.com/blog/pwning-cctv-cameras/ Did anyone really pentest or monitor the devices or the solutions that they are using/installing? We're talking about devices that stream HD/FullHD/4k[or more] detailed images/video streams. Or the "open" world out there means no privacy at all?
  10. Because I work with facts more than screenshots or simple words, we can test that theory anytime, with any IP-enabled/network-enabled device, to see what network traffic it does [ under whatever settings the users are comfortable or used with ]. A sniffer session [with or without a decoder or several decoders attached] can't lie.
  11. Please read the articles. And the discussion around Foscam. Even if you "disable" (mhm, actually no) the P2P via the Web Interface / CMS / Config something, it still uploads. To a bunch of IPs/different addresses. Of course, you could disable DNS lookups. But that might bring other problems (push or e-mail, for example). Or you could completely firewall it, but that will render useless remote viewing. And complicate things. A lot. And this without discussing the security of the uploads - if they are done encrypted or not, rendering them vulnerable to simple sniffing/decoding.
  12. At least there you know what you stored/when you stored and have a different control (can't say full control). But in case of "some" P2P implementations you have no control at all, as outlined in the articles posted. And no simple way to disable it or the uploads.
  13. 1st thing first: one simple problem - how to determine if a camera is unresponsive and at what level. 2nd: there are ways to reboot a software-unresponsive camera without the need for a "hardware control" (in most cases) 3rd: what if... the Networked Power Manager also gets stuck? It's the same as with any other Internet/Network-enabled device. By design of the device, that shouldn't happen. By design of the network/solution (as you already mention), that shouldn't happen too. But what if? Well... There are several ways to do it. Even though I do think the most elegant way is to use a "watchdog" (we're working with/developing this type of solution), there are also enough ways to software-un-stuck the devices; for example, we can reboot almost any DAHUA/HIK-based device with just the common DATA port exposed - as needed in any remote surveillance solution that doesn't go through P2P mayhem. I'm sure it also works for other brands too, with a lil' bit of tweaking.
  14. Might be a [very] poor SoftwareWDR/DSS implementation. "Play" around with image settings/OSD (if it has).
  15. You could record locally the cameras (either with the help or a NVR or cards) and "push" the event recordings via FTP to a remote server and notify (e-mail?) that an event has been going on. There also might a possibility for a custom solution/software that just "subscribes" to the event channel and requests the stream when a motion event occurs. That sort of software can be done, but it's not a "pure" hardware solution.
  16. Chrome is no longer supported by DAHUA's WebPlugin.
  17. SmartPSS does not work with "3rd party" devices, but you can use one external alarm from a camera/nvr.
  18. dexterash

    DAHUA NVR Problem

    For the 100000th time: removing the battery WILL NOT RESET the DVR/NVR/etc. Nor can you use master passwords via LAN.
  19. Even if you can find an almost perfect software(so to say), there are many devices with (very) poor ONVIF implementation. That's why the vast majority of CMS use proprietary protocols(specific to manufacturer/device), not ONVIF.
  20. Careful about ONVIF, since it's general, but very "strict"... It's not widely accepted and most ONVIF functions are not really implemented.
  21. You need a "generic" solution that will work with anything? That ain't gonna happen...
  22. Depends on the hardware you use. For example, for DAHUA, we developed a software (based on their SDK) that doesn't decode, just sits silently in the tray and pop-UP a live video when motion is being triggered by the device(motion is one event, but we can subscribe to more). It's the same technology - or way to work - used by mobiles to deliver push-emails. And that's PUSH better than any PULL with decode.
×