search

iceman1001 / proxmark3

[Deprecated] Iceman Fork, the most totally wicked fork around if you are into proxmark3
http://www.icedev.se/pm3.aspx
GNU General Public License v2.0
464 stars 116 forks source link

hf search command is broken #226

Closed jmichelp closed 5 years ago

jmichelp commented 5 years ago

When I flash my brand new pm3-rdv40 with iceman's fork (compiled from git HEAD), hw tune reports that the HF antenna works (more than 40V IIRC and 70V for the LF) but when I put a tag in front of the antenna and run hf search, all I receive is an error message about a communication timeout and after a while I got the prompt back and the search says that there's no tag present. If I run hf 14a info it doesn't find any tag. I tried with a DESFire EV1 and an iClass tag that I had at hand.

But then if I flash the firmware from the official repo (same thing, compiled from git HEAD), then everything works as expected: the tags are found and the hf search command doesn't show any error, finds the tag quickly and returns.

iceman1001 commented 5 years ago

Don't know about your distances between antenna and tag I tested 14b, 14a, 15, iClass & Defire tags without problem just now on a RDV40

`pm3 --> hf sea [!] timeout while waiting for reply.

[-] no known/supported 13.56 MHz tags found

pm3 --> hf sea [!] timeout while waiting for reply. UID: D0 02 19 54 20 C4 8E A3 MFG: 02, ST Microelectronics SA France Chip: 06, SRI512

[+] Valid ISO14443-B Tag Found

pm3 --> hf sea UID : 04 9D BA 42 A2 3E 80 ATQA : 00 44 SAK : 08 [2] TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1 | 1k Ev1 MANUFACTURER : NXP Semiconductors Germany [=] proprietary non iso14443-4 card found, RATS not supported [=] Answers to magic commands: NO [+] Prng detection: HARD

[+] Valid ISO14443-A Tag Found

pm3 --> hf sea UID : E0 04 01 50 76 C1 D0 6A TYPE : NXP(Philips); IC SL2 ICS20/ICS21(SLI) ICS2002/ICS2102(SLIX)

[+] Valid ISO15693 Tag Found

pm3 --> hf sea [!] timeout while waiting for reply. CSN: 96 55 A4 00 F8 FF 12 E0 CC: 4E FF FF FF FF FF FF FF Mode: Application [Locked] Coding: ISO 14443-2 B/ISO 15693 [+] Crypt: Secured page, keys not locked [!] RA: Read access not enabled Mem: 2 KBits/2 App Areas (31 * 8 bytes) [1F] AA1: blocks 06-12 AA2: blocks 13-1F OTP: 0xFFFF

KeyAccess: Read A - Kd or Kc Read B - Kd or Kc Write A - Kc Write B - Kc Debit - Kd or Kc Credit - Kc App IA: FF FF FF FF FF FF FF FF [+] : Possible iClass (legacy tag)

[+] Valid iClass Tag (or PicoPass Tag) Found

pm3 --> hf sea UID : 04 41 84 A2 F3 39 80 ATQA : 03 44 SAK : 20 [1] TYPE : NXP MIFARE DESFire 4k | DESFire EV1 2k/4k/8k | Plus 2k/4k SL3 | JCOP 31/41 MANUFACTURER : NXP Semiconductors Germany ATS : 06 75 77 81 02 80 02 F0

[+] Valid ISO14443-A Tag Found `

jmichelp commented 5 years ago

I will try again but I tried 5 or 6 times, changing the distance between the tag and the reader without any luck. And when I flashed the official repo, it worked on th first try.

iceman1001 commented 5 years ago

... have you tried RVD40, https://github.com/RfidResearchGroup/proxmark3 ?

TomHarkness commented 5 years ago

This sounds like a client / device communication issue. What OS are you on? I had a similar issue with some very cheap USB-C --> USB adaptors on my macbook pro.

iceman1001 commented 5 years ago

what's your output from

 hw status
 hw version
 hw tune
jmichelp commented 5 years ago

No USB-C converter were being used in my case (BTW it would have been a great improvement for rdv40 to put a USB-C plug as it would have allowed the proxmark3 to draw more current -- but that's another topic). I tested on Linux and OS X. In both case it was connected to a USB2 port.

It took me a while before being able to test again because flashing the firmware stopped in the middle. This could have been nothing if I hadn't mistakenly used make flash-all instead of make flash-os. So it took me a while to solder a connector to the JTAG connector and recover the bootloader as it was also giving errors when writing to the memory.

Good news: hf search worked today. But it seems to me that with official firmware the pm3 gets more sensitivity. With iceman fork I need several tries before finding the sweet spot for placement.

The slowness of the command as well as the flashing issues I encountered (where it stops in the middle of the operation because the pm3 reboots) were both due to ModemManager. Even though the udev rules were there, something might have changed in the configuration or behavior of this service because when running dmesg I saw error messages like failed to set dtr/rts line and then a USB disconnect event. Stopping ModemManager solved the issue. I will try to put a USB analyzer and see what's happening there. Maybe there's something missing on the USB descriptor or a request is sent to the pm3 which doesn't know how to handle it.

And for reference the issue I encountered with OpenOCD flashing on OS X seems to be due to a lack of power. I was assuming that powering the pm3 through it's USB connector would have been enough but it was flaky and I had to retry several times. As soon as I put a bit of power on the 3.3V pin of the JTAG connector (which alone was not enough), it worked perfectly.

iceman1001 commented 5 years ago

I suggest that you try the repo:

https://github.com/RfidResearchGroup/proxmark3

It is the new default for RDV40 dedicated and has a lot of fixes for it already.

Bad usb cables? or flaky usb power.. yup, that will definitly screw things up.

The ARM doesn't support USB-3, so we never considered switching connectors.

jmichelp commented 5 years ago

I cloned the repo and will give it a try. But I want to have the USB analyzer to record if there's a change of behavior between the 3 repos (rdv40, iceman, and official) with regards to the ModemManager issue I ran into (and also compare with OS X). I guess I won't be the only one to potentially brick (in the way that JTAG is the only way to go) the pm3 because of this so if we can fix once for all the CDC implementation it's a plus.

I was using the nice silicon USB cable that was provided with the rdv40. If it's a bad cable, I might not be the one to blame ;-)

The big advantage of USB 3.1 is that the power negotiation is separated from the protocol. So AFAIK you can have a USB2 device with an USB-C connector but you need to add 1 chip for the power negotiation. And then you're good to draw 1A on 5V if that's what you need.

iceman1001 commented 5 years ago

1% chance of cable fault :( Some people like the blame game, who can blame them? Try another cable if you have it, just to make sure.

jmichelp commented 5 years ago

I was joking. I know manufacturing issues happens and to be honest having a bad USB cable is nothing (even though I kinda like the one that is provided!). And I already tried also with another cable: it made no difference.

iceman1001 commented 5 years ago

dang, and here I thought that would be a quick fix....

turning of the modemmanager, that should have enabled you to flash.. Don't know how you messed up bootrom... It only happens if you interrupt (ctrl-c) the flasher during the writing sequence... takes practice.

jmichelp commented 5 years ago

Sorry if it wasn't clear in my previous messages. The bootrom got screwed because I typed make flash-all instead of make flash-os. Combined with ModemManager problem, it basically stopped in the middle of the bootrom and made the proxmark reboot.

The power issue I ran into while trying to restore the bootrom was happening later with a mac laptop. It took me a while to understand it was lacking a few milliamps to stabilize the JTAG. But once the bootrom was back, I also experienced again on mac the flashing operation being interrupted. That's why I'll try to dig deeper and understand what's causing this because it might happen to others.

iceman1001 commented 5 years ago

don't get me wrong, I am glad you are trying to solve this mystery. I can't help you, no macbook dude.

make flash-all should normally work good. oneliner, hardcoded comport

update.sh should work with trying to find comport

TomHarkness commented 5 years ago

What model of Mac are you using? I've been testing on the latest MBP i7 purchased a few weeks back. 2014 MBP and a 2012 MacMini that's specced out. No issues like this EVER, its so strange!

TomHarkness commented 5 years ago

update.sh is not working on OS X. Working on a fix for it.

iceman1001 commented 5 years ago

update.sh is for linux based OS. Its not expected to work on MacOS, but if you make a version of it that works that would be great

joanbono commented 5 years ago

Hi @iceman1001 @TomHarkness , just opened #230 for that. I commited the one I was using to update my pm3.

TomHarkness commented 5 years ago

We should be able to make one script for both OS with OS detection. Look over at the RDV4 fork at:

https://github.com/RfidResearchGroup/proxmark3/issues/6

I have only a few issues to resolve with that and one syntax issue. Maybe you could help make a universal script?

joanbono commented 5 years ago

Sure @TomHarkness , it will take me 5 minutes to do that. @iceman1001 are you OK with that? I think it's a good idea.

iceman1001 commented 5 years ago

I am fine with it. This issue was about hf search and not about the update scripts. @jmichelp What is your status?

jmichelp commented 5 years ago

Answering @TomHarkness question: MBP 2014 running OSX 10.13.6 (High Sierra). I suspect that I have a piece of software or a kext that is interfering with the pm3 on mac. I will try to dig it. As for my original issue, the slowness was due to ModemManager under Linux. hf search works. I just have the feeling that it's less sensitive than on the official repo. I'll have to do more test but I'm really busy nowadays. Closing the issue on my side as it's working.