Tag Archives: ACSDi

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

Crestron automatic module deobfuscator

One problem my company faced on occasion, while working with legacy programs from other vendors, was receiving Crestron programs or modules that were password protected to prevent viewing and modification. Programs could still be compiled without the password, and protected modules could be added to other programs, but that was all.

I spent some time considering the design Crestron may have used for this. If it were my system to develop and there were no backwards-compatibility concerns, I’d probably use some sort of public key/private key encryption, with the private key hidden inside of the compiler.

As it turns out, the “encryption”, or rather, obfuscation was far simpler than that. Without going into details, it turns out the password for protection was included in effectively clear-text inside the protected file, always at a certain position. I wrote a small tool to parse a source file, look at the position, and output the password. (After all, it’s far simpler to allow the vendor’s tools to handle decryption.)

This script was hosted on the internal server and is still among the company’s set of tools. It has saved considerable time and effort on a few occasions.

Technologies: Crestron; Linux, Apache, PHP

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

Deploying files to our field technicians

One of the initial challenges my company faced early on was getting files to technicians. Our work involved creating large binary files that were not always friendly with email attachments.

The original solution for this problem was Afian File Manager, which worked rather well for our small company. The Afian solution had the following drawbacks, however:

  • Only one file could be uploaded at a time
  • Files made two long-distance trips; one to the hosted server, then one to the tech
  • Technicians would have to manually refresh the page to see new files
  • The file upload process involved invoking a file upload dialog in a web browser
  • The hosted server had storage & upload size limitations, and we had big files
  • Manually removing older files for older jobs was painful and slow

(Note that this was 2008, and Afian has improved quite a lot in the interim.)

As we continued to grow and business continued to hasten, these drawbacks grew more and more troublesome. While working on my own jobs, I used some of my downtime to work on a new solution I dubbed “Staffian”. Staffian solved the problems above in a few ways:

  • Locally hosted on our Linux machine, so files only make a single long-distance trip
  • Folders served internally via Samba to integrate well with a workflow in Windows
  • Fully Ajax-powered, so technicians would see file updates near-instantly
  • Leveraged a huge amount of storage that we already had
  • Automated archival and deletion of older jobs

As the tool grew over time, we added additional features:

  • Automatic access to a shared folder of common resources (e.g. software)
  • Automatic user management with password generation in one click
  • Logging user logins and downloads with a live-updating internal viewer

That tool served us very well over 6 years. Just before my departure, I was working on a full-rewrite of Staffian to modernize it further. I’ll write about that in a future post.

Technologies: Linux, Apache, MySQL, PHP (ie LAMP); Samba; Ajax