GalaxyGuy

Featured on hackaday: http://hackaday.com/2015/11/26/hacker-uncovers-security-holes-at-csl-dualcom/

According to Matt, the standards were outdated. Nobody needs to get into the arc to take control, so the physical attributes don't matter much in that case. The standards are pretty open on the software side where an attack is far more likely.

What is the new version for the V3.00 based module ? Pretty peeved at Honeywell support, as they did not provide this to me as part of my investigations into RF issues. They only updated on the other two F135 firmwares. Very poor comm's. I also think that the panel firmwares need to at least be adjustable on the 31 second front, otherwise there is no last resort... Just to clarify that there are now three versions of the G2/Flex/Dimension portal available (as far as compatible firmware goes that is): 1. The original C079 which can have rotary address dial or fixed jumpers: V1.08 2. The Rev F2 C079 portal which has pcb trace aerial: V2.11 3. The latest Rev A2 C079 portal with optional Russian frequency and test mode for visual (LED) signal strength: V3.0X -- For those who have purchased one of my G2 USB leads - As well as programming the G2, this lead can be used to flash upgrade the RF modules. I am also releasing an updated firmware for the LCE-01 Ethernet module to resolve a (very intermittent) protocol issue when the virtualkeypad is used alongside the RF portal. The LCE is V2.20 Dimension Firmware is at: V6.92 (enables outputs on apps) (although 520 and 264 cannot be used with the app until a new app release is available - Ethernet modules drop offline with the current app) G2 Firmware: V1.56 Galaxy G3: V5.55 E080-2 Ethernet: V2.11 E080-4 Ethernet: V3.05 Flex V3: V3.18 IB-Ethernet (Flex V3): V1.02

Sounds about right. I managed to jam the Honeywell in 31 seconds when testing earlier. Tried two portal versions with different firmwares and all did the same. No way of adjusting either.

I cannot determine any local mast information. It's a bit of a mission to start asking which network providers and which phones are in use Etc.

An example I was looking at today took its first single RF Jam after 11 months of flawless operation. The system hadn't skipped a beat with a perfect heartbeat test signal record and daily open/close reporting.

The Honeywell RF portal is based on the CC1101 from TI.

I'm only using panel diagnostics at the moment. I have some measurement equipment ordered for further investigation. I'm also awaiting further direction from Honeywell, as there are three different C079 portal variants all with different firmwares (and recent changes) and information on the changes hasn't been available. I also have conflicting installer reports of one portal variant fixing the problem at customer sites, but the trouble with this is that only time will tell if this is actually the case - the installer seemed convinced though... This particular installer is in the Netherlands, so whatever seems to be happening, it's doesn't seem limited to the UK.

I'm not sure what's going on at the moment, but certainly seeing Honeywell systems with some issues. Perhaps the Honeywell has tighter parameters for RF noise triggering a Jam. I believe it's a 3 minute period of signal jam that constitutes a jam tamper. I am not sure what the protocol does underneath that as far as signal levels Etc, but there's no real way of preventing the tamper at the panel side when the RF portal is fitted. If this does have something to do with mobile comm's (speculation at the moment), then it could mean trouble ahead... I really hope not.

Has anyone else seen an increase in alarm system wireless issues this year ? I'm not sure if it's based on the wireless systems uptake, but I have accounts where there has been no issues for many months suddenly start getting random jam alerts at no particular set time points. I'm very suspicious that this is something to do with the increase in mobile 4G. Perhaps I am just being paranoid...

See if you can get an updated firmware. If not, IPSec would be the best of what's there. You need more information on the L2TP to see what is actually implemented.

Depends on your router or VPN gateway secureiam. Something based around open source will likely be updated quickly when any issues are discovered. If you're using one entry point, then it's easier to focus efforts to keep it up to date. Much easier to do that than to rely on very small teams of security equipment designers to find vulnerabilities and release fixes. My personal experience of reporting such a vulnerability to one vendor of a 'third party approved' device, was that they just didn't want to know. When your phone connects via VPN a secure tunnel is created into the private network and all apps/IP based programs behave as they would in the private network. All traffic between your external location and your VPN device is secure, so it doesn't matter anymore that your app traffic is plain text. The 'vulnerable' devices remain in the private network.

Port forward should be the last resort with customers warned about the vulnerability. Just because something is password protected, doesn't mean there's some other vulnerability available through the forwarded port. Installers are adding IP enabled devices in customers premises without having any idea of how secure the device and its internal protocols are. VPN should be the preferred connection method, with the firmware in the VPN device being regularly updated to ensure that any vulnerabilities have been addressed.

No, was talking about converting the UDL code for the app in order that customers don't see it.

Still easy to pick up with wireshark for those that want it.

If the panel has been locked down properly, then you will not be able to connect with RSS. The virtual keypad 'backdoor' is not a back door and the pin should also have been changed if the panel is locked down. Other than that, it requires specialist equipment to interface with the Atmel CPU. Easier to display the zones, note them and then default.

Is the HKC encrypted traffic?

Texecom or Honeywell Galaxy. Texecom doesn't encrypt the communication though, so you'd need to use a VPN connection with it.

It would need to be a faulty device to be staying in write mode. Depending on the Ethernet firmware, the level can dip down momentarily (buggy Honeywell firmware), so you can probably just ignore on the COM4 device and the virtual keypad for it KP15. I think it's probably easier for you to swap devices until you have them all done. If this was at a customer site, I would say to just swap them all and then test them back in the office. It may be better doing the same at home in order to keep false alarms at a minimum. Apart from that, you'd need to connect a bus analyser/recorder and watch the traffic in order to debug the issue.

No the length is too short and the bus too resilient for this to be an issue. But if Ethernet COM4 is dropping out too, then it rules any open on the bus out. It would appear that something is dragging the bus down. A slave device can do this if it sits in write mode when it shouldn't. An intermittent short to the A/B lines would also do the same.

Is RIO 102 on one of the RS485 branches on its own ? If yes, then suspect the connection to the other branch. If no, then it can be any of the devices on the bus that's causing the issue. Just because 102 remained, doesn't mean it was causing the fault. It could just mean that it had just responded prior to the bus error and managed to respond again when the bus error had recovered. Check the devices diagnostics reports in menu 60. Keep an eye on the devices for a while, ensuring that they remain at 100%. If a device has issues, it may drop below 100% momentarily and this may be an indication that it's the one bringing down the bus. With power off, check each devices differential pair resistances with respect to ground - check for low resistances (panel too). If that all looks okay, then it's a matter of swapping out until you root cause to the faulty device.

That's a Fire sounder right ? You will need to fit a suitably rated relay in order to switch 240VAC from 12VDC. Something like this will work. You may want to source something with appropriate approvals markings. This one is rail mount - I normally work with rails to keep things neat in the panel. http://www.ebay.co.uk/itm/DIN-Rail-Mount-2-SPDT-10A-Power-Relay-Interface-Module-12V-Version-/161168508254?hash=item258664455e

Lol, have you tried soldering 0402 chip components in the density required by smart phone ? Little Johnny would end up with a 1980's brick

When you have the engineer code, this still doesn't give you the RSS code. There is no menu option to reset the RSS code. There is a convoluted way to get the code - PM me if you need to know. It sounds like your office based system sets a (random or derived) password and stores this in the RSS database. As you don't know this, the only way to get it is to export the config from the office system. The password is encrypted in the RSS database, so you cannot see it in the exported site file. The RSS password is the equivalent of the downloader ID on the G2. It's more secure than the G2 though, as it's alphanumeric and can be longer than the 8 digit G2 downloader. There's no menu access to the rss code though.

No need for additional modules with the Galaxy G2. The panel will monitor the PSTN line input for voltage and provide a local alert if there is a problem (as per JW). The panel will also assert the fault output if you want this to trigger a separate signaling method. Third party multi-path devices can also be installed in the panel, but the G2 has a limited power output, so it's a push for the G2 system to drive system peripherals plus a combined GSM/Ethernet device. A UPS based Broadband/GSM router is also an option for single path devices where the fixed broadband line may be susceptible to sabotage and more than a line fault needs to be detected.