Hi everybody
I have a nedap card with two system onboard : one is a mifare DESFire, which I can read with the flipper ; the second is a 125 khz id which I am unable to scan.
I know there is a 125 khz id on this card because it can grant access with 125 khz-only reader. How can I access to the 125 khz id ? I have searched for a raw-record 125 khz reader, but was unable to find it – although I see here and there mention to record of raw RFID informations.
Many thanks for advices !
To get RAW RFID recordings, you should first enable debug mode in settings. And don’t forget to turn it off when you’re done - it inhibits power saving mode.
1 Like
Many thanks maqumih. I have now a raw record and I can dig in it. I will share with you what I can understand form this record.
Maybe sharing the read raw with flipper support and ask for the card support to be added to flipper later?
Hello everydoby
I have now four raw records from nedap LF card :
nedap_raw_LF_4.zip (18.5 KB)
I use GitHub - hnesk/flipper-raw-rfid: A python library for reading and analyzing Flipper Zero raw RFID files (tag.[ap]sk.raw) to transform raw to csv, and I interpret them with Manchester method (Manchester code - Wikipedia). Meantime I have searched for documentation about nedap tag, and I have found an interesting resource from Proxmark : https://github.com/RfidResearchGroup/proxmark3/blob/master/client/src/cmdlfnedap.c
In this code, there is a proposition for structuration of a nedap-tag LF message :
Index map E E
preamble enc tag type encrypted uid P d 33 d 90 d 04 d 71 d 40 d 45 d E7 P
1111111110 00101101000001011010001100100100001011010100110101100 1 0 00110011 0 10010000 0 00000100 0 01110001 0 01000000 0 01000101 0 11100111 1
uid2 uid1 uid0 I I R R
1111111110 00101101000001011010001100100100001011010100110101100 1
0 00110011
0 10010000
0 00000100
0 01110001
0 01000000
0 01000101
0 11100111
1
Tag ID is 049033
I = Identical on all tags
R = Random ?
UID2, UID1, UID0 == card number
From my raw interpretation, I obtain effectively 128 bits stream (with repetition, as attended), but preamble can be found in Manchester and Manchester inverse reading ; and for some tag I have two possibilities to place preamble :
manchester
Ft* -2 : 11111111101001100101011010101010101111010110000111101111110111000001111111110100001100011000111101000110001000000000000101111000
- Ft-1 : 11111111101000011000110001111010001100010000000000001011110001111111110100110010101101010101010111101011000011110111111011100000
- Am : 11111111101000011100000000000111111001101111010101010000101001111000010000001001000001011111110100101101100111011000000111101111
- Mm : 11111111101110011000000011010101010000101001111000010000000000111000010011111001100000110110000111111001110000000000000101111000
- Neh : 11111111101010011001100100101010101111010110000111101111100110111101001111010100100000011000011110111000000000000000000101111000
manchester inverse
- Ft : 11111111101000011100000000010110011010100101010101010000101001111000010000001000111110000000001011110011100111000010111001110111
- Am : 11111111100000011001000010101010111101011000011110111111011011111010000000101101001001100010011111100001000000000000010111100011
- Mm-1 : 11111111101000011100000000010001100111111100101010101111010110000111101111111111000111101100000110011111001001111000000110001111
- Mm-2 : 11111111100011110110000011001111100100111100000011000111111111111101000011100000000010001100111111100101010101111010110000111101
- Neh : 11111111101000011100000000010101100110011011010101010000101001111000010000011001000010110000101011011111100111100001000111111111
Now when I apply the Proxmark structuration to my readings, I cannot retrieve all the properties they assumed, peculiarly P and d bits which are for me not identical. I am not able to find another regularity between my readings.
manchester
préambule tag type (encodé) uid crypté P d uid2 d uid1 d uid0 d I d I d R d R P
Ft-2 1111111110 0100001100011000111101 0001100010000000000001011110001 1 1 11111101 0 01100101 0 11010101 0 10101111 0 10110000 1 11101111 1 10111000 0
Ft-1 1111111110 0100110010101101010101 0101111010110000111101111110111 0 0 00011111 1 11101000 0 11000110 0 01111010 0 01100010 0 00000000 0 01011110 0
Am 1111111110 0100001110000000000011 1111001101111010101010000101001 1 1 10000100 0 00010010 0 00010111 1 11101001 0 11011001 1 10110000 0 01111011 1
Mm 1111111110 0111001100000001101010 1010000101001111000010000000000 1 1 10000100 1 11110011 0 00001101 1 00001111 1 10011100 0 00000000 0 01011110 0
Neh 1111111110 0101001100110010010101 0101111010110000111101111100110 1 1 11010011 1 10101001 0 00000110 0 00111101 1 10000000 0 00000000 0 01011110 0
manchester inverse
préambule tag type (encodé) uid crypté P d uid2 d uid1 d uid0 d I d I d R d R P
Ft 1111111110 0100001110000000001011 0011010100101010101010000101001 1 1 10000100 0 00010001 1 11100000 0 00010111 1 00111001 1 10000101 1 10011101 1
Am 1111111110 0000001100100001010101 0111101011000011110111111011011 1 1 10100000 0 01011010 0 10011000 1 00111111 0 00010000 0 00000000 1 01111000 1
Neh 1111111110 0100001110000000001010 1100110011011010101010000101001 1 1 10000100 0 00110010 0 00101100 0 01010110 1 11111001 1 11000010 0 01111111 1
Mm-1 1111111110 0100001110000000001000 1100111111100101010101111010110 0 0 01111011 1 11111110 0 01111011 0 00001100 1 11110010 0 11110000 0 01100011 1
Mm-2 1111111110 0001111011000001100111 1100100111100000011000111111111 1 1 11010000 1 11000000 0 00100011 0 01111111 0 01010101 0 11110101 1 00001111 0
If you have any idea to pursue this deciphering, please let me know !
Hi everybody
I digg in another direction, due to a more complete reading of https://github.com/RfidResearchGroup/proxmark3/blob/master/client/src/cmdlfnedap.c , in which I found this line :
//NEDAP demod - ASK/Biphase (or Diphase), RF/64 with preamble of 1111111110 (always a 128 bit data stream)
As a consequence, I use Differential Manchester encoding to render my csv, and here are the results :
Ft 11111111100011110100010001100000110010000100000000111000101001010010001110010100110000000000011100010010000000011101010111110111
Am 11111111100011110100010001100000110110000111000000111011101101010011010000010001100000000000011100010010000000000100000101011000
Mm 11111111100011110100010001100000000010010001101000010101000010110100010000010100100000000000011100010010000000011001010100000010
Neh 11111111100011110100010001100001010110001110100011111011000001010001000110010000000000000000011100010010000000011111010101010110
préambule tag type (encodé) uid crypté P d uid2 d uid1 d uid0 d I d I d R d R P
1111111110 0001111010001000110000 0110010000100000000111000101001 0 1 00100011 1 00101001 1 00000000 0 00111000 1 00100000 0 00111010 1 01111101 1
1111111110 0001111010001000110000 0110110000111000000111011101101 0 1 00110100 0 00100011 0 00000000 0 00111000 1 00100000 0 00001000 0 01010110 0
1111111110 0001111010001000110000 0000010010001101000010101000010 1 1 01000100 0 00101001 0 00000000 0 00111000 1 00100000 0 00110010 1 01000000 1
1111111110 0001111010001000110000 1010110001110100011111011000001 0 1 00010001 1 00100000 0 00000000 0 00111000 1 00100000 0 00111110 1 01010101 1
As you can see, this is more coherent with proxmark documentation, and I have now Identical and Random blocks as attended. There is though some 1 as separator, but I don’t know if it is a matter. I hope this work willbe useful to implement nedap tag in future upgrade.