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.
can you get a "Valid" range that works by just incrementing around as many of the following tags as you can get time for?
0000000001111000011011111010000000110000101111100001111000001011
0000000001111000011100010110000000110000001111011011011001000011
0000000001111000011100010010000000110000001111011011011001000011
0000000001111000010111101010000000111001111111111101011111101111
0000000001111000010011101110000000111010111011011010110111000011
0000000001111000011100110110000000110110111110101010110111110111
0000000001111000010111100010000000110000111111100000011100011111
the more ranges of valid tags we get the closer we can get to identifying the bits that go into the algorithm. and we might just see a pattern arise.
Last edited by marshmellow (2015-01-17 05:52:12)
Offline
Do you guys want a script for this? Tell me what I can do to help out
Offline
If I had a reader I would want to have a Sim command available for this tag and then a script to run take a tag binary and Sim all the potential tags around it (by incrementing the id and reverse incrementing the checksum)
Even just a Sim command may speed up the process... ( that should be pretty easy. . but I've been waiting for iceman's Sim changes before I play with them.)
But I can't speak for lanix13..
Offline
There has been so much new code to implement and merge so I'm not done with my merging yet..
after that there are some minor bugs need to be fixed,
after that there is the "lf t55xx" changes to adapt to your new code (Marshmellow),
and then.. then.. then.. I will jump on the old "LF SIM" problem in the arm-source..
Offline
No problem iceman, I understand. Holiman just asked how he could help, and if we could script it.
Offline
@marshmellow, I took just your top number today and worked it out from top to bottom.
We know the cards split up like this:
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 11000011 1 10000010 11
and for this whole stack the first part stays the same for all cards:
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1
So I incremented the next set up to 11111111 and then also decremented it down to 00000000 - (from 255 down to 0)
While changing that set I did the opposit to the last set just like before. However this time I found that when it reached 11111111, I would just wrap it around to 00000000 or vise versa. And this worked!
Using this method I was able to find 255 valid card numbers. Here are some samples from my set of numbers:
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 11111111 1 01000110 11
.....
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 11000111 1 01111110 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 11001000 1 01111101 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 11001001 1 01111100 11
....
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 01000110 1 11111111 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 01000101 1 00000000 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 01000100 1 00000001 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 01000011 1 00000010 11
....
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 00000011 1 01000010 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 00000010 1 01000011 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 00000001 1 01000100 11
00000000 0 11110000 1 10111110 1 00000001 1 00001011 1 00000000 1 01000101 11
Here you can easily see the patern of what I am doing. (I did use scripts to work this out)
I will now work on the next number you gave me.
Offline
Good work. It appears the second part of the card number is subtracted from another number that is calculated by the first part of the card number, the facility code and possibly the family code, but possibly more...
An xor gets close on the right 4 digits but not the left.
Offline
Another sequence should confirm the last 8 bits of the card number works as I said above. But it would also be nice if we could try incrementing a fc or a higher card number bit, and then seeing if we can find the checksum.
Another test would be to take a working tags binary and try changing each bit one at a time (excluding the preamble) and seeing if it still works. That might help us confirm which bits are used in the checksum calc.
Offline
Could you test this one tag for me, it is an outlier from someone else's testing, but I don't think it should work. 00787120303db643 but instead should be 00787120303db647
Offline
Ok, here is the next card number set.
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 00000000 1 01000110 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 00000001 1 01000101 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 00000010 1 01000100 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 00000011 1 01000011 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 00000100 1 01000010 11
.......
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 01000101 1 00000001 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 01000110 1 00000000 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 01000111 1 11111111 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 01001000 1 11111110 11
.......
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110100 1 10010010 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110101 1 10010001 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110110 1 10010000 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110111 1 10001111 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10111000 1 10001110 11
.......
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 11111101 1 01001001 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 11111110 1 01001000 11
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 11111111 1 01000111 11
Offline
@marshmellow, I will try those card numbers out and let you know, most likely tomorrow. I agree, we now know how the card numbers increment within that 255 but we need to know how to increment the fc or the other parts of the card number to find the next sequencial set of 255 card numbers.
Offline
I think the right 4 bits of the fc increment in the same manner
Offline
Hmm... ok, I will play around with the last 4 of the fc, but why only the last 4 bits?
Offline
It might be all of it but somewhere the first 4 and last 4 bits get out of sync.
Offline
@marshmellow, you are right, of the two card numbers you gave me this one worked 00787120303db647, the other did not.
Offline
OK earlier in this thread there must have been a typo then, it was throwing me off
Offline
Now that is interesting, the one you gave me: 00787120303db647 that does work is this:
00000000 0 11110000 1 11000100 1 00000001 1 00000011 1 10110110 1 10010001 11
and from that previous set you find this similar one:
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110110 1 10010000 11
notice the similarities with the fc and the crc between the two.
Offline
Using what we learned from that previous comparison, I took it one step further and incremented the fc by one and decremented the crc by one to get this:
00000000 0 11110000 1 11000110 1 00000001 1 00000011 1 10110110 1 10001111 11
and it worked on the reader! Now we can see how to get to different sets of sequencial 255 cards and it helps us understand the connection between the fc and the crc.
Offline
yes, those samples let me to think at least the right 4 fc bits increment the same way as the right 8 bits of the card number.
i'm not sure it expands to the entire fc though, but that would be one important step to test.
then we have to figure out how the left 8 bits of the card number factor in.
Offline
Ok, I did a little more, this time only incrementing the fc and decrementing the crc. I wanted to see what going into the 5th bit of the fc would do and all the following worked:
00000000 0 11110000 1 11000101 1 00000001 1 00000011 1 10110110 1 10010000 11
00000000 0 11110000 1 11000110 1 00000001 1 00000011 1 10110110 1 10001111 11
00000000 0 11110000 1 11000111 1 00000001 1 00000011 1 10110110 1 10001110 11
00000000 0 11110000 1 11001000 1 00000001 1 00000011 1 10110110 1 10001101 11
00000000 0 11110000 1 11001001 1 00000001 1 00000011 1 10110110 1 10001100 11
00000000 0 11110000 1 11001010 1 00000001 1 00000011 1 10110110 1 10001011 11
00000000 0 11110000 1 11001011 1 00000001 1 00000011 1 10110110 1 10001010 11
00000000 0 11110000 1 11001100 1 00000001 1 00000011 1 10110110 1 10001001 11
00000000 0 11110000 1 11001101 1 00000001 1 00000011 1 10110110 1 10001000 11
00000000 0 11110000 1 11001110 1 00000001 1 00000011 1 10110110 1 10000111 11
00000000 0 11110000 1 11001111 1 00000001 1 00000011 1 10110110 1 10000110 11
00000000 0 11110000 1 11010000 1 00000001 1 00000011 1 10110110 1 10000101 11
so it looks like it goes beyond that 4th bit. I will push into the 6th bit just for one more verification.
Offline
Looks good. I think I'm close
Offline
Here you see I went into the 6th bit of the fc and it still worked
00000000 0 11110000 1 11011101 1 00000001 1 00000011 1 10110110 1 01111000 11
00000000 0 11110000 1 11011110 1 00000001 1 00000011 1 10110110 1 01110111 11
00000000 0 11110000 1 11011111 1 00000001 1 00000011 1 10110110 1 01110110 11
00000000 0 11110000 1 11100000 1 00000001 1 00000011 1 10110110 1 01110101 11
Offline
ok here it is:
(0x10E-(FC+C1+C2))&0xFF=CS
FC=facility code
c1= first 8 bits of card number
c2= second 8 bits of card number
cs= checksum value
Last edited by marshmellow (2015-01-21 19:33:45)
Offline
it may include the family code and the other byte (0xF0) and that would then be:
0xFF-((0xF0+0x01+FC+C1+C2)&0xFF)=CS
that kind of makes more sense.
Last edited by marshmellow (2015-01-21 19:43:08)
Offline
Hmm... it isn't coming out for me so I think I am going to show my ignorance. Can you give a small example?
Offline
00000000 0 11110000 1 11100000 1 00000001 1 00000011 1 10110110 1 01110101 11
preamble F0 E0 01 03 B6 75
F0 + E0 + 01 + 03 + B6 = 28A
28A & FF = 8A
FF - 8A = 75
Last edited by marshmellow (2015-01-21 22:41:06)
Offline
please test as many random numbers as you can while you have access to the reader to confirm this works.
Offline
Thanks, that did it for me. I don't have it scripted yet but I have verified 3 cards using this math and all three have been 100%
Offline
@marshmellow What you figured out seems to have done the trick, here is some php script I did to be able to generate the full card number based on the number written on the front of the card. Every card I have tried so far has worked.
[== PHP ==]
<?php
//card number: XSF(01)3B:44725
$fc=0x3B;
$card=44725;
$cardbin=str_split(base_convert($card, 10, 2));
//echo "Card in binary = ".implode($cardbin)."\n";
$c1="$cardbin[0]$cardbin[1]$cardbin[2]$cardbin[3]$cardbin[4]$cardbin[5]$cardbin[6]$cardbin[7]";
//echo "c1 = $c1\n";
$c2="$cardbin[8]$cardbin[9]$cardbin[10]$cardbin[11]$cardbin[12]$cardbin[13]$cardbin[14]$cardbin[15]";
//echo "c2 = $c2\n";
$hexC1 = base_convert("$c1", 2, 16);
//echo "c1 in hex = $hexC1\n";
$hexC2 = base_convert("$c2", 2, 16);
//echo "c2 in hex = $hexC2\n";
$step1 = 0xF0 + $fc;
//echo "Step1 = $step1\n";
$step2 = $step1 + 0x01;
//echo "Step2 = $step2\n";
$step3 = $step2 + base_convert($hexC1, 16, 10);
//echo "Step3 = $step3\n";
$step4 = $step3 + base_convert($hexC2, 16, 10);
//echo "Step4 = $step4\n";
$step5 = $step4 & 0xFF;
//echo "Step5 = $step5\n";
$step6 = 0xFF - $step5;
//echo "Step6 = $step6\n";
$binary = sprintf("00000000 0 11110000 1 %08b 1 00000001 1 %s 1 %s 1 %08b 11", $fc, $c1, $c2, $step6);
echo "$binary\nlf io clone ".base_convert($binary, 2, 16);
echo "\n";
?>
Offline
Thanks to everyone who has done such great work on the HID XSF cards. I have been following along and wish I had the programming skills to contribute something to the forum.
I downloaded and installed Asper’s pm-bin-0.0.6 onto my proxmark and it worked perfectly in reading my Kantech card. At work we once had all Kantech XSF cards but except for the parking garage they have been replaced with iClass cards. So I have one last reader that I can test on.
The problem I have is this: I have been trying to generate a hex number to enter into my proxmark to generate a new card using just the facility code and the card number as found on the outside of my card. Using marshmellow’s method to calculate the checksum:
(00000000 0 11110000 1 11100000 1 00000001 1 00000011 1 10110110 1 01110101 11
preamble F0 E0 01 03 B6 75
F0 + E0 + 01 + 03 + B6 = 28A
28A & FF = 8A
FF - 8A = 75
Adding all of these together (F0 to B6) I end up with a checksum of 728 which when converted to a bin is 1011011000, which is 10 digits not 8. When I enter the entire bin sequence from the F0 to the checksum and generate a hex number it works, my proxmark writes to the new card and then when it demods it gives me the correct site code and card number but the checksum is clearly wrong.
When my proxmark spits out the final string of bin numbers that represent the checksum they end in 00 and not 11. I checked the forum and all of the checksums appear to end in 11, or at least I think that’s correct.
The proxmark scans the duplicate card fine, (correct facility and card number) but the HID reader in the basement just does not respond in anyway to the card. Not so much as a beep. I have clearly missed something and it is probably obvious but I can’t see it.
I am sorry to ask this but I understand what 28a & 75 represent in marshmellow’s formula but what does the FF stand for.
Offline
The & is a bitwise and.
Offline
Thank you marshmellow. That helps, a dumb question but I appreciate your help.
Offline
I don't quite grasp the calculation from the binary/hex to the XSF number on the card/fob it self, or vise virsa.
Could you show me en example of doing it manually, please?
Offline
use the windows calculator in programmer mode. (or another calculator)
Offline
That actually simplified figuring it all out. Thank You!
Offline
I went ahead and wrote a quick executable to do all needed calculations, from & to all values.
http://www.mediafire.com/download/mqve8q8hqazam8k/ioProx_Calculator_[1.0.1.4].zip
Hopefully some find it useful.
Offline
a suggested patch, maybe Marshmellow can test it out.
uint8_t crc = bytebits_to_byte(BitStream+idx+54,8);
uint16_t calccrc = 0;
for (uint8_t i=1; i<6; ++i)
calccrc += bytebits_to_byte(BitStream+idx+9*i,8);
calccrc &= 0xff;
calccrc = 0xff - calccrc;
char *crcStr = (crc == calccrc) ? "ok": "!crc";
PrintAndLog("IO Prox XSF(%02d)%02x:%05d (%08x%08x) [%02x %s]",version,facilitycode,number,code,code2, crc, crcStr);
[edit] fixed the comparison. Works with a tracefile.
Last edited by iceman (2015-03-23 17:57:09)
Offline
Committed
Offline
This might sound silly, but did anyone notice that the ioProx chips are writable?
Using the clone command, I was able to write a different fob number into it.
I was also able to copy an EM41xx card number into it. (Though I used a chinese hand held cloner which automatically adds a password. Trying to remove it bare no fruits for me so far, and I'm not even able to write a different EM41xx to it using the same cloner)
Offline
Would be great if we could sniff the traffic between your tag and cloner so we have a change to identify the password used by the cloner.
Darik, Could you do that and upload the trace?
Offline
I think the ioprox are not password protected.
Offline
that would be a relief,
Offline
So are them T55x7 ?
Offline
I tried the t55x7 write command on a genuine ioProx :
proxmark3> lf io fskdemod 1
proxmark3>
proxmark3> #db# 00000000 0
proxmark3> #db# 1xx0000 1
proxmark3> #db# 0xxx011 1
proxmark3> #db# 00000001 1
proxmark3> #db# 10xxx10 1
proxmark3> #db# 10xx01 1
proxmark3> #db# 01xxx00 11
proxmark3> #db# XSF(01)3x:44xx5 (00x4exxxxxdc3)
proxmark3> lf t55xx writeblock 12345678 2
Writting block 2 with data 12345678
proxmark3>
proxmark3> lf io fskdemod 1
proxmark3>
proxmark3> #db# Stopped ---> GONE
proxmark3> lf io clone 00x4exxxxxdc3
Cloning tag with ID 00x4exx xxxdc3
Press pm3-button to abort simulation
proxmark3>
proxmark3> #db# DONE!
proxmark3> lf io fskdemod 1
proxmark3>
proxmark3> #db# 00000000 0
proxmark3> #db# 1xx0000 1
proxmark3> #db# 0xxx011 1
proxmark3> #db# 00000001 1
proxmark3> #db# 10xxx10 1
proxmark3> #db# 10xx01 1
proxmark3> #db# 01xxx00 11
proxmark3> #db# XSF(01)3x:44xx5 (00x4exxxxxdc3)
Last edited by app_o1 (2015-03-28 10:42:39)
Offline
It is indeed a t55x7.
Trace Block 1 = 0xE0150152
Trace Block 2 = 0x4211AF86
Offline
Did you get the latest source to compile App_o1 ?!?
I think the "lf io fskdemod" is outdated now
Offline
lf io fskdemod is current, and functions well.
Offline
cool , thanks M.
Offline
Would be great if we could sniff the traffic between your tag and cloner so we have a change to identify the password used by the cloner.
Darik, Could you do that and upload the trace?
I'm fairly certain I'm doing this wrong..
I tried:
lf snoop 1
data sample 24000
data plot
data mandemod
I tried synchronizing pressing the write function on the cloner and hitting enter on the keyboard..
Results:
Manchester decoded bitstream
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
.. etc .. for about 60-90 lines or something...
I only just started with the proxmark3 within the past 3-4 weeks.
Any tips towards the right direction & I should get it going.
I tried a couple of other demods, such as ask.
Best I could get is the graph (Amplified):
That is from the first of the two readers, with a t5577 card emulating em4100
Offline
Nice! Are you running on the latest source from GitHub?
And if you can save the trace? i.e. "data save mytrace.pm3" and upload it somewhere?
Offline