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.
I would like to summarize here T55x7 configurations used to simulate/emulate other 125kHz tag types.
T55x7 BLOCK0 POSSIBLE CONFIGURATION SETTINGS
blue = initial default configuration
============================================================================================================
============================================================================================================
============================================================================================================
EM410x (and clones)
============================================================================================================
HID 26-bit 125kHz
============================================================================================================
HID 35-bit 125kHz
============================================================================================================
HID formats > 37 bits 125kHz
Block 0:
0x001070C0
Meaning it will transmit 192 raw bits - or 8 bit preamble & 92 manchester de-coded bits. Commercial recievers only output weigand data for the data after the first 1 bit.
So instead of the format having up to 44bits (of which 37 can be used in weigand data) it now has 92 (of which i believe 82 bits can be used for weigand data - depending on reader/software capability).
after the 8 bit preamble there is an manchester de-coded 8 bits of Company Code or OEM specific data - example I have is 10011110
the remainder follows the basic format outlined in HID 26-bit scheme above.
============================================================================================================
Indala 26-bit w format
EDIT 2018: There are a few errors in this image including the last three bits 101 should actually be shifted to the beginning of block 1 and is part of the preamble. also the checksum calculation is incorrect.
============================================================================================================
AWID_FSK 26-bit
============================================================================================================
HID "Long" format" (up to 84bits)
ID: 9e000000010000283400fe7
Card No.:2573
Decode 10000283400fe7 to bits: 10000000000000000001010000011010000000000111111100111
Take from bit 19 to bit 30 (starting from bit0) and convert back to Dec to obtain Card No. = 2573
============================================================================================================
(normal HID except for the start sentinel).
I changed the start sentinel from 0x0F to 0x1D as shown below and then programmed it into a T5567 card. I read the card using standard HID readers and they all correctly read the card with the output being as shown below. The parity bits are correct for the 37-bit format. I believe that it must be a vendor that licensed the format from HID but uses a different front-end OEM code/start sentinel.
00001111 0101 0101 0101 0101 0101 0101 0101 0110 0110 0110 1010 1001 1010 1010 1010 0110 1010 0101 1010 1010 0110 1010 (original)
00011101 0101 0101 0101 0101 0101 0101 0101 0110 0110 0110 1010 1001 1010 1010 1010 0110 1010 0101 1010 1010 0110 1010 (modified)
T5567 Registers:
Block0 = 0x00107060
Block1 = 0x1D555555
Block2 = 0x5666A9AA
Block3 = 0xA6A5AA6A
Output from HID Reader:
HID 37-bit H10304
Wiegand Code = 0x0015EFDCF7
FC = 350
CN = 519803
============================================================================================================
It depends on the technology option being used:
Quadrakey supports the use of different embeddd RFID options including the OmniProx and OmniClass.
The OmniProx is basically a HID equivalent FSK technology that uses a 34-bit Honeywell/Northern format. As a result the Block 0 register configuration would be the same as for HID (e.g. 0x00107060).
As a test, try programming a T55x7 with the following settings to see if the reader will react at all (e.g. beep/blink):
These values create a 34-bit OmniProx card with a facility code = 211 and a card number = 26975.
Block 0 = 0x00107060
Block 1 = 0x1D555965
Block 2 = 0x55569969
Block 3 = 0xA6599AAA
However, if the Quadrakey is using the OmniClass technology (which is basically HID iClass) then you can "NOT" duplicate the card using a T55x7.
============================================================================================================
T55x7 block0 configuration = 0x00147040
============================================================================================================
Q5
Q5 Card No: 1365205
T55x7:
block0 configuration = 0x00150060 (bitrate 64cpb; Direct Modulation; Biphase; 3 blocks)
or
block0 configuration = 0x6001F004 (birate 64cpb; Direct Modulation; Manchester; 2blocks)
or
block0 configuration = 0x6001805A (birate 50cpb; FSK2 RF/10-RF/8; 5 blocks)
or
block0 configuration = 0x6000F014 (birate 32cpb; PSK1 RF/2; 2 blocks)
block1 data = 0x69980299
block2 data = 0xA642C221
block3 data = 0x8DA5699F
Real Q5 data (emulated inside the above T55x7 configs):
(Card No: 1365205)
block0 configuration = 0x6001F066
or
block0 configuration = 0x6001F004 (bitrate 64cpb; Direct Modulation; Manchester; 2 blocks)
or
block0 configuration = 0x6001805A (birate 50cpb; FSK2 RF/10-RF/8; 5 blocks)
or
block0 configuration = 0x6000F014 (birate 32cpb; PSK1 RF/2; 2 blocks)
block1 data = 0x69980299
block2 data = 0xA642C221
block3 data = 0x8DA5699F
Here it is Q5 register block0 configuration (it is different from T55x7 one):
============================================================================================================
BITS EXPLANATION (various tags)
SC = Site Code
CN = Card Number
O = Odd Parity
E = Even Parity
HID 26 bit / Wiegand 26 bit / H10301
SC 2, 3, 4, 5, 6, 7, 8, 9
CN 10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25
E 1 2, 3, 4, 5, 6, 7, 8, 9, 10,11,12,13
O 26 14,15,16,17,18,19,20,21,22,23,24,25
HID 37 bit standard / H10304
SC 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17
CN 18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
E 1 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17,18,19
O 37 19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
HID 37 bit HUGE / H10302
SC NONE
CN 2-36
E 1 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17,18,19
O 37 19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
HID Clock & Data / H10320
SC NONE
CN 1-32 Hex format but does not allow A-F only 0-9 - meaning 100110011001 is actually 999 not 2457
E 33 1, 5, 9,13,17,21,25,29
O 34 2, 6,10,14,18,22,26,30
E 35 3, 7,11,15,19,23,27,31
E 36 4, 8,12,16,20,24,28,32
NOTES:
- 37 bit formats exclude the 1 start bit that preceeds all other weigand data formats.
- That basic raw format is what HID follows for any <= 37bit format
- For > 37 bits however the format is slightly different (see above "HID formats > 37 bits 125kHz").
HID 35bit Corporate 1000
SC 3, 4, 5, 6, 7, 8, 9, 10,11,12,13,14
CN 15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34
E 2 3, 4, 6, 7, 9, 10,12,13,15,16,18,19,21,22,24,25,27,28,30,31,33,34
O 35 2, 3, 5, 6, 8, 9, 11,12,14,15,17,18,20,21,23,24,26,27,29,30,32,33
O 1 2, 3, 4, 5, 6, 7, 8, 9, 10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35
Indala 26bit
SC 2, 3, 4, 5, 6, 7, 8, 9, 10,11,12,13
CN 14,15,16,17,18,19,20,21,22,23,24,25
E 1 2, 3, 4, 5, 6, 7, 8, 9, 10,11,12,13
O 26 14,15,16,17,18,19,20,21,22,23,24,25
read here for further information.
Tecom 27 bit
SC 16,20,25,24,23,19,7, 11,15,4, 3
CN 1, 2, 14,13,10,27,21,17,18,22,26,8, 9, 12,5, 6
============================================================================================================
The credits for the above stuff go to the original authors !
If you have other working block configurations please post them here (for example Indala 26-bit and HID 35-bit Corporate 1000)
Last edited by asper (2014-04-18 10:45:19)
Offline
I'm a bit confused here. Are the HID and AWID different 26-bit FSK protocols? Can the T5567 mimic both of them? If so, then how does the T5567 know which protocol to produce. Block 0 looks the same on both of them. I would assume Block 0 is where the protocol is set. I say that because the EM410x Block 0 is different than the others. Carl55's pictorial of the HID format below indicates that the card number is stored in Block 3 while the AWID pictorial shows it stored in Block 2.
Offline
The protocols are the same, as both HID and AWID use the same FSK modulation and transmit 3 blocks of data. The actual data format in binary is different for the two.
Offline
What would be the best way to close a HID Prox 26 card onto a T5557?
I tried reading the id with
lf hid fskdemod
#db# TAG ID: 200637da27 (60691)
#db# TAG ID: 200637da27 (60691)
#db# Stopped
and then cloning with:
lf hid clone 200637da27
Cloning tag with ID 200637da27
#db# DONE!
But the cloned card cannot be read by any reader (not even on the proxmark with "lf hid fskdemod").
What would be the right way to do it?
Offline
Forget it. Seems to be fixed in the current release.
Offline
There is an error in the above list that shows 37 bit HID. It should be any HID format greater than 37 bits requires the said detailed changes in formatting for chip programming. So you could replace the heading: HID 37-bit 125kHz. with: HID formats > 37 bits 125kHz
Offline
A number of formats are also listed at http://www.proxmark.org/forum/viewtopic.php?id=1653
Offline
There is an error in the above list that shows 37 bit HID. It should be any HID format greater than 37 bits requires the said detailed changes in formatting for chip programming. So you could replace the heading: HID 37-bit 125kHz. with: HID formats > 37 bits 125kHz
Done. Also added bits explanation from the other thread.
Is it possible to make a specific T5557 simulation (bytes to write) for each specific situation or bits decoding in only happens "reader-side" ?
Last edited by asper (2014-01-20 11:43:29)
Offline
Not sure what your asking. Do you want to have a separate simulate command for the proxmark for each format, or a different write command to a T55x7 for each format, or something else entirely? You cannot program a tag to have more than one format at a time. But someone could write some code for the proxmark to do the formatting for you and just ask for the sc and card#
Last edited by marshmellow (2014-01-20 14:26:07)
Offline
No I would like to know if each kind of bit "interpretation" needs different bytes to be written in T5557 configuration block (pm3 independantly).
Offline
As far as in know, for HID formats, the transition from <=37 bits to >37 bits is the only change that requires a different configuration block settings. Other formats like EM4100 and Indala require different configuration block settings.
Offline
Thank you for clarifications. Can you provide Indala configuration (or is it the same of other tags) ? It seems to be missing in the 1st post.
EDIT
And what about HID 35bit format ?
Last edited by asper (2014-01-20 20:47:45)
Offline
I use: 0x00081040
also note that the above image for EM410X formats has a typo for block 0.
instead of 0x000148040 it should be 0x00148040
Offline
HID 35bit follows the standard HID configuration settings (just like 26 bit), just a different data format for blocks 1-3 as outlined above.
Offline
So em410x is the same as indala ? (Thank you for pointing out the error, i will elaborate the pic to correct it asap).
Can you make a practical example (all t5557 blocks) for a hid 35 bits?
Offline
Indala = 0x00081040
EM410X = 0x00148040
they are different.
as far as hid 35 bit, if I get some free time I'll try and put something together.
Offline
Error in EM410x picture corrected.
Can you also make an example (all t5557 blocks) for Indala ? I am sorry to ask those stupid questions but I am really "weak" in 125kHz filed (no tags to test) and I want to collect the greatest amount of information possible.
EDIT: thank you for your time !
Last edited by asper (2014-01-20 21:36:53)
Offline
something bad happened above...
the heading HID 37 bit HUGE / H10302 is missing the data that went with it.
and the data below that heading should have had the heading: HID Clock & Data / H10320
Offline
My fault. Corrected right now (from my mobile phone, I hope all is ok).
Offline
There is a lot of information missing for the indala format, and what is there isn't entirely correct - see: http://www.proxmark.org/forum/viewtopic.php?id=624
Offline
There is a lot of information missing for the indala format, and what is there isn't entirely correct - see: http://www.proxmark.org/forum/viewtopic.php?id=624
You mean in general or in the 1st post of this thread ?
Offline
In the first post of this thread indala looks wrong. I like the link tho. The 26 bit indala SC, CN, E, and O AFAIK should be identical to 26 bit HID. How those bits are arranged on the card memory is different and is explained in the link.
Offline
I am not good at 125kHz, I am just learning and collecting info, if you want to provide corrections I will be glad to improve the 1st post
Last edited by asper (2014-01-25 19:02:36)
Offline
Thank you very much ! It works GREAT !
Hid 35 bits have the same block0 as hid 26 bits, right [00107060]? While hid 37 is slight different [001070C0], correct ?
A silly question: in "bit explanation (vaious tags)" bit0 is NEVER considered... is it present or the explanation consider the 1st bit as bit1 insted of bit0 ?
Last edited by asper (2014-01-29 07:53:57)
Offline
I'm not sure where you are referring to, I typically start counting at one for ease and to count the bits (tho sometimes I start with 0 to match a reader SDK or something). If you are referring to the chips memory then there is a locking bit to every block that sometimes is referred to bit 0 but it is only used when programming and it is never sent by the chip.
Offline
I'm not sure where you are referring to, I typically start counting at one for ease and to count the bits (tho sometimes I start with 0 to match a reader SDK or something). If you are referring to the chips memory then there is a locking bit to every block that sometimes is referred to bit 0 but it is only used when programming and it is never sent by the chip.
You are right, I was not clear in my words;
Look at this:
HID 37 bit standard / H10304
SC 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17
CN 18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
E 1 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,16,17,18,19
O 37 19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36
Has HID 37 a "bit0" or bit0 of the above example correspond to bit1 ? This is important in decoding/descrambling bits because we must know the correct bits label to define a decoding profile.
Offline
See the legend for what sc,cn,e,o means: there is not a bit0 mentioned in the format you quoted.
BITS EXPLANATION (various tags)
SC = Site Code
CN = Card Number
O = Odd Parity
E = Even Parity
Offline
Perfect
Offline
I use these settings for recording
;TEMIC 5557
tabl_temic_ask_init: 0x00148040 ;bit rate 64cpb ;Direct modulation,Manchester ;2 block
tabl_temic_fsk_init: 0x00107060 ;bit rate 50cpb ;FSK 2a RF/10-RF/8 ;3 block
tabl_temic_psk_init: 0x00081040 ;bit rate 32cpb ;PSK1 RF/2 ;2 block
;sokymat q5
tabl_sokym_ask_init: 0x6001F004 ;bit rate 64cpb ;Direct modulation,Manchester ;2 block
tabl_sokym_fsk_init: 0x60018056 ;bit rate 50cpb ;FSK 2 RF/10-RF/8 ;3 block
tabl_sokym_psk_init: 0x6000F014 ;bit rate 32cpb ;PSK1 RF/2 ;2 block
Offline
Hi sentinel, can you explain what you mean with "recording" ?
Offline
I think he is talking about recording/programming/setting/writing/configuring the configuration block (?)
Offline
Marshmellow I sent you a message on ICQ.
I would like to know if hid cards has 44 and 84 HEX ID values or there are others (I think that 48 and 88 is the real size, maybe 4 leading 0 ?).
Last edited by asper (2014-02-20 10:30:00)
Offline
I just recently got a T5557 compatible card and i wonder how to extract the data.
I want to read the blocks as they are.
proxmark3> lf t55xx readblock 0
Reading block 0
#db# DONE!
proxmark3> data samples 10000
Reading 10000 samples
Done!
proxmark3> data mandemod
Manchester decoded bitstream
1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 1 0 0 0 0 0 0 0 1 1 1
0 1 0 0 0 1 1 0 0 1 1 1 1 1 1 1
1 1 1 1 1 0 1 1 1 0 1 1 1 1 1 1
1 0 0 0 1 0 1 1 1 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0
0 0 0 0 0 1 1 1 0 1 0 0 0 1 1 0
0 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1
1 0 1 1 1 1 1 1 1 0 0 0 1 0 1 1
1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 1 0 0 0 0 0 0 0 1 1 1
0 1 0 0 0 1 1 0 0 1 1 1 1 1 1 1
1 1 1 1 1 0 1 1 1 0 1 1 1 1 1 1
1 0 0 0 1 0 1 1 1 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0
0 0 0 0 0 1 1 1 0 1 0 0 0 1 1 0
0 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1
1 0 1 1 1 1 1 1 1 0 0 0 1 0 1 1
1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0
iNow what i get is:
10011 0000000000001000100000001110100
01100 1111111111110111011111110001011
10011 0000000000001000100000001110100
01100 1111111111110111011111110001011
10011 0000000000001000100000001110100
01100 1111111111110111011111110001011
10011 0000000000001000100000001110100
Can someone hint me how to interpret these first 5 bits in line 0? And why do i get the inverse? I dont see the settings for such behaviour in the data sheet.
Offline
It appears the mandemod command is interpreting the end of a looping transmission as an error and it inverts the interpretation. do you know that the chip is configured for Manchester? Also I think with the readblock function you need to use data bitsamples or data hexsamples and not mandemod. but i'm going off memory..
Offline
It appears the mandemod command is interpreting the end of a looping transmission as an error and it inverts the interpretation. do you know that the chip is configured for Manchester? Also I think with the readblock function you need to use data bitsamples or data hexsamples and not mandemod. but i'm going off memory..
Thank you! You hinted towards the issue. I demodulated my graph manually (on paper) and found the parts that the get misinterpreted by mandemod (which isnt really working well for me, ill have a look).The Sequence terminator modulation is adding in cycles without modulation. Just 1 cycle though and it seems this shift in flanks is beyond the
int tolerance = clock/4
.
Just for the record, from the data sheet:
This basic mode
sequence terminator consists of four bit periods. During the first and third bit period, the data value is 1. During the second and
fourth bit periods, modulation is switched off (using Manchester encoding, switched on).
So what i see in the plot is 1N1N<32bit block0>1N1N<32bit block0>. (1N1N is 4 bit length, mandemod sees them as 10101, i can "see" it too, that only works if i greatly tolerate wrong timing on flanks.)
ST can be switched on/off (active1) in bit 29 on block 0.
Offline
there are other threads that have mentioned some issues with mandemod and timings, I believe there was a work around being done to manually set the timings, though I believe it is buggy for now. I'll see if I can remember where I saw that and post a link.
Offline
You mean to manually set the clock i think. Thats not the problem though, mandemod function isnt made for mandemodding just a part of the samples and skipping those that do not fit. Small errors in captures are overcome with allowing some tolerance - probably the only reason i get an output here. If it would go strictly after manchester rules it would throw an error on any of those TS and stop.
Ill write some code for better handling of these cool T55x7 cards sometime, but for now ill go with manual demod.
Offline
Makes more sense, sorry, I've been distracted. I would like it if the mandemod function would warn you that it hit errors in the stream and "tolerated" them, because I think it often tolerates them and outputs something completely wrong, as in this case. something to look at I guess.
for block reading a T55xx I usually just use a GIS TS-38 reader, so I haven't experimented too much with the proxmark readblock function.
Offline
Ill work on it soon. Ill decrease tolerance and allow to skip samples that are not modulated. We ll see how tjat works out.
I have ideas for even more sophisticated demod options (like regex just for mixed modulation waves) but ill have to test some stuff for that.
Offline
can a moderator make this thread sticky? it is a good reference tool for most new comers, and it would help if they didn't have to dig so far to find it.
Offline
Given some docs from Asper, I implemented some more descramble patterns in em410x decode.
Add: DEZ 3.5b, DEZ 3.5c, DEZ 20/ZK, paxton, pattern1 (unknown), pattern sebury
fix: minor bugfix in the DEZ 10
EM410x pattern found:
EM TAG ID : 0142b7c9fd
Unique TAG ID: 8042ed93bf
DEZ 8 : 12044797
DEZ 10 : 1119341053
DEZ 5.5 : 17079.51709
DEZ 3.5A : 001.51709
DEZ 3.5B : 066.51709
DEZ 3.5C : 183.51709
DEZ 14/IK2 : 00005414308349
DEZ 15/IK3 : 000550878679999
Other : 51709_183_12044797
DEZ 20/ZK : 08000402141309031115
Pattern Paxton : 30148605
Pattern 1 : 7BAF5B 8105819
Pattern Sebury : 51709 55 3656189 (C9FD 37 37C9FD)
Last edited by iceman (2015-03-24 22:35:47)
Offline
It was just pointed out that the image for 35 bit prox has an error. The block numbers are backwards. They should be numbered from the left to right 1 to 3 not 3 to 1. Also it appears the data about quadrakey is incorrect (or different versions of it exist) per the recent nexkey/nexwatch posts, quadrakey is actually a PSK modulated 32 bit ID with nexwatch formatting.
Offline
Hi, I am trying to lock t55xx after execute hid clone command
I am trying to write block 0 with value original 107060 to 107070
but it's kind of changed to some other value with top turn on.
Can someone please guide me
Best regards
Offline
Hi, I am trying to lock t55xx after execute hid clone command
I am trying to write block 0 with value original 107060 to 107070
but it's kind of changed to some other value with top turn on.Can someone please guide me
Best regards
I would also be interested to know if the proxmark can lock t55x7 cards after writing to them. I have a Chinese reader/writer device that can lock cards which I use when I need to lock them but it would be good if this could be done on the proxmark3 ?
Offline
To password protect it is just a matter of writing your pwd to blk 7 and writing the correct config block for your tag with pwd mode on.
Locking is different and makes the tag permanently read only.
Offline
To password protect it is just a matter of writing your pwd to blk 7 and writing the correct config block for your tag with pwd mode on.
Locking is different and makes the tag permanently read only.
Yes I was hoping to lock the tag with the proxmark to make it read only as this can be done using chinese reader/writers. From your post I assume I could add a pwd to stop people writing to the tag but it would be easier if there was a simple command to lock the card?
Offline
Most ppl prefer the password option as that leaves the possibility that at least you can change the programming if needed later. However, it should be as simple as adding a parameter for the locking bit to the write command. So if you'd like it, add it. .
Permanently locking a tag is not very useful in RFID testing and research, which is the intended function of the pm3. It is NOT a cloner.
Offline
And if someone asks you to clone it for them, then they will not know either wheater its pwd or lock protected. Theuy just want a clone and don't know the stuff behind it.
Offline
BTW, original tags from real mfgs aren't locked but password protected instead.
Offline