Closed digitalentropy closed 5 years ago
This is a known issue.
The reading any LF has better distances with the current dual lf antenna, but writing t55x7 is worse. It usually needs the tag direct over the antenna very close.
As improvements @proxgrind has created a first prototype lowQ LF antenna which has great write distance but it comes with the price of shorter reading distances. The second prototype uses swithes to switch between lowQ and highQ, giving best of worlds. I think it will be released in May. At the same time as the large LF antenna will be released.
It wouldn’t be so bad if it would at least work at SOME distance. With the particular credentials in question I been unable to get it working at any distance.
Are there any potential optimizations or changes that can be made to T5577 settings that might allow writes to execute successfully without resorting to the upcoming new antenna?
On May 3, 2019, at 1:05 AM, Iceman notifications@github.com<mailto:notifications@github.com> wrote:
This is a known issue.
The reading any LF has better distances with the current dual lf antenna, but writing t55x7 is worse. It usually needs the tag direct over the antenna very close.
As improvements @proxgrind has created a first prototype lowQ LF antenna which has great write distance but it comes with the price of shorter reading distances. The second prototype uses swithes to switch between lowQ and highQ, giving best of worlds. I think it will be released in May. At the same time as the large LF antenna will be released.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/RfidResearchGroup/proxmark3/issues/182#issuecomment-488954540, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAKYZPWBZXAYTRJVBDKFLEDPTPIYTANCNFSM4HKIQOJQ.
Feel free to contribute, this is an open source project.
I believe most folks are quite aware of the open-source nature of the project.
However, as someone who is not as intimately familiar with the hardware design or the code, I was curious if you felt this was a hardware limitation or if there is a possibility of some optimization of software or settings.
I did not mean to imply that it was your responsibility to provide a fix, which seems to be the way my question was taken.
On May 3, 2019, at 7:45 AM, Iceman notifications@github.com<mailto:notifications@github.com> wrote:
Feel free to contribute, this is an open source project.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/RfidResearchGroup/proxmark3/issues/182#issuecomment-489082867, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAKYZPX2IIHI536D5MPCZHTPTQXWDANCNFSM4HKIQOJQ.
There is two kinds of problems with LF.
Usually ppl mixes those two things up, they think the writing didnt work but actually the decoding the signal when reading fails. Easiest to detect with running dedicated commands ie:
Looking at the outcome of the script from issue #149 also gives an indication.
Ok, lets see, @mrwalker33 just recently added support for full set of downlink protocols for T55XX commands. You could test them out and see if that improved reading / writing your tags? Not really a fix for demodulation part.
Just doing some testing and some interesting results. RDV 4.0 (stock antenna) The basic T55 read/write commands give the same results as before (as expected) as that code should not have changed. But setting the T5577 into a different downlink mode (coms from reader to card) seemed to help. The card did not need to be in the exact position to work. e.g. I set the T5577 into long leading reference. this mode is backwards compatible with default mode, but when used will send a leading "sync" pulse to the card. Below is a sample output calling the dump with and without the leading 0 downlink mode calls. This was a blank card, so it would be expected that if the card did not accept the command, it would send out the blocks of 00's the first is normal dump then with nothing moved, the 2nd command with the r 2 got the correct results.
[usb] pm3 --> lf t55 dump
Reading Page 0:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 00000000 | 00000000000000000000000000000000 | ....
01 | 00000000 | 00000000000000000000000000000000 | ....
02 | 00000000 | 00000000000000000000000000000000 | ....
03 | 00000000 | 00000000000000000000000000000000 | ....
04 | 00000000 | 00000000000000000000000000000000 | ....
05 | 00000000 | 00000000000000000000000000000000 | ....
06 | 00000000 | 00000000000000000000000000000000 | ....
07 | 00000000 | 00000000000000000000000000000000 | ....
Reading Page 1:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 00000000 | 00000000000000000000000000000000 | ....
01 | 00000000 | 00000000000000000000000000000000 | ....
02 | 00000000 | 00000000000000000000000000000000 | ....
03 | 00000000 | 00000000000000000000000000000000 | ....
[usb] pm3 --> lf t55 dump r 1
Reading Page 0:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 000880E0 | 00000000000010001000000011100000 | ....
01 | FFFFFFFF | 11111111111111111111111111111111 | ....
02 | FFFFFFFF | 11111111111111111111111111111111 | ....
03 | FFFFFFFF | 11111111111111111111111111111111 | ....
04 | FFFFFFFF | 11111111111111111111111111111111 | ....
05 | FFFFFFFF | 11111111111111111111111111111111 | ....
06 | 66667777 | 01100110011001100111011101110111 | ffww
07 | FEEDBEEF | 11111110111011011011111011101111 | ....
Reading Page 1:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 000880E0 | 00000000000010001000000011100000 | ....
01 | FFFFFFFF | 11111111111111111111111111111111 | ....
02 | FFFFFFFF | 11111111111111111111111111111111 | ....
03 | 90000400 | 10010000000000000000010000000000 | ....
So, with the latest firmware, you need to get the card such that it can accept the initial write (the tricky bit) then send lf t55 write b 3 1 d 90000400 if its a real T5577 (clones don't always work) it will allow the card to use long leading 0 reference. So then try adding the r 1 options to the read and write commands.
image of the clam shell card placed roughly on the PM3 (offset by the blueshark)
closed because of inactivity. Suggested fixes use the new R parameter and/or get a low Q LF antenna.
Describe the bug I have observed that the RDV4 LF antenna appears to have some degraded performance on some T5577 tags. While I have observed the issue on a few generic blank T5577 cards, in my own testing the behavior is most pronounced on clamshell-style T5577 cards, such as those used by an OEM, as seen below.
In the above example, Kantech happens to use a non-protected T5577 chip in their OEM cards which allows the cards to be erased and re-written.
While read performance is quite forgiving, I have been unable to successfully perform any writes or ioProx clone operations to one of these clamshell-style cards using the RDV4.
Running the same version of the firmware on an RDV2 board results in highly reliable writes and I have no issues performing writes on RDV2 hardware.
To Reproduce Steps to reproduce the behavior:
Expected behavior Writing to full-sized T5577 credentials should be reliable regardless of antenna shape or size used in the card.
Screenshots N/A
Desktop (please complete the following information):
RDV2 Hardware Info
RDV4 Hardware Info
```code pm3 --> hw version [ Proxmark3 RFID instrument ] [ CLIENT ] client: RRG/Iceman [ PROXMARK ] external flash: present smartcard reader: present USART for addon support: absent [ ARM ] bootrom: RRG/Iceman/master/2ec05efa 2019-05-02 11:25:24 os: RRG/Iceman/master/2ec05efa 2019-05-02 11:25:57 [ FPGA ] LF image built for 2s30vq100 on 2019/ 4/18 at 9:35:32 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23 [ Hardware ] --= uC: AT91SAM7S512 Rev B --= Embedded Processor: ARM7TDMI --= Nonvolatile Program Memory Size: 512K bytes, Used: 249944 bytes (48%) Free: 274344 bytes (52%) --= Second Nonvolatile Program Memory Size: None --= Internal SRAM Size: 64K bytes --= Architecture Identifier: AT91SAM7Sxx Series --= Nonvolatile Program Memory Type: Embedded Flash Memory pm3 --> hw status #db# Memory #db# BIGBUF_SIZE.............40000 #db# Available memory........40000 #db# Tracing #db# tracing ................1 #db# traceLen ...............0 #db# Currently loaded FPGA image #db# mode.................... HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23 #db# Flash memory #db# Baudrate................24MHz #db# Init....................OK #db# Memory size.............2 mbits / 256kb #db# Unique ID...............0xd567a882a72ab725 #db# Smart card module (ISO 7816) #db# version.................v3.11 #db# LF Sampling config #db# [q] divisor.............95 (125 KHz) #db# [b] bps.................8 #db# [d] decimation..........1 #db# [a] averaging...........Yes #db# [t] trigger threshold...0 #db# LF T55XX config #db# [a] startgap............29*8 (232) #db# [b] writegap............17*8 (136) #db# [c] write_0.............15*8 (120) #db# [d] write_1.............47*8 (376) #db# [e] readgap.............15*8 (120) #db# Transfer Speed #db# Sending packets to client... #db# Time elapsed............1500ms #db# Bytes transferred.......884736 #db# Transfer Speed PM3 -> Client = 589824 bytes/s #db# Various #db# MF_DBGLEVEL.............1 #db# ToSendMax...............-1 #db# ToSendBit...............0 #db# ToSend BUFFERSIZE.......2308 #db# Installed StandAlone Mode #db# LF HID26 standalone - aka SamyRun (Samy Kamkar) pm3 --> data tune [=] Measuring antenna characteristics, please wait... ... [+] LF antenna: 72.23 V - 125.00 kHz [+] LF antenna: 39.80 V - 134.00 kHz [+] LF optimal: 72.23 V - 125.00 kHz [+] LF antenna is OK [+] HF antenna: 49.00 V - 13.56 MHz [+] HF antenna is OK [+] Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz. ```
Additional context In testing I have also observed that placement of the target antenna coil appears to be far more sensitive on the default RDV4 hardware, while the default RDV2 hardware appears to be more forgiving in alignment and distance of the target T5577 tag. I do not know if this is something that can be mitigated in software or if it is a limitation of the more compact antenna design used in RDV4.