Proxmark3 community

pietjepuk

Member

Registered: 2011-04-16

Posts: 5

UID always 30 bits

Hi,
I've been following the development of the hitag2 protocol on proxmark3 with great interest, and it's a very steep learning curve for me !

Now using the new commands (r623 - r625) I keep getting the same response on reading a tag :

proxmark3> lf hitag reader 21 test
#db# Starting Hitag reader family                 
#db# List identifier in password mode                 
#db# Configured for hitag2 reader                 
#db# Uknown frame length: 30                 
proxmark3>

Now, as I understand it, hitags and hitag2 should both return a 32 bit uid on the reader sending 11000, and in any mode (password or crypto) communication starts the same: request uid >> answer with 32 bit uid.

I'm using the "zik zak" standard antenna, and if the tag is close enough ( 0-2 centimetres) it always returns the same frame length of 30, so I think the antenna is ok.
I have not been able to get the data of any hitag commands into the "plot" window to verify manually... but I'm not even sure this is implemented..
I'm sure it's a hitag2 or a hitagS.

Am I missing something here ?

PS I found in a hitagS datasheet ( http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/HTS.pdf ) that the first 8 bits of the uid define the tag type .. I could only find it for hitagS, but maybe I can find the hitag1 and 2 also, that could make a nice addition to the lf hitag command list to scan for tag type... (and a not so difficult one to create.;-) I will try to hobby this into the source and post a diff for one of you to review...

Thanks!

rule

Member

Registered: 2008-05-21

Posts: 417

Re: UID always 30 bits

proxmark3> lf hitag reader 21 test
#db# Starting Hitag reader family                 
#db# List identifier in password mode                 
#db# Configured for hitag2 reader                 
#db# Uknown frame length: 30                 
proxmark3>

I assume you added a new command here, I can't remember the "test" command being part of the interface (yet ?:))

Now, as I understand it, hitags and hitag2 should both return a 32 bit uid on the reader sending 11000, and in any mode (password or crypto) communication starts the same: request uid >> answer with 32 bit uid.

You are right, but as the datasheet explains, the response header of a HitagS chip contains only a single 'one' bit in stead of the five 'ones' that Hitag2 sends. I've already made the code a bit more flexible, for example, if you type 'lf hitag reader' you will see that there are several functions defines by a command code (0 < number < 30). Where the first range is reserved for HitagS (0-09, lets write that as 0x), the second for Hitag1 (1x) and the last one for Hitag2 (2x).

I've coded out some features for Hitag2 already (21,22,23,25), you are more than welcome to help write some code for the other products (hitag1/S).

I'm using the "zik zak" standard antenna, and if the tag is close enough ( 0-2 centimetres) it always returns the same frame length of 30, so I think the antenna is ok.
I have not been able to get the data of any hitag commands into the "plot" window to verify manually... but I'm not even sure this is implemented..
I'm sure it's a hitag2 or a hitagS.

Am I missing something here ?

The antenna is ok! And no, you will not be able to get them into a plot screen. The data is not just sampled in raw format, but it is interpreted by the proxmark code. The plot only works if you just suck in a massive of samples from the ADC.

PS I found in a hitagS datasheet ( http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/HTS.pdf ) that the first 8 bits of the uid define the tag type .. I could only find it for hitagS, but maybe I can find the hitag1 and 2 also, that could make a nice addition to the lf hitag command list to scan for tag type... (and a not so difficult one to create.;-) I will try to hobby this into the source and post a diff for one of you to review...

Always look forward to find new features and commands in the repository Let me know if you need SVN access to commit the changes.

Cheers,

  Roel

pietjepuk

Member

Registered: 2011-04-16

Posts: 5

Re: UID always 30 bits

Hi Roel,

The "test" is meant as the (obviously false) password, which -if I understand correctly from the code- is ok to be false up to after receiving the uid, as it only afterwards gets send.
So no matter what password, I think I should still be receiving a 32 bit uid .... -Correct ???

As for the selection logic using the lf hitag reader 21,22,23,25. I understand perfectly how you wrote it and intend the logic of this. What I was thinking to add is a command that just requests the hid, and then tells you the tag type derived from the uid. Then ultimately remove the selection difference between hitag S/1/2 in the menu and let the code decide for itself what to do depending on the derived tag type (or throw an error if the command is not possible for the tag type).

Concerning SVN access, I'm honoured by the offer, but please understand I don't know c. I just edit, try, fail, try again, look it up, fail again, till I've got something that works for me.
So committing to the repo would not be a good idea if you want stable code... I would however love to share my changes to the code !! But they'll need reviewing...

As for sharing code. The only way I could get a stable usb connection was by changing the code to use libusb-1.0, following a post somewhere on this forum and then adapting it to the current trunk (tried osx native, linux native, linux in a vm, now running stable in a ubuntu 12.04 virtual machine on osx). So the question is if you stick with the old libusb intentionally.
I'll post a diff in the linux-client forum, maybe it can help someone...

So my question remains: why only 30 bits in the uid I receive.

Some more data:

proxmark3> lf hitag reader 21
#db# Starting Hitag reader family                 
#db# List identifier in password mode                 
#db# Configured for hitag2 reader                 
#db# Uknown frame length: 30                 
proxmark3> lf hitag list
recorded activity:          
 ETU     :rssi: who bytes          
---------+----+----+-----------          
 +      0:    :     c0             
 +     74:   0: TAG 55! 55! 55! 54

If I look at the c0 the reader transmitted it doesn't look strange converted to bin it's 11000000 ... just leave away some 0's
The last 2 bits of the reply are 00, so that could be right also ?? Don't understand the exclamation marks though..

Thanks for helping !

rule

Member

Registered: 2008-05-21

Posts: 417

Re: UID always 30 bits

The "test" is meant as the (obviously false) password, which -if I understand correctly from the code- is ok to be false up to after receiving the uid, as it only afterwards gets send.
So no matter what password, I think I should still be receiving a 32 bit uid .... -Correct ???

True, but you need to know what kind of encoding is used. While Hitag2 only supports one way of encoding, the Hitag1 and HitagS support communication with various encoding length (16, 32 or 64 periods, where one period (T0) = 8us). If you look at the datasheet at page 14, besides those modes, you will see the anti-collision coding is different from the regular coding (Manchester/Biphase) as defined at page 13.

First, decide which kind of coding you prefer to interpret (hint: start with slowest communication, which means biggest amount of periods per bit, lowest bit-rate). Then you should patch the decoding function accordingly.

As for the selection logic using the lf hitag reader 21,22,23,25. I understand perfectly how you wrote it and intend the logic of this. What I was thinking to add is a command that just requests the hid, and then tells you the tag type derived from the uid. Then ultimately remove the selection difference between hitag S/1/2 in the menu and let the code decide for itself what to do depending on the derived tag type (or throw an error if the command is not possible for the tag type).

You say "the hid", with that you mean the 'id', or maybe "hitag id"? I don't think you can derive the product type (1/2/S) from the id. What I do know is that you can find the difference between Hitag2 immobilizer products (PCF 7936/41/42/46/47/52/62). I would not be so simple to just "automatically" detect this, or you should try all combinations for all products, which may slow down the functionality significantly.

Concerning SVN access, I'm honored by the offer, but please understand I don't know c. I just edit, try, fail, try again, look it up, fail again, till I've got something that works for me. So committing to the repo would not be a good idea if you want stable code... I would however love to share my changes to the code !! But they'll need reviewing...

Some code that is in the repository is very clean, well documented and greatly working. Other parts are buggy and preliminary. But the important requirement is that it should work at least as a proof an concept (bit buggy, but useful for finding out how to communicate with RFID  products)

As for sharing code. The only way I could get a stable usb connection was by changing the code to use libusb-1.0, following a post somewhere on this forum and then adapting it to the current trunk (tried osx native, linux native, linux in a vm, now running stable in a ubuntu 12.04 virtual machine on osx). So the question is if you stick with the old libusb intentionally.
I'll post a diff in the linux-client forum, maybe it can help someone...

Great work! This would be a awesome contribution. I've noticed that sometimes (newer systems) the USB seems to have a lot of problems. If your code can fix most of the problems regarding this, it would be a big improvement to the current code in SVN repository. You can send me a email for SVN access (or just email me the diff/patch).

So my question remains: why only 30 bits in the uid I receive.

Some more data:

proxmark3> lf hitag reader 21
#db# Starting Hitag reader family                 
#db# List identifier in password mode                 
#db# Configured for hitag2 reader                 
#db# Uknown frame length: 30                 
proxmark3> lf hitag list
recorded activity:          
 ETU     :rssi: who bytes          
---------+----+----+-----------          
 +      0:    :     c0             
 +     74:   0: TAG 55! 55! 55! 54

Short answer, not so easy, what you receive is probably not correct and requires different way of decoding.

If I look at the c0 the reader transmitted it doesn't look strange converted to bin it's 11000000 ... just leave away some 0's
The last 2 bits of the reply are 00, so that could be right also ?? Don't understand the exclamation marks though..

0xC0 = 1100 0000, but only 5 bits are transmitted which you can find in the code (from hitag2_password())

  // No answer, try to resurrect
  case 0: {
    // Stop if there is no answer (after sending password)
    if (bPwd) {
      DbpString("Password failed!");
      return false;
    }
    *txlen = 5;
    memcpy(tx,"\xc0",nbytes(*txlen));
  } break;

Cheers,

  Roel

Thijs

Member

Registered: 2012-09-20

Posts: 5

Re: UID always 30 bits

Hi pietjepuk,

I can't help you with your 30 bits problem, but I'm very interested in what you wrote about the usb connection.

As for sharing code. The only way I could get a stable usb connection was by changing the code to use libusb-1.0, following a post somewhere on this forum and then adapting it to the current trunk (tried osx native, linux native, linux in a vm, now running stable in a ubuntu 12.04 virtual machine on osx). So the question is if you stick with the old libusb intentionally.
I'll post a diff in the linux-client forum, maybe it can help someone...
.

I can't find the diff in the linux-client forum? Did you post it already?

Thijs