KeyFOB at 153mHz

ntk · 2015-05-28 14:00:06

well. I have two PAK tags, the correct one for my door and one I bought on ebay. If I put the right tag close to the door reader LED lit up, I here a click, the sound I think that comes from the lock/bolt moving mechanism,and door opens.

with the wrong tag there is definitely nothing no light no sound, I have ask someone to hear with me to make sure, that no sound comes out at all. The person confirms there was nothing to hear.

The urmet dous wont help us??? Hummm, So what else can we do? You suggest we can try to clone the data we have to the T55x7 but what is about the UID?

Does the UID change automatically within this T55x7 cloning process... Does this clone, do a write ector 0 too?

The company boosts around that "each of ourr key is unique and nearly impossible to copy" , I think they means this UID, they woud be fool mentions it but not use it to identify the right key to the right door.

ntk · 2015-05-28 14:09:53

if I have the authentic company door reader and I do have it here on my table, what do I need extra, and how should I connect, wire to see some data?

There must be a communication to the wrong tag and the full communication ti the right tag .... do we have HW people here? Or should I seek help for this modification or wiring from other places like RCF522, arduino or strawburry PI things?

app_o1 · 2015-05-28 15:45:26

You should have a label at the back of the reader showing what wire is for what function.
Red is +VDC
Black is GND
Green is Data0
White is Data1

But all you need now is a - and a +
Connect a 9V battery to it. You won't burn it if you connect it the wrong way. Then try to swipe your tag. It should react.

From there, you can either monitor the data coming out D0/D1 or sniff what's happening (on the reader's antenna or the tag's antenna).

Last edited by app_o1 (2015-05-28 15:51:51)

marshmellow · 2015-05-28 16:51:16

if you have an ata55x7 tag you can program it with the bits you read, and configure it for NRZ/Direct rf/32. it might act like a clone (if the reader isn't picky and we got the NRZ/Direct modulation correct).

UID, they woud be fool mentions it but not use

UID means different things to different people.. i've found often marketing is just that - good marketing...

Last edited by marshmellow (2015-05-28 16:53:26)

ntk · 2015-05-28 17:08:13

thank app_o1,

app_o1 wrote:

You should have a label at the back of the reader showing what wire is for what function.
Red is +VDC
Black is GND
Green is Data0
White is Data1

unfortunately I have more wires than that

yes I have the wire colour code at the back too. but i have two wires red +12V and orange red +5V. Would it be ok for connecting the +12V to 9V , what about the 5V wire?

app_o1 wrote:

But all you need now is a - and a +
Connect a 9V battery to it. You won't burn it if you connect it the wrong way. Then try to swipe your tag. It should react.
From there, you can either monitor the data coming out D0/D1 or sniff what's happening (on the reader's antenna or the tag's antenna).

there is also the D0/Clk (data 0. clock?) and D1/SIG (Data1/Signal?) if I tapa oscilloscop to D1, I would see the wave, but if I don't have an Osci but the PM3 or arduino or Open OPD where should I tap it to, so that we can still do the demodulation analysing signal on PC

Is the idea feassible at all?

en4rab · 2015-05-28 17:43:43

The PAC fob i ordered from ebay arrived this morning, and after much faffing i have some results.
I have both a stanley and a PAC one tag to play with now, they both seem to read better at 134KHz on my proxmark, a 26c3 zik zak one antenna as below:
Measuring antenna characteristics, please wait.........
# LF antenna: 19.74 V @ 125.00 kHz
# LF antenna: 8.46 V @ 134.00 kHz
# LF optimal: 21.62 V @ 123.71 kHz

doing some messing using the latest git firmware so i could use "data rawdemod nr 32" i got very similar results to ntk only for some reason my data seemed to be inverted compared to his demodulation.
I also put both tags on my RFIDler and ran autotag which returned this for the PAC one using ASK decoding:
17FFC812641B51519164C506D5B36D07 (there was no startbits set for this so it starts at a random point)
messing around with the bits I recorded from my tags and the inverted bits from ntk looking for matches i think i might have found the start bits, i found a match with all 3 tags bits being the same and i think the start bits are FF9024C836

Setting the startbits on my RFIDler to FF9024C8 and running it as a reader returned the following for my tags
FF9024C8364C8722C88E23AB623A327F stanley
FF9024C836A2A322C98A0DAB66DA0E2F PAC one
The inverted demodulated bits from one of ntks traces were (partially redacted as its not my card)
FF9024c836********************70
Its possible that is a bad read but the fact it ended with 0 is what makes me thing the start bits are FF90...

I switched back to firmware 0.0.7, for some reason 2.0.0 wont program my Q5 tags, and tried programming a Q5 tag (sokymat bobsled) to emulate this using RF/32,NRZ/Direct modulation,max block 4 (6000F078) for a T55x7 you will have to work out the config block and whilst it isnt as steady reading on the rfidler i see some bit errors it does seem to spit out the right values if you hold your tongue at the right angle.
Sadly i dont have any real infrastructure to test against

Last edited by en4rab (2015-05-28 17:44:23)

marshmellow · 2015-05-28 18:13:29

i would tend to agree with the starting position. not sure which device inverted the bits, it really depends on the implementation of NRZ/Direct, some have a high wave always = start of 1 data bits some it is the start of 0 data bits..

being that the wave is low (for ntk's tag) when it begins and how i've seen the ata55x7 implementation of nrz/direct, at least for cloning purposes i'd lean towards the invert of your strings as being necessary to program on the ata55x7.

(we tend to like the FF9 for starting points due to the EM influence but multiple zeros is just as effective as indala teaches us.)

Last edited by marshmellow (2015-05-28 18:17:35)

marshmellow · 2015-05-28 18:19:15

just curious, how old is your Q5 tag?

ntk · 2015-05-28 18:43:04

marshmellow wrote:

if you have an ata55x7 tag you can program it with the bits you read, and configure it for NRZ/Direct rf/32. it might act like a clone (if the reader isn't picky and we got the NRZ/Direct modulation correct).
UID, they woud be fool mentions it but not use
UID means different things to different people.. i've found often marketing is just that - good marketing...

HUmmm the data we have is this
0110111100011011
0001111000000000
....
0011101001101110
1110001100111010
1110100110101110

how can we put it in a forat we can write to R55x7 I have ne done before.

When I look around for T55x7 tag command I found this lf t55xx wr [ ]
it complains when i left password empty

proxmark3> lf t55xx wr 11223344
Usage: lf t55xx wr <block> <data> [password]
<block>, block number to read. Between 0-7
<data>, 4 bytes of data to write (8 hex characters)
[password], OPTIONAL password 4bytes (8 hex characters)
Examples:
lf t55xx wd 3 11223344 - write 11223344 to block 3
lf t55xx wd 3 11223344 feedbeef - write 11223344 to block 3 password feedbeef
proxmark3>

I dont have the password. So there must be other "we can wite to T55x&"

Sorry for my late reply I am still looking around to find the write command for "you can program it with the bits you read, and configure it for NRZ/Direct rf/32"

I also found one "lf HID clone" which write direct bits 44 or 85bits to T55x7.... but what doe it mean "and configure it for NRZ/Direct rf/32"

dont we havee to change the bits into hex format Marshmellow

Last edited by ntk (2015-06-02 17:25:35)

ntk · 2015-05-28 18:45:44

marshmellow wrote:

just curious, how old is your Q5 tag?

erm...huuuum... my Q5 tag?

marshmellow · 2015-05-28 19:14:46

ntk wrote:

marshmellow wrote:
just curious, how old is your Q5 tag?
erm...huuuum... my Q5 tag?

sorry en4rab's Q5. (i haven't seen one of those in years...)

marshmellow · 2015-05-28 19:18:46

ntk wrote:

how can we put it in a forat we can write to R55x7 I have ne done before.
When I look around for T55x7 tag command I found this lf t55xx wr [ ]
it complains when i left password empty
proxmark3> lf t55xx wr 11223344
...
I dont have the password. So there must be other "we can wite to T55x&"
...
I also found one "lf HID clone" which write direct bits 44 or 85bits to T55x7.... but what doe it mean "and configure it for NRZ/Direct rf/32"
...
dont we havee to change the bits into hex format Marshmellow

yes the bits have to be converted to hex.
the 'lf t55xx wr' write command is correct, however, you have to specify a block. (see memory map)
at http://www.proxmark.org/forum/viewtopic.php?id=1767 in the first post there is a link to the datasheet. it will have the memory map and other information you need to figure out how to program the ata55x7 to your needs.

Last edited by marshmellow (2015-05-28 19:19:26)

en4rab · 2015-05-28 19:21:26

marshmellow I got the tags in bulk off ebay for cheap http://www.ebay.co.uk/itm/131516399667
They are aparently Q5's and the config word calculated using the Q5 datasheet appears to work, sadly there are not dates on the tags or boxes so i have no idea how old they are, the keyring loop on these is a bit rubbish and prone to snapping, but they were cheap

marshmellow · 2015-05-28 19:24:45

as a side note, it isn't in the main trunk yet but in my fork i just added an offset option to the 'data printdemodbuffer' command so it can print the hex(or binary) of the demodulated tag starting from various offsets.

Last edited by marshmellow (2015-05-28 19:25:10)

ntk · 2015-05-28 22:32:32

en4rab wrote:

The PAC fob i ordered from ebay arrived this morning, and after much faffing i have some results.
I have both a stanley and a PAC one tag to play with now, they both seem to read better at 134KHz on my proxmark, a 26c3 zik zak one antenna as below:
Measuring antenna characteristics, please wait.........
# LF antenna: 19.74 V @ 125.00 kHz
# LF antenna: 8.46 V @ 134.00 kHz
# LF optimal: 21.62 V @ 123.71 kHz
doing some messing using the latest git firmware so i could use "data rawdemod nr 32" i got very similar results to ntk only for some reason my data seemed to be inverted compared to his demodulation.
I also put both tags on my RFIDler and ran autotag which returned this for the PAC one using ASK decoding:
17FFC812641B51519164C506D5B36D07 (there was no startbits set for this so it starts at a random point)
messing around with the bits I recorded from my tags and the inverted bits from ntk looking for matches i think i might have found the start bits, i found a match with all 3 tags bits being the same and i think the start bits are FF9024C836
Setting the startbits on my RFIDler to FF9024C8 and running it as a reader returned the following for my tags
FF9024C8364C8722C88E23AB623A327F stanley
FF9024C836A2A322C98A0DAB66DA0E2F PAC one
The inverted demodulated bits from one of ntks traces were (partially redacted as its not my card)
FF9024c836********************70
Its possible that is a bad read but the fact it ended with 0 is what makes me thing the start bits are FF90...
I switched back to firmware 0.0.7, for some reason 2.0.0 wont program my Q5 tags, and tried programming a Q5 tag (sokymat bobsled) to emulate this using RF/32,NRZ/Direct modulation,max block 4 (6000F078) for a T55x7 you will have to work out the config block and whilst it isnt as steady reading on the rfidler i see some bit errors it does seem to spit out the right values if you hold your tongue at the right angle.
Sadly i dont have any real infrastructure to test against

0110111100011011 6F1B
0001111000000000 1E00
1101111110110110 DFB6
...
0010010010011001 2499
0011101001101110 3A6E
1110001100111010 E33A
1110100110101110 E9AE

Oh dear, finally I have the hex's but I could not see the "FF9024c836" en4rab has foundt ....

Last edited by ntk (2015-06-02 17:26:14)

marshmellow · 2015-05-28 22:42:20

Remove the first 3 bits (shifting all the binary)and try again. (Hint: windows calculator in programmer mode, or another calculator can convert)
Also, you won't get ff902... You will get 006fd... As your data is inverted when compared to en4rabs

Last edited by marshmellow (2015-05-28 22:43:16)

marshmellow · 2015-05-28 22:44:29

Hint in binary the start of your data looks to be 000000000110....

ntk · 2015-05-28 22:55:49

0110111100011011 6F1B B1f6
0001111000000000 1E00 00e1
....
0010010010011001 2499 9942
0011101001101110 3A6E e6a3
1110001100111010 E33A a33e
....
0011101001101110 3A6E e6a3
1110001100111010 E33A a33e
1110100110101110 E9AE ea9e

I have the binaries, the hex and the hex's inverts and still see no where FF9024c836, you ment the invert of the binaries?!

Last edited by ntk (2015-06-02 17:26:48)

marshmellow · 2015-05-28 22:57:36

Inverted means 1=0 and 0=1

ntk · 2015-05-28 23:11:03

oh dear that you do all by hand, + en4rab also can see the pattern in it ... and translate to hex,

alone what we have this morning took me 2hrs to do the hex ... now everything from beginning. That is crazy

marshmellow · 2015-05-28 23:48:06

Use tools. . I think you shouldn't invert to go onto a ata55x7. But if you want to, use the pm3. data rawd nr 32 1. It will invert for you.

ntk · 2015-05-28 23:59:29

this invert thing and traslation to hex is looking horrible on time taking, but that does not worry me much.

Bigger problem is the document ATA5567.pdf, to which the post1 written by Asper in topic http://www.proxmark.org/forum/viewtopic.php?id=1767 pointed...

Then I found this part

"
Writing must fo
llow these rules:
• Standard write needs the opcode, the lock bit, 32 data bits, and the 3-bit address (38 bits
total)
• Protected write (PWD bit set) requires a valid 32-bit password between the opcode and data
bits or address bits
• For the AOR wake-up command, an opcode and a valid password are necessary to select
and activate a specific tag
Note: The data bits are read in the same order as written.
If the transmitted command sequence is invalid, the ATA5567 enters regular-read mode with the
previously selected page (by former opcode “10” or “11”)."

I think you want to point out that I have to work out how to construct the bits for a standard wrtie for T55x7 so I don't need the password

marshmellow · 2015-05-29 04:22:45

also take a look at the help for the t55xx write command ( lf t55xx wr h )
(other than the typo in the example [wd] i just noticed it should help you know the format of the command. )

the key in the datasheet is to understand the memory organization and size of blocks. so you can know how to program the multiple blocks that will be needed for this clone attempt. (then you need to figure out the configure block settings to get the modulation and clock rate (data rate) and number of blocks to output is.)

ntk · 2015-05-29 10:40:37

i have done all the converting to hex, invert, and "drop" variations, but I must admit I am confused and failed here I could not find the bits you and en4rab have mentioned

http://www.filedropper.com/calcres

ntk · 2015-05-29 14:34:53

1byte = 8 bits, take the ntk binary

01101111000110110001111000000000110111111011011001101111100100110010010010011001001110100110111011100011xxx
10111111011011001101111100100110010010010011001001110100110111011100011001110101110100110101110

drop 3 bytes then perform Hex conversion ...

01101111
00011011
00011110 00000000110111111011011001101111100100110010010010011001001110100110111011100011001110101110100110101110yyy011001001110100110111011100011001110101110100110101110

the bits I have dropped is
011011110001101100011110 in hex: 6F1B1E
and the resr of the binary string converted in Hex is
00DFB6abcdefE9AE

I still don't have any where the marker marshmellow and nezrab talk about

Last edited by ntk (2015-06-02 23:37:35)

marshmellow · 2015-05-29 14:40:08

Drop 3 BITS not bytes.

marshmellow · 2015-05-29 14:41:08

Or find the binary marker I mentioned and start from there...

ntk · 2015-05-29 16:01:55

while waiting on correcture/instruction/hint to understand why my calculation is giving out different result than from other ( I am not an electronic student.)

I made an attempt on the issue writing to T55x7 according the document and the help part of this comand. Writing happen on two front write the cnfig block to block 0, and write data to block 1 to 7

So regarding writing data to T55x7 we have... if correct that my data starts like here, I have 7 block of data
00DFB66F
1 9324993A
...
7 AE6F1B1E
00DFB66F (after this bytes data repeats again)
9324993A
..
6EE33AE9
AE

That means I have 7 time the beloave instruction for writing data.
i have to write 7 times
lf t55xx wr 1 9324993A
lf t55xx wr 2 6EE33AE9
...
lf t55xx wr 6 6EE33AE9
lf t55xx wr 7 AE6F1B1E

and then I have to write the config block to the block 0,

Now how to construct the config block???? ...

Last edited by ntk (2015-06-02 23:38:21)

marshmellow · 2015-05-29 16:32:00

I would recommend programming only the 4 blocks of repeating data into blocks 1 to 4

ntk · 2015-05-29 17:12:38

what is a configuration block:
When the Tag enters the electromagnetic field transmitted by the RFID reader it draws power from the field
and will commence transmitting its data if so configured. How the T5557 will respond upon entering the RF
field is dependent on the data stored in the Configuration block at block address 0.
Block 0, Configuration data.

now it is strange I am lost again ... although I still not understand much but it seems that there are way to configure the configuration block by filling the bits but only for ASK, Bi, PSK medulation where is about NZ ...

ntk · 2015-05-29 17:17:47

marshmellow wrote:

I would recommend programming only the 4 blocks of repeating data into blocks 1 to 4

yes, I can see what you mean. We wrtie only necessary 1 to 4, So on Page0 we can leave the 3 blocks, 5,6,7 for password, and anything thing else

marshmellow · 2015-05-29 17:21:55

Direct = NRZ = modulation
in the config block you tell it how many blocks to auto transmit (maxblock i think.) the password block is always only block 7, and can be used for a password if password mode set, or just more data.

Last edited by marshmellow (2015-05-29 19:58:02)

ntk · 2015-05-29 17:41:25

In addition to the 7 user defined blocks, the T5557 rfid transponder also has two blocks of Traceability data
located in page 1. This information is not alterable and contains manufacturer codes, lot numbers, and other
such data for tracing the source of the transponder. So that part I dont need to care

Howto build the configuration for block 0

there is 32 bits of the configuration block to construct

bit 0 set to logi 1 would prevent all further writing
bit 1 to 11 is for set master code
bit 12 - 14 determine the bit rate of data transmitted from transponder to reader
bit 15 is always 1 for which meaning???
bit 16 to 20 define encoding protocol; for eaxample A bit pattern of 10000 selects Manchester Encoding
bit 21 to 23 is 000 PSK of AOR what ever it means...
bit 24 is 0
bit 25 to 27 is master block Determine the maximum block address transmitted in standard READ mode.
bit 28 Set this bit to activates the Password mode;in this Password mode all blocks need a password to be sent before they can be read or written. The password required is stored in data block 7

bit 30 to 31 always 0
bit 32 to indicate POR what ever it means.

convert the 32bits to hex, t have 11223344 then write

lf t55xx wr 0 11223344

ntk · 2015-05-29 19:47:58

go to T5557.pdf document. in figure 3 is the bit to chose from figure3, if this is a manchester modulation this would not be too complicated. But for NZ even when I combine figure3 and tabell1 i could not put down the bits for NZ 32 modulation.

Could you give me some guidance here so I can come nearer to the stage of test the tag at the door pls
I would say
it start with
00110000000000001001100011100001
because I am not clear how to do the NZ I code the bits wit reserved modulation

ntk · 2015-05-29 20:37:10

for NZ=direct

the bit look like this:

0 0110 0000000 010 0 00000 00 01 110 0 0 00 1

would it be ok, Marshmellow?

marshmellow · 2015-05-29 21:13:45

The locking bit isn't included in the 32 bit write Cmd. Not sure why you are turning on the init delay (or por delay) and the xmode OTP should be 0 (bit 24). Other than that looks good.

ntk · 2015-05-29 21:40:19

can you try with this one

I write this way because without separation very easy for mistake
0 0000 0000000 010 0 00000 00 01 110 0 0 00

000400E0

en4rab · 2015-05-29 22:07:23

When i decoded the tags i bought for some reason where you have a 1 bit i get a 0 bit, im not sure why.
You could get the same as i read with the command "data rawdemod nr 32 1" which will invert all the bits.
In the example below i have done that as i have working on my tags this way and I cant get my head round searching for 006f
The data from your tag (inverted read) looks like this:
1001001110000111
1111110010000001
0010011001000001
1011001101101101
1001101100010110
0100010001110011
0001010001011001
0100011001000011
1001001110000111
1111110010000001
I have cheated a little and cut mostly whats needed to save a bit of space, looking through it you can see at the end of the first line the beginning of a run of nine 1's then 128 bits later this run of nine 1's repeats.
so the bits arent aligned to what i think are the start bits, deleting the bits before the first run of nine 1's and moving it all up so it lines up nicely gives:
1111111110010000 FF90
0010010011001000 24C8
0011011001101101 366D
1011001101100010 B362
1100100010001110 C88E
0110001010001011 628B
0010100011001000 28C8
0111001001110000 7270
I cut this where the second run of nine 1 bits started as that is the tag just repeating the message again, the card just sends the above 128 bits over and over.
On the right is these bits as hex values.
The blocks on a t55x7 chip are 32 bits so to write the above bits to each block the commands would look like:
lf t55xx wr 1 FF9024C8
lf t55xx wr 2 366DB362
lf t55xx wr 3 C88E628B
lf t55xx wr 4 28C87270
Then you just need to configure how the t55x7 chip sends these bits.
Looking at the datasheet figure0-2 (block 0 initial configuration setting) the settings needed are
Data bitrate = RF/32
Modulation = Direct
Maxblk = 4
and since your card was sending inverse and i inverted the data because it made it easier for me inverse=1 if you read it normally and lined the bits up to 006F it would be inverse=0
any other options in the config block should be 0 which i think should give a config block of
00080082
double check this as writing the wrong thing to the config block can render a t55xx useless particularly OTP would mean no reprogramming it again
then if it all looks ok
lf t55xx wr 0 00080082
to write the config block.
Then try reading this card as if it were your original tag to see if it gives the same results, or go try it on a door.

ntk · 2015-05-29 22:13:36

the master key I think we should leave it always <>6 so 000 is best all time; not set to 110 (something with 6 then test mode write commands are ignored)

I witch that POD on by common sense that the device should wait until voltage reached certain level, the ST terminator set to 1 because something with synchronising, synchronising sounds like good... but no, L1 people mostly put ) there

We guess and seek common sense but but HW L1 thinks different, when we have definite value like Manchester, Password = yes etc. anything else even this master key bit, if dont know what exactly for we should not guess or use common sense, we just not switch them on .... that woud cause less damage ... I think that is the philosophie of L1, to them that T5557 protocol is written for.

ntk · 2015-05-29 22:22:38

00080082 0 0000 0000000 100 0 00000 00 01 000 0 0 10

thanks for made clearer to me. But COnfiguration block has problem
is it not Nezrab

dat bit rate would be RF/50

bit 24 should not be 0
bit 31 should be )

ntk · 2015-05-29 22:37:58

en4rab wrote:

W
00080082
double check this as writing the wrong thing to the config block can render a t55xx useless particularly OTP would mean no reprogramming it again
then if it all looks ok
lf t55xx wr 0 00080082
to write the config block.
Then try reading this card as if it were your original tag to see if it gives the same results, or go try it on a door.

Yes I do believe you by trying to understand the T55x7.pdf file I came across a thread on this Proxmark3 forum, when they learn to read oscilloscop and decoding the password from the 70 bytes to unlock a T55x7 card which is lock after using Chinese cloner....

I would not wish to run on "that way" if I still can walk.

Yes tonight I like to test our results

en4rab · 2015-05-29 22:38:38

the bitrate bits span a byte boundary, ignore the lock bit that isnt part of the config block
look in the row marked hex to see which bits are in which bytes:

ntk · 2015-05-29 23:08:48

thanks, I check the mask again

bit 12,13,14 = 010 data bit rate RF/32
bi 16 -20 all o mean direct modulation
bit 21 to 24 all 0 PSK CF set to RF/2; AOR 0 bit 24= 0
bit 25-27 set 100 means MAX block 4, ok max available to cycle, I understand this one now.
bit 28 set to 0 is no password
bit 29-30 set to 0 OK
bit 31 =1 !!!!!!!!!!!!!!!!! <<<<<<<<<<<<<<< ------------------- pls explain this
bit 32 =0

en4rab · 2015-05-29 23:15:35

bit 31 is inverse data, if set a 0 becomes a 1 and a 1 becomes a 0 when transmitted, because i am super lazy i inverted the data when reading the tag so i could look for the FF90 start, then setting this bit should invert it back so it transmits like your fob did.
The alternative would be to not invert when reading your tag and search for the start of 006F and program the blocks with this data and not invert the transmission ie set bit 31 to 0

marshmellow · 2015-05-29 23:35:38

The inverse data function *should* only work in xmode which requires different settings. That reference image is good but the datasheets are better.

ntk · 2015-05-30 00:29:55

now I am totally lost

http://www.filedropper.com/X

Last edited by ntk (2015-06-02 23:41:52)

ntk · 2015-05-30 01:04:11

I expect 3 of the 4 experiments not working, but all constellations work. How????

ntk · 2015-05-30 04:28:14

I still have few questions
1/ why do we know with certainty that this is Nr/32 and not different data rate like 16; or FSK modulation
2/when figure out the configuration for block 0 , what is the PSK CF why do we know that the correct setting is RF/2
3/we make a lot of thougths reg. invert appearing of data but with invert bit set or not, and with nezrab's data blocks or mine (obviously wrong because I dropped too many bits) all combination are working .... why????

marshmellow · 2015-05-30 05:10:25

Plot the wave (data plot). Then overlay a grid every 32 samples (data grid 32). Line up the fastest transition from high to low. It is RF/32. The nrz part takes some experience looking at the waves.

Ignore the PSK settings on the chip as they are only used with PSK modulations.

With the invert sometimes the reader can adjust for it. And as far as start position, the data repeates while the tag is powered so it should ultimately output the full string... Sometimes readers can get picky tho with this.

Now as far as your tests, I assume you are testing on the reader you have powered up instead of an actual door system? And it blinks the same as with the original tag?

ntk · 2015-05-30 10:38:44

I am going to buy battery/ power supply to setup the table reader, so I can conveniently test more commands. lf snoop for example.

Last edited by ntk (2015-06-19 10:03:25)

Proxmark3 community

Announcement

#51 2015-05-28 14:00:06

Re: KeyFOB at 153mHz

#52 2015-05-28 14:09:53

Re: KeyFOB at 153mHz

#53 2015-05-28 15:45:26

Re: KeyFOB at 153mHz

#54 2015-05-28 16:51:16

Re: KeyFOB at 153mHz

#55 2015-05-28 17:08:13

Re: KeyFOB at 153mHz

#56 2015-05-28 17:43:43

Re: KeyFOB at 153mHz

#57 2015-05-28 18:13:29

Re: KeyFOB at 153mHz

#58 2015-05-28 18:19:15

Re: KeyFOB at 153mHz

#59 2015-05-28 18:43:04

Re: KeyFOB at 153mHz

#60 2015-05-28 18:45:44

Re: KeyFOB at 153mHz

#61 2015-05-28 19:14:46

Re: KeyFOB at 153mHz

#62 2015-05-28 19:18:46

Re: KeyFOB at 153mHz

#63 2015-05-28 19:21:26

Re: KeyFOB at 153mHz

#64 2015-05-28 19:24:45

Re: KeyFOB at 153mHz

#65 2015-05-28 22:32:32

Re: KeyFOB at 153mHz

#66 2015-05-28 22:42:20

Re: KeyFOB at 153mHz

#67 2015-05-28 22:44:29

Re: KeyFOB at 153mHz

#68 2015-05-28 22:55:49

Re: KeyFOB at 153mHz

#69 2015-05-28 22:57:36

Re: KeyFOB at 153mHz

#70 2015-05-28 23:11:03

Re: KeyFOB at 153mHz

#71 2015-05-28 23:48:06

Re: KeyFOB at 153mHz

#72 2015-05-28 23:59:29

Re: KeyFOB at 153mHz

#73 2015-05-29 04:22:45

Re: KeyFOB at 153mHz

#74 2015-05-29 10:40:37

Re: KeyFOB at 153mHz

#75 2015-05-29 14:34:53

Re: KeyFOB at 153mHz

#76 2015-05-29 14:40:08

Re: KeyFOB at 153mHz

#77 2015-05-29 14:41:08

Re: KeyFOB at 153mHz

#78 2015-05-29 16:01:55

Re: KeyFOB at 153mHz

#79 2015-05-29 16:32:00

Re: KeyFOB at 153mHz

#80 2015-05-29 17:12:38

Re: KeyFOB at 153mHz

#81 2015-05-29 17:17:47

Re: KeyFOB at 153mHz

#82 2015-05-29 17:21:55

Re: KeyFOB at 153mHz

#83 2015-05-29 17:41:25

Re: KeyFOB at 153mHz

#84 2015-05-29 19:47:58

Re: KeyFOB at 153mHz

#85 2015-05-29 20:37:10

Re: KeyFOB at 153mHz

#86 2015-05-29 21:13:45

Re: KeyFOB at 153mHz

#87 2015-05-29 21:40:19

Re: KeyFOB at 153mHz

#88 2015-05-29 22:07:23

Re: KeyFOB at 153mHz

#89 2015-05-29 22:13:36

Re: KeyFOB at 153mHz