If you have a device with a dot matrix LCD such as the 128x64 pixel KS0107/8 and you want to capture the output or monitor the display remotely, then the Dot Matrix LCD Sniffer/Decoder Bluetooth Adapter (DoMSnif) is just the thing you need. It will passively monitor the parallel display data from any supported LCD screen, and send it via Bluetooth or USB to a device of your choice where it can be decoded, processed or even interacted with.
With the ability to decode this LCD data sorted, the next logical step was to miniaturize the components, so it could parasitically clamp onto any device's LCD cable and stream the data to an external device:
There have been a few challenges along the way, but this won't hinder the development of a device that will breath new life into locked down, feature deprived hardware.
All DoMSnif code on these project pages or subsequent code repositories are licensed under the GNU General Public License (GPL) unless otherwise stated. Documentation on these project pages are licenced under the Creative Commons Attribution-Share Alike 4.0 license.
So after mulling over a few options, it looks like it's best to do the decoding on a dedicated microcontroller and send a decoded LCD frame buffer periodically to a Bluetooth controller, which can then send this data to a client at its own leisure.
This solution means that there is no interruption to the high priority interrupts required to capture all the LCD instructions (which happens on the NRF52 when Bluetooth is operational). If you miss any of these instructions coming in, the decoded image can become corrupt, as each instruction either tells it which column/page to write in or which pixels to write.
The sending of data over a UART connection from the decoding chipset to another Bluetooth controller will not interfere with this, as it will send bytes "when it can" between LCD instructions. This transmission happens as a simple start sequence, then sequentially reading out each display byte and finally a CRC check. This is then buffered by the Bluetooth controller and sent to a client periodically. This framebuffer is essentially the bitmap of the image, so the client doesn't require anything fancy to decode it.
For the prototype it's still using the Feather for the Bluetooth comms, but it now also has as a Teensy for the dedicated LCD decoding:
The final version will consist of a much more simplified board containing an NRF52 chipset for Bluetooth, a SAMD21 for the LCD decoding, some level converters and a power supply. Something along the lines of this:
The code is "mostly" working on the prototype, but it still requires some testing. There was some issues building BLE support into the Visual Studio demo application so the data could be visualised. But that for the most part is working now with the help of the Universal Windows Platform, Windows.Devices.Bluetooth classes:
After some testing, the nRF52832 on the Feather module being used is not going to work well for this project alone.
The data is fed into the LCD approximately every 14us:
However the critical radio sections of the nRF52832 can take much much longer than this:
These Bluetooth critical sections have the highest priority on the nRF52832 (otherwise they wouldn't work), so several LCD data events can occur before the LCD data ready interrupt is actually triggered (aliasing/skipping data).
So now to find another method of gathering the LCD data...
Whipping together a quick prototype adapter board for the NRF52 Feather was pretty simple. The main thing to note was level conversion between the 5V LCD signal lines and the 3.3V pins of the feather which in this case was achieved through some resistor dividers. The 5V line is connected to the VBUS (5V) input of the Feather to power the board from the LCD cable.
A smaller, more streamlined board will be created later. But now there's software to write!
There's very few visualisation tools out there to translate the binary KS0108 LCD data to an actual visual output and none offered the ability to import or display a dataset from any source. So I guess we have to make one.
Fortunately the KS0108 has a pretty simple layout:
A KS0108 based 128x64 pixel LCD module consists of two controllers, each with 8 pages and each page consisting of 64 column bytes. So we can structure the code very similarly:
Combine this with a little GUI magic and we get a nice little tool to import data from a CSV file and output it to a window in realtime:
Now, we have the base code for decoding the KS0107/8 module, we can now start porting it to an NRF52 board.
If you can hear audio, then it can be recorded by another analog source, rendering DRM ineffective.
The same can be said about any device. If you can see the data you want, then you can record it. Well fortunately we don't have to go quite Neanderthal on such devices with a camera setup. Instead, we can sniff the display data directly.
Adding an additional 20 pin header to the ribbon cable of the LCD connection (or creating a pass through board), gives us direct access to the digital data being sent to the LCD display. While there was no markings on the LCD board to determine its interface, by looking at the signalling it was found to be a KS0107/8 based device used in most hardware devices.