Trouble duplicating Motorola ASP/Indala - Same data doesn't work

tinfever · 2016-04-06 06:16:41

I've got a bit of a puzzle for you guys. I'm trying to duplicate a card that is marked as an "ASP by Motorola". From what I have read this means it is the same as an indala card.

Short story: cloned the card by doing:

lf search
lf indalademod
lf indalaclone 47203b015

and double checking my work with another lf search and lf indalademod. Looks good.

But it doesn't work on the reader. The original card makes the reader light up and beep but the cloned card with the exact same data does nothing. It's like won't even recognize it as a card.

The plots of the different cards look like the same data but perhaps not transmitted to meet the standards of the reader.

Do you guys have any thoughts? Should I get the equipment so I can snoop when the original card is used against the reader? Is there such a thing as a low quality T5577 card?

Another quirk, although perhaps user induced, occasionally the original card will show a different initial 'lf search' than 47203b015 but it will always demod back to 47203b015. On two other cards I have for this reader, this happens a majority of the time. Is there some sort of communication between the reader and the card more than just the card shouting it's number over and over again? Is there anyway to replicate that behavior on another card where it has to be "indalademod"ed in order to get the final data?
=========================================

Long Story:

Here's what I've done so far.

proxmark3> lf search
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:

BitLen: 64
Indala UID=0000000000000000000000000000010001110010000000111011000000010101 (472
03b015)

Valid Indala ID Found!
proxmark3> lf indalademod
Recovered 937 raw bits, expected: 937
worst metric (0=best..7=worst): 5 at pos 182
UID=0000000000000000000000000000010001110010000000111011000000010101 (47203b015)

Occurrences: 14 (expected 14)

Seems simple enough...

I put in a T5577 card.

proxmark3> lf indalaclone 47203b015
Cloning 64bit tag with UID 47203b015
#db# DONE!
proxmark3> lf search
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:

BitLen: 64
Indala UID=0000000000000000000000000000010001110010000000111011000000010101 (47203b015)

Valid Indala ID Found!
proxmark3> lf indalademod
Recovered 937 raw bits, expected: 937
worst metric (0=best..7=worst): 7 at pos 178
UID=0000000000000000000000000000010001110010000000111011000000010101 (47203b015)
Occurrences: 14 (expected 14)

Great... Except it doesn't work on the reader I want it to.

The original card makes the reader beep and light up, the duplicated card does absolutely nothing. It's like it doesn't even exist.

Further investigation

Plot of Original Card:
Plot of Duplicated Card: gYQkh9s.png?1

It looks like the same data but maybe the T5577 just isn't transmitting it perfectly enough?

Plot of Different Brand Duplicated Card:

Interesting. It appears there are differences even between T5577 card from different vendors.

tinfever · 2016-04-06 06:38:16

Here are some traces of the card originals I have:

"ecard" - Other Original Card
https://drive.google.com/open?id=0B4C5_10jlx3Qc1hiOHUwS29ieHc
https://drive.google.com/open?id=0B4C5_10jlx3QOUFrX3h6OTQxMFk
https://drive.google.com/open?id=0B4C5_10jlx3QVjFhZ1pvT3VYVUk

"rcard" - Other Original Card
https://drive.google.com/open?id=0B4C5_10jlx3QR2lNSklsYkl3S28
https://drive.google.com/open?id=0B4C5_10jlx3QT2t4U05INTgzQ2M
https://drive.google.com/open?id=0B4C5_10jlx3QT0xoYm90VTdhNm8

"zcard" - Main Focus Card Shown in OP
https://drive.google.com/open?id=0B4C5_10jlx3QWjBMcjRlV2NYaU0
https://drive.google.com/open?id=0B4C5_10jlx3QbUdDNWctemZuUzA
https://drive.google.com/open?id=0B4C5_10jlx3QUlFRWktmeTRKOVE

and here is is a trace of each of the two duplicates of Z card (the only one I am working on at the moment):

https://drive.google.com/open?id=0B4C5_10jlx3QcGxxMGlwYlhzX00
https://drive.google.com/open?id=0B4C5_10jlx3Qb3EydV9nSmF2cWM

ericlam2728 · 2016-04-06 11:21:59

1. Lf read

2. Data samples 16000

3. Lf indalademod

4. Clone it to the t5577 card.

Let me know if it worked

marshmellow · 2016-04-06 13:10:36

Are you using the most current github code or one of the precompiled releases?

tinfever · 2016-04-06 17:17:52

ericlam2728 wrote:

1. Lf read
2. Data samples 16000
3. Lf indalademod
4. Clone it to the t5577 card.

Let me know if it worked

I'll give it a try but I don't see what that would do differently than I am already doing.

marshmellow wrote:

Are you using the most current github code or one of the precompiled releases?

This was attempted with both 2.4.0 and 2.5.0 precompiled Windows releases. I will compile the latest github code and give it a try when I have some time. Has something changed that would effect this since the 2.5.0 Windows release?

marshmellow · 2016-04-06 17:22:03

Yes there have been changes. Also trust lf search more than lf indalademod. Or do data rawdemod p1 and locate the repeating pattern.

marshmellow · 2016-04-06 17:24:56

I'll take a look at the traces shortly.

marshmellow · 2016-04-06 17:57:55

the original card isn't a duel technology card is it? has LF chip and HF chip inside? possibly LF is being phased out and reader you are attempting on only reads the HF?

the duplicate you made appears correct, under quick review. each size antenna attached to a t55xx chip will transmit a slightly different waveform as you've noticed. but it shouldn't affect the reader's ability to read it. the ecard has a different starting phase so it might be psk2 or something different.

do you have card numbers printed on these tags?

tinfever · 2016-04-07 00:44:05

ericlam2728 wrote:

1. Lf read
2. Data samples 16000
3. Lf indalademod
4. Clone it to the t5577 card.

Let me know if it worked

Tried it and exact same thing happened. Cards don't exist to the reader. I don't think this did anything differently than what I had already tried.

marshmellow wrote:

the original card isn't a duel technology card is it? has LF chip and HF chip inside? possibly LF is being phased out and reader you are attempting on only reads the HF?
the duplicate you made appears correct, under quick review. each size antenna attached to a t55xx chip will transmit a slightly different waveform as you've noticed. but it shouldn't affect the reader's ability to read it. the ecard has a different starting phase so it might be psk2 or something different.
do you have card numbers printed on these tags?

I don't know if these are dual technology cards. I have tried hf search on them but received no response so I assumed they weren't.

I can say this though: 'zcard' is an older card marked 'ASP by Motorola' but 'rcard' and 'ecard' are newer and marked as indala.

I also have the printed numbers on the card if they are any help:

ecard: 11101457783-1 02671
rcard: 11101457783-1 02674
zcard: 1570 01331

tinfever · 2016-04-07 07:32:22

For now I am only worrying about zcard and why the original makes the reader beep and blink but the clone doesn't. After that I will see if the differences between zcard and rcard/ecard are an issue.

I have done an hf search on zcard and received no response. I am trying to figure out how to get the raw data from HF and plot it and also be able to upload it but I can't seem to find the right way to do that. How do I tell the proxmark that I want samples from HF instead of LF?

Also, when I first plug in the Proxmark and do 'hw status' it says it is in HF mode so I do a 'data samples 40000'. This just gives me a bizarre looking plot and data that won't 'rawdemod' to anything. If I do 'data samples 40000' again it doesn't even seem like it pulls new samples but when I do data buffclear first, it looks like it pulls 40000 samples of nothing until I reset the Proxmark again.

Anyways, for now the question is: Why will the original card cause the reader to light up but a T5577 with the exact same data causes nothing?

I wish I could be of more help here instead of relying on you guys so let me know if there is something I can do.

Here is a link to what I think might be a HF trace of zcard. I'm not 100% sure what this is coming from though: https://drive.google.com/open?id=0B4C5_10jlx3Qb3NPbDJTVDBnMDQ

tinfever · 2016-04-07 07:46:37

I also compiled the client and everything from the latest github and installed the newly compiled bootrom and fullimage.

marshmellow · 2016-04-07 14:36:26

there is no HF raw capture mode, (except hf snoop, but that won't power your tag), mainly because most HF cards don't say anything until they are talked to by a reader (anti-collision procedures).

i'm not sure what the cause is of the issue you are having. do you have a reader model#? i suppose it might be possible the reader actually does a block read instead of a OTA read, in that case it might actually use a password.

try to snoop the reader/original card read.

lf snoop is a bit tricky because timing is everything. hold the pm3 antenna in front of your tag run lf snoop and hit the reader with the tag quickly. if you get the timing right you should be able to do `data samples` and data plot and see something...

tinfever · 2016-04-07 19:53:12

I'm nearly positive the reader is a HID multiCLASS SE® RP40. Interestingly, the cloned card did work right up until the point a new reader was installed. After that only the original card would create any kind of reaction.

I'll see if I can snoop between the reader and original.

tinfever · 2016-04-07 21:05:39

This is a 7z file containing 14 snoops data saves in a row. I wrote a little script to repetitively lf snoop, data samples, and data save so that timing was much easier. From my brief look, there is something happening on snoop8. I haven't had any time to do any real looking at them though. These snoops were received in numerical order and between all 14 there should be at least 2 times where the card was hit against the reader and recognized.

I'll see if I can get anything out of the data later but I couldn't get it to rawdemod to anything when I tried.

Snoop 7z: https://drive.google.com/open?id=0B4C5_10jlx3QRG9IRkVxVm13TU0

marshmellow · 2016-04-07 22:08:52

interesting... i can see the tag spewing it's data in-between large areas that look like the reader attempting to communicate but the reader communication didn't show up. it just wiped out the tag transmission in portions.

no where do i see what the reader said. nor does it look like the tag ever spit anything out other than it's full ID.
was your pm3 antenna between the reader and card? did the card actuate the reader (make it beep) during the snoop?

how strong is your pm3 lf antenna?

marshmellow · 2016-04-08 03:56:26

also you could try writing to your t55x7 clones the following:
block 1: a0000000
block 2: 8e407602
instead of the defaulted demoded data. (I have a theory that the 101 at the end might actually be supposed to be at the beginning as part of the preamble)

tinfever · 2016-04-08 04:47:24

Here is another 7z file of 28 consecutive snoops: https://drive.google.com/open?id=0B4C5_10jlx3QVXpPdWtqTUNNbzQ

When doing these the lf antenna is between the reader and the card. While doing these I am also generally starting the script, putting the antenna and card against the reader, waiting until the reader reacts, removing the antenna/card, and repeating as many times as possible.

Here is a hw tune of my proxmark with both antennas. If I understand this correctly, my LF antenna should be plenty strong enough:

# LF antenna: 46.89 V @   125.00 kHz
# LF antenna: 22.00 V @   134.00 kHz
# LF optimal: 46.89 V @   125.00 kHz
# HF antenna: 30.84 V @    13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

tinfever · 2016-04-08 05:52:22

That's actually a really interesting theory. I'll give that one you provided specifically a try but it poses an interesting question. How do we know what the start and end of the transmission are? and does it even matter since all the card does is say it end to end?

I actually loaded a t5577 with each of these and they all gave the same 'answer' to 'lf search'...47203B015

0000000000000000000000000000010001110010000000111011000000010101 = 000000047203B015
1000000000000000000000000000001000111001000000011101100000001010 = 800000023901D80A
0100000000000000000000000000000100011100100000001110110000000101 = 400000011C80EC05
1010000000000000000000000000000010001110010000000111011000000010 = A00000008E407602

There are even more possible loadings that would all demod to the same thing. Probably 64 different possibilities if I'm thinking about this right. How do we know which one is the right one and does it matter?

I'm thinking it might matter because if a certain number of leading or trailing 0's are part of the actual signal, the timing would matter. The 0's from the signal would be timed correctly but if we picked the wrong section out as the signal, the reader would be looking for more properly timed 0's. I don't know if the t5577 is broadcasting with the exact same timing between multiple transmissions but if it wasn't, how we choose the section could definitely effect whether or not a card works.

Disclaimer for others: Nothing I say should be taken for fact. I'm not trained and am just taking a mildly educated guess.

I'll give at least these four each their own card and try them out.

Hmm...would it be worth loading more than just block 1 and 2 with the correct 1's and 0's? what if I continute the pattern into as many blocks as possible? If the t5577 is then broadcasting the signal more than once with the correct timing, some part of it will have to be right. If I the tag broadcasts a signal and a half, somewhere in there the reader might see what it is looking for.

I might be going insane...

Last edited by tinfever (2016-04-08 05:54:10)

ntk · 2016-04-08 09:17:38

your antenna is very good. Is your PM from elechouse, or self-build? I believe apt-get had once similar experience, too good antenna caused problem in writing

iceman · 2016-04-08 09:49:28

Its what marshmellow mentioned, the preamble is unclear. The demod just guesses where it should start.
if you look at the indalademod sourcecode you might find out how it tries to conclude that it is a indala tag.

marshmellow · 2016-04-08 12:51:35

Since your traces appear to show the reader powering up the tag multiple times may indicate that it is attempting to get synced up with the output via timing. The 101 is about the only bits that would make sense to swap to the beginning as it is static.

tinfever · 2016-04-09 02:09:59

You guys are great. The T5577 using the data you provided made the reader beep. Now unfortunately that card is old so even the original won't open the door so I need to figure out how to apply what you saw to ecard and rcard.

I'll keep messing with it.

The other cards do seem to be demoding differently. This is ecard demoded and inverted:

0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000
0001101011001000
0000110110010010
0101010000000000
0000000000000000

I'm pretty much just guessing but am I correct to assume I should use the following section:

00000110
10110010
00000011
01100100
10010101

then shift the 101 to the preamble to get this:

10100000
11010110
01000000
01101100
10010010

which in hex is this:

A0D6406C92

So I should program the t5577 with this?

proxmark3> lf t55 dump
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 000000A0 | 00000000000000000000000010100000
  2 | D6406C92 | 11010110010000000110110010010010
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000

Actually, that doesn't demod to the same thing or get recognized as an indala. I'll try again without inverting.

Last edited by tinfever (2016-04-09 02:10:29)

tinfever · 2016-04-09 02:30:28

Actually...how about this?

rawdemod p1 for ecard

1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111
1110010100110111
1111001001101101
1010101111111111
1111111111111111

Section is this

1011111111111111
1111111111111110
0101001101111111
0010011011011010

Converts from binary to hex to this:

BFFFFFFE
537F26DA

and gets programmed to this:

proxmark3> lf t55 dump
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00001040 | 00000000000000000001000001000000
  1 | BFFFFFFE | 10111111111111111111111111111110
  2 | 537F26DA | 01010011011111110010011011011010
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000
Reading Page 1:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | E0150A50 | 11100000000101010000101001010000
  2 | BC78985B | 10111100011110001001100001011011
  3 | 00000000 | 00000000000000000000000000000000

Its looking good when I'm 'lf search'ing and looking at it. It's doing the exact same thing as the original card did. lf search will sometimes pull different demod data but it all indalademods down to the right thing. Also the rawdemod data looks perfect.

I'll go give it a shot.

By the way, could you provide some insight into how you knew that 101 was part of the preamble? and how do you know which 101 is the correct one? I only guessed this one because it has a similar pattern to the other one of 101 and then a bunch of the same thing until the next block.

marshmellow · 2016-04-09 05:10:47

Because this card appears inverted, you need to shift one more bit from the end to the beginning. (I expect). 101 inverted is 010...

I'd then try it and try the invert of it.

tinfever · 2016-04-12 19:42:19

I am very pleased to report that all four cards I tried worked. These all worked, the names may not be completely accurate because it might actually be a 010 inverted start but you get the idea:

ecard 101 start
ecard 101 start inverted
rcard 101 start
rcard 101 start inverted

I will post the final T5577 block data for each of these so that if anyone in the future runs into this, they'll be able to recreate what we did.

I'm still unclear on how you knew that it had to start with 101 though. Can you elaborate?

Also, marshmellow, would you take a PayPal or Bitcoin tip/donation? I really appreciate your help with this.

I'll also donate to the site/proxmark3 project/etc if there is a way.

Thank again!

tinfever · 2016-04-15 02:25:49

Here are the final loads that all worked:

rcard 101 start

Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | BFFFFFFE | 10111111111111111111111111111110
  2 | 53FF23FA | 01010011111111110010001111111010
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000

rcard 101 start inverted

Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00000000 | 00000000000000000000000000000000
  1 | 40000001 | 01000000000000000000000000000001
  2 | AC00DC05 | 10101100000000001101110000000101
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000

ecard 101 start

Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | BFFFFFFE | 10111111111111111111111111111110
  2 | 537F26DA | 01010011011111110010011011011010
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000

ecard 101 start inverted

Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 40000001 | 01000000000000000000000000000001
  2 | AC80D925 | 10101100100000001101100100100101
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000

and now that I'm looking at them, I'm noticing some commonalities between ecard and rcard. I wonder if there is a pattern and more can be generated... Although I'm pretty sure the cards are authorized by having their number entered into the system as authorized for a certain thing. A card with the same pattern might not be authorized for the same things as mine.

Once again, I'd still like to donate to the forums and marshmellow if possible. I'm very grateful.

Proxmark3 community

Announcement

#1 2016-04-06 06:16:41

Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#2 2016-04-06 06:38:16

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#3 2016-04-06 11:21:59

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#4 2016-04-06 13:10:36

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#5 2016-04-06 17:17:52

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#6 2016-04-06 17:22:03

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#7 2016-04-06 17:24:56

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#8 2016-04-06 17:57:55

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#9 2016-04-07 00:44:05

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#10 2016-04-07 07:32:22

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#11 2016-04-07 07:46:37

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#12 2016-04-07 14:36:26

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#13 2016-04-07 19:53:12

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#14 2016-04-07 21:05:39

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#15 2016-04-07 22:08:52

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#16 2016-04-08 03:56:26

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#17 2016-04-08 04:47:24

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#18 2016-04-08 05:52:22

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#19 2016-04-08 09:17:38

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#20 2016-04-08 09:49:28

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#21 2016-04-08 12:51:35

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#22 2016-04-09 02:09:59

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#23 2016-04-09 02:30:28

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#24 2016-04-09 05:10:47

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#25 2016-04-12 19:42:19

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

#26 2016-04-15 02:25:49

Re: Trouble duplicating Motorola ASP/Indala - Same data doesn't work

Board footer