Reverse engineering c4z drivers
I'm frustrated how it's impossible to fix bugs in drivers, and when developers exit the space they leave dead or struggling to survive drivers with no possibility of support. As such, I want to see if it's possible to reverse engineer the encryption used on the c4z files.
Note: Do not steal software, do not encourage people to steal software. Don't do illegal things, this is a purely education post talking about the process of reverse engineering.
I've done a pretty extensive deep dive in trying to figure out how to decrypt these drivers, even so far as to have about 13 gpus trying to brute force guess the drivers.p12 password for the past week, as well as alAlso decompiled the director binary using Ghidra, but that's... not really going anywhere either /sigh.
It seems the closest anyone has gotten has been this article in 2016:
https://pushstack.wordpress.com/2016/03/06/control4-driver-decryption/
The basic idea: The drivers are encrypted using pub/priv encryption, using either C4's own crypto library, or the openssl one. (I believe the c4 library just wraps the openssl one). On a controller, in the /opt/control4/etc/certs directory are several .p12 stores, one of which is labeled drivers.p12.
The director executable unlocks the p12 store, and uses the private key to decrypt the drivers before loading them into memory. (Is the assumed flow). You can either try to guess the password to the p12 store, or intercept the password provided to the decryption library.
The former requires just a lot of horsepower (I have 13 gpus trying for the past 2 weeks), the latter requires a lot of cross platform compile / debug stuff. I'm not super familiar with crossplatform toolchain type stuff, but every day I'm getting better heh.
One thing to note is the controller is not running a full linux distro, it's running busybox. So if you try to change the C shared libs you're going to segfault everything on the box until you restore factory settings.
What I've done so far
a) Get gdbserver running on it. I've done this via static linking, this may or may not work, if I can get cross-platform toolchain stuff working, then I may recompile this correctly.
b) recompile openssl with symbols, and get it working (I have not been able to do this just yet, but I think I have a path)
c) Used Ghidra to disassemble / decompile the director binary. This is done, but not very readable (obviously). I may start trying to lift as many strings as I can from the resources and see if I can just get lucky on guessing.
Anyone else have any progress on this avenue, or want to contribute?
** Disclaimer: Don't steal other people's work, pay for software you use, etc. This is about using encrypted drivers as a learning tool, and more importantly having full control over your system. **
Wow - that’s some extensive work! Well beyond my capability. It’s interesting reading your approach. Good luck figuring it out!
Shouldn't be too difficult. I'll see if I have time to write the decryptor on the weekend. Kind of busy coding other things atm.
Put my other C4 cracker on hold until I get my hands on a unit for testing.
Apologies for the delay. I've just finished the decryption routine, and tested it on a driver i created myself.
Basically, you were approaching this in a much more complicated manner than was required.
I've written the decryption program - can you provide a driver so i can run it against it? It seems to work fine on drivers i created myself that are encrypted.
Edit: Seems there may be more than one encryption. I've broken the lua script encryption, but downloaded a Sonos driver that appears to be encrypted differnetly.
Quote from Azazel on March 22, 2022, 3:47 pmEdit: Seems there may be more than one encryption. I've broken the lua script encryption, but downloaded a Sonos driver that appears to be encrypted differnetly.
I was going to recommend downloading a driver, but I now see you've already done this. I guess it should not be surprising that there are multiple types of encryption.
@Azazel There was an older form that used a badly implemented symmetrical AES encryption. Documented (for educational purposes only) here
The new one uses public/private key encryption using the openssl library. aes-256 cbc. The encryption code in python is freely available on their github page: https://github.com/control4/drivers-driverpackager/blob/master/createc4z/CreateC4Z.py
Another idea that someone contributed but I haven't tried myself is to attach a debugger to cryptolib.dll on the virtual director. Might be easier 😀
Yep,
Realised all this after I wrote the code to reverse the old protection 🙂
Downloaded a driver, then realised straight away what was going on 🙂
Certainly won't have the time to continue on with the public/private decryption any time soon; I published an early release of my C4 File downloader and there didn't appear to be much interest in that.
I see the value in this, so i'll certainly look into it when I have time. A quick glance, into the Director exe, and i'm pretty confident the drivers.p12 is your private key.
I’m interested in this as well, there’s a decryptor available on zen hacks for the old encryption, I’ve had little luck finding a decryptor for the C4z file type.
Hi @azazel, would you have an example of how to decrypt once the private key has been discovered?
@Dingleberry, if you have the key and know the password you can just use openssl to decrypt the lua file.
"""
openssl smime -decrypt -binary -in Code.lua.encrypted -inform DER -out Code.lua -inkey c4.private.pem
"""
Once you have a decrypted driver you need to edit driver.xml and remove the encryption flag from the source. To repackage a driver, just zip all the files back together but exclude the original encrypted lua file.