wired CSV | miscellaneous | 220pts
This was an interesting misc challenge. The problem provided us with an image of a logic circuit along with a large CSV file containing the timestamps that voltage switches between high/low. I had absolutely no clue where to start with this problem having almost no background with hardware, however I did work on this problem with one other person who solved it with ease while walking me through it.
It’s pretty hard to see from the size here but if you zoom in you can make out the markings on the chip as well as the labels on the tape for some of the wires. We have an Atari POKEY chip hooked up to a Saleae Logical Analyzer.
The 0/1 values in the CSV file correspond to the values recorded by the logic analyzer, and each is timestamped for when the the wire switches between high/low. We then parse the data in the CSV file.
From Wikipedia we can get the following image:
If we zoom in on the tapes of the wires we can make out the number ‘6’, which corresponds to the blue wire that is plugged into the logic analyzer as the 7th wire from the top. If we assume these numbers are indexed from 0 we can now tell which colored wire corresponds to each numbered wire in the CSV file. We then look at the chip side of the wire to see which pin each wire is connected to. We end up with the following mapping:
Wire 0 – K0 Wire 1 – K1
Wire 2 – K2 Wire 3 – K3
Wire 4 – K4 Wire 5 – K5
Wire 6 – KR1 Wire 7 – KR2
From the Data Sheet we find out that these pins correspond to keyboard codes. In the data sheet we also find the following useful information for interpreting these codes:
Unfortunately, the data sheet had no information about how to decode the 6-bit binary counter, however a google search revealed the keyboard mapping.
KR1 is the important pin as it indicates when to debounce the keyboard code. Therefore we want to loop through the data with respect to when KR1 switches between high and low. We implement the debouncing logic using the data sheet.
After running this we get the following output:
Not quite correct. After some debugging I figured I must be computing the state of K0-K5 incorrectly at a given time that KR1 switches between high and low. I noticed that a lot of the keys were being decoded as 2 keys being depressed. In these cases, one of the lines (K0-K5) had changed extremely close to when the KR1 line switched from high to low, by a factor of about 10-7. This caused my code to place the incorrect value for this line’s bit in the compare latch. I then added a threshold to the indexOf_closest_time function so that the closest time found must be smaller than the time being queried for by at least that threshold.
This returned the correct flag: FLAG;_8-BIT-HARDWARE-KEYLOGGER\n. Unfortunately this is slightly misspelled due to the threshold not being tuned perfectly.
@speeeday 