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.
alucardx wrote:i think the better question is "is it worked?"
The specifications for the unit show that it should clone EM cards but makes no mention of supporting HID cards. Hence my question to diaconom - does he/she know if it can clone HID cards.
I don't mean to be pedantic but "is it worked" doesn't make sense to me as a question.
is this the unit : h*t*t*p://www.aliexpress.com/item/Handheld-125Khz-250-375-500-625-750-875-1mhz-13-56MHZ-RFID-Duplicator-Copier-Writer-10X/2024094600.html
seem like too good to be true, but when the unit arrive, i tested with HID Prox II card, see if it can be done or not
Offline
I have just resent you my address.... pls check.
Hi have you received it? I sent it to the first address you gave me
Offline
is this the unit : h*t*t*p://www.aliexpress.com/item/Handheld-125Khz-250-375-500-625-750-875-1mhz-13-56MHZ-RFID-Duplicator-Copier-Writer-10X/2024094600.html
seem like too good to be true, but when the unit arrive, i tested with HID Prox II card, see if it can be done or not
125Khz-250-375-500-625-750-875-1mhz-13-56MHZ
They must be kidding...
Offline
alucardx wrote:is this the unit : h*t*t*p://www.aliexpress.com/item/Handheld-125Khz-250-375-500-625-750-875-1mhz-13-56MHZ-RFID-Duplicator-Copier-Writer-10X/2024094600.html
seem like too good to be true, but when the unit arrive, i tested with HID Prox II card, see if it can be done or not
125Khz-250-375-500-625-750-875-1mhz-13-56MHZ
They must be kidding...
I agree...
Offline
sorry ppl as I was busy moving house so have been offline...
->genexis<- got your FABS in the mail and sent you email - 9 received and 8 of them are T55xx and have been reset and are now ready to program without a password One of them is an EM4100 read only FAB.
->gbhuk & alucardx<- the "fancy" cloner will only do NON-encrypted cards copies - but I did manage to clone both 125Khz and 13.56mhz (HID cards are not supported)
I'm waiting for my log analyser to try to decode the password similar to what gbhuk has done... will report back my status... my new saleae should be here on Tuesday
Offline
(HID cards are not supported)
I'm waiting for my log analyser to try to decode the password similar to what gbhuk has done... will report back my status... my new saleae should be here on Tuesday
Good to know that it doesn't support HID - thanks!
Good luck with your new Saleae logic analyser - if you need any guidance on how I determined the password with it please ping me - I saved the traces from the one I did.
Offline
-> if you need any guidance on how I determined the password with it please ping me
HELP
I managed to save and capture the data of a write sequence from one of the Handheld RFID writers with the known password.
I hope you can help teach us how to use the captured data to export it and make it usable.
Thanks
Offline
Cool, You mind to share that captured data?
Offline
Here is the raw data I captured: http://goo.gl/kaH6hM
Hope you can make sense out of it.
Last edited by diaconom (2014-10-08 16:53:15)
Offline
Anyone making any sense of the Saleae LLC Logic capture file above?
Offline
I had to double-check that I'd loaded your trace and not mine because the results are remarkably similar...
[1+Page select] [Password 1-32] [Lock Bit] [Data 1-32] [Addr 2-0]
10 01010001001001000011011001001000 0 01010001001001000011011001001000 111 = block 7
10 01010001001001000011011001001000 0 01010001001001000011011001001000 111 = block 7
10 01010001001001000011011001001000 0 11111111100000010010000000000000 001 = block 1
10 01010001001001000011011001001000 0 11110000010101111100100111100100 010 = block 2
10 01010001001001000011011001001000 0 00000000000101001000000001010001 000 = block 0
Again the programmer sends 5 blocks of 70 bytes, as above. This is expected when the programmer is setting the 32 bit password in block 7.
The password it sets is any of the seven highlighted blocks of 32 bits converted to hex, which is: 51 24 36 48
Your new cloner appears to set the same password as my little blue one.
I know for sure that it's your trace I'm loading and not my old one as the data it writes to blocks 1 and 2 (the card ID) is different.
So to reset the password bit on a card or tag with a Proxmark the command should be the same as in my previous post here: http://proxmark.org/forum/viewtopic.php?pid=11778#p11778
Offline
gbhuk,
-> I managed to save and capture the data of a write sequence from one of the Handheld RFID writers with the known password.
"Known password !!"
My capture is also from a "little blue one" similar to the start of this tread and the password was known as it had worked with your previous suggestion - sorry for the confusion but now that I know the capture works correctly I'll do the same with the "other" cloner (with currently unknown password)
Can you help me teach me how you converted the capture file to binary ?
Offline
"Known password !!"
Ah - I missed that!
No problem - at least it shows that the capture worked, as you say.
I'm a bit pressed for time today but will try to write something up over the weekend on how to interpret the captured data to binary blocks.
By the way - if you turn off the unused channels on the Saleae Logic software your next data capture file will be a lot smaller :-)
Offline
Ok, so I have a little time on my hands after all...
Sorry if you already know some or most of this but I think it's useful to know how the data on the card is organised - because it's key to understanding how the cloner programs the card. It's a lot simpler than it looks.
The card has 7 blocks of data, each 33 bytes wide (lock bit + 32 bits).
Block 7 is where the 32 bit password is stored, if a password is set.
Block 0 holds the configuration data, and if the cloner sets a password then it also sets bit 28 of block 0 to a '1'
I mention this as it's not strictly necessary to remove the password from block 7 to make the card programmable by the Proxmark, setting this bit to '0' will remove the password protection, but we need to know the password in order to do it.
Getting the password from the logic analyser trace is not too difficult:
The datasheet shows that for a 'standard write' to a block on the card 38 bits are sent in total, organised as:
[2 bit op-code ] [1 lock bit] [32 data bits] [3 block address bits] = 38 bits
However if the PWD bit is set then a 32-bit password is sent between the op-code and the data bits:
[2 bit op-code ] [32 bit password] [1 lock bit] [32 data bits] [3 block address bits] = 70 bits.
Data is written to the card by On-Off Keying the carrier, which looks like this at the base-metal level:
The card waits to see a long start gap (Sgap) and then takes each subsequent burst of data to be a 'bit'. A long burst = 1 and a short burst = 0. The shorter gap between bursts (Wgap) is the same duration between each bit.
Your trace shows 5 'packets' of 70 bits being transmitted by the cloner.
The first packet looks like this:
You can see the Start Gap (in red) then the 70 long and short burts of data corresponding to the bits the cloner's transmitting to the card.
It's a simple case of 'reading' a longer burst as a '1' and a shorter burst as a '0' for each of the 70 bits.
In the above case the bits are:
1001010001001001000011011001001000001010001001001000011011001001000111
We know that the data is organised as:
[2 bit op-code ] [32 bit password] [1 lock bit] [32 data bits] [3 block address bits] = 70 bits
The op-code is always [10] for page zero - which is the memory page we're interested in.
The next 32 bits are the password.
The next bit is a lock bit (which if it's set locks the block permanently and according to the data sheet it cannot be reset over RF)
The next 32 bits are data
The last 3 bits are the block address it's writing to.
So, splitting the packet up gives:
10-01010001001001000011011001001000-0-01010001001001000011011001001000-111
Op-code = 10
32 bit password = 01010001001001000011011001001000
lock bit = 0
32 bit data = 01010001001001000011011001001000
3 bit block address = 111 = 7 decimal
As it's writing to block 7 - which is the password block, in this packet the 32 bits of the password data and the 32 bits of the 'data' data are the same.
The password is: 01010001001001000011011001001000
Separating that into bytes and converting to hex gives:
01010001 00100100 00110110 01001000
5 1 2 4 3 6 4 8
The datasheet states that the bits are sent in the order that they're read, so the password is (hex) 51243648
There's really no need to decode the other four 'packets' - I just did it to verify that I'd got the right password and to see what was going on at the electronics level.
Hope this helps and I look forward to your report on the 'new' cloner... :-)
Last edited by gbhuk (2014-10-13 20:50:47)
Offline
gbhuk,
your guide is a great help and without the pic I would not have realized I was looking at the wrong highs and lows, none the less your guide was so clear I could capture and extract the password for the "new" alixxx multi freq cloner and used proxmark to reset the fab back to default writing block 0 to disable the password, thus allowing me to program with proxmark or a different handheld cloner.
I looked for the write to block 7 as the last 3 bits are easy to find and since the data and password section should match reconfirming the password read is correct.
So here is the command I captured:
Write to Block 7: 1000000000000011011000011110000111000000000000011011000011110000111111
Password: 0000 0000 0000 1101 1000 0111 1000 0111
Hex: 0 0 0 D 8 7 8 7
Last edited by diaconom (2014-10-11 02:53:08)
Offline
diaconom,
Great! That's two 'cloner' passwords we have to add to the collection :-)
Offline
If you look at the PM3 sourcecode on Github, there is a "lf snoop" ...
It doesen't produce any output for me. I tried many different firmwares: latest on Github, the latest on Googlecode, older firmwares, etc.
What do I miss?
Please, help me in receiving the "wow! signal"...
Last edited by MilkThief (2014-10-14 17:31:14)
Offline
I noticed that lots of the lf commands actually doesn't download the data to the client..
for example:
"lf t55xx read/readpwd"
"lf em4x read/readpwd"
"lf snoop"
I tested to download the snooped data, but it doesn't give so much..
the "lf read" / "data samples" / "data plot" works better to get a signal
Offline
the "lf read" / "data samples" / "data plot" works better to get a signal
Sure, but decoding a UID watching at the plot is not so funny... :-)
Offline
often you need to run data samples command after lf commands that "read", but i admit i haven't tried lf snoop yet... (on my to do list)
Offline
Great to see this topic, very useful but I am afraid more/other passwords are being used now.
I had bought some cheap easy tags to experiment with link aliexpress tag
But somehow I could not write to the tags while the same commands worked fine on other tags. what the .... was going on. Thanks to this topic I now know why. great explaining!
I have tried various password I found here and even the brute force for a short while but then I thought lets put it on the forum.
I have asked the seller if I needed a special cloner for these tags (then I know for sure a password is being used) or in case the tags where protected if he could provide me the password.... (I know,the chances are very little he will give me that). so far still no response from the seller. maybe a Chinese holiday....
So I could only advice people not to buy these tags (unless you want to get )
I haven't bought a cheap cloner for 10 euro's to test if cloning that way works. It's more fun to do it directly with the proxmark.(if I succeed)
Has anyone found another password lately I could use to test and try to remove the password bit?
lf t55xx write b 0 d 00148041 p newpassword?
by the way: I bought good working dual rfid tags (UID+t5577 chip) works great on HF and LF(no password or writing troubles).
link
Offline
You can always test the following in my fork.
"lf t55 brute" - with defaultpwd.dic file
"lf t55 recoverpw" - for finding bitflips in known pwd. Error in writing could generate these bitflips.
on your tags..
Offline
@gbhuk, @diaconom
I would like to look into the traces you have captured with Salaem and discussed about in this thread, but links have been expired. Could you share them again. Please. Many thanks.
I would like to see if there are parallel between when capture traces with salaem and when snoop traces of the proxmark3.
I am not sure I would find also the 5x 70bit of the write command clearly in the snoop trace...
But parallelity will help me to identify in the Pm3 snoop trace the start gap and looking at the right bits to find the op code, the 4 bytes password in clear text, the lock bit (zero) and 32bit data it caries for compare. ...
nowadays I see some Salaem for under $15 for an amateur you think they are ok. With cable set should I get? and where should I connect to, to capture the trace? at 2 connectors of the antennas?
Offline
Hi @gbhuk, @diaconom,
I'm having trouble figuring out the configuration on my T55xx tags after being cloned. Could you guys post the result of lf t55xx detect on one of your tags? I also captured the writing sequence from my blue cloner, you can see it here: http://proxmark.org/forum/viewtopic.php?id=6245
Thanks!
Offline