Is now delivering the (OS 2.3) with a new lighting user interface, new features that enable customers to personalize their own experiences, new applications for commercial installations and updated certified drivers. “OS 2.3 brings a new level of performance, reliability and capability to Control4 systems,” says Control4 CEO Martin Plaehn.
“Our new software packs a punch, delivering an exceptional experience for consumers and includes enhancements and purpose-built features and tools for our dealers, including hundreds of updated device drivers supporting both residential and commercial installations.” OS 2.3 will result in faster, more responsive systems, according to the company, while also empowering consumers with the ability to customize and adjust specific preferences on their own. For instance, users can also add or swap out smartphones and tablets within their Control4 MyHome account. The MyHome app also boasts faster start-up and reconnect time, better Rhapsody Music Service integration, and additional language support for non-English speaking customers. One of the key attributes of the OS 2.3 release is the new lighting UI that enables control via TVs, Control4 touchscreens, smartphones, and tablets. In addition, new personalization and editing capabilities include the ability to directly edit and manage specific lighting functions from Control4 touchscreens and the MyHome PC app, eliminating the need for a service call. Additionally, Control4’s new Advanced Lighting Scenes Agent enables more efficient programming of lighting scenes. The new Control4 Driver Editor enables dealers and developers to create and test new drivers without requiring a fully installed onsite Control4 system for designing and developing drivers for third-party products.
Control4 is now delivering the Control4 Operating System v2.3 (OS 2.3) with a new lighting user interface, new features that enable customers to personalize their own experiences, new applications for commercial installations and updated certified drivers. May 29, 2017 - Originally posted by RCP on 2017/3/17: Latest Driverworkseditor.
OS 2.3 also includes support for Control4 Simple Device Discovery Protocol (SDDP), which will automatically identify and load the correct driver for Control4 devices, as well as an expanding roster of third-party devices. Systems will now be able to automatically discover and add devices to projects without requiring the typical driver search and binding. Using SDDP, a device’s IP address also will be automatically discovered and configured.
Control4 has created nearly two dozen new drivers and provided updates to over 300 drivers. For integrators with commercial clients, OS 2.3 also adds a number of new capabilities:. The new Access Agent, which enables a user to limit unauthorized access through password protection and the hiding of selected functions, provides business owners more controlled access to automated capability. The new FieldServer driver provides support for commercial HVAC systems through the FieldServer Technologies’ QuickServer Gateway enabling automation access to Delta Controls, GE, Honeywell, Johnson Controls, Mitsubishi, Rockwell and other thermostats over device networks including BACnet, Lonworks, Modbus, and more via serial, bus or TCP/IP. The enhanced Themes SDK enables user interface customization by dealers to thematically brand screens on Control4 displays (TV, touchscreens).
The software upgrade to OS 2.3 from OS 2.x systems is free; however, there may be some dealer fees associated with an upgrade. Software upgrades from OS 1.x systems involve a Software Upgrade License fee, or the purchase of a new Controller in addition to any installation fees charged by your dealer. Editor’s Note: Some images in the photo gallery are of poor quality as they were taken from this.
Some time ago Thomas Dankert posted a comment in response to my Reversing Somfy RTS blog post describing how the Control4 driver scripts are encrypted. Due to the recent activity around this post, I finally made some time to look into this(thanks Rick for posting the code). This turn out to be a nice example of how not to use crypto. So I decided to write this post to highlight some of the mistakes. I don’t go into to too much detail about the cryptographic attacks, because they are already described in a lot of publications.
If you want to know more about these attacks or cryptography in general I can suggest Dan Boneh’s cryptography course on. Thanks to Thomas Dankert and Rick for doing the real work and sharing the information.
Decrypting the drivers Thomas describes the encryption process as follows in his comment. The “driver” is a XML file with an embedded lua script. The control4-box seems to know about the air transmission format (OOK, 433.42Mhz, etc), so the script only constructs the frame.
The encryption is standard AES, but I really do not understand why they chose to implement it like that. They do use AES, but only to encrypt a simple counter (a 16 byte array), that is then used to XOR the plaintext with. 1) Base64-decode the contents of the tag.
2) Setup AES in ECB Mode, with IV = 0 and Blocksize of 128 bits. Hi, The c4z driver used RSA with X509 encryption,I find the private key in the control4-box,but the private key is encryption. Could you explain me how to decrypt the control4 c4z drivers? To get the encoding passphrase you need to intercept it when the director process tries to install an encrypted driver itself. Actually this is quite simple.
You need to install gdb on the controller, and replace the openssl libraries that are shipped by C4 with your own, that you will compile to include debugging symbols. Once you have installed your libraries, restart the director, then run gdb on the controller and attach to the director process. Set a breakpoint inside the openssl library, at the entrance of the routine that reads the private key. In Composer Pro, try to install an encrypted driver: gdb will stop at your breakpoint and show you the memory address where the passphrase is stored. I just decoded an handful of drivers ? Some of these have some LUA obfuscation but that is rather trivial to bypass. I can tell you with 100% certainty you don’t need to recompile ? You don’t need the variables because you can just check the call stack.
I’m not saying it isn’t easier with debugging symbols, but it is definitely doable without. The passphrase IS stored as a string, but yes–it is just random letters (and if i recall symbols too). You can still set breakpoints on exported functions of libcrypto, which is what I did. I thought I was the only one that thought of the GDB thing. Good on you for figuring it out. If you’ve done it right there should only be like 15 or so, and its going to be incredibly obvious which one is the key from my recollection.
Just to be clear, looking at the binaries alone for strings isn’t going to work. You need to use GDB to set a breakpoint in the function that reads in a cert with a pass from the libcrypto library. Then load a driver, and when the breakpoint is hit, check the stack for string pointers. I can’t remember the exact commands to do this, but some googling should help you figure it out. You can then use the resultant key to decrypt the encrypted private key, which appears in plaintext in the director binary.