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
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.
FDX-B / ISO 11784/5 Animal Tag ID Found:
1111111111111111
1111111011010100
1100101010011111
0100111111111111
1111111111111111
1111111011010100
1100101010011111
0100111111111111
1111111111111111
1111111011010100
1100101010011111
0100111111111111
1111111111111111
1111111011010100
1100101010011111
0100111111111111
1111111111111111
1111111011010100
1100101010011111
0100111
how do i program in the t55xx tag please help
"ISO 11784 & 11785 are international standards that regulate the radio frequency identification (RFID) of animals, which is usually accomplished by implanting, introducing or attaching a transponder containing a microchip to an animal."
I am very junior and not the right member to help you but would you share what you have in that animal is microchip why would you want to write from micro chip to at55xx, which is a lot bigger to handle? I google for "microchip AT55xx At55x7" I could not see anything small enough fitted to micro classification
How do you know that it is FDX-B type and not FDX or half duplex HDX? So that is ASK and not FSK you use Proxmarkto scan and can use "lf askdemod" get that information and decoding to your binary data above?
if you want to work with At55xx there are document "At55x7.pdf" and "At5555.pdf" from the document section
proxmark3> lf read
#db# Sampling config:
#db# [q] divisor: 95
#db# bps: 8
#db# [d] decimation: 1
#db# [a] averaging: 1
#db# [t] trigger threshold: 0
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 00 00 00 00 00 00 00 00 ...
proxmark3> data samples 10000
Reading 10000 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data plot
proxmark3> data
> data fdxbdemod
FDX-B / ISO 11784/5 Animal Tag ID Found:
proxmark3> data printdemodbuffer x
DemodBuffer: 002566AC16000000002566AC16000000
I don't know if I am in the right path......
You are on the right path. The output of your last cmd gives you the data you need to program on blocks 1-4 of a t55x7 (see t55xx write cmd). Then you just need to figure out the config block settings of block 0. If I remember correctly I believe fdx b is ask/biphase. You can do a 'data detectclock a' to get the clock bit rate.
Hang on... Something doesn't look right. Can you do a 'lf search u' and post the results? If your tag was really a fdx b then it should have output the fdx info contained in the id... My guess is it may be a false positive.
Edit: that is, i guess, unless you purposefully omitted the fdx ID info. but that still doesn't explain why your printdemodbuffer had two repeats of your tag's data.
Last edited by marshmellow (2015-07-06 04:47:11)
i've found that the fdx-b code could fairly easily return false positive results, as the only real check was the check for the preamble of 00000000001, which could be found in many tags. i've adjusted this now in my fork and will soon issue a pull request to get the fix into the next release.
so i'm curious now what Go_tus actually has, it is NOT an FDX-B (based on the printdemodbuffer hex output)
Last edited by marshmellow (2015-07-06 05:27:55)
Hi marshmellow,
I have tried to code with t55xx write 1 002566AC write 2 16000000
with the configuration 90080040 and I have tried 90082, I am so good with this but the T55x7. And I try to lf search turn out national I'd country code are same. Except it doesn't work with the reader
Uh do you mean the 00000000001 header bit right?, I repost the full read of the card again
Thank you marshmellow
I got mixed sorry, write 4 blocks and configuration using q5 configuration 600f0e8
max block 4, carrier 32,rf/00 inverted, biphase
When I try to lf search this card, it sames ID, but still no work
I must have few steps, should I encoded by using national id, country, application ID to get 128-bit data and try to writes those 1-4 blocks again ?
If your data is 002566ac16000000 then it is NOT FDX-B and it was incorrectly identified/demodulated.
Can you post the results of the following cmd sequence:
lf read
data samples 40000
data rawdemod am
Hi Marshmellow, Thank you having a look about this tag. the number on the tag is 00001CDD.
proxmark3> lf search u
#db# Sampling config:
#db# [q] divisor: 95
#db# bps: 8
#db# [d] decimation: 1
#db# [a] averaging: 1
#db# [t] trigger threshold: 0
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 1e 13 1a 31 27 3e 33 38 ...
Reading 20000 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:
No Known Tags Found!
Checking for Unknown tags:
Possible Auto Correlation of 4096 repeating samples
Unknown ASK Modulated and Manchester encoded Tag Found!
if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
proxmark3> data rawdemod am
Using Clock: 32 - Invert: 0 - Bits Found: 512
ASK/Manchester decoded bitstream:
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
0000000000000000
0000111001101110
1100110111111001
0000000000000000
possible. it definitely looks like that binary is the correct demod. (it also looks kinda like other tags on the forum, i'll find the link)
i'd lean towards maybe :
00000000
1CDD9BF2
but either should get it done.
Last edited by marshmellow (2015-07-07 15:49:59)
btw, you can post a trace like you did before if you are a Contributor (which someone has now made you ) by using the BBCode:
[] with word code inside, then ending with [/] with the word "code" after /
you get a code box like this one
this is the same format tag as: http://www.proxmark.org/forum/viewtopic.php?id=2250
can we get a name for the system/reader these tags go to?
Hi Marshmellow, Thank you , one more thing please, what the block 0 will be like. I try to do but I fail, the clock went 64 which I want is clock = 32 .. can you help out please. By the way I like your code in the FDX-B in version 2.1
if you are using a t55x7 then see the first post in http://www.proxmark.org/forum/viewtopic.php?id=1767 for how to construct the configuration block.
iceman also assisted with the FDX-B code, but as you found it produced false positives too easily .. it will be fixed in the next version (assuming i get time to finish my other changes so i can issue a pull request to github soon... )
Last edited by marshmellow (2015-07-07 15:58:37)
Hi Marshmellow, I don't know the name of the tag but I want to add to the proxmark. I will try to code this one, by the way I am not good in programming , I will do what I can do, who do I sent it to?
it would be good to get a system or reader or some kind of identification of what the tag is or for. we will have many UnidentifiedDemod demods if we add them with no identification.
plus i'd guess the 9BF2 is some sort of CRC. if that can be identified then we can make sure we won't get false positives. i haven't yet had a chance to run the crc checks.
ideally code currently is submitted by issuing a pull request to the github repository. this requires a github account (free) and forking the proxmark3 repo, making your changes and then issuing a pull request.
github's learning curve isn't as steep as the pm3's
actually the F2 is the same for the tag in the link in post 17. so maybe: F20000 00001CDD 9B where F20000 = preamble? 9B = Facility code or checksum?
i've run the a search on the checksum and got nothing.
we need more examples...
Last edited by marshmellow (2015-07-09 21:21:22)
Hi, I still waiting for more samples, anyway I have done some little progress
[== Undefined ==]
#db# Sampling config:
#db# [q] divisor: 95
#db# [b] bps: 8
#db# [d] decimation: 1
#db# [a] averaging: 1
#db# [t] trigger threshold: 0
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 52 38 20 0e 00 00 00 00 ...
proxmark3> data samples 40000
Reading 39999 bytes from device memory
Data fetched
WARNING: Command buffer about to overwrite command! This needs to be fixed!
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data setdebugmode 1
proxmark3> data AMVdemod 00001cdd
Card ID Bytes 00001CDD
DEBUG: Bitlen from grphbuff: 39999
Using Clock:32, Invert:0, Bits Found:513
ASK/Manchester - Clock: 32 - Decoded bitstream:
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
0111001101110110
0110111111001000
0000000000000000
0000000000000000
binary : 00000000000000000001110011011101
Found AM V card
DemodBuffer: 00001CDD9BF20000
proxmark3>
If you link your github fork, then @marshmellow and I take a look at it. and give you tips.
but normally, you push your commits to your own master, then create a PullRequest into the PM3 master. There is GitHub howtos..
I saw your PR on github. Good work, may I suggest you divide the LF additions in a seperate PR instead of together with your iclass changes.
And same goes here with the "usage" (-h) metod.
However I'm not sure how your "data amviking demod" works. You take a cardid, then print the binary?!?
With the other demod cmds you get a detailed breakdown of the read bytes from the card.
Hi,
I have a card that was detected as FDX-B but reading this thread makes me think that it is a false positive and may instead me an AM V card.
Checking for known tags:
FDX-B / ISO 11784/5 Animal Tag ID Found:
Animal ID: 0000-0001024xxxxx
National Code: 0001024xxxxx
CountryCode: 0000
Extended Data: False
reserved Code: 1920
Animal Tag: True
CRC: 0x35XX - [4AXX] - Failed
Extended: 0xD
Valid FDX-B ID Found!
proxmark3> data printdemodbuffer x
DemodBuffer: 003XXXXXX5800000003XXXXXX5800000
Yes Iceman, also a demod and clone command in lf cmd.
I wanna do more but I have little knowledge. please guide me.
Did you get the clone command working in your fork?
Since the CRC failed, it looks like a false positiv.
There is some home-animal traces in the trace folder if you want to compare the plots.
I've not taken the AM V changes into my fork since I don't have a tag or trace to test it with.
I took your changes @Gustothebun but your solution doesnt actually decode a viking tag, it only compares with an id you supply in the command...
I have seen this format used on White cards and grey fobs. Both of them had an 8 digit code printed on them. So whilst Gustothebun's solution doesn't actually decode the tag it is still useful.
From his post he typed the 8 digit code:
proxmark3> data AMVdemod 00001cdd
Which gave him the binary
binary : 00000000000000000001110011011101
Which I believe could then be written onto blocks 1-4 of a T55x7 tag.
Can anyone please help me work out the block 0 configuration settings?
the HEX data you want to write from that binary is 1CDD, so you need only on block not 4,
For the rest of dates, needed to configure the block 0, I assume you want to leave as Go_tus posted in #8:
"carrier 32,rf/00 inverted, biphase"
then your block0 is 00090020
it could work as chipchip says, however since there is not a known demod algo for AMV (viking) , its more of a guesswork.
edit: thanks @marshmellow for pointing it out. AWID -> AMV
Last edited by iceman (2015-09-13 16:55:49)
Iceman meant amv not awid. And as he says we don't have a true demod yet so # of blocks may be questioned. The print demod example above suggests 2 blocks, whereas gusto seems to indicate 4 blocks. One block almost certainly would not work however as leading zeros are always important to lf formats.
Looking closer it is definitely 2 blocks, rf/32 and Manchester not biphase. That is enough info to build the correct block 0. There is a link earlier in this topic to the block 0 reference
@crispy
I think marshmellow's assessment is correct: 2 blocks, rf/32 and Manchester.
But for your experiment I provide all configuration block 0 with
- 1 data Blck is 00088020
- 2 data Blcks is 00088040
- 4 data Blcks is 00088080
I took your changes @Gustothebun but your solution doesnt actually decode a viking tag, it only compares with an id you supply in the command...
Is there a correct decode of this kind of tag somewhere?
Hi,
Sorry I am very unfamiliar with github. I would like to be able to do "data AMVdemod" to do what go_tus did in an earlier post to get the DemodBuffer:
>data AMVdemod 00001cdd
Found AM V card
DemodBuffer: 00001CDD9BF20000
To do this, would the best way be to download gustothebun zip file (https://github.com/gustothebun/proxmark3) and compile it?
Or is there an easier way to use his "data AMVdemod" command?
Thanks
I agree with iceman.
You don't need to use that, My code was a simply string search for the match card number in the binary demod buffer,
but there was a bug in the clone function, I used a wrong constant T5555 shifting It should be T55x7 shifting. My mistake
you need is to find patterns in binary bits
find the binary of the number that print on the card 8 bytes
and the following 8 bytes for another block that's all
Last edited by Go_tus (2015-10-02 17:12:32)
According to some pdf on Viking Electronics the viking tag should be a 26bit Wiegand.
ref thread, http://www.proxmark.org/forum/viewtopic … 778#p18778
Using: 1CDD9BF2
Internal Card # 52729
Facility Code # 110
Running the viking clone command
lf viking clone 00001cdd9bf20000
Running the latest demod from @Marshmellow, gives..
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:
Reading 30000 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
Viking Tag Found: Card ID 00001CDD, Checksum: 9B
Raw: F2000000001CDD9B
Valid Viking ID Found!
So the xorchecksum seems to be correct and the preamble seems to be correct.
But running cardid in the brivo calculator doesn't quite seem right.
FacilityCode and Internal Cardnumber would be nice to have for the clone command.
Last edited by iceman (2015-11-10 19:40:29)
the brivo calc will expect there to be the standard wiegand parities, and there aren't any in the raw data. if the reader outputs wiegand, then it generates the parities and tacks them onto "some" of the data read from the card.
but since 8 raw hex digits seem to be printed on the tags (32 bits) i'm not sure how a reader would split that raw data or why the raw data is printed instead of the 26 bit card id or facility code...
if someone has a reader and could share a printed id and what the id the reader sends/saves in the access control software we could put this to rest.