As I mentioned in the previous post, my university uses a somewhat rare access control technology called 'MARLOK': each user is issued a key, whose identity is encoded in a series of holes in the shank of the key (kind of like an old punch-card). The key is inserted into a reader next to a door, and if the user has privileges to the door, it is momentarily unlocked.
I was interested in reading the key (and possibly eventually building something to emulate the key, in a reader), so I had a couple of little boards made to mount infrared emitters and detectors at the appropriate distances to read the three tracks of the key.
Initial Research
Before doing all this, I tried to look up the MARLOK system on the internet. Details were sparse; the only information of any substance is here, where someone reports that each key encodes 24 bits of ID. Otherwise, there's very little info out there; nothing on the structure of the encoding, how the clock is embedded/recovered, etc.
The Current Test
The sensor (with key inserted) is shown below. The emitters are Kignbright APT2012F3C; they are wired in parallel with a 460Ohm current limiting resistor, leading to a total of 5mA passing through them collectively. The detectors are Everlight PT19-21C/L41/TR8 phototransistors; they are connected to the positive rail, and then through 2.2kOhm resistors to ground. The voltage is sampled at the top of the resistors by a microcontroller, then sent out at 100Hz through the serial port.
The key has three tracks; the black plastic is infrared-transparent. The metal of the key is punched with square holes to allow for IR light to travel through the key.
The ends of two of the tracks were totally accidentally exposed, to show the structure of the holes (shown below). As you can see, the holes are square. From the data I show later, the middle track is a clock signal; this makes sense, as the middle hole is offset from the exposed side track by a half-hole-width, so that transition on the clock track signals when to sample the data tracks.
Below is a plot of the three track traces; the left is when the sensor was seated at the base of the key, and the right occurred as I slid the sensor off the key. Green is the middle track, red and blue are the side tracks. Note that it took a little messing around to get this data; originally, the LED current was three times what it was for these trials, and it saturated the clock channel (since, being in the middle, it got illumination from all three LEDs).
This next is the same information, but at the end of the sensor removal, as the sensor comes of the end of the key.
From the data, I saw that the middle track was the only one that was always on; from this (and the fact that its holes were offset from the other tracks' holes), I assume it is the clock signal.
Looking at the traces over a full sensor-removal, I saw the following patterns of holes:
01111110011101
11111111111111 END OF KEY>>
00001001110111
As i said above, the middle track was the only one that was always 'on'. Additionally, since the first clock has both 'on', and the last has both 'off', and the internet says these keys encode 24 bits, and there are 14 total clock pulses, I assume that the end-of-key data track bits are always 'on', and the base-of-key data track bits are always 'off', which likely helps in level determination and data recovery.
Moving Forward
As evidenced in the data traces, I'm having difficulty keeping the key straight in the sensor; I'll need to do something to mechanically narrow the passage. Once this is done, it'll be possible to recover sampling times from the clock transitions. It might also be possible to improve the signal level by masking the LEDs so that they don't bleed over into the other channels as much.
Data Recording Software
To get this data, I created a microcontroller firmware that samples the three channels, then packs each 12bit sample into a message packet (which includes a start sentinel nibble for frame alignment) and sends it over the serial port. I then created a general-purpose serial port data-extractor and -viewer for MATLAB, which is available here.
I was interested in reading the key (and possibly eventually building something to emulate the key, in a reader), so I had a couple of little boards made to mount infrared emitters and detectors at the appropriate distances to read the three tracks of the key.
Initial Research
Before doing all this, I tried to look up the MARLOK system on the internet. Details were sparse; the only information of any substance is here, where someone reports that each key encodes 24 bits of ID. Otherwise, there's very little info out there; nothing on the structure of the encoding, how the clock is embedded/recovered, etc.
The Current Test
The sensor (with key inserted) is shown below. The emitters are Kignbright APT2012F3C; they are wired in parallel with a 460Ohm current limiting resistor, leading to a total of 5mA passing through them collectively. The detectors are Everlight PT19-21C/L41/TR8 phototransistors; they are connected to the positive rail, and then through 2.2kOhm resistors to ground. The voltage is sampled at the top of the resistors by a microcontroller, then sent out at 100Hz through the serial port.
The key has three tracks; the black plastic is infrared-transparent. The metal of the key is punched with square holes to allow for IR light to travel through the key.
The ends of two of the tracks were totally accidentally exposed, to show the structure of the holes (shown below). As you can see, the holes are square. From the data I show later, the middle track is a clock signal; this makes sense, as the middle hole is offset from the exposed side track by a half-hole-width, so that transition on the clock track signals when to sample the data tracks.
Below is a plot of the three track traces; the left is when the sensor was seated at the base of the key, and the right occurred as I slid the sensor off the key. Green is the middle track, red and blue are the side tracks. Note that it took a little messing around to get this data; originally, the LED current was three times what it was for these trials, and it saturated the clock channel (since, being in the middle, it got illumination from all three LEDs).
This next is the same information, but at the end of the sensor removal, as the sensor comes of the end of the key.
From the data, I saw that the middle track was the only one that was always on; from this (and the fact that its holes were offset from the other tracks' holes), I assume it is the clock signal.
Looking at the traces over a full sensor-removal, I saw the following patterns of holes:
01111110011101
11111111111111 END OF KEY>>
00001001110111
As i said above, the middle track was the only one that was always 'on'. Additionally, since the first clock has both 'on', and the last has both 'off', and the internet says these keys encode 24 bits, and there are 14 total clock pulses, I assume that the end-of-key data track bits are always 'on', and the base-of-key data track bits are always 'off', which likely helps in level determination and data recovery.
Moving Forward
As evidenced in the data traces, I'm having difficulty keeping the key straight in the sensor; I'll need to do something to mechanically narrow the passage. Once this is done, it'll be possible to recover sampling times from the clock transitions. It might also be possible to improve the signal level by masking the LEDs so that they don't bleed over into the other channels as much.
Data Recording Software
To get this data, I created a microcontroller firmware that samples the three channels, then packs each 12bit sample into a message packet (which includes a start sentinel nibble for frame alignment) and sends it over the serial port. I then created a general-purpose serial port data-extractor and -viewer for MATLAB, which is available here.
No comments:
Post a Comment