Featured post

A new year, just begun…

If you’re here, you might be aware that I’m looking for a new job.


I’ve decided to put together this small single-purpose website for the sake of finding my way into your offices. You likely have some position open somewhere, some desk sitting empty with an idle little SIP endpoint. I want to be sitting at that desk. I want to talk to people on that dusty G.722 codec. And you can make that happen.

I’m excited to find a place that values a highly technical asset. I have a broad base of knowledge and experience that can add horsepower to your company, department, and team. I work well with others and I love to collaborate on hard projects with problem solving. I have tons of other positive attributes that you’re going to scan past while reading, so I’ll jump straight to the point.

We should have a meeting, you and I, to discuss how I can add to your company. You will find a link to the current edition of my resume on the right sideat the bottom of this page.

Stick around. I’ll be updating this journal with more details of my past and current projects.

Creating a community on Reddit

At one point in my history with Reddit, I helped foster and build a community centered around people in the Minneapolis/St. Paul metro area getting together. For lack of a more creative name, I called it /r/twincitiessocial. (Note the sidebar, which says “created by ironiridis“.)

Like any community, the initial development was slow and clumsy. It was only with the excellent involvement of other members of the community that it was able to build into a much larger, more successful “subreddit”. It taught me quite a lot about interacting with people, about handling conflict, and about the advantages (and strong disadvantages) of each member’s investment in and ownership of the various meetings.

A conflict that arose was over the public use and acknowledgement of drug use. Certain members were intent on hosting events for the purpose of using cannabis. In retrospect, this should have been obvious from the outset, but it caught myself and other leading members by surprise. We decided to make a formal declaration that such meetups would be explicitly removed, with a series of justifications, foremost of which was the Reddit Terms of Service that disallowed the discussion or advocation of any illegal activity. This resulted in the community’s first major splintering, and the creation of /r/twincitiesents by some with a strong opposition to the declaration.

Another community conflict grew over time from the size of /r/twincitiessocial, and from that popularity, its increasing deviation from “social” things. Many of the most popular posts at the time were humor, complaints, and in one particularly divisive case, threats against an entire group of people. When the leading members discussed the issue, it was clear that there was an ideal solution: push off-topic posters to re-post their content on the more general community /r/twincities. When the soft suggestions were ineffective over a few months, a harder line was drawn with removal of off-topic posts. The second major community conflict stemmed directly from this, and led to my resignation from the community as a whole.

Now in the better hands of community leader Brian Grondin, the communities have flourished. /r/twincitiessocial continues to be active and very focused, and /r/twincities has been resurrected as the most relevant community available for general discussion of the Metro area.

I’m proud of what those communities have accomplished, and happy to have them now under the guidance of a smarter person.

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