Tags: logic-analyzer hardware image
Rating:
**Description**
> As every year, can you please decode [this](https://archive.aachen.ccc.de/35c3ctf.ccc.ac/uploads/blink.csv.gz) for me?
>
> 
**Files provided**
- [blink.csv.gz](https://archive.aachen.ccc.de/35c3ctf.ccc.ac/uploads/blink.csv.gz)
**Solution**
The image shows a prototyping setup with:
- a LED board (bottom right)
- an oscilloscope (top) showing some squarewaves / digital data capture
- a logic analyser (centre)
- a Raspberry Pi (bottom left)
It is clear that the Pi has a program running that presumably displays the flag on the LED board at some point, and that the logic analyser captured this operation as the file we were given. The oscilloscope might give some additional hints for what to look for in the data but it is not terribly important to solving the challenge.
Unpacking the `blink.csv.gz` file, we can see that it is a quite large (410 MiB) Comma-Separated Values file, i.e. a text-based table format. In the first 21 lines we see some metadata emitted by the logic analyser, but more importantly, we see the labels for all the 10000000 data entries that follow.
```bash
$ wc -l blink.csv
10000021
$ head -n 22 blink.csv
#Model,MDO3014
#Firmware Version,1.26
#
#Waveform Type,DIGITAL,,,,,,,,,,,,,
#Point Format,Y,,,,,,,,,,,,,
#Horizontal Units,s,,,,,,,,,,,,,
#Horizontal Scale,0.004,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#Sample Interval,4e-09,,,,,,,,,,,,,
#Record Length,1e+07,,,,,,,,,,,,,
#Gating,0.0% to 100.0%,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#Vertical Units,V,V,V,V,V,V,V,V,V,V,V,V,V,V
#Threshold Used,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65,1.65
#,,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#,,,,,,,,,,,,,,
#Label,OE,LAT,CLK,E,D,C,B,A,B2,B1,G2,G1,R2,R1
#TIME,D13,D12,D11,D10,D9,D8,D7,D6,D5,D4,D3,D2,D1,D0
-1.0000000e-03,0,0,0,0,1,0,0,0,0,0,0,1,0,1
```
`TIME` is the only column with decimal data, but it is irrelevant to us (it is enough to know that successive lines represent samples taken at successive times), so we will ignore it. The remaining columns are all digital, only taking values `0` or `1`. Some of their labels are clear enough, some not so much:
- `OE` - ?
- `LAT` - latch?
- `CLK` - clock
- `E` ... `A` - ? 5 bits = 64 possible values
- `{R,G,B}{1,2}` - 2 bits for each colour channel - Red, Green, Blue
`CLK` is a very important signal to see in captures like this. It is not trivial to perfectly synchronise two devices, so it is common to use a dedicated clock signal emitted by one device (master) that tells the other (slave) when to read data from the remaining signals. In our case we only need to read data entries when the clock "goes high", i.e. its value is `0` on the previous sample and `1` on the current sample.
At this point we can try to test various theories about how the data is actually transmitted using the remaining signals (`LAT`, `E` ... `A`, and `{R,G,B}{1,2}`). However, for a speedy flag it was worth trying the simplest possible method – what if the Pi transmits displays the flag right away, i.e. there is no metadata exchanged, just pixels?
It would be useful to know what shape the data would be in. The photo is in good enough resolution (and was actually much higher res during the CTF) for us to be able to count the individual LEDs on the LED board. It consists of two 64x64 squares, 128x64 pixel resolution in total.
Then we can assume that `R1` is the most significant bit of the red channel, `R2` is the LSB (not that it really matters), and print out pixels!
[Full pixel reader script](https://github.com/EmpireCTF/empirectf/blob/master/writeups/2018-12-27-35C3-CTF/scripts/Blink.hx)
The output is by no means perfect, but it got us the flag with minimal effort!
`35C3_D4s_blInk3nL1cht3n_1st_so_wund3rb4r`
