ZipCar Cards?

Omikron · 2015-01-06 21:53:31

Has anyone been able to figure out what type of chip ZipCar uses for its cards?

I've tried to figure out if it's LF or HF, and I can't even get that far. Both LF and HF voltages drop when the card is near, but not by the normal amounts that I'm used to seeing.

marshmellow · 2015-01-16 18:31:14

sorry, never heard of them...

Omikron · 2015-04-06 01:34:21

marshmellow wrote:

sorry, never heard of them...

They're an hourly car rental services operating in about 25 cities in the US and a few abroad: http://www.zipcar.com/

I've found no public data about what technology their cards use, and I've so far been unable to identify it conclusively myself. It seems to be a hybrid card of some kind, but not any known one that I've encounter previously.

marshmellow · 2015-04-06 01:48:24

Any idea what reader model reads them?

Omikron · 2015-04-07 04:10:11

marshmellow wrote:

Any idea what reader model reads them?

No, because I haven't taken one apart yet. The readers are OEM'd and do not usually have any markings other than ZipCar's, HOWEVER:

It looks like all the hard work people have put in recently in fixing broken commands has paid off as, I am now able to identify the tag using the PM3 as an em410x tag. However, I arrived at this conclusion in a somewhat odd way.

It started when I noticed that performing "hw tune" while having a T5577 card on the antennas caused a voltage drop in BOTH HF and LF antennas, which was unexpected since the card is supposed to be LF only. I remembered that I saw this same unexpected drop when taking a look at the ZipCar membership cards, and thought perhaps they are using the same chips!

So I grabbed my ZipCard and here's what my initial results were. Keep in mind that all data in this post is modified so as to conceal the original card data. At the moment I did not have extra ZipCards to play with.

proxmark3> lf read
#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: ff fb a3 58 1a 00 19 9d ...
proxmark3> data samples
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data rawdemod am

Using Clock: 32 - Invert: 0 - Bits Found: 512
ASK/Manchester decoded bitstream:
07710000111100110
01100101007710011
177177770011111111
11117777001000001
111111111111177770
0010000000000010
11101111177000000
0100000001111101
1111101000000000
1011101001110111
07777171111777711001
1011101011111110
0010111110111111
777700000000010111
110111111777700000
0000000001111101
11111111077000000
00000101110117700
0000000000011111
1000101010011101
1001111111000101
11110000700000000
11111010111007700
0000000001111101
11111111110177001
0000010111111111
11101717000100000
11111111111101770
01001111177001111
1100111111100110
01770000000011101
77000000000011111

proxmark3> lf t55xx config
Modulation : ASK
Bit Rate   : 0 - RF/8
Inverted   : No
Offset     : 0
Block0     : 0x00000000

proxmark3> lf t55xx detect
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'
proxmark3> lf t55xx
help             This help
config           Set/Get T55XX configuration (modulation, inverted, offset, rate)
detect           [1] Try detecting the tag modulation from reading the configuration block.
read             <block> [password] -- Read T55xx block data (page 0) [optional password]
write            <block> <data> [password] -- Write T55xx block data (page 0) [optional password]
trace            [1] Show T55xx traceability data (page 1/ blk 0-1)
info             [1] Show T55xx configuration data (page 0/ blk 0)
dump             [password] Dump T55xx card block 0-7. [optional password]
special          Show block changes with 64 different offsets
proxmark3> lf t55xx dump
0xFE738000  11111110011100111000111100000000 [0]
0x38000039  00111000111010010100000000111001 [3]
0x00005040  00000010101000000100000001000000 [4]
0x00000000  00000000000000000000000000000000 [5]
0x00000000  00000000000000000000000000000000 [7]

Following that I attempted a couple of read block commands with FFFFFFFF as a password (no particular reason, just wanted to see how it responded) and found that it stopped responding completely to all t55xx commands. However, the NEXT time, got data samples, I got completely different results:

proxmark3> lf read
#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: a9 5b 17 00 00 00 00 00 ...
proxmark3> data samples
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data rawdemod am

Using Clock: 64 - Invert: 0 - Bits Found: 512
ASK/Manchester decoded bitstream:
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
1111110111111101
0000110000001100
0000001100000011
0111101001111010
EM410x pattern found:

EM TAG ID      : DEADBEEFDE
Unique TAG ID  : 8675308675

Possible de-scramble patterns
HoneyWell IdentKey {
DEZ 8          : 18373562
DEZ 10         : 8623452987
DEZ 5.5        : 54654.12312
DEZ 3.5A       : 334.54654
DEZ 3.5B       : 221.54654
DEZ 3.5C       : 554.54654
DEZ 14/IK2     : 45234513452452
DEZ 15/IK3     : 346345634563456
DEZ 20/ZK      : 34523463457568245652
}
Other          : 54654_334_12341324
Pattern Paxton : -1495244546
Pattern 1      : 0xABABAB - 12345678
Pattern Sebury : 1234 12 1234567  (hex: FFFF FF FFFFFF)

Following that I switched to using a few em410x commands and everything ran smoothly.

Does anyone have any thoughts on why initially the card appeared to be responding to T55xx commands and then stopped, but started working correctly as a em410x card? Any chance the last reader used left the card in an unexpected state somehow?

marshmellow · 2015-04-07 04:20:10

Looks like you got garbage out of the t55xx command. And then finally got a good em410x read with no errors. Might have a weak antenna or it is a weak tag, or a strong antenna and no space between card and antenna.

Last edited by marshmellow (2015-04-07 04:20:45)

Omikron · 2015-04-07 05:18:57

marshmellow wrote:

Looks like you got garbage out of the t55xx command. And then finally got a good em410x read with no errors. Might have a weak antenna or it is a weak tag, or a strong antenna and no space between card and antenna.

Yes, I suppose that's possible, but all of the behaviors I described were observed numerous times, even after removing and replacing the tag on the antenna. The behavior of the ZipCard didn't change until I issued a read command with a bunk password, at which point it changed immediately, even without touching or moving the card. Perhaps the PM3's memory was in a garbage state.

marshmellow · 2015-04-07 05:32:27

the t55xx commands (especially with the any of the pre-compiled versions of code out atm) would output anything it could demod based on the configuration that was set. it did not autodetect a t55xx tag so when you attempted to read it read based on 0 settings or clock of rf/8 and ASK modulation, which your card was ASK just a much higher clock, rf/64, so the output is garbage. depending on the next t55xx commands sent it may have changed the t55xx read configuration resulting in what appeared to be no more response, but was just more correctly, not the response it was looking for.

if you have a strong antenna, or a very strong tag, the demods for ask/man had trouble auto detecting the clock in previous versions of code, which ultimately was the problem with your previous reads. there are updates on github and in progress that fix this.

if the tag you have is actually a t55x7 then there is a slight chance a poor antenna could transmit a read command that the tag may have heard a write command and could have modified the tags config block... but that is a stretch. (but in this case your readings now would be bogus and the tag would no longer be functional on the original reader.)

Last edited by marshmellow (2015-04-07 05:38:29)

iceman · 2015-04-07 07:28:59

Since the remake of "LF T55XX" commands, the reading a t55xx tag process is a bit different.

you must always start it off with running:

lf t55xx detect

This is to try to automatically detect in which way the t55xx tag is currently configured as.
If you dont run this command, the default configuration of "ASK clock RF/8 , non-inverted, offset 0" is used.

if the detect command fails, you can manually configure it with the "lf t55xx configure" command.
however, since the new lf commands is in place, the detection rutine is quite good at its job.
When it fails, its because of what Marshmellow mentioned in earlier posts regarding antenna signals.

The following process is to prefer:

--Show the window for the data.  
DATA PLOT

-- try read an known / unknow LF tag.
LF SEARCH 
LF SEARCH U

--reading T55XX tag

LF T55XX DETECT
LF T55XX INFO

-- dumping T55XX data
LF T55XX DUMP

I added the data plot command, since its very good at showing the signal and once you become better at reading lf tags you start to see when it was a bad read. There was a thread somewhere on the forum with many pictures of how the correct signal looks like for different modulations. very good to know actually.

Last edited by iceman (2015-04-07 07:43:22)

marshmellow · 2015-04-07 07:35:04

also, just to speed up your reading/testing of lf tags, try the

lf search

command

marshmellow · 2015-04-07 07:36:31

lol iceman... beat me to it...

iceman · 2015-04-07 07:43:57

You are tired from all changes you just commited

aydiosmio · 2015-09-11 08:45:33

I have successfully copied a Zipcard with a T55xx. Zipcar uses the AWID SR-2400 reader and GR-AWID cards.

Thanks to the recent awid firmware commands, I was able to kludge my way to a clone.

proxmark3> lf search

AWID Found - BitLength: 40 -unknown BitLength- (44837) - Wiegand: 020029cc1, Raw: 016711114111cde9a2111111

Valid AWID ID Found!

That's weird. AWID is usually 26 bits. Proxmark seems to be only guessing at a card number and it appears Zipcar orders their cards with a non-standard bit format. Skip a few steps and I tried to clone with the following values.

proxmark3> lf awid clone 0 44837
Preparing to clone AWID26 to T55x7 with FC: 0, CN: 44837 (Raw: 011de1141da0211111111111)
Block 0: 0x00107060
Block 1: 0x011de114
Block 2: 0x1da02111
Block 3: 0x11111111

That's clearly almost but no cigar. But the clone function is showing some magic pixie dust in block 0. Let's try manually programming the T55xx.

proxmark3> lf t55xx write 0 00107060
Writing to block: 0  data  : 0x00107060
proxmark3> lf t55xx write 1 01671111
Writing to block: 1  data  : 0x01671111
proxmark3> lf t55xx write 2 4111cde9
Writing to block: 2  data  : 0x4111CDE9
proxmark3> lf t55xx write 3 a2111111
Writing to block: 3  data  : 0xA2111111
proxmark3> lf search

AWID Found - BitLength: 40 -unknown BitLength- (44837) - Wiegand: 020029cc1, Raw: 016711114111cde9a2111111

Valid AWID ID Found!

It works! Verified with Zipcar's reader.

CAUTION: Zipcards are not write-locked. It's possible to render the cards unusable with the Proxmark's t55xx commands.

meter · 2015-09-11 21:00:24

Thank you for sharing your experience, I don't know zipcards but maybe a day might be useful.

Last edited by meter (2015-09-12 09:18:23)

Upgrade · 2015-09-13 02:52:30

@aydiosmio Could you please block or edit your last post for duplicating the Zipcar cards?

I don't think Zipcar would appreciate users to be able to duplicate the cards. Just don't want any legal ramifications coming back to the site.

Thanks in advance.

marshmellow · 2015-09-13 14:21:52

@upgrade, I believe that is the moderators job. And I don't think zipcard is more of a legal concern than iclass, Mifare, hid prox or all the others on this site.

marshmellow · 2015-09-15 21:06:09

btw @aydiosmio, your tag doesn't follow AWID standard protocol. the parities are wrong, as is the basic format outline. either it is a "new" awid style of formatting or a custom FSK format for whatever cards you have that was mis-interpreted as awid. the OP was confirmed to have EM410X style cards for what he considered the ZipCar Cards which definitely is not similar to your card.

aydiosmio · 2015-09-15 21:41:23

I forgot to mention, those card values are altered for privacy, as they're from my actual Zipcard. Apologies, I don't have any inactive card values to share.

The proxmark identifies the card properly, but I'll go back and validate the parity and bit format against AWID.

aydiosmio · 2015-09-15 21:47:01

Upgrade wrote:

@aydiosmio Could you please block or edit your last post for duplicating the Zipcar cards?
I don't think Zipcar would appreciate users to be able to duplicate the cards. Just don't want any legal ramifications coming back to the site.
Thanks in advance.

If you insist, I will. But the cards hold no inherent value and can't be used concurrently. You can't use duplication to defraud the service. I made a copy of mine because getting them replaced if lost is a pain in the butt.

You'll also have to instruct me on how to edit a post, as I don't see any option in the forum to do so.

aydiosmio · 2015-09-15 22:00:45

marshmellow wrote:

The OP was confirmed to have EM410X style cards for what he considered the ZipCar Cards which definitely is not similar to your card.

All US cities I've been to used the same AWID SR-2400 readers for their Zipcars, so of course I presumed the cards which the proxmark identified as AWID were AWID -- with some variation on the standard format, which isn't uncommon.

I re-read Omikron's comments on em410 and I'll verify that the em410 commands work on my card. I had the card soft-brick with the t55xx commands, and it seems what happened to Omikron also happened to me.

marshmellow · 2015-09-15 22:11:09

aydiosmio wrote:

I forgot to mention, those card values are altered for privacy, as they're from my actual Zipcard. Apologies, I don't have any inactive card values to share.
The proxmark identifies the card properly, but I'll go back and validate the parity and bit format against AWID.

This would explain why I couldn't figure out why the pm3 said that raw value was an awid... Thx.

Proxmark3 community

Announcement

#1 2015-01-06 21:53:31

ZipCar Cards?

#2 2015-01-16 18:31:14

Re: ZipCar Cards?

#3 2015-04-06 01:34:21

Re: ZipCar Cards?

#4 2015-04-06 01:48:24

Re: ZipCar Cards?

#5 2015-04-07 04:10:11

Re: ZipCar Cards?

#6 2015-04-07 04:20:10

Re: ZipCar Cards?

#7 2015-04-07 05:18:57

Re: ZipCar Cards?

#8 2015-04-07 05:32:27

Re: ZipCar Cards?

#9 2015-04-07 07:28:59

Re: ZipCar Cards?

#10 2015-04-07 07:35:04

Re: ZipCar Cards?

#11 2015-04-07 07:36:31

Re: ZipCar Cards?

#12 2015-04-07 07:43:57

Re: ZipCar Cards?

#13 2015-09-11 08:45:33

Re: ZipCar Cards?

#14 2015-09-11 21:00:24

Re: ZipCar Cards?

#15 2015-09-13 02:52:30

Re: ZipCar Cards?

#16 2015-09-13 14:21:52

Re: ZipCar Cards?

#17 2015-09-15 21:06:09

Re: ZipCar Cards?

#18 2015-09-15 21:41:23

Re: ZipCar Cards?

#19 2015-09-15 21:47:01

Re: ZipCar Cards?

#20 2015-09-15 22:00:45

Re: ZipCar Cards?

#21 2015-09-15 22:11:09

Re: ZipCar Cards?

Board footer