Tag Archives: AMX

AMX automatic source code decrypter

AMX has always had a good reputation of making programs and touchpanel projects extractable from the device they’re loaded into. Nearly all AMX touchpanels can be extracted, but source code can be a little more unlikely.

AMX software is developed in a program called NetLinx Studio. Depending on some preference values set by the user, when a program is compiled, an SRC file (for “source”) can be generated containing all of the source files used to compile. If this file exists, an upload of the compiled binary will also queue up an upload of the SRC file. Another preference option in NetLinx Studio is to generate these SRC files encrypted with a password.

As it turns out, an SRC file is simply a ZIP file with a different extension. Likewise, the encryption method used with SRC files is the same legacy encryption offered by PKZIP version 2.x. This type of encryption is vulnerable to something called a known-plaintext attack, which means that if you already know some of the contents of a ZIP file, you can deduce how it was encrypted by comparing the original and encrypted versions. And by luck, we have that too.

NetLinx Studio includes in every SRC file a copy of NetLinx.axi, which defines all of the language constants and definitions used at the time of compilation. This is important, because everyone uses the same NetLinx.axi files, so SRC files are especially vulnerable to the known-plaintext attack. The only difficult part is in gathering the various versions of NetLinx.axi.

I observed that ZIP headers expose the CRC of the unencrypted file. Using this CRC, I can uniquely identify the version of NetLinx.axi inside the encrypted SRC file. After going through our historical files and gathering (what I believe to be) every version of NetLinx.axi that was ever released, and discovering their CRC values, I built a library of these sorted by CRC for the attack. The shell script that I wrote follows this sequence:

  1. Get the CRC value from the ZIP header for NetLinx.axi
  2. Look up that value in our folder; if it isn’t found, bail out
  3. Automatically set up the correct command line for PkCrack
  4. PkCrack outputs the password for the SRC file to successfully extract.

This process takes about 5-10 seconds in total.

Technologies: AMX; Linux, Bash

Vidyo AMX and Crestron Modules

Vidyo was referred to my company by a Crestron representative when they were looking to build a custom control module for integrating with their VidyoRoom line of dedicated codecs. Vidyo was happy to learn that we also provide AMX programming support, and so we set out to build both the AMX and Crestron modules that Vidyo would offer as standard for their products.

As with most projects, the most challenging part of this project was communication. We initially failed to understand their needs and also failed to communicate the timeline we anticipated. Much of the project was spent recovering from this mishap and rebuilding trust with Vidyo, while trying to negotiate a reasonable delivery criteria we each could agree upon. Fortunately, we met this goal and continued to build our relationship with Vidyo.

In terms of technical challenges, Vidyo needed a fairly straightforward conversion of their on-screen interface into the example programs shipping with the modules. Their on-screen interface had access to a wealth of internal state data and queries that the API didn’t yet offer, so we coordinated on improving the API with Vidyo to make these tools available. In addition, their UI included some patterns that we hadn’t yet implemented in the AMX or Crestron spaces. One particular example:

  1. User enters a string on touchpanel
  2. The controller calls a Vidyo API to determine what types of results are returned when this string is searched for on their portal
  3. When the results are returned, a further API call is made to determine the state of the endpoint in some conditions
  4. Finally accumulating the information, the correct API command can be issued to initiate the video session.

While this type of interaction would be simple and near-instant with modern programming (for example, making an SQL query or firing a library call) particularly with blocking calls while this processing occurs, Crestron and AMX have no such benefit. Neither system offers a blocking call per se, all inputs and outputs are asynchronous. As such, there is a lot of complex state maintenance in that code to understand what the results actually mean when they are returned. The AMX module in particular adds quite a lot of context information back to the main program when this type of exchange occurs, taking that burden off of the programmer.

The AMX module on AMX.com and the Crestron module on Crestron’s Application Market are the modules I developed and published during my time with Advanced Control Systems. The documentation was also produced by myself and my coworker Steve.

Technologies: AMX; Crestron; RS232/Serial; TCP/IP

Intelix AMX and Crestron Modules

Intelix approached my company to create a suite of modules for an upcoming line of hardware that would ease integration of Intelix products with AMX and Crestron systems. I was assigned to this project mainly because I had the appropriate skills for both ecosystems and I was already familiar with making modules from our prior engagement with Vidyo.

This project presented two main problems:

  • Their internal API documentation we had was revised during our work, prior to receiving the products with which to test.
  • The wide variety of products, with varying APIs and capabilities, made presenting a consistent interface difficult.

The FLX-series hardware had a particularly tricky design to model within the Crestron module, as the hardware itself is reconfigurable, and the module needed to provide a static all-encompassing command set due to language restrictions. We solved this by providing several sub-modules that could be cherry picked depending on hardware as configured.

The modules offered by Intelix on their website today are the modules I developed and published during my time with Advanced Control Systems. The documentation was also produced by myself and my coworker Steve.

Technologies: AMX; Crestron; RS232/Serial; TCP/IP