Hacks

Hack: Elecrow Laser Engraver Tool Protocol

~ admin ~ Leave a comment

Disclaimer: Contains Amazon Affiliate and direct links to products.

This is Part II of our Elecrow Laser Engraver Tool hackery:

What We Did

Roughly:

  • Sniff USB (under both Windows and OS X)
  • Identify packets to/from the ELET (Elecrow Laser Engraver Tool)
  • Isolate individual commands by pushing app buttons and seeing what was sent and received
  • Formalize those commands for repeatability

This is the same process you’d use to reverse engineer any protocol, e.g., if you want to find out how the littleBits app talks to their CodeKit board, or what commands are being sent to your cheap ESP8266 120V relay controller, or pretty much anything.

How We Did It

The first step in figuring out how the Elecrow app was talking to the engraver was to sniff the USB connection. Under Windows we used USB Analyzer. Under OS X we used Wireshark, but needed to bring up the interface so Wireshark could track it:

$ sudo ifconfig XHC20 up

(And conversely bring it down when we were done.)

Wireshark is pretty great, by the way, but provides very complete information, which isn’t always what we need. In this case we needed to filter by the source, so we clicked the “Fan” icon and looked for likely suspects in the Wireshark display.

We knew from Windows USB sniffing that the fan on/fan off commands were four bytes long, but under OS X we were seeing the entire block of 32 bytes plus the payload data from the Elecrow software, so our first guess was to look for something that was 36 bytes long:

Wireshark: Find the Device
Find the Source, Luke

Once we had that we could set a display filter to see just this data, and add a column to display it:

  • Filter the Source, Luke
  • Isolate useful data

Getting this data into something we could (trivially) look at and dissect was a dive back into the world of Wireshark. First we saved just our filtered packets:

Wireshark: Export Displayed Packets
Export Displayed Packets

Then fell into the following workflow (roughly):

  • Capture and filter data as shown above
  • Export the selected packets via Export Specified Packets…
  • And only exporting the “Displayed” packets (as per our filter)
  • Run tshark to save off just the “Leftover Capture Data”…
  • …and strip out the newlines via tr so they didn’t muck up the analysis
  • Turn this into a binary file with a quick-and-dirty script
  • Analyze the result

Here’s the tshark command to save just the isolated data (and strip out the newlines to create a clean binary file for analysis):

tshark -r test2.pcap -T fields -e usb.capdata | tr -d '\n' > outfile

The Python script, lifted off the net somewhere, but it’s trivial to implement in any language:

import binascii
import sys
string = open(sys.argv[1],'r').read()
sys.stdout.write(binascii.unhexlify(string)) # needs to be stdout.write to avoid trailing newline

Under OS X we tried out Synalyze It! and it was okay, but we found the grammar creation to be a bit fraught. Honestly for this it wasn’t worth the effort since (a) the messages were short anyway, and (b) we pretty much knew we were going to replace the controller board, but it was interesting.

(It did, however, highlight the need for one of our old, old projects that’s been on the backburner for a number of years–our Data File Disassembler, that we’ll bring into the modern age Real Soon Now.)

To sanity-check our assumptions we cobbled together a small NodeJS app and we were able to turn the fan on and off (04 00 04 00, 04 00 05 00 respectively) under a separate app, but that was as far as we wanted to take it. Knowing (a) it was a custom protocol that (b) didn’t work with anything else was enough for us.

The initial protocol hacking notes are in a Github repo. If we (or anyone else) develops any tools around its native protocol we’ll try to keep the repo updated. If nothing else, we may include a tool that’ll wrap up the protocol capture so the binary files can be downloaded to an RPi which could then be used to send duplicate commands to a printer, allowing semi-automated printing without having to use the included application.

What’s Next

In Part III we’ll start grafting on a commercially-available SainSmart controller we hope will be a drop-in replacement (delta the GRBL configuration) for the controller board that comes with the ELET. Hint: worked out of the box, just needs configuration and endstops.)

Resources

Products