Greenlight HPS Part 3: Planning an Attack

(Warning, wall of text!)

So we had this laser which probably not only had more interlocks than a nuclear reactor, but also actively prevented us from defeating those interlocks. What we wanted in the end was to be able to dial in a diode current, and have the diode driver run the diodes at that current. We also needed the crystal temperatures, water temperatures, and Q-switch settings to automatically adjust themselves according to the user current setting.

From the service information AMS had leaked on their website (the AMS Technical Services site is riddled with holes), we knew the following:

• The service fix [Check CAN bus cables between LCB and LPS] to problem 130 in the HPS Problem Codes indicated that the subassemblies communicated via CAN (an automotive bus).
• The description of problem 209, [A voltage supply is out of spec. on the Laser Power Supply/Vuemetrix board] indicated that the diode driver was manufactured by Vuemetrix. The output power suggested that it was a variant of the VueHV stack driver.
• The following screenshot from an instructional document shows the current vs. power for a typical laser:

XPS but you get the idea

Knowing this, we had several approaches to turning on the laser.

1. Disassemble the laser into constituent subcomponents, turn on those subcomponents, and reassemble into a laser. This meant figuring out how to turn on the chiller, diode driver, and Q-switch driver. We knew the Vuemetrix driver could probably be persuaded to connect to the VueHV software, and the Q-switch driver was a stock NEOS part.
2. Spoof a surgical smartcard. We were able to get a smartcard off of eBay. The card had "Atmel" written on it, which meant it used an Atmel Cryptomemory secure IC. The cryptomemory had several known exploits, including a brute-force approach which would have taken ~70 days on my fastest machine, and a power analysis approach which was more involved, but would have only taken a few minutes.
3. Exploit the unencrypted nature of the CAN bus to figure out what messages did what, and build a new controller that played the appropriate messages over the bus.

(1) had the advantage of being guaranteed to work; however, it meant we would lose the self-protection that the stock Laserscope controller provided, and we figured that having things like underflow and overtemp were good. (2) was also known to work, and was pretty much a standard power analysis attack; unfortunately, neither of us had much experience in such techniques. (2) would have also given us a completely turn-key way to turn on the laser, one that did not involve any extra hardware.

We decided to go with #3 because we had access to a borrowed CAN transceiver, and we figured it was a good middle ground between keeping enough of the internal firmware to protect the laser, while allowing us to hopefully build a custom user interface that did not look like a medical interface (as cute as the touchscreen was, being able to monitor critical laser parameters and set power in something other than 10W increments would have been real useful!)