LF HITAG - fails

[iceman1001]

Describe the bug the lf hitag commands fails to work

To Reproduce Steps to reproduce the behavior:

1. put hitag2 tag on pm3 antenna
2. lf hitag reader 26
3. fails...

Expected behavior fully functional / verified working card operations with pm3 and a hitag card.

Desktop (please complete the following information):

• rdv4
• latest source
• ubuntu / mingw

Additional context This problem has existed for a while, @doegox brought this to my attention some days ago. found a hitag2 card today and could verify that the hitag2 commands doesn't work.

[iceman1001]

Looking at hitag.c in armsrc, gives you that it uses its own clock definition.
compared with the newly remade legic stuff from @drandreas which also uses a custom clock but the code is neat and nice, the hitag code is not on par with current coding style for pm3 when it comes to device (arm) usage.

[iceman1001]

More ppl has also notice this, see https://github.com/Proxmark/proxmark3/issues/798 I don't think it has to do with i2c direct, I would say it has to do with init of clocks etc.

[iceman1001]

A missing TC0 init and bobs your uncle.

[doegox]

Not quite :)

• RRG loaded on Pm3 Easy : :+1:
• RRG loaded on Pm3 rdv4 : :-1:
  • With original highQ antenna : nothing
  • With lowQ antenna : sometimes it gets some part of the frame, but not all

[iceman1001]

For it works for me.

• RRG loaded on Pm3 rdv4 👍 LowQ antenna

[iceman1001]

The reading distance is crap. I must have it direct on antenna.

[iceman1001]

As seen below, I need to position the tag until it reads.

pm3 --> lf hita read 26
#db# Configured for hitag2 reader
#db# Uknown frame length: 5
pm3 --> lf hita read 26
#db# Configured for hitag2 reader
#db# Uknown frame length: 31
pm3 --> lf hita read 26
#db# Configured for hitag2 reader
#db# Uknown frame length: 31
pm3 --> lf hita read 26
#db# Configured for hitag2 reader
#db# Uknown frame length: 2
pm3 --> lf hita read 26
#db# Configured for hitag2 reader
#db# Uknown frame length: 31
pm3 --> lf hita read 26
#db# Configured for hitag2 reader
Valid Hitag2 tag found - UID: ac20a810
pm3 -->

[ghost]

Sorry for capturing this post, but what do you mean by highQ and lowQ antenna? Is meant the signal quality or a special antenna.

Thanks.

Gesendet von ProtonMail mobile

-------- Original-Nachricht -------- An 13. März 2019, 12:20, Philippe Teuwen schrieb:

Not quite :)

• RRG loaded on Pm3 Easy : 👍

• RRG loaded on Pm3 rdv4 : 👎

• With original highQ antenna : nothing

• With lowQ antenna : sometimes it gets some part of the frame, but not all

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Danyc0]

@gtpy they're referring to antennas with different Q factors. As far as I know the highQ antenna is the one that currently comes with the PM3 RDV4, and the lowQ antenna I believe is a new one currently in development.

@iceman1001 have you got a photo of your tag position when it's getting a solid reading?

[iceman1001]

That would be the new prototypes for LF antennas. The old one had HighQ which communicated with T55X7 cards badly. The new prototype has lower Q value with less general reading distances but much better communications with t55x7

https://pbs.twimg.com/media/D0tnnqkV4AAtybM.png:large

And there is prototype to replace the dual antenna, a medium and a large prototype. @doegox has been testing the first prototype out. We have identified some things to improve. A bit higher Q value.. mean while the firmware has been adapted to always center the lf signal once collected.

[iceman1001]

Tested offical repo on RDV4, works but equal crappy distance and need to find a sweetspot with the tag.

[ghost]

Thanks for information @Danyc0 @iceman1001 Now I have some more stuff to read ;)

[doegox]

So my latest tests:

• RRG code on Easy, always very reliable
• RRG code on RDV4 + hiQ : nothing
• RRG code on RDV4 + lowQ : some bits... up to 31...
• RRG code on RDV4 + lf-only antenna : mostly ok, with like 0.5cm distance max

[iceman1001]

The current LF peak detection could be better if I understand the comments I have gotten on Twitter etc.

[iceman1001]

@doegox just showed a 9cm readout, but its done manually. I have succeded to do it with 5cm just like that. Getting good distances is possible.
We will need to refactor the edge_peak implementation in hitag2.c / hitagS.c to use the ADC path instead.

[doegox]

FTR:

lf cmdread d 50 z 166 o 116 c 000111
data ltrim 200
data norm
data rawdemod am
data printdemodbuffer o 5 x

I'm missing the very last bit, probably rawdemod am giving up on the very last transition but the signal is there.

Edit : last bit was a bug in Manchester decoder, now fixed

[bosb]

I like the workaround of @doegox but I do not get the connection of 000111 to Start_Auth [11000] ? What do I miss to understand that 000111 is Start_Auth?

[doegox]

Hehe someone noticed, good catch @bosb . Actually it's just the way to define a zero and a one. So you can equally use

lf cmdread d 50 z 166 o 116 c 000111
lf cmdread d 50 z 116 o 166 c 011000

The leading symbol can be a "0" or "1", it doesn't matter, it's just to introduce a first pause in front of the actual signal.

[florianrock]

Hello,

i got an proxmark3 rdv4 end of 2018. i would love to merge the changes for hitag S from normal proxmark3 repo into here and also refactor to ADC path.

Only problem is that rdv4.0 was shipped end of 2018 with the hiQ antenna. Is it anyhow possible to get an lf-only or lowQ antenna somewhere? (best would be shipment in germany)

Thanks, Florian

[iceman1001]

For hitag I don't think you need the lowQ antenna. You can get the lowQ antennas at the offical distributors Hackerware, Lab401 & Sneaktechnology.

The HitagS is already in this repo. but the state of how they work is unknown since there seem to be few ppl who has a Hitag reader & cards & proxmark to play with.

I think most of hitag problems is software related, given @doegox 's success using lf cmdread..

[florianrock]

well the state of hitagS here can't handle tags in standard mode, only advance mode.. I submitted last year a refactoring to normal proxmark3 repo, and would merge it here.

regarding to doegox comment

• RRG code on RDV4 + hiQ : nothing

i didn't try a lot with my antennas, so i will write some dummy code this week and play around with my antennas if its really just software related i should get any signal. Same time i wrote the stores if its possible to just order the antennas (cause i can't find the products)

i will keep you updated, if i will get signal with dummy code i will refactor the hitag code at this weekend.

[iceman1001]

yup, I never took your changes since the core hitag code desperate needs a refactoring. I have the code for ADC path but no time.

[florianrock]

can you may provide me code samples? would for sure help.. you can mail it to my private e-mail username @ gmail ;)

well im not so sure if the original rdv4 antenna is just a software problem but i will find out when starting refactoring.

but even with the command i have to place the hitags card really precisely on the antenna. [usb] pm3 --> lf cmdread d 50 z 166 o 116 c 110000 ...

with old (non rdv4 proxmark) i can even hame some space between antenna and tag proxmark3> lf cmdread d 50 z 166 o 116 c 110000 Waiting for a response from the proxmark...
You can cancel this operation by pressing the pm3 button

db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample

db# buffer samples: 98 9f 9f 00 00 84 ff ff ...

[ViRb3]

@doegox are you sure the manchester decoder last bit is fixed? My UID last bit is a 0 using your sample code, while lf hitag reader 26 shows it as 1.

[doegox]

Well it worked on my UID, I didn't do intensive tests and I have one single Hitag...

[iceman1001]

@doegox Got a branch for you to test

[iceman1001]

Hitag read / write should work better but it is untested for crypto mode / password mode.

[aczid]

Hitag read / write should work better but it is untested for crypto mode / password mode.

I've tested HITAG2 wakeup, reading in crypto and password mode, and it works perfectly! What about logging the raw LF samples during use of the hitag2 reader next to the digital data? Is that a part of the roadmap?

[iceman1001]

that is the big issue. We have the bigbuff... which is shared for tracelog and the signal decoding. So if you do data sample and zoom out, you should see the raw signal around 20000 sample index.

Good thing it works again. The problem then is sniff and simulate where we can do the different data collection for the different attacks.... Suggestions?

[aczid]

My intuition would be to simply reserve a (configurable?) chunk of the bigbuf for raw samples and opportunistically log to it until that area is full. I don't see why this is a huge problem, how small is this bigbuf anyway?

For all situations a small chunk of analog samples would already be really helpful and should not interfere with space for the tracelog, as the amount of trace data generated is relatively small in all LF applications (AFAIK). Just 1 kB should be about enough to log the first command and response, and that is often all you really need to see when using it as a test tool.

For some situations you might want to choose between fully analog or fully digital logging. It occurred to me that if it were somehow possible to send the sample buffer to the host via asynchronous (DMA) transfers then the host could do the full signal decoding for all non-standalone situations. I assume that's not possible in the current usb serial situation.

As a user, I think it would be great if I could just configure a setting that sets a dividing line between the digital and analog sample area. The rest of the code should just respect that boundary and use 2 separate logging interfaces to log data to each area.

How does the EM4x50 reader accomplish the trick of showing me digital data and an annotated modulation waveform? Trickery that goes outside of this dual log interface I imagine it should have?

[iceman1001]

64kb ram, whereas recent mods to stack size and bigbuffer making it adjustable. Around 41kb at the momemt. We havent sorted out all different usages and documented it yet. Then those needs to be adapted if possible. Which is all another story but it relates as it touches the same problem about LF for tracelog/raw signal data.

Let me first highlight what is possible today. you can today already see the full tracelog and the raw signal from the last command

The tracelog part isn't large if you look at normal comms for hitag. Its when you start trying to log and implement the attacks that you start get into troubles. If you gonna do the extended attack, its gonna eat up some 2-4kb. For just log, then the data needed for the attack some more 4kb at least. Then comes the lf signalry part, how to decode raw signal HITAG and how much space you need for some few commands which is at the momement around 20kb-ish. Next part is the HITAG crypto-mode, which needs space for the crypto, crypto stream etc. That brings up the old discussion if the tracelog should show the encrypted stream or the decrypted or both.

Now, for the attacks you can not simply keep the raw signal for it. We just don't have space. We have space for about one-two transactions raw signal. So you compromise which raw signal parts you wanna see, but you never gonna see the signal from a whole extended attack.

The proxmark way of saving raw signals on device side is an issue about available RAM. Sending it over to the client ad-hoc takes time. Will you loose LF trafic meanwhile you do it? Even if you buffer stage it, you will eventually have to send it to the client, during it you loose signal samples.

HF parts of proxmark usually don't save raw signals. With the 30kb inside fpga being able to log the last samples, is what we can do there but difference is the decoding is done much more on FPGA side, leading to smaller memory requirements on the device side. With more RAM available for simulation memory, tracelog, crypto etc.

Maybe add a custom HITAG decode for the FPGA to save some space, but loose raw samples...

I am not sure at all what you suggest the em 4x50_read command does. It certainly doesn't use the tracelog. It uses as most all other LF command the idea of collect a raw signal 10-30kb, download to client, decode to data and present to user. It doesn't use any crypto nor tracelog. It does most work on clientside.

Feel free to come up with a better solution! I have been having issues with getting the SIM and SNIFF to work with HITAG2. Which is needed to collect the data needed for the different attacks.

[aczid]

Keeping analog samples when running attacks or other intensive work makes no sense. It's most useful when building an emulator of the reader or the tag, and may also be helpful when sniffing to get the full picture. That's the use case I'm thinking about. I think it can also be useful as a teaching aid.

you can today already see the full tracelog and the raw signal from the last command

This is what I want. I simply want to run regular LF commands and see a glimpse of the raw samples collected along the way. If I do lf hitag reader 26 and data samples 2000 and data plot I am looking at the tracelog data. How can I see the sample buffer?

It uses as most all other LF command the idea of collect a raw signal 10-30kb, download to client, decode to data and present to user.

This is what I meant by sending the sample buffer to the host. This seems useful for my usecase and most non-standalone use cases that don't need to send a lot of data back and forth to the tag. Thanks for claryfing. I understand a hitag solution has to work differently.

HF parts of proxmark usually don't save raw signals.

I agree HF is out of scope here.

[iceman1001]

look at signal

lf hitag reader 26
data samples 
data ltrim 20000    -->  the signal starts around 20 000
data plot

look at tracelog.

lf hitag list
trace list hitag2

[usb] pm3 --> trace list hitag2
[=] downloading tracelog from device
[+] Recorded activity (trace len = 33 bytes)
[=] Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
[=] Hitag1 / Hitag2 / HitagS - Timings in ETU (8us)

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |        164 | Rdr |c0                                                                       |     | START AUTH
        356 |       1980 | Tag |10  bd  a8  10                                                           |     |
         90 |        254 | Rdr |c0                                                                       |     | START AUTH
[usb] pm3 -->

[iceman1001]

The first parts of samples == tracelog the second part , dunno, I am curious on this one. why it shows up. the third part == hitag raw command reader 11000, tag answer

[aczid]

Oh man. I was expecting the sample data at the start of the buffer when doing 'data samples'. This is honestly pretty confusing. But thank you, I think that is all I wanted!

[iceman1001]

Before there was only two parts... some noice in the beginning of bigbuf (samples) which is the trace log data. then at 3000-ish sample was the raw signal.

Now it seems a signal seems to be inside...