Closed jmichelp closed 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 `
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.
... have you tried RVD40, https://github.com/RfidResearchGroup/proxmark3 ?
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.
what's your output from
hw status
hw version
hw tune
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.
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.
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.
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.
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.
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.
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.
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
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!
update.sh is not working on OS X. Working on a fix for it.
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
Hi @iceman1001 @TomHarkness , just opened #230 for that. I commited the one I was using to update my pm3
.
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?
Sure @TomHarkness , it will take me 5 minutes to do that. @iceman1001 are you OK with that? I think it's a good idea.
I am fine with it. This issue was about hf search and not about the update scripts. @jmichelp What is your status?
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.
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 runhf 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 runhf 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.