Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Hey guys,
I have a couple of Keri NXT keychain-style tags, with serial numbers that begin with N. The format is not Pyramid or anything detected by the standard lf search, but I have made some progress and have successfully cloned one of the tags to a standard T5557 card.
What I have so far: it's a 125kHz carrier, FSK2 modulation, RF/50 bitrate, inverted. Cloning is as easy as lf search u, data rawdemod fsk2, data print x. Then configure the T5557 like below, and write the 16 bytes of data to blocks 1-4 like any other tag. The card serial number is Wiegand format with an 8-bit site code and 16-bit user code, printed as something like NXXXX YYYYYY where YYYYYY=65536*site+user. The XXXX seems to be irrelevant (probably just for Keri's record keeping).
What I don't have yet: the card 26-bit Wiegand code is encrypted into the 128 bit data, and the encryption seems very difficult to break. I have two tags with adjacent serial numbers, and the bit patterns look completely different apart from a standard 4-byte start sequence. The other 96 bits are encrypted (Keri does advertise NXT as using 96-bit encryption, so this makes sense). It can't be that difficult because the reader has to undo the encryption, so it's likely something simple, but I haven't figured it out yet.
Ask: I need a copy of the firmware .bin file for any Keri NXT-compatible reader. Can't get this from Keri without a dealer login. Then I can perform disassembly and static analysis to figure out the encryption (I'm pretty sure the 26-bit Wiegand data is sent unencrypted over the RS-485 link). PM me if you can help!
I would share the card serial numbers here but it may reveal my identity so I'm going to not do that on the public forum at least.
-- T55x7 Configuration & Tag Information --------------------
-------------------------------------------------------------
Safer key : 0
reserved : 0
Data bit rate : 4 - RF/50
eXtended mode : No
Modulation : 5 - FSK 2 RF/8 RF/10
PSK clock frequency : 0
AOR - Answer on Request : No
OTP - One Time Pad : No
Max block : 4
Password mode : No
Sequence Start Terminator : No
Fast Write : No
Inverse data : Yes
POR-Delay : No
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x00105082 00000000000100000101000010000010
-------------------------------------------------------------
Offline
Update: looking at the pictures in https://fccid.io/N42KERINXT5R/Internal- … os-1185414, it seems like the Keri NXT readers (e.g. NXT-3R, NXT-5R) use simple PIC16F series microcontrollers. This makes me even more eager to get hold of the firmware.
Last edited by HackAgenda (2017-12-30 02:34:16)
Offline
Some additional information from http://license.kerisys.com/docs/Serial_ … _Rev-A.pdf: the 4 digits of the tag serial number (after the 'N', or the 'K', etc.) are a manufacturing date code. The first 3 digits are the day of the year (e.g. 358), the last digit is the last digit of the year (e.g. 5 for 2015). This confirms that it isn't related to the internal code.
Offline
Phew, another update: I now have copies of the latest version of Doors.NET, and the latest NXT-3R reader firmware binary file. It's definitely PIC format and I'm working on the disassembly file now, but it's going to be difficult and may take some time...
Offline
HackAgenda!
Thank you very much for the first 4 four digits on the card keri )!
Offline
Conclusion of what is figured out.
NXXXZ AABBBB
where
XXXZ = manufacture date code
- Z is the last digit of the year (e.g. 5 for 2015) (decimal)
- X, the day of the year (e.g. 358) (decimal)
AABBBB= sitecode << 32 | cardnumber
Offline
A quick update. I've decompiled and understood maybe 1/2 of the NXT reader firmware. It's not easy and there are still many missing pieces.
One thing I've learned is the Keri NXT cards have an "internal card number" which is a bit scramble of the "external card number". The algorithm to convert between the two is quite simple. However, the internal card number bears no relation with the 11 bytes of data stored in the card's memory. I'm pretty sure the 11 bytes include a checksum because modifying a single bit at a time and writing the number to a T55xx produces a card that the reader doesn't respond to in any way at all, whereas with a valid card the reader will immediately beep before talking to the controller.
Would love to figure out whether the reader actually decodes the 11 bytes into the "internal card number" before sending it over the RS-485 link, or whether it sends the 11 bytes raw and just computes a checksum. If it's the latter then I'll need to decompile the NXT controller firmware to figure out the decode algorithm, which will be more difficult since the firmware is much larger, MPC555X, and in a different format.
Offline
Some additional information from http://license.kerisys.com/docs/Serial_ … _Rev-A.pdf: the 4 digits of the tag serial number (after the 'N', or the 'K', etc.) are a manufacturing date code. The first 3 digits are the day of the year (e.g. 358), the last digit is the last digit of the year (e.g. 5 for 2015). This confirms that it isn't related to the internal code.
Thanks for this.
Offline
Hello I have a Keri keycard not the small fob. With a pm3 could I clone it to my t5577 chip Implanted in my hand
Offline
Reverse engineering the NXT reader firmware turned out to be very difficult - no further progress made here unfortunately. The next step would be for someone with a NXT reader to figure out whether the reader itself decrypts the data. You'd need to look at what the reader sends over the RS-485 link when it reads one of these tags.
Offline
You would have to find the encryption key for the on board 128 bit encryption and the correct encryption type. The data encrypted is in the Pyramid block layout. Once decrypted, the actual data bits might be scrambled and have other abstractions. It's a real mess. Looking at the Kerri firmware, just on the surface, those guys have a hard-on for encryption and i can see why.. it locks down the card dead right. A real bunch of pros hacking on the firmware would be needed, perhaps with other clues, to get that format nailed down.
Offline
Sorry to gravedig an old post but could I possibly grab that firmware image? Also, has anybody sniffed the reader-card crypto exchange? Not to get too optimistic, but it would be funny if I could just replay the signal on my SDR ^_^
Offline
Hey guys,
I have a couple of Keri NXT keychain-style tags, with serial numbers that begin with N. The format is not Pyramid or anything detected by the standard lf search, but I have made some progress and have successfully cloned one of the tags to a standard T5557 card.
-- T55x7 Configuration & Tag Information -------------------- ------------------------------------------------------------- Safer key : 0 reserved : 0 Data bit rate : 4 - RF/50 eXtended mode : No Modulation : 5 - FSK 2 RF/8 RF/10 PSK clock frequency : 0 AOR - Answer on Request : No OTP - One Time Pad : No Max block : 4 Password mode : No Sequence Start Terminator : No Fast Write : No Inverse data : Yes POR-Delay : No ------------------------------------------------------------- Raw Data - Page 0 Block 0 : 0x00105082 00000000000100000101000010000010 -------------------------------------------------------------
----
HackAgenda,
What were the commands you used to read the NXT Keri fob that was not detected by the standard LF SEARCH?
thanks.
Offline
HackAgenda,
What were the commands you used to read the NXT Keri fob that was not detected by the standard LF SEARCH?
thanks.
The tags can be read by a "lf search u", followed by "data rawdemod fsk2" then "data print x".
Offline
Sorry to gravedig an old post but could I possibly grab that firmware image? Also, has anybody sniffed the reader-card crypto exchange? Not to get too optimistic, but it would be funny if I could just replay the signal on my SDR ^_^
Here's a snapshot of all the firmware files in Doors.NET circa 2018: https://gofile.io/?c=jATxO9
The relevant files are NXT_v020568.bin and possibly RIM_v030321.bin, depending on whether it turns out to be the card reader itself or the RIM interface module that decrypts the sequence emitted by the card.
There is no reader-card crypto exchange, the tag just transmits a repeating and fixed 16-byte sequence when activated. However, the data in the sequence itself is encrypted. So it's easy to clone a tag using a standard T55xx by copying the byte sequence, but you can't map from the card number to the byte sequence or vice versa without understanding how it is encrypted.
Some useful links:
http://www.microchip.com/wwwproducts/en/PIC16F88
http://ww1.microchip.com/downloads/en/D … 30487c.pdf
http://ww1.microchip.com/downloads/en/D … 01291H.pdf
https://www.nxp.com/docs/en/reference-m … 554_RM.pdf
Good luck!
Last edited by HackAgenda (2019-09-02 18:18:05)
Offline
Pages: 1