Control 4 License Hack
Your first program Like all programming books teach, we’ll do the same – start with a basic hello world program. The majority of the stuff in here is how to create a program in Driver Editor, upload it with composer and then run it to see the output. Once you can do this, then it going to be easy to add everything else piece by piece. One thing I’m not going to cover is how to write programs in lua, there is plenty on the Internet on how to do this. A good start would be here: To be honest I didn’t know anything about lua before I started to write a driver, like all languages I tend to hack my way through and look at examples to learn the formatting. So if you know how to write a program in pretty much any language you’ll be able to pick up lua in minutes. Running Driver Editor Once you have installed driver editor on your windows system and start it up you have to create a new file.
Driver Editor comes with a number of templates that include relevant configurations for the device driver you are writing. For example using the TV template comes with a lot of the things you will need to code or modify for a TV driver. To start, create a file based on the Base Driver Template We’ll use the base for now because its a lot simpler and doesn’t contain too much to be changed for a small driver. As a side note, if you want to create drivers that are just programs and don’t need a user interface, then the base driver template is a good choice. Give it a Name Once you have created a driver you need to fill out the details that will be shown in Composer.
As you can see filling in the fields on the Main tab is a lot easier than creating XML to describe it. Thats what will be done when the driver is saved, so you can immediately see why using Driver Editor is a good move. For now just put in details for the following. Manufacturer – C4Drivers. Model – Hello World.
Name – Hello World Driver You can change the other text fields and add notes if you like, but the other settings can stay as they are for now. Create an Action We know we are just going to output the text “Hello World”, but we need some way of running the code. Drivers tend to work on something happening, so we are going to create an action to say the words. The actions for a device are something that you may see when you click on a device in Composer in the System Design folder. Most of the standard Control4 drivers don’t have an Actions tab, but a lot of the 3rd party drivers do. What we will do is add another button to this screen so we can run our code on the Controller. Its useful to create actions to run pieces of your code when developing without having to setup a whole set of events for it to be triggered.
Go to the Codes/Commands tab and on the right of the screen move your mouse over the Actions folder and it will pop out. In the box you can right click and click Add. So lets add our action, in the Details box you can give it the name Say Hello and the command helloworld The name is what will be shown on the button on the Actions tab of the device, and the command is the name of the command that will be sent to your program when it is clicked.
Lets write the code Ok, Finally lets add the code to do what we want. In Driver Editor you add your code on the Codes/Commands Tab, and then the Script Tab on the panel below. In here you will see all the code for the driver, because you used a template there is already a lot of code to help with processing the different things that the driver may need to deal with. We are going to be adding the command that is run when the action button is pressed, you should have given this the name helloworld when defining the action. When any action is sent to the driver the function EXCMD.LUAACTION is called. The only parameter to this is tParams and this contains the name of the command.
In turn this then calls the function where you will put your code. The name of the function is LUAACTION.' Your command' So in our case we need to create a function called LUAACTION.helloworld This will then be run when someone clicks the action button we created. So lets do this by adding the following function to the file. Function LUAACTION.helloworld print ('Hello World!' ) end Once you have done this you can save the driver and lets upload it to the Controller.
Save the driver as helloworld.c4i and we can move on to installing and running it. Install and Run the Driver Now you have saved the driver you add it like any other driver. Just copy the file to the Documents/Control4/Drivers folder on your computer. Run Composer (or close and re-run it if its already open). Connect to your Home Controller. Find the new driver by searching for it when in System Design. Select the room where you want to put the device, for our purposes its not really going to matter at this stage where you put it as we aren’t connecting to anything else.
Then either double click on the driver or drag and drop it to the room. Now you have the driver installed we can move on to running our action. Select the device Hello World Driver, or whatever you named it if you changed the name. On the Actions tab in the Properties panel you will see the action we created. Click Say Hello to run the command. On the Lua tab you can see the Lua Output box which is where the output (the print statement) was directed. So there you have it, clicking the action causes it to run your code.
Not very interesting, but its a start and shows you what you need to do so that you can create a driver and put it on your system. Replace Print with Debug You’ll notice that we used the print command in our driver.
Chances are in your drivers you aren’t going to want to output text, but you will want to get information back for testing and debugging. The template we started with has good code support for debug output, so we can easily change the function to support this. The debug functions support sending the output at different levels. 0 – Alert – Dbg:Alert. 1 – Error – Dbg:Error. 2 – Warning – Dbg:Warning. 3 – Info – Dbg:Info.
4 – Trace – Dbg:Trace. 5 – Debug – Dbg:Debug If you output at a certain level, then it will only be shown if debugging is turned on at the same level or higher. What that means is that if you output a debug message using Dbg:Info, then it will be shown if debugging is enabled at Info, Trace or Debug. For example if you change the function to use the Dbg:Debug function instead, the output will only be shown when you have changed the debug mode to print and the level to debug in the properties of the driver. Try setting this to debug on your driver now. Also change the driver code to send at the debug level function LUAACTION.helloworld Dbg:Debug ('Hello World!'
) end Now save the driver again. Update the Driver on the Home Controller Now you have changed the driver you will need to update it on the Home Controller. There are multiple ways of updating drivers, but the quickest I found is to. Go to the device in System Design in the Composer application.
Right click the device. Select Update Driver. Choose your updated driver. You will notice that it complains that the version numbers are the same. You can fix this by updating the driver version number in the main tab of the Driver Editor.
Control4 License Hack
Try making the change and updating the driver again, you’ll notice it doesn’t complain about version numbers now. You should do this every time you make a change to a driver that you are going to release so that features like Manage Drivers in Composer work correctly to let you know which drivers need updating.
Now check its been updated by checking the properties are set correctly and running the Say Hello action by clicking the button. If all is done right then you will see that the Lua Output is the following: Starting Timer: Debug ExecuteCommand(LUAACTION) ACTION: helloworld Hello World!
Control 4 License Hacked
Obviously it shows more than just what you put in your command, also anything else the code outputs for the debug level is shown as well. Example Code and Drivers All the driver files and code examples are located on github at. FYI for anyone trying out this very nice tutorial. The tutorial is a bit dated (October 2014). It is based on an old version of DriverEditor (2.x?) whereas the more recent DriverEditors (3.x) are quite a bit different. It is easily adaptable in this regard. The tutorial also uses a base template that doesn’t seem to exist anymore in DriverEditor.
This is more challenging to overcome. It means you have to choose some other template (I used the generic Pool proxy template instead). All the new templates don’t use Dbg method anymore (it has been replaced with LogDebug).
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.
Control 4 License
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.