[Resolved...NO BUG] it seems HID section has a new bug....

ntk · 2016-03-11 10:19:55

here is the SW I use
Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2016-02-21 13:55:57
os: /-suspect 2016-02-21 13:56:06
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at 9: 8: 8
uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 169009 bytes (32%). Free: 355279 bytes (68%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

Either the usage of "lf hid fskdemod" or "lf hid clone" has a bug. The clone T5x7 does not behave as a clone from HID proxcardII is expected.

pls see log file what I try to show the bug here

http://pastebin.com/ZHpsApcn

How is the configuration in int CmdHIDClone(const char *Cmd) done? I can not understand the code but it seems the writing is hard coded, not usign step like

lf t55xx wr b 0 d CCCCCCCC
lf t55xx wr b 1 d HHHHHHHH
lf t55xx wr b 2 d HHHHHHHH
..
lf t55xx wr b x d HHHHHHHH

Assume we had max data blocks=3 then the config CCCCCCCC combi for clock zero would be d 0010706

or in this case data for block zero = 00107040

RF/50;fsk2a;rf/2; 2 blocks;no PW; no STT
00000020
06e2314f

So I should have success after the clone to read with
lt t55 detect
lt t55 config
lt t55 read b 0 (result should be 00107040)

if it is true I can write to T55x7 this way? Or is it wrong what I expected?

Last edited by ntk (2016-03-20 04:40:09)

iceman · 2016-03-11 16:24:41

I have no problem running the clone command and getting a positive identification.

pm3 --> lf hid clone 2006e2314f
Cloning tag with ID 2006e2314f
#db# DONE!
pm3 --> lf se
Reading 30000 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:

HID Prox TAG ID: 2006e2314f (6311) - Format Len: 26bit - FC: 113 - Card: 6311

Valid HID Prox ID Found!

ntk · 2016-03-11 18:55:01

Thank you for your check Iceman.

Are you copy to a white T55x7 card or to a blue chip T55x7?

I did did many tests. Just do to more cloning test with checking HW tune between reading and write, to be sure the antenna has not got lost somehow. The result is the same: blue chip a T55x7 does not emulate the HID proxcard II correctly. The writing definitely has done its effect on the T55x7 chip, ask reading goes from defualt ASK modulation plot, to a new plot; but the plot looks different compared to the original HID ProxCardII. Also "lf search" thinks it finds PSK and not FSK2a.

I have not an HID reader for testing whether the clone is working So I can only compare the plot and use t55xx commands to check t55 detect or config on the cloned t55x7, what are your reading on the clone for modulation?

With the real HID card each time lf search can find HID valid, but not when check the clone.

I am setting up for compile latest of git SW to see fault may disappear

PART2:

SW at top of GIT behaves similar! not the clone I expect.

lf search can find the original HD proxcardII but not the clone. It thinks clone modulation could be PSK1!

here are the traces
https://www.dropbox.com/s/um9ff4ecxpvz6pe/investigated_HIDreal.txt?dl=0
https://www.dropbox.com/s/1zzcg2ptz904xe5/investigated_HIDclone.txt?dl=0

and log traces
http://pastebin.com/WhuvZZmH

Last edited by ntk (2016-03-11 19:17:41)

iceman · 2016-03-11 19:05:41

You should always compile the latest source from GitHub.

I tested on a blue t55x7 keyfob, I don't think its yr tag. How about you recompile and flash and test again?

ntk · 2016-03-11 19:19:38

thanks you Iceman. I just did. pls see PART2. in my post #3

"fault" is same.

ntk · 2016-03-11 19:39:25

the problem is related with my blue T55x7 chip.

I just do the clone on an T55x7 card and lf search now can see both the origin and the clone.

Repeat test and it is confirmed the clone on blue T55xt somehow is not correct

http://pastebin.com/eHrBkMUj

I will test MM42 too what I have used yesterdays, I think fault will disappear too if I clone HID to the T55x7 card (came in the PM3 package)

I still don't know why the blue bahaves like that ... bad chip?

RETESTED MM42 SW

Confirmed MM42 is ok.

HID Clone is ok on T55x7 white card

HID clone shows issue on the blue T55x7 chip, lf search not found, guesses it is PKS1

So the blue chip I have is at fault. Not a SW bug.

Sorry for the false alarm.

log trace is here http://pastebin.com/FWsxjL8a

Last edited by ntk (2016-03-11 20:11:21)

iceman · 2016-03-11 20:39:07

Your blue tag, are you sure its a T55x7? and not a Q5 (T5555) ?

ntk · 2016-03-11 20:58:48

that was one blue T55x7 I have played several time with. perhaps I have damaged it somehow.

Here is the trace I run commands t55 from a virgin blue T55x7

http://pastebin.com/etLdWSF3

it is definitely T55x7.

(Now when you ask, I am surprise that by default STT bit is set in the virgin blue chip)

Last edited by ntk (2016-03-11 21:12:43)

iceman · 2016-03-11 21:09:22

Have you tried to write a different block0 on it?

ntk · 2016-03-11 21:27:19

N I haven't done that way.

At first I wanted to test the command in HID sector on a blue t55x7 directly, demod and clone, hence I created the failure log. Then to confirm the fault is in the damaged\"bad" blue chip, I ran HID clone command on the white T55x7 card.

Now I will try to use t55 write commands on the "bad" blue chip now

00107060
and the Tag ID is 2006e2314f so I made two data blocks from that
00000020
06e2314f

====================== X7
lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 00000020
lf t55xx wr b 2 d 06e2314f

Hummmm but 00107060 means RF/50; fsk2a; RF/2; 3 data blocks max; PW bit none and STT none

so should I do like this
====================== X7
lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 00000020
lf t55xx wr b 2 d 06e2314f
lf t55xx wr b 2 d 00000000

or this

====================== X7
lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 00000000
lf t55xx wr b 2 d 00000020
lf t55xx wr b 2 d 06e2314f

or use 00107040 means RF/50; fsk2a; RF/2; ONLY 2 data blocks max; PW bit none and STT none
like this

====================== X7
lf t55xx wr b 0 d 00107040
lf t55xx wr b 1 d 00000020
lf t55xx wr b 2 d 06e2314f

What do you think Iceman? which one is correct and equivalent to the HID clone command? and why the clone command use configuration 00107040 with max data blocks =3. I can not see the logic there.
I would not damage my chip more...No?

iceman · 2016-03-11 21:42:38

You will not damage the tag. There is a Wipe command which empties the tag and writes a default block0

The other question, if u go with 3blocks change block0 .
If you go with 4blocks, use a block1 with zeros.

However i dont think that will produce a good hid copy.

ntk · 2016-03-11 21:51:48

use block1 with padding o. I Understand.

I will be back in 30min. Sorry.

ntk · 2016-03-11 23:04:29

Have tried all variants on the blue chip, PM3 failed to see te cone as HID clone.

A HID clone on white T55x7 card was successful, so I Have tried all variants again on the white T55x7 card, But here PM3 also failed to see the written card as a HID clone.

So we have to use cmdHIDClone() function. That is an amazing coding trick- Can not see where the config block zero is coded but run that function, then the card pick up 107060 ... but from where is it hard coded?

ntk · 2016-03-12 02:00:09

After using t55 wipe command on the blue T55x7s, I am able to clone HID proxcardII to any of the blue T55x7 chip with the "lf hid clone" command.

But, still fail in the trial for a general clone approach with configuration block setting, and write data blocks using the tag ID
or
lf read
data samples
data rawdemod fsk
lf t55 write.... also failed to make a good clone.

Why can we not do that way?

marshmellow · 2016-03-12 06:02:05

ntk wrote:

Why can we not do that way?

because you are not building the raw blocks at all correctly... there is a sticky thread that clearly explains this.

iceman · 2016-03-12 07:40:45

run the clone commands on a working t55x7, then dump the t55x7 tag, you'll see how your raw id is transformed into what is needed when making a hid clone manual.
the sourcecode also tells you what to do and since its involves some extra steps of transforming data, some user made the "lf hid clone" command... so you don't have to do this manually anymore...

ntk · 2016-03-12 10:30:10

the raw block building and the t55x7 dump of a working clone...

that is, I will look into it. Thank you.

ntk · 2016-03-12 21:33:58

@Marshmellow you mention raw block building, do you mean this sticky thread at http://www.proxmark.org/forum/viewtopic.php?id=1767,
Have you got something easier to read for beginner? there is hardly any explanation

Apart from that the word raw data I see in the result of t55 trace or t55 dump but I can see how 2006e2314f is related to data in block 1 or block2. That link you call "raw data building" I I misunderstood you

t55x7 dump of a working clone from HID proxcardII
http://pastebin.com/xXJh5JgA

Chip Type : T55x7
Modulation : FSK2a
Bit Rate : 4 - RF/50
Inverted : Yes
Offset : 31
Seq. Term. : No
Block0 : 0x00107060
1 | 1D555955 | 00011101010101010101100101010101
2 | 5569A959 | 01010101011010011010100101011001
3 | 5A5665AA | 01011010010101100110010110101010

HID Prox TAG ID: 2006e2314f (6311) - Format Len: 26bit - FC: 113 - Card: 6311

proxmark3> lf t55xx trace
-- T55x7 Trace Information ----------------------------------
-------------------------------------------------------------
ACL Allocation class (ISO/IEC 15963-1) : 0xE0 (224)
MFC Manufacturer ID (ISO/IEC 7816-6) : 0x39 (57) - Silicon Craft Technology Thailand
CID : 0x00 (0) -
ICR IC Revision : 0
Manufactured
Year/Quarter : 2013/0
Lot ID : 3138
Wafer number : 19
Die Number : 7507
-------------------------------------------------------------
Raw Data - Page 1
Block 1 : 0xE03900D0 11100000001110010000000011010000
Block 2 : 0xC4299D53 11000100001010011001110101010011
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x00107060 00000000000100000111000001100000
-- T55x7 Configuration & Tag Information --------------------
-------------------------------------------------------------
Safer key : 0
reserved : 0
Data bit rate : 4 - RF/50
eXtended mode : No
Modulation : 7 - FSK 2a RF/10 RF/8
PSK clock frequency : 0
AOR - Answer on Request : No
OTP - One Time Pad : No
Max block : 3
Password mode : No
Sequence Start Terminator : No
Fast Write : No
Inverse data : No
POR-Delay : No
-------------------------------------------------------------
proxmark3> lf t55xx dump
0 | 00107060 | 00000000000100000111000001100000
Using Clock:50, invert:1, fchigh:10, fclow:8
FSK2a decoded bitstream:
1 | 1D555955 | 00011101010101010101100101010101
2 | 5569A959 | 01010101011010011010100101011001
3 | 5A5665AA | 01011010010101100110010110101010
4 | 00000000 | 00000000000000000000000000000000
5 | 00000000 | 00000000000000000000000000000000
6 | 00000000 | 00000000000000000000000000000000
7 | 00000000 | 00000000000000000000000000000000
0 | 00107060 | 00000000000100000111000001100000
1 | E03900D0 | 11100000001110010000000011010000
2 | C4299D53 | 11000100001010011001110101010011
3 | 00A00003 | 00000000101000000000000000000011

ntk · 2016-03-13 17:25:24

I still cannot understand that picture regarding HID Wiegand 26bit picture

I have the feeling the answer lie in using SC, CN, E, O to make the raw block as MM shown here

HID 26 bit follows Wiegand 26 bit exactly - AKA H10301
HID 37 bit standard - AKA 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 - AKA 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 - AKA 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

All these HID formats follow the raw basic format outlined here http://www.proxmark.org/files/Documents … xample.pdf

NOTE: 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.
As I will outline in next post.
Last edited by marshmellow (2013-06-21 16:42:53)
"

@Asper could I have a copy of the excel sheet you mention for raw coding the wiegands , I would like to recreate some results using card number, site info to understand that picture. Thanks

ntk · 2016-03-13 17:28:35

I still cannot understand that picture regarding HID Wiegand 26bit picture

I have the feeling the answer lie in using SC, CN, E, O to make the raw block as Marshmellow shown here
"
HID 26 bit follows Wiegand 26 bit exactly - AKA H10301
HID 37 bit standard - AKA 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 - AKA 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 - AKA 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

All these HID formats follow the raw basic format outlined here http://www.proxmark.org/files/Documents … xample.pdf

NOTE: 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.
As I will outline in next post.
Last edited by marshmellow (2013-06-21 16:42:53)
"

@Asper could I have a copy of the excel sheet you mention for raw coding the wiegands , I would like to recreate some results using card number, site info to understand that picture. Thanks

iceman · 2016-03-13 17:38:18

Not quite, the raw bytes you have is already HID encoded SC/CN.
The key to understand the block data is that its manchester encoded. Look at the sourcecode armsrc/lfops.c in the function CopyHIDtoT55x7

ntk · 2016-03-13 19:52:46

Thank you for pointin gthat out

something in the data block 1, it is not 00000000
but
#load preamble
data[1] = 0x1D96A900 | (manchesterEncode2Bytes((hi2 >> 16) & 0xF) & 0xFF);

...

data[1] = 0x1D000000 | (manchesterEncode2Bytes(hi) & 0xFFFFFF);

Problem: I still can not understand the reason, where the preamble comes from

ntk · 2016-03-13 19:56:26

may I have the excel file pls. I need to code a few wiegands by card nr to get used to it. Also I like to see the preamble must be also in there

iceman · 2016-03-13 20:04:11

the preamble is a starting pattern found from analysing official hid tags. it is needed to make a proper clone.

ntk · 2016-03-13 20:29:44

"a starting pattern found from analysing official hid tags" Very wise. It explains why I failed...

So assume if I have a facility code 1096 and a card number 392537, but I don't have the card to do "lf hiid fskdemod 1" or "data hidfskdemod" to get the tag id to clone it, if I even not know if it is 26 bit or 35 bit or 37 bit wiegands... How would be my data blocks 1, 2, 3 be? Can I use the excel file to create the raw data for those 3 variants

If I have neither the real reader nor the card I guess the way to do is : I should try out all 3 variants on t55x7, with each different block 0 datas. Then I will ran "lf hid fskdemod 1" and if I get the tag ID out of one clone T55x7 of the three variants, I know then that that exact variant was the right guess with type of wiegand and raw coding, and that exact clone should work once we put it on the real HID reader

Can you follow me? Or would you solve differently?

Last edited by ntk (2016-03-13 20:36:46)

ntk · 2016-03-13 21:26:31

look at the dump code of the working t55x7 clone from HID ProxCardII CN 6311 FC 113
"
Block0 : 0x00107060

1 | 1D555955 | 00011101010101010101100101010101
2 | 5569A959 | 01010101011010011010100101011001
3 | 5A5665AA | 01011010010101100110010110101010

0 | 00107060 | 00000000000100000111000001100000
1 | E03900D0 | 11100000001110010000000011010000
2 | C43EE5F3 | 11000100001111101110010111110011
3 | 00A00003 | 00000000101000000000000000000011
"

and look at this 4 new data blocks

00107060
1D5559A9
9596559A
AA999956

Sinister ... it contains similar elements the D, the A, the 5, the 9, the 6 ... just different order and amount of occurences...

Following my thought in the above post #25, I do my experiment

I write

lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 1D5559A9
lf t55xx wr b 2 d 9596559A
lf t55xx wr b 3 d AA999956

to a t55x7, and then I run "lf search" or "lf hid fskdemod 1" ... and unexpected, it gives a verdict

"
HID Prox TAG ID: 2e890bfaa1 (64848) - Format Len: 35bit - FC: 1096 - Card: 392528
Valid HID Prox ID Found!
"

Now it is damned confused. I use block 0 001007060 for 26 bit, and the reading results a 35 bit... What is going on?
I did not exect I can accept it as a clone of a HID at all, but it does, and it tell me a 35 bit HID variant is here!!!!!

Only anrange the elements and it gives a real FC and CN and wiegand type!!! Isn't it a coincidence! It is better than magic!

It is only one shame ... It is not what I expect ... I expect for CN 392537 not 392528

I hate guessing .... Why/where is it going wrong? Can you see it? Can you veterans see it?

Last edited by ntk (2016-03-13 21:59:25)

ntk · 2016-03-13 22:30:31

@0xFFFF

reg http://www.proxmark.org/forum/viewtopic.php?id=1653&p=2
"
I have taken the utility offline as it wasn't getting used and people were not giving feedback. I have re-written most of it and added many more features. When it is closer to completion, I'll see if anyone is interested."

is it easy to used? If it is possible could you pls release the link again. Thanks

iceman · 2016-03-14 06:06:49

You have misunderstood things.

Block 0 has only to do with configuring the T55x7. Nothing else.

HID proxII uses a certain modulation (PSK/FSK/ASK/NZR etc) on a certain biterate/speed (32/40/50/64 etc), that is what you tell the t55x7 card with block0 to use.

When you do a normal LF READ on the T55x7, it sends block 1-2-3-4. Not block0.
For the HID reader only ses a long row of bytes. To make sense of this long row of bytes, it has to know where it should start to understand it. This is the purpose of the preamble.
After the preamble comes a row of bits/bytes that the HID reader understands and can transform into a raw wiegand code. From the wiegand code it can calculate FacilityCode and CardNumber.

If you want to go from FC/CN you have to go through this above process in reverse....

You can not jump into the middle and skip some steps and expect it to work.

Last edited by iceman (2016-03-15 06:56:10)

ntk · 2016-03-14 21:38:29

iceman wrote:

You have mis-understood things.
So for a HID reader it only ses a long row of bytes. To make sense of this long row of bytes, it has to know where it should start to understand it. This is the purpose of the preamble....
after the preamble comes a row of bits/bytes that the HID reader understands and can transform into a raw wiegand code.. for the wiegand code it can calculate FacilityCode and CardNumber...

thank you iceman. The way your way to explain is very clear for the layman. So in my case I will follow the picture 2HID 26-bit 125kHz" in the sticky thread http://www.proxmark.org/forum/viewtopic.php?id=1767 and convert backward to get the CN an FC.

somewhere I saw people asking link to a conversion excel file, but link is empty; I have checked the section files/software/documents on proxmark.org but could not see it anymore. Is it correct that it is about calculation the raw data for the HID wiegand format?

iceman · 2016-03-15 06:58:06

There are online tools which calculates wiegand codes.

http://www.brivo.com/support/card-calculator/

or you learn how do it yourself.

ntk · 2016-03-15 16:25:46

I would like to learn to do it myself. Could you kindly point me to some support document to realise that learning.

Longtime ago in the hacker scene I saw a video showing that you should not leave your fob/card unattended because alone with a picture of the number printed on card/fob, hacker can calculate datas and make a copy of your fob. That was the case of a EM41xx fob.

NOT that I want to do any hack activity but that video has triggered my interest in RFID. You are experienced and know a lot could you tell me, do we have such a tool or document about it on our forum? I would like to read it because now I think I coud understand a bit better than the time I saw that s.o. else did the work like magic.

I wonder if similar attempt is possible with HID, like proxcardII where CN and long number to be seen our side of the card. if there a tool to automatically doing the calculation needed. That could be a project to be tempted ...

Last edited by ntk (2016-03-15 16:30:11)

iceman · 2016-03-15 16:34:11

there is the excel sheet, but then you don't learn to do it yourself.

otherwise you have found the sticky thread http://www.proxmark.org/forum/viewtopic.php?id=1767 there you can learn how to do it yourself.
you can also read the source code for actual implementations.

You already have all you need to figure it out.

ntk · 2016-03-20 03:53:03

I have two questions, pls share your knowledge. Thanks.

Question nr1:

in the document http://www.proxmark.org/files/Documents/125%20kHz%20-%20HID/HID_format_example.pdf
it says
"B i t s u s e d f o r e v e n p a r i t y c a l c u l a t i o n a r e
u n d e r l i n e d i n b l u e .
O d d p a r i t y b i t s a r e u n d e r l i n e d i n r e d . "
also in http://proxclone.com/wiegand.html
it says "The first parity bit (even) is calculated from the first 12 bits of the code and the trailing parity bit (odd) from the last 12 bits." But how is parity bit calculated? What is the formula? EP or OP will a binary element 0 or 1, but how to calculate from the 12 said fields?

Question nr2:

in http://www.proxmark.org/forum/viewtopic.php?id=1653
0xFFFF said "
SC = Site Code
CN = Card Number
O = Odd Parity
E = Even Parity
Wiegand 26 bit
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"

how are the initials and numbers related to the raw data format? In the 44 binary string CN should be filled in into the position 2 to 17, BUT in this post I read "CN 10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25" why 21 ... 25? what is the meaning of this line related to the 26 bits Wiegand data formar displayed in http://www.proxmark.org/files/Documents/125%20kHz%20-%20HID/HID_format_example.pdf? Why many people sumarised and passed around tables of
SC = Site Code
CN = Card Number
O = Odd Parity
E = Even Parity" as if they are orientation or supports to understand\calculate something? There must be a document or a first discussion leading to the summary of these values...which one is it?

Last edited by ntk (2016-03-20 03:59:21)

ntk · 2016-03-20 04:09:30

Appropos OT:
Wonder if an administrator could change the header to [resolved NO BUG] to avoid confusion when newbies came across this thread. Sorry to bother you, I can not change the topic title. Thanks

Last edited by ntk (2016-03-20 04:10:10)

marshmellow · 2016-03-20 04:12:49

Edit your first post to edit the title.

ntk · 2016-03-20 04:41:37

Thanks @marshmellow.

ntk · 2016-03-20 05:33:13

Question3:

when take the example http://www.proxmark.org/files/Documents/125%20kHz%20-%20HID/HID_format_example.pdf
with the values FC=0x63 and CN=0x1C25, converted and recalculated

excel

But what cause EP to be 0, OP=1 at first place? formula to calculate parity?

Question4:
Before chose a template to fill in the bits we must know, apart from FC, CN, already the HID Wiegand type 26, 35, 37, 40 etc

One can see the CN on the back of a entry access card in clear print, but not the FC nor the Wiegand type in clear print!!! So where\How can we get those two critical infos before we can sit down to make the required raw datas?

Last edited by ntk (2016-03-20 05:38:20)

iceman · 2016-03-20 07:47:27

It would be better if you started a new thread for your new questions.

The original question is answered.

But to your other questions, the short answer is google it.

1) google how to calc parity. its not hard once you get it.
2) instead of writing the whole names, an abbrevation is used. Makes it easier in compressed space situation, like a table when you want to map a name and a certain bit.
3) see answer to question 1.
4) yes, where would you find that data? that is the question. what comes to your mind?

ntk · 2016-03-20 13:44:59

Thank you Iceman. Indeed it would be better each new question make a new thread, but all my question is related to understand one example table of exactly One card and type. I would find it obscured to spread the questions all over the forum.

If you don't mind I would stay in one place, until I get to the ground of it.

I did google a lot. Seen also new useful infos not displayed on Proxmark forum.

Back to the questions
"Parity bits[edit]
Main article: Parity bit
A parity bit is a bit that is added to a group of source bits to ensure that the number of set bits (i.e., bits with value 1) in the outcome is even or odd. It is a very simple scheme that can be used to detect single or any other odd number (i.e., three, five, etc.) of errors in the output. An even number of flipped bits will make the parity bit appear correct even though the data is erroneous." you can google to see where it comes from.

if you have looked closely my excel sheet I attached, you see yellow fields and blue fields related to OP, EP. add all the 12 bit sum is 5, on both sides! Still, OP must 1 and EP must be 0 for the raw datas to be
D3 shall be 5 A 9 5 6 5 9 9
D2 shall be 5 5 6 9 A 5 6 9
D1 shall be 1 D 5 5 5 9 5 5

and the example to be 0 x 0 2 0 0 6 C 6 3 8 4 A
F a c i l i t y C o d e = 0 x 6 3
C a r d N o . = 0 x 1 C 2 5
F o r m a t - H 1 0 3 0 1 2 6 - b i t

Now to Q2
In http://www.proxmark.org/files/Documents/125%20kHz%20-%20HID/HID_format_example.pdf

Title "P r o g r a m m i n g a T 5 5 5 7 / 5 5 6 7 r e a d / w r i t e c a r d
t o e m u l a t e a H I D 2 6 - b i t 1 2 5 K h z R F I D C a r d
u s i n g F S K m o d u l a t i o n"

Note for EP, OP
"B i t s u s e d f o r e v e n p a r i t y c a l c u l a t i o n a r e
u n d e r l i n e d i n b l u e .
O d d p a r i t y b i t s a r e u n d e r l i n e d i n r e d"
for EV bit 14,..,25
for OP bit 1,..,13 from the 44 bits string (Tag Transmits the preamble and all 44 bits )

in the original answer at http://www.proxmark.org/forum/viewtopic.php?id=1767
"Wiegand 26 bit
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"

E=EP, O=OP which bit mapping is it. Do both sources speak the same mapping? Why the need of expressions "E 1 2, 3, ..13" or "O 26 14, 15, ..25"?

The infos are basic, fundamental for the students but it is obscured somehow.

there seems to be clearly an intention not a fault, because it repeats over HID 37 bit standard - AKA H10304, Indala 26bit etc ... as if someone agrees somehow on a system of display mapping bits...

Could you see why I ask now?

To your answer on Q3
pls come back to the excel sheet and Q1 continued

To your answer on Q4
You say the how (just use PM or look in to the source code). PM is execution program, steps from a previous repeat knowledge and an existing HID card hear the 44bits transmit ( T a g T r a n s m i t s t h e p r e a m b l e a n d a l l 4 4 b i t s bu t c o m m e r c i a l R F I D r e c e i v e r s o n l y o u t p u t w e i g a n d d a t a f o r t h e l a s t 2 6 - 3 7 b i t s ( d e p e n d e n t o n c a r d f o r m a t ) . That is how does PM know

My question comes from different angle: I stand outside doors, saw s.o. flashes a HID card of CN , and even show me the back of card, like in the example I see C a r d N o . = 0 x 1 C 2 5 then a long string of 11 digit, and hyphen, and one more digit. No FC, no type in clear print. So where to see it has to come on this mapping, so PM can read CN 0x1C25, tag ID 0 x 0 2 0 0 6 C 6 3 8 4 A, 4 4 - b i t F S K. The rest is then easy.

Can you follow me now? Hang on did you hint I must read those critical infos to generate a working HID card from the access control SW of that door?

Last edited by ntk (2016-03-20 14:32:14)

iceman · 2016-03-20 15:11:44

You seem to have a big issue with bits and bytse. Good luck with your understanding. I'm not gonna answer this thread anymore.

ntk · 2016-03-20 15:50:34

pls Iceman. Don't be upset. I am sorry if I made you feel like that. I appreciate your supports not only reg here on HID

To be honest i have no electronic background, or working in RFID fields as you, and many experts n this forum, so maybe when exchange infos to each other, you people understand things about bits and bytse differently or take knowledge for granted.

My interest is to layout and to understand in details the mapping coding of basic HID example. If it is wrong pls show me where I did wrong, or where I misunderstood certain bits parts. If I don't learn I won't be here. I am not here to aggravate you or anyone.

If my questions do, it is not my intention.

ntk · 2016-03-27 19:54:41

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

No more question on this type of secret insider writing; nor calc first nor calc sec nor calc last ...

Still, I need one or two more tiny small bits to unwrap the puzzle.

ntk · 2016-03-28 00:37:44

Case 1:
Assuming tag system HID; tag type Wiegand 35bit; FC: 333 CN 196040

lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 1D5559A9
lf t55xx wr b 2 d 59969966
lf t55xx wr b 3 d AA9A9656

checked tag T55x7 with lf search (thanks for the function):
HID Prox TAG ID: 2e29a5fb91 (64968) - Format Len: 35bit - FC: 333 - Card: 196040
Valid HID Prox ID Found!

Case 2:
Assuming system HID; tag type Wiegand 35bit; FC: 666; CN 996699

lf t55xx wr b 0 d 00107060
lf t55xx wr b 1 d 1D5559A9
lf t55xx wr b 2 d 665A66A9
lf t55xx wr b 3 d 69999A6A

checked tag T55x7 with lf search (thanks for the function):
HID Prox TAG ID: 2e535e6ab7 (13659) - Format Len: 35bit - FC: 666 - Card: 996699
Valid HID Prox ID Found!

One 2 more tiny more bits then fully clear .... Something still felt not right here from the very first start... where\what is it hidden there?

ntk · 2016-03-28 00:55:58

There is a FSK2a modulation type to emulate HID tag with a T55x7, But there is not FSK2a in T5555 tag system ... What modulation could be chosen instead?

Test with ASK or direct or simple FSK seem not to create similar graph ... Wrong?

Apt-Get · 2016-03-28 20:49:55

Why are you even bothering with the t5555? just use t5577 for HID. Square Peg, Round hole never works..

Last edited by Apt-Get (2016-03-28 20:50:21)

ntk · 2016-03-28 20:55:39

I have checked all the example traces in the proxmark traces directory, for further HID study, I need more. If you have HID trace could you pls share to me here or mail to me PatienceIsaVirtue102@gmail.com.

It is for own raw coding study only && don't worry I wont ask questions.

I am looking for PM3 traces of HID\Wiegand tag sector, or actually anything involved with facility code, card ID number, FF code
HID H10301
HID H10302
HID H10304
HID H10320
Wiegand 32, 35, 37, 40 bit
AWID
Indala
Quadrakey
Kantec
Tecom

thanks

ntk · 2016-03-28 21:05:19

Dear Apt-get, thank you for your advise. I have done already raw coding on T55x7.

I read in a document "https://media.blackhat.com/us-13/US-13-Brown-RFID-Hacking-Live-Free-or-RFID-Hard-Slides.pdf" that says it is possible to clone to T55x7 /T5555 in the same breath. So, for general study I trace back that part, and tested out some experiments. but it does not work. It comes down that fsk2a is not available in T5555's modulation list. What to do?

PS:
that document, because there is a very interesting note in there too. but the "genius" heads didn't explain how. B****rds

Last edited by ntk (2016-03-28 21:11:44)

marshmellow · 2016-03-29 04:02:38

It isn't rocket science. Read the datasheets, and understand what fsk is. You can't understand the end without the basics. All the information is widely available.

ntk · 2016-03-29 16:16:28

... and if you want to clone it to T5555 (or Q5) just use 60018056 for block zero,
lf t55xx wr b 0 d 60018056

ntk · 2016-03-29 16:35:58

... but not Q5 is interesting.

This Blackhat USA 2013 note , on p10
caught my interest

Last edited by ntk (2016-03-29 18:23:40)

Proxmark3 community

Announcement

#1 2016-03-11 10:19:55

[Resolved...NO BUG] it seems HID section has a new bug....

#2 2016-03-11 16:24:41

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#3 2016-03-11 18:55:01

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#4 2016-03-11 19:05:41

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#5 2016-03-11 19:19:38

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#6 2016-03-11 19:39:25

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#7 2016-03-11 20:39:07

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#8 2016-03-11 20:58:48

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#9 2016-03-11 21:09:22

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#10 2016-03-11 21:27:19

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#11 2016-03-11 21:42:38

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#12 2016-03-11 21:51:48

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#13 2016-03-11 23:04:29

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#14 2016-03-12 02:00:09

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#15 2016-03-12 06:02:05

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#16 2016-03-12 07:40:45

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#17 2016-03-12 10:30:10

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#18 2016-03-12 21:33:58

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#19 2016-03-13 17:25:24

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#20 2016-03-13 17:28:35

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#21 2016-03-13 17:38:18

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#22 2016-03-13 19:52:46

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#23 2016-03-13 19:56:26

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#24 2016-03-13 20:04:11

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#25 2016-03-13 20:29:44

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#26 2016-03-13 21:26:31

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#27 2016-03-13 22:30:31

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#28 2016-03-14 06:06:49

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#29 2016-03-14 21:38:29

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#30 2016-03-15 06:58:06

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#31 2016-03-15 16:25:46

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#32 2016-03-15 16:34:11

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#33 2016-03-20 03:53:03

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#34 2016-03-20 04:09:30

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#35 2016-03-20 04:12:49

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#36 2016-03-20 04:41:37

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#37 2016-03-20 05:33:13

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#38 2016-03-20 07:47:27

Re: [Resolved...NO BUG] it seems HID section has a new bug....

#39 2016-03-20 13:44:59

Re: [Resolved...NO BUG] it seems HID section has a new bug....