Help cloning my flat keys

John · 2009-09-03 14:48:07

Hehe, ah, i think it's too late for that

To be honest, maybe i should buy the more expensive one... you've been really helpful Adam, and you even sent me a cloned RFID card!

Tell you what - let's raise the stakes...
If your cloned card works Adam, i'll get the LAHF one. If it doesn't, i'll have to go with the LF one.

Deal? haha

As for the girlfriend issue, hehe... well... i can't lie to her. She sees all. Seriously. That giant eye from Lord Of The Rings has got nothing on her.

henryk · 2009-09-03 15:33:31

John, I'd categorize the LF reader as a waste of money. The LF market is way too fractured so it will only be useful for a very tiny percentage of the tags out there. And you're not very likely to encounter that many LF tags on a day to day basis, opposed to HF where you're likely have one in your metro card, student ID and credit card each.

I can almost guarantee that the proxmark3 is a complete replacement for any LF reader hardware (though maybe not for the shiny software that may or may not come with a 'real' reader).

John · 2009-09-03 16:03:37

Yeah, you're probibly right Henry...
My next challange after LF access tags will be my student card. I havn't looked at it yet, but i'm fairly confident it'll be a Mifare.

Your totally right though - LF tags seem to be 'simple', in that a proxmark with askdemod/fskdemod/mandemod is more than enough to decode anything on them.
I'm still not so sure if i can use losim in quite the way i want (ie, specifying the data and modulation to use), but it still seems that without Adam's code and supported hardware, i won't be able to write a Q5 to clone my tag.

This is a question i probibly should have asked a long time ago Henryk - what hardware would you recommend?

d18c7db · 2009-09-03 23:18:45

henryk wrote:

I do think we need a more structured, framework-y approach to these things though. The current code is an exquisite mess of several highly specific functions and a few halfheartedly generalized functions (e.g. why is that parameter "BOOL at134khz", why is it not "int divisor"?).

The at134Khz is legacy, the PM3 only supported two LF values at 125 and 134 Khz. After I added the divisor functionality to the FPGA for (semi) arbitrary LF generation, I thought I took out all references to 125 and 134 khz and replaced them with divisor references. Obviously missed one so feel free to correct them as you come across them.

I agree about the code, it's a mish mash of contributions from various people, most of them (including me) not being actual programmers so there is no real structure or framework to it. Any help you could provide in that respect would be most appreciated.

adam@algroup.co.uk · 2009-09-03 23:40:50

John, for HF experimentation I would recommend a PN532 based reader like the 'touchatag', which allows you to do APDU based stuff as well as low level stuff using libnfc... Also, it's super cheap!

For LF, the ACG is probably the best commercial writer around and supports the most formats I've seen, so is likely to be useful for the longest. I don't agree that LF is going to disappear soon - look at prox cards in general - they've been around for 10's of years and although new systems are replacing them with HF formats, there will be loads of older installations still using them for years to come...

[edit - oops! I miss-read the point here - it wasn't lifespan that was the issue, but the fractured market - and I guess the comment below covers that]

In the fullness of time we'll get the PM3 writing to Q5 tags, but if you want to program them *right now*, the ACG is probably your best bet.

Last edited by adam@algroup.co.uk (2009-09-03 23:49:55)

XEROEFFECT · 2009-09-04 02:52:03

adam@algroup.co.uk wrote:

I don't agree that LF is going to disappear soon - look at prox cards in general - they've been around for 10's of years and although new systems are replacing them with HF formats, there will be loads of older installations still using them for years to come...

I don't believe LF will ever be replaced. They are too cheap to be phased out. Installers of such devices will always be greedy and go with whats in their best interest. They don't give a shit cause Money makes the world go round.

Last edited by XEROEFFECT (2009-09-04 02:53:44)

adam@algroup.co.uk · 2009-09-04 10:23:43

Looking at the decoding, we can simply treat the data as 8 bit HEX, and take 16 sequential '0' bits as a start sentinel (or in the case of the 999 tag, 16 sequential '1' and then invert). You then get 32 bits of ID followed by some kind of checksum or parity and F2 as a stop sentinel - haven't had time to look at the checksum properly yet...

04008064

0 0 0 0 0 0 0 0 00
0 0 0 0 0 0 0 0 00

0 0 0 0 0 1 0 0 04
0 0 0 0 0 0 0 0 00
1 0 0 0 0 0 0 0 80
0 1 1 0 0 1 0 0 64

1 0 1 1 1 0 1 0 BA

1 1 1 1 0 0 1 0 F2

05015749

0 0 0 0 0 0 0 0 00
0 0 0 0 0 0 0 0 00

0 0 0 0 0 1 0 1 05
0 0 0 0 0 0 0 1 01
0 1 0 1 0 1 1 1 57
0 1 0 0 1 0 0 1 49

0 1 0 0 0 0 0 0 40

1 1 1 1 0 0 1 0 F2

99531670

0 0 0 0 0 0 0 0 00
0 0 0 0 0 0 0 0 00

1 0 0 1 1 0 0 1 99
0 1 0 1 0 0 1 1 53
0 0 0 1 0 1 1 0 16
0 1 1 1 0 0 0 0 70

1 1 1 1 0 1 1 0 F6

1 1 1 1 0 0 1 0 F2

(edited to correct error as per next post)

Last edited by adam@algroup.co.uk (2009-09-04 13:15:33)

XEROEFFECT · 2009-09-04 11:25:38

adam@algroup.co.uk wrote:

05015749
0 0 0 0 0 0 0 0 00
0 0 0 0 0 0 0 0 00
0 0 0 0 0 1 0 1 05
0 0 0 0 0 0 0 1 01
0 1 0 1 0 1 1 1 57
0 1 0 0 1 0 0 1 49
0 1 0 0 0 0 0 0 40
1 1 1 1 0 0 1 0 BA

Theres an error on the last line. Hex value Should be F2. Now theres definitely a pattern emerging on the stop parity.

Last edited by XEROEFFECT (2009-09-04 11:33:04)

adam@algroup.co.uk · 2009-09-04 13:10:42

Well spotted! So F2 is probably a trailer...

XEROEFFECT · 2009-09-04 15:06:11

I think that the second last hex value belongs to the UID. It's too random to be anything else. Last time I programmed a EM4XX card I remember I had to insert 10 hex values otherwise it would give me a write error. What do you think?

henryk · 2009-09-04 20:35:27

adam@algroup.co.uk wrote:

You then get 32 bits of ID followed by some kind of checksum or parity and F2 as a stop sentinel - haven't had time to look at the checksum properly yet...

I've tried simply going over all CRC-8 polynoms (with code from http://whats.all.this.brouhaha.com/2004 … al-finder/) and have found a calculation that will, for all three tags, give the correct result. So if John had some more tags one could verify that...

$ cat transit.c
// Modified CRC routine from http://whats.all.this.brouhaha.com/2004/07/08/brute-force-crc-polynomial-finder/
// Original copyright 2004 Eric Smith <eric@brouhaha.com>
// Modified by Henryk Plötz <henryk@ploetzli.ch> 2009-09-04

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

uint32_t crc_block(uint32_t * data, int width, int count,
                   int order, uint32_t poly, uint32_t init, uint32_t post)
{
    uint32_t crc;
    uint32_t d;
    int b;
    int i;

    uint32_t crc_mask = (1 << order) - 1;

    crc = init;

    while (count--) {
        d = *(data++);
        for (i = 0; i < width; i++) {
            b = crc & 1;
            crc >>= 1;
            if (b ^ (d & 1))
                crc ^= poly;
            d >>= 1;
        }
    }

    crc ^= post;
    crc &= crc_mask;

    return (crc);
}


int main(int argc, char *argv[])
{
    int i, j;
    uint32_t crc, data[4];

    if (argc != 5) {
        fprintf(stderr, "usage:\n");
        fprintf(stderr, "%s XX XX XX XX:\n", argv[0]);
    }

    for (i = 0; i < sizeof(data) / sizeof(data[0]); i++) {
        data[i] = strtol(argv[1 + i], NULL, 16);
    }

    printf("%02X %02X %02X %02X %02X\n", data[0], data[1], data[2],
           data[3], crc_block(data, 8, sizeof(data) / sizeof(data[0]), 8,
                              0x80, 0x5A, 0x00));

    exit(0);
}

$ make transit
cc     transit.c   -o transit
$ ./transit 04 00 80 64
04 00 80 64 BA
$ ./transit 05 01 57 49
05 01 57 49 40
$ ./transit 99 53 16 70
99 53 16 70 F6

Both magic values (initial value 0x5A, e.g. alternating bits set, and 'polynom' 0x80, e.g. just the highest bit set) look suspicious so this is probably close to the real function. Since it's only ever setting the top bit in the CRC register and only ever looking at the bottom bit, it's probably implemented as a linear shift register with an initial value.

John · 2009-09-04 20:53:11

Mate! Good job!!

Am i right in saying that you used a program which bruteforced the function variables untill the input made the output?

In otherwords, that fact that all three worked doesn't mean the function is right for all fobs, - but rather it's designed to be right for these three fobs. (and hopefully all others)

I'll pop over to a friends house now and give you the bitstream... but still. If this works... i'm seriously seriously impressed by the method. Really cleaver stuff.

It's 9:00pm, so i'll pop up there now :3

henryk · 2009-09-04 22:13:30

John wrote:

Am i right in saying that you used a program which bruteforced the function variables untill the input made the output?
In otherwords, that fact that all three worked doesn't mean the function is right for all fobs, - but rather it's designed to be right for these three fobs. (and hopefully all others)

Exactly, iterating stupidly over all 256 polynoms (well, not all of these make sense, but whatever) and 256 initial values . I did have two other related matches, but they didn't have this peculiar structure.

Actually, now that I'm thinking about the structure and wondering that it would be odd to have a LFSR which doesn't work with the same bit order as the transmission on the air, I might be wrong. The function is much simpler:

0x04 xor 0x00 xor 0x80 xor 0x64 xor 0x5A = 0xBA
0x05 xor 0x01 xor 0x57 xor 0x49 xor 0x5A = 0x40
0x99 xor 0x53 xor 0x16 xor 0x70 xor 0x5A = 0xF6

This also has the propery of being independent of the bit order, if you change the 0x5A constant appropriately, so I'm fairly sure that is the method that's really being used.

John · 2009-09-05 00:50:07

Unfortunatly, yet somewhat predictably, my friend who i was going to ask for a fob off don't have one. Hers broke a while ago, and she doesn't have the cash to buy a new one (at £80).

There are plenty of other people who i can ask for there fob, but none of which i'm comfortable enough with to pop over at 12:48 at night

I'll get a few tomorrow. Promise :3

adam@algroup.co.uk · 2009-09-05 07:36:44

henryk wrote:

Actually, now that I'm thinking about the structure and wondering that it would be odd to have a LFSR which doesn't work with the same bit order as the transmission on the air, I might be wrong. The function is much simpler:
0x04 xor 0x00 xor 0x80 xor 0x64 xor 0x5A = 0xBA
0x05 xor 0x01 xor 0x57 xor 0x49 xor 0x5A = 0x40
0x99 xor 0x53 xor 0x16 xor 0x70 xor 0x5A = 0xF6
This also has the propery of being independent of the bit order, if you change the 0x5A constant appropriately, so I'm fairly sure that is the method that's really being used.

A simple rolling XOR would be my first choice (in fact that's the only method I had tried so far on these, and was about to start on open source polynomial examples, but you saved me the trouble...

However, a plain XOR failed, so I'm curious how you arrived at adding the final 0x5A to the end?

henryk · 2009-09-05 07:48:19

adam@algroup.co.uk wrote:

However, a plain XOR failed, so I'm curious how you arrived at adding the final 0x5A to the end?

As I said, I assumed a CRC and tried all polynoms and all initial values. This gave three polynom/init pairs that worked for all three tags. One of them, polynom 0x80 and initial value 0x5a seemed just 'right' (the other polynom was, IIRC 0x76 with two different initial values). And a CRC with polynom 0x80 simply degenerates into a linear feedback shift register with some initial value and then xoring in the data bit stream. This didn't feel right since the data would need to be fed in in an order different from transmission order. And then it occurred to me that an LFSR which only looks at the lowest bit essentially degenerates to a simple 8-bitwise xor, all the while keeping the brute forced initial value.

John: If your friend still has her tag number and didn't have it revoked in the system, you could try and clone it nonetheless. Now that we have framing, transmission format and checksumming, it should be pretty straightforward to synthesize the modulation data for any given tag number. You could then use the proxmark with the losim command to emulate it (or try my soundcard+simple load modulator approach).

adam@algroup.co.uk · 2009-09-05 08:09:47

Sterling work!

Well, as it's a bit simpler for the rolling XOR I've knocked up a quick python script that does it for you... You just specify the bytes you know and it works out the final required byte value:

$ ./xorcheck.py 05 01 57 49 40

Target matched with Byte value: 5A

$ ./xorcheck.py 04 00 80 64 ba

Target matched with Byte value: 5A

$ ./xorcheck.py 99 53 16 70 F6

Target matched with Byte value: 5A

I'll add it to the tools section

adam@algroup.co.uk · 2009-09-05 08:23:24

BTW, I wasn't clear with my original question - what I meant was why add a final value at all? What is the purpose of adding the final byte to the XOR chain?

XEROEFFECT · 2009-09-05 08:48:52

Guys, really sorry to hold you up but could you explain what XOR is. I've googled around, found explanations for it but cant seem to work out how Henryk arrived to the following answers:

Henryk wrote:

0x04 xor 0x00 xor 0x80 xor 0x64 xor 0x5A = 0xBA
0x05 xor 0x01 xor 0x57 xor 0x49 xor 0x5A = 0x40
0x99 xor 0x53 xor 0x16 xor 0x70 xor 0x5A = 0xF6

adam@algroup.co.uk · 2009-09-05 09:34:55

http://en.wikipedia.org/wiki/Exclusive_or

XEROEFFECT · 2009-09-05 09:59:22

Thanks Adam. I just realised Henryk must have used a calculator. I thought It was all done manually and that the answer was meant to be obvious. Thats why I got thrown off. I was sitting here like an idiot trying to merge 1's and 0's. Cool, Windows calculator helped me solve that one.

Last edited by XEROEFFECT (2009-09-05 10:01:04)

henryk · 2009-09-05 11:48:42

adam@algroup.co.uk wrote:

Well, as it's a bit simpler for the rolling XOR I've knocked up a quick python script that does it for you... You just specify the bytes you know and it works out the final required byte value:
$ ./xorcheck.py 05 01 57 49 40
Target matched with Byte value: 5A

No offense, but ... WTF? You do realise that your script will always give out an answer (so "matched" is a bad choice of wording) and that you can simply directly calculate it, instead of looping? XOR is excessively commutative, so »XOR(a,b,c,d,X) == e, find X« simply means »X := XOR(a,b,c,d,e)«. Also this is not a CRC but an LRC, so your comments and variable names are somewhat off.

adam@algroup.co.uk wrote:

what I meant was why add a final value at all? What is the purpose of adding the final byte to the XOR chain?

Maybe it's some kind of obscurity. Or meant as protection against drift (if you rotate all transmitted bytes you'd still end up with a matching LRC, were it not for the initial value). But mostly obscurity, I think.

adam@algroup.co.uk · 2009-09-05 12:06:50

henryk wrote:

adam@algroup.co.uk wrote:
Well, as it's a bit simpler for the rolling XOR I've knocked up a quick python script that does it for you... You just specify the bytes you know and it works out the final required byte value:
$ ./xorcheck.py 05 01 57 49 40
Target matched with Byte value: 5A
No offense, but ... WTF? You do realise that your script will always give out an answer (so "matched" is a bad choice of wording) and that you can simply directly calculate it, instead of looping? XOR is excessively commutative, so »XOR(a,b,c,d,X) == e, find X« simply means »X := XOR(a,b,c,d,e)«. Also this is not a CRC but an LRC, so your comments and variable names are somewhat off.

Errr... No, we're looking for a value that matches the specified LRC byte... (I'll fix the CRC/LRC mis-wording), so it needs to loop through all 256 possible values until it gets a match. I've updated the output to make it slightly clearer:

$ ./xorcheck.py 99 53 16 70 F6

Target (F6) matched with final byte value: 5A

John · 2009-09-05 12:21:59

Heh, you guys are both way to smart =P

Adam - Could some ID's be longer than four hex? Perhaps your code work for others in this sort of format:

xorcheck.py 04:00:80:64 BA
> 5A

xorcheck.py 05:01:57:49 40
> 5A

Yeah? So then someone with a longer UID perhaps could just do:

xorcheck.py 04:30:64:26:74:38:99:24 B5
> 32

Just seems like a good idea... i don't know how hard it would be to actually do it though -_-;

adam@algroup.co.uk · 2009-09-05 12:59:18

The code already does that - the last argument is the LRC, so it doesn't matter how many you specify in front...

Usage: ./xorcheck.py <ID Byte1> <ID Byte2> ... <LRC>

Last edited by adam@algroup.co.uk (2009-09-05 13:00:11)

adam@algroup.co.uk · 2009-09-05 14:08:33

henryk wrote:

No offense, but ... WTF? You do realise that your script will always give out an answer (so "matched" is a bad choice of wording) and that you can simply directly calculate it, instead of looping? XOR is excessively commutative, so »XOR(a,b,c,d,X) == e, find X« simply means »X := XOR(a,b,c,d,e)«. Also this is not a CRC but an LRC, so your comments and variable names are somewhat off.

OK, so I've now understood what you meant (it's a long time since I was at school, so terms like 'excessively commutative' take a while to sink in.. ...

Your mathematical approach is clearly more sensible, so I've tweaked it accordingly...

$ ./xorcheck.py 05 01 57 49 40

Target (40) requires final LRC XOR byte value: 5A

XEROEFFECT · 2009-09-05 16:46:20

Adam,
When you programmed the bit pattern to the Q5 tag, did it include the LRC byte as well? If it did, why did you guys have to dwell with the bits so hard. Does the XOR byte value tells us anything useful?

Last edited by XEROEFFECT (2009-09-05 16:46:51)

adam@algroup.co.uk · 2009-09-05 18:51:38

The Q5 I programmed was a straight clone so I didn't need to know what the data represented. If we want to be able to create arbitrary tags we need to know how to construct all the data bits from the UID.

John · 2009-09-05 22:37:52

Sorry for the silence today guys. I've had a pretty bad day.
A friend of mine died in a car crash yesterday near gatwick, then my girlfriend told me we were going to her cousins wedding this evening (I had no idea), and the fob that Adam sent me didn't seem to work. (I only had 3 seconds to test it, so it might just have been bad luck. )

The Defcon lanyard and sticker cheered me up though mate . Really liked that.

Anyway, I'm currently sitting in a field on a small wet bale of hay... Havnt got a clue who any of these people at this wedding reception are.. My back hurts...
Worst. Day. Ever.

Anyway, I've had a few drinks so I'll probibly regret sending this message when I next see it... But bah. If you can't talk to an anonomous forum of your peers then who can you talk to.

I'll get another drink now...That'll cheer me up :]

oh yeah, and I can't get a fob to test the checksum formula out until Monday. Bugger

XEROEFFECT · 2009-09-06 02:28:43

Dear John,

Please accept my sincere condolences on the passing of your dear friend. I am so sorry about your loss.
Although I never met your friend, I know what they mean to us. Sorry.

John · 2009-09-06 11:00:52

That's very kind of you XERO, thank you
She was a good woman who was always happy. In her 34 years I'm sure she spent more time laughing than I ever will. It's a tradagy that she's gone, especially since she had an 12 y/o kid with no father... But I'll take a leaf out of her book and stay positive. Shed want that.

Anywhoo, this has nothing to do with RFID, so I'm really sorry I brought it up. I was just having a really bad day yesterday I suppose
I should learn not to drink and type. It was never a problem until I got an iPhone

John · 2009-09-06 16:52:13

Okay, small update:

Adam's card currently doesn't work

I read it with the proxmark, and it does have exactly the same mandemod output as the original waveform i uploaded (so it was definetly cloned correctly, and it didn't break during transport).

I then scanned the original Transit999 again.. around 10 times.

I got the same output as the cloned card 50% of the time.
The other 30% of the time i got the inverse, and 20% of the time i got gibberish.

I didn't move the antenna or card between each loread, and i couldn't see any peaks which didn't hit the max in the plots of the inverted, or the non-inverted. I'll continue looking into this to see why it might be happening.

Also - whilst i was at this wedding yesterday, my flatmate's keyfob broke
I think someone cursed me yesterday tbh... but moving on, i scanned it with the proxmark.

It definatly replies - but it's a much weaker signal:
http://www.proxmark.org/files/index.php … ad=odd.pm3

Don't know what's going on there - maybe i blew it from scanning it too much? Maybe it was just a co-incidence. Anyone experience fobs breaking from being scanned by a PM3?

Since i'm now down to two fobs between four flatmates, i figured i had no choice but to act decisively and buy the ACG from Adam's shop (with five blanks).

I know it's a lot, but it's actually cheaper than buying 2 new fobs from my flat's Managing Agent

So two tasks to do this evening:
1. Get some more fobs to try out the Xor formular, and
2. Use losim to get a door open without a fob.

John · 2009-09-07 00:07:01

Okay, here's the evening report:

I've learnt some interesting things about my Proxmark today... perhaps other people have experienced this.. perhaps not.

I noticed that my first few reads of the day are generally a little 'off'.
Earlier when i said 50% of the reads where not correct, i was finding that mandemod was returning the inverse (0->1, 1->0) of the correct output, or somethings the stream would start correct, something odd would happen in the middle, then the end would be okay.

Thinking back to my previous forays in RF things (mainly HAM radio), i remember the gear i was using required a warm-up before it was working at peak performance. Normally only a few seconds/minutes to be honest, and rarely did it have an effect on making sense of a communication.

But perhaps the PM3 needs to be running for a few minutes, or do a few reads, before it's fully warmed up?
Would that sound like a plausible explination to why the tags 'read funny' at first? Just a thought.

Anyway, i didn't login to speculate. Here are some facts:

I managed to get a new fob to test:

0 0 0 0 0 0 1 1 - 0x03
0 0 0 0 0 0 1 0 - 0x02
0 1 0 0 1 0 0 1 - 0x49
1 0 1 1 1 0 1 1 - 0xBB

1 0 1 0 1 0 0 1 - 0xA9

1 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

As you can see - Henryk's fantastic efforts seem to be correct for all Transit fobs! Woohoo!
I'm going to have a look at some other blocks of flats tomorrow guys, to see what sorts of fobs they use there - see what kind of % of the market Urmet Domus have in my area.
I think it is rather sizable to be honest. In the 90's i predict.
I only wish to do it because Henryk did something similar at HAR2009 with car keys.

I also had a play with losim.

Man, i can't tell you how magical it is to see the door pop open when you put your PM3 antenna to the door. Really weird.
Kinda like when i picked my first lock - you get that sense that everything you know to be true about this technology is not what it seems.
You don't *need* a key fob to open these doors, just like you don't *need* a key to open a lock.
Since i opened my first lock, i always check out locks i come across to see what sort of lock / manufacturer is being used. It's become second nature almost.

I bet, hehe, and i'm not saying it's a good thing, but i bet this obsessive-compulsive behaviour will now carry on to RFID access systems too.

Unfortunatly, you can't tell just by looking what the frequency / modulation / encryption is being used by a tag. I don't think that will stop me from being curious now though.

So yeah, i had a play with losim... but i found a few things with it i would like to change if / when i learn to code in C :

1 - if you do loread/losamples/losim - you have to do loread again before you can do anything else.
Using losim seems to clear the memory of the PM3. That tripped me up at first

2 - If you do anything which changes the shape of the plot after loread/losamples - then losim probibly won't work.

If you dec it, demodulate it, etc, it doesn't seem to work.

3 - Allthough losim probibly repeats the signal in it's buffer over and over and over, it probibly doesn't do it very fast.

For this reason, the following losim (probibly) wouldn't work:

1 0 0 1 1 0 1 1 1 0 1 1 1 0 1 0
1 0 0 1 1 1 1 1 0 0 1 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 0 0 0 1 0 0 1 0 0

Where as, something like this might:

1 0 0 1 1 1 1 1 0 0 1 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 0 0 0 1 0 0 1 0 0
1 0 0 1 1 0 1 1 1 0 1 1 1 0 1 0
1 0 0 1 1 1 1 1 0 0 1 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 0 0 0 1 0 0 1 0 0

Does that make sense?

All the bits are in the first example, but for whatever reason, the reader doesn't see the thing properly.
There's probibly a tiny bit of lag for each cycle, which throws the reader off pace mid-way through the UID.
In the second example, there's probibly still lag - but because there's atleast one whole message before a repeat, the reader accepts it.

(I did test the above, using a sample of 700 and a sample of 1000 - however the data above is made up. I don't know the correct start of the sequence yet. Perhaps tomorrow using ltrim i can find out exactly where it starts)

Pretty soon a LF writer will arrive in my mailbox - and i can start cloning fobs for real

Once i'm able to do this - my next challange is to help out my man Xero with his similar situation.

I read your thread Xero, and i feel terrible for you. I went through all the same hiccups and frustrations you experienced when getting the PM3. Fortunatly, i have a tiny tiny tiny bit of coding experience (well, compiling atleast. ****ing Gentoo), so i managed to fix it - but still. Must have been seriously stressfull -_-;

Again, thank you everyone for all your help and support!
If i do end up selling fobs for a small profit (which is unlikely, but hey... perhaps i could sell them in other blocks of flats), i know what i'm spending the money on:

Tickets to HAR 2010 to see Henryk and thank him in person ( and buy him a drink if he'll let me )
Tickets to Defcon to see Adam ( again, for high fives and beer )
Tickets to Australia / NZ, to see XERO / the beaches and d18c7db / Flight of the Conchords, respectivly.

XEROEFFECT · 2009-09-07 00:45:23

@John
Haha.. you make me smile. Gotta say though, It has been so challenging for me from the first day and still is. I just looked at some old posts and now I'm thinking- what a Fuckwit. Hopefully new guys can just read my posts, laugh and learn from my mistakes. One day soon I'll be able to write scripts and then I'll sign up again as HenrykBrother or sometning. In the meantime I'll just keep asking.
Dude, I need a favour.... can you post a screen shot of the Q5 wave plot the same way you did b4. I havn't got my pm3 on me and I'm curious to see whats happening.

Last edited by XEROEFFECT (2009-09-07 01:06:43)

John · 2009-09-07 01:34:47

Sure, but if you're wondering if the trace looks similar to your keyfob's trace, i don't think it will be much use to you.

From what i understand, your fob is FSK (mine is Manchester) modulated.
Adam put this Q5 fob into Manchester modulation mode, set the clockrate to 32, and then uploaded the bits to send.
On your fob, he would probibly set the modulation to FSK, sent the clockrate to 64, and then upload the bits. The trace would look totally different.

In other words - i'm sure we will be able to clone your fob eventually
Hell - i have a writer. I'll do it for you when i know how

XEROEFFECT · 2009-09-07 02:49:50

John, post a screenshot of the wave without doing any functions to the data. like the first pic you posted below on the previous page on this thread. Just wanna compare both your waves.
Thanks dude.
PunBB bbcode test

Last edited by XEROEFFECT (2009-09-07 11:11:10)

adam@algroup.co.uk · 2009-09-07 09:33:08

John wrote:

All the bits are in the first example, but for whatever reason, the reader doesn't see the thing properly.
There's probibly a tiny bit of lag for each cycle, which throws the reader off pace mid-way through the UID.
In the second example, there's probibly still lag - but because there's atleast one whole message before a repeat, the reader accepts it.

OK, that's interesting - if the Q5 is spitting out the exact same data pattern as the PM3 then it *should* work. However, it may be suffering from the same problem - we are only programming a single instance of 64 bits into the Q5 so it is having to cycle and repeat the pattern which may introduce a tiny delay between cycles... We have room to store 224 bits on the Q5, so we could program 3 sets of 64 instead of just one and see if that helps... As you've ordered an ACG reader I'll email you the beta code and you can try it out yourself...

BTW, Glad you liked the lanyard etc., and I'm also very sorry to hear about your loss...

As far as meeting up goes, you don't need to travel far... Check out http://dc4420.org - we have regular London meets and the next one will be around the end of September...

Last edited by adam@algroup.co.uk (2009-09-07 09:33:48)

XEROEFFECT · 2009-09-07 10:17:59

Hmmm. Jonathan Westhues wrote about something similar but it only relates to the PM3. I'm curious to know where the start point was programmed in the Q5 card and if it took into account the sync pattern. I've provided a reference to this article below. I'm pretty sure the reason the Q5 dosn't work is cause there is no sync pattern which tells the reader "Get ready, here it comes"

Jonathan Westhues wrote:

If all that I want is to clone the tag, then it is arbitrary which point in the signal I designate as t=0. The ID just loops, so the signal over the air is unaffected. That feature between the cursors looked sort of like a sync pattern, though, and it occurs in both tags’ traces. For want of a better idea, I will write my demod code to correlate for that, and use that as its reference. Then I can demodulate the received signal to a bit string.

Last edited by XEROEFFECT (2009-09-07 10:23:05)

adam@algroup.co.uk · 2009-09-07 10:31:54

The sync pattern is embedded in the 64 bits - it's either the 2 HEX 0x00 bytes or the single 0xF2...

adam@algroup.co.uk · 2009-09-07 10:36:39

John wrote:

Earlier when i said 50% of the reads where not correct, i was finding that mandemod was returning the inverse (0->1, 1->0) of the correct output, or somethings the stream would start correct, something odd would happen in the middle, then the end would be okay.

Thinking about it, the most likely explanation is that we cloned the data inverted. All we need to do is invert it back again and I bet the 64 bit Q5 pattern will work.

BTW, you know you can specify 'i' to mandemod to invert the output for you?

e.g.

mandemod i 32

Last edited by adam@algroup.co.uk (2009-09-07 10:46:21)

XEROEFFECT · 2009-09-07 11:07:27

Does that mean all hex values must be changed once inverted to reflect the bit pattern or just the 2 HEX 0x00 bytes and the single 0xF2? Maybe i'm wrong but when you said invert did you mean start with 0xF2 > Bit Pattern > end with 2(0x00)

Last edited by XEROEFFECT (2009-09-07 11:17:07)

adam@algroup.co.uk · 2009-09-07 12:52:23

I meant that the read John originally posted was probably completed inverted. i.e. all bits must be flipped...

I've now implemented encoding of Q5 from the hex UID:

$ ./transit.py 99531670 WRITE

transit v0.1a (using RFIDIOt v0.1z-beta)
Reader: ACG LFX 1.0 (serial no: 07090142)

Encode: 0000000000000000100110010101001100010110011100001111011011110010
Waiting for blank tag...
Tag ID: Q00DC4420
*** Warning! This will overwrite TAG! Proceed (y/n)? y

Q5 Control Block: 6000F004
Q5 Data Block 01: 00009953
Q5 Data Block 02: 1670f6f2

Writing block 02: 1670f6f2
Writing block 01: 00009953
Control: 6000F004

Done!

and reading it back with the PM3 produces identical data to the inverted decode of John's trace, so I'm reasonably confident this Q5 tag will work...

John, I'm going to program all Q5s in your package with this code so when you get it please try one out on the door... (don't worry, they are rewritable - just use 'q5reset.py' to set it back to 'blank' mode....

XEROEFFECT · 2009-09-07 13:22:10

It makes sense. Since the 2 other transit 500 fobs had a low sync (please correct me if I got the wording wrong- low sync) it should work this time. I can't wait for the results. Getting really impatient.

Last edited by XEROEFFECT (2009-09-07 14:22:49)

John · 2009-09-07 14:26:05

Sorry for the confusion guys - To make it clear, the inverted read i gave originally (transit-best.pm3) was incorrect.
For whatever reason (and personally i belive it's because the PM3 hadn't warmed up yet), the mandemod of that trace was inverted. I have no idea why.

When Adam made me a Q5 with that trace on it, it didn't open the door (because it was inverted).

In a second issue, when i used losim with a sample which was only big enough to contain all the bits - but not in a compleate sequence - the door wouldn't open.

This contradics Jonathan's statement of t=0 being arbitary, because there is probibly lag between each loop. And if that lag occurs mid bitstream, it won't open the door.

For this reason, Adam's idea of having a few loops of the 64bit sequence is quite clever - as we don't even need to know where the sequences starts/ends.

Of course, it can be found by using ltrim or writing the card over and over with a different hex value first (only 8 different combinations after all) - but still, using several loops is still quite clever

When i received the ACG i'll be able to figure out if knowing where the bitstream starts really is an important factor or not.

I'll also be able to try out other fun UIDs, such as x00 x00 x00 x00, xFF xFF xFF xFF, etc.

EDIT:

Hehe, so am i XERO!
Adam will either ship it today or tomorrow, which means it'll probibly be 3-4 days before it arrives.

Can't wait xD

Last edited by John (2009-09-07 14:32:08)

XEROEFFECT · 2009-09-07 14:34:46

Oi, Your confusing me now. How did you figure Adam configured Q5 to loop a few times. From my little understanding, Looking at post 92, Adam just programmed the crap in once. Your thoughts?

John · 2009-09-07 14:50:34

Ah, sorry, i'm making it worse -_-;

He didn't - he only did 64 bits and he started with x00 x00.

But there's a chance that it's only x00 that is needed to initiate the message, or perhaps xF2 x00 x00.

So if it doesn't work, he suggested doing the loop three times.

"We have room to store 224 bits on the Q5, so we could program 3 sets of 64 instead of just one and see if that helps..."

He didn't actually do it - but it would be the next step if these new cards don't open the door.

Last edited by John (2009-09-07 14:52:47)

adam@algroup.co.uk · 2009-09-07 15:08:13

XEROEFFECT wrote:

Oi, Your confusing me now. How did you figure Adam configured Q5 to loop a few times. From my little understanding, Looking at post 92, Adam just programmed the crap in once. Your thoughts?

I suggested that I *could* put three copies of the 64 bits into the Q5 instead of just one, but I don't think that will be necessary as I believe the Q5 will output a rolling 64 bits with no delay between the last bit and the fisrt each time it rolls over... However, I've shipped the package on a next-day delivery, so hopefully by this time tomorrow we'll know for sure!

adam@algroup.co.uk · 2009-09-07 17:49:56

John wrote:

In a second issue, when i used losim with a sample which was only big enough to contain all the bits - but not in a compleate sequence - the door wouldn't open.
This contradics Jonathan's statement of t=0 being arbitary, because there is probibly lag between each loop. And if that lag occurs mid bitstream, it won't open the door.

What might be happening here is not that the PM3 is introducing a delay, but because the sample is not an EXACT multiple of 64 bits, it is effectively delivering a corrupted stream as it will go out of sync each time it wraps. If the reader expects to get at least two good consecutive reads (for integrity checking) after it get synchronised, this will never happen and the read will fail.

John · 2009-09-08 00:49:16

Ah - yes that's a very good hypothesis. I think i would agree with that rather than the lag/delay theory.

The only way to prove it is to either buy another proxmark (to sniff the reader/proxmark chatter, and rule out lag) or to rewrite losim to have a parameter for bitstreams / modulation like the Q5 (to rule out corrupted stream playback).

To be honest, there are lots of uses for losim having that functionality. Testing different UID's than the one captured over-the-air is one. The potential for brute-forcing with UID's is another.

How fast is the whole stream being replayed per second? At 125Mhz i bet it's fast.

Bearing in mind that there are 4,294,967,295 potential UID's on this system (00 00 00 00 ~ FF FF FF FF) - how long would that take to try them all? Years or seconds?

I should get some sleep - i have a very important package arriving tomorrow

Night guys!

XEROEFFECT · 2009-09-08 00:56:44

While you guys are about to sleep, I wake up. Then I feel lonely for the rest of the day
Can't wait to hear results. I'm getting a good vibe on this one. Good luck and good night John & Adam.

Proxmark3 community

Announcement

#51 2009-09-03 14:48:07

Re: Help cloning my flat keys

#52 2009-09-03 15:33:31

Re: Help cloning my flat keys

#53 2009-09-03 16:03:37

Re: Help cloning my flat keys

#54 2009-09-03 23:18:45

Re: Help cloning my flat keys

#55 2009-09-03 23:40:50

Re: Help cloning my flat keys

#56 2009-09-04 02:52:03

Re: Help cloning my flat keys

#57 2009-09-04 10:23:43

Re: Help cloning my flat keys

#58 2009-09-04 11:25:38

Re: Help cloning my flat keys

#59 2009-09-04 13:10:42

Re: Help cloning my flat keys

#60 2009-09-04 15:06:11

Re: Help cloning my flat keys

#61 2009-09-04 20:35:27

Re: Help cloning my flat keys

#62 2009-09-04 20:53:11

Re: Help cloning my flat keys

#63 2009-09-04 22:13:30

Re: Help cloning my flat keys

#64 2009-09-05 00:50:07

Re: Help cloning my flat keys

#65 2009-09-05 07:36:44

Re: Help cloning my flat keys

#66 2009-09-05 07:48:19

Re: Help cloning my flat keys

#67 2009-09-05 08:09:47

Re: Help cloning my flat keys

#68 2009-09-05 08:23:24

Re: Help cloning my flat keys

#69 2009-09-05 08:48:52

Re: Help cloning my flat keys

#70 2009-09-05 09:34:55

Re: Help cloning my flat keys

#71 2009-09-05 09:59:22

Re: Help cloning my flat keys

#72 2009-09-05 11:48:42

Re: Help cloning my flat keys

#73 2009-09-05 12:06:50

Re: Help cloning my flat keys

#74 2009-09-05 12:21:59

Re: Help cloning my flat keys

#75 2009-09-05 12:59:18

Re: Help cloning my flat keys

#76 2009-09-05 14:08:33

Re: Help cloning my flat keys

#77 2009-09-05 16:46:20

Re: Help cloning my flat keys

#78 2009-09-05 18:51:38

Re: Help cloning my flat keys

#79 2009-09-05 22:37:52

Re: Help cloning my flat keys

#80 2009-09-06 02:28:43

Re: Help cloning my flat keys

#81 2009-09-06 11:00:52

Re: Help cloning my flat keys

#82 2009-09-06 16:52:13

Re: Help cloning my flat keys

#83 2009-09-07 00:07:01

Re: Help cloning my flat keys

#84 2009-09-07 00:45:23

Re: Help cloning my flat keys

#85 2009-09-07 01:34:47

Re: Help cloning my flat keys

#86 2009-09-07 02:49:50

Re: Help cloning my flat keys

#87 2009-09-07 09:33:08

Re: Help cloning my flat keys

#88 2009-09-07 10:17:59

Re: Help cloning my flat keys

#89 2009-09-07 10:31:54

Re: Help cloning my flat keys