oeyek / proxmark3

Automatically exported from code.google.com/p/proxmark3
GNU General Public License v2.0
0 stars 0 forks source link

weird usb resets resulting in failed proxmark commands #33

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. connect proxmark3
2. start client/proxmark3
3. issue hf 14a snoop
4. issue hf 14a list

What is the expected output? What do you see instead?

I expected to see the output of the buffer, however what I get is this:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 517-unclean 2012-01-16 14:28:58                 
#db# os: svn 517-unclean 2012-01-16 14:28:59                 
#db# FPGA image built on 2009/12/ 8 at  8: 3:54                 
proxmark3> hf 14a snoop
proxmark3> hf 14a list
write failed: No error!
Trying to reopen device...

Connected units:
    1. SN:  [004/087]

Connected units:
    1. SN:  [004/087]

Connected units:
    1. SN:  [004/087]
...
This is repeated until the watchdog triggers and the device is restarted.

dmesg tells me:
[30254.160613] usb 4-1.2: new full speed USB device number 85 using ehci_hcd
[30254.232483] usb 4-1.2: device descriptor read/64, error -32
[30254.408288] usb 4-1.2: device descriptor read/64, error -32
[30254.528373] hub 4-1:1.0: unable to enumerate USB device on port 2
[30255.183285] usb 4-1.2: new full speed USB device number 87 using ehci_hcd
[30260.269540] usb 4-1.2: New USB device found, idVendor=9ac4, idProduct=4b8f
[30260.269543] usb 4-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[30260.269545] usb 4-1.2: Product: ProxMark-3 RFID Instrument
[30260.269546] usb 4-1.2: Manufacturer: J. Westhues
[30260.269548] usb 4-1.2: SerialNumber: ChangeMe
[30260.271023] generic-usb 0003:9AC4:4B8F.003A: hiddev0,hidraw3: USB HID v1.00 
Device [J. Westhues ProxMark-3 RFID Instrument] on usb-0000:00:1d.0-1.2/input0
[30294.911904] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110
[30301.902818] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110
[30308.893848] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110
[30315.884776] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110
[30322.875665] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110
[30329.866700] usb 4-1.2: usbfs: USBDEVFS_CONTROL failed cmd proxmark3 rqt 128 
rq 6 len 255 ret -110

I'm trying this on Linux x64 3.0.1, libusb 1.0.9.

On a side note... Before a snoop command is issued, this works:
proxmark3> hf 14a list
recorded activity:          
 ETU     :rssi: who bytes          
---------+----+----+----------- 

And a similar problem is visible using card emulation:
proxmark3> hf 14a sim
Emulating 14443A TAG with UID 0               0          
write failed: No error!
Trying to reopen device...

Connected units:
    1. SN:  [004/089]
....

Let me know if I can provide any further information that helps in tracking 
this issue down...

Original issue reported on code.google.com by terrence...@googlemail.com on 16 Jan 2012 at 6:05

GoogleCodeExporter commented 8 years ago
I am having the same issue:

root@logic:~/proxmark3-read-only/client# gdb proxmark3
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /root/proxmark3-read-only/client/proxmark3...done.
(gdb) r
Starting program: /root/proxmark3-read-only/client/proxmark3 
[Thread debugging using libthread_db enabled]

Connected units:
    1. SN: ChangeMe [002/015]
[New Thread 0xb7fe1b70 (LWP 3836)]
[New Thread 0xb77e0b70 (LWP 3837)]
proxmark3> hf 14a snoop
proxmark3> read failed: could not detach kernel driver from interface 0: No 
data available(-19)!
Trying to reopen device...

proxmark3> hf 14a list

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7fe1b70 (LWP 3836)]
0x00133f46 in ?? () from /lib/libusb-0.1.so.4
(gdb) bt
#0  0x00133f46 in ?? () from /lib/libusb-0.1.so.4
#1  0x08061628 in SendCommand (c=0xb7fe036c) at proxusb.c:45
#2  0x0804fb7e in GetFromBigBuf (dest=0xb7fe0430 "", bytes=1920) at data.c:31
#3  0x08052b2d in CmdHF14AList (Cmd=0x8271813 "") at cmdhf14a.c:31
#4  0x080609fe in CmdsParse (Commands=0x806f540, Cmd=0x827180f "list") at 
cmdparser.c:56
#5  0x08052f84 in CmdHF14A (Cmd=0x827180f "list") at cmdhf14a.c:240
#6  0x080609fe in CmdsParse (Commands=0x806f4a0, Cmd=0x827180b "14a list") at 
cmdparser.c:56
#7  0x08052787 in CmdHF (Cmd=0x827180b "14a list") at cmdhf.c:48
#8  0x080609fe in CmdsParse (Commands=0x806fc60, Cmd=0x8271808 "hf 14a list") 
at cmdparser.c:56
#9  0x08060ec7 in CommandReceived (Cmd=0x8271808 "hf 14a list") at cmdmain.c:89
#10 0x0804bad9 in main_loop (targ=0xbffff6e4) at proxmark3.c:117
#11 0x0017bd31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#12 0x010d20ce in clone () from /lib/i386-linux-gnu/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb) 

Original comment by mike.gui...@gmail.com on 4 Feb 2012 at 12:38

GoogleCodeExporter commented 8 years ago
Some more info:

(gdb) info reg
eax            0xb7fe036c   -1208089748
ecx            0xb7fe02a8   -1208089944
edx            0x40 64
ebx            0x138ff4 1282036
esp            0xb7fe01e0   0xb7fe01e0
ebp            0xb7fe036c   0xb7fe036c
esi            0x0  0
edi            0x1  1
eip            0x133f46 0x133f46
eflags         0x10286  [ PF SF IF RF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51
(gdb) disass 0x133f46
No function contains specified address.
(gdb) disass 0x133f46
No function contains specified address.
(gdb) x/s 0xb7fe036c
0xb7fe036c:  "\a\002"
(gdb) x/s 0xb7fe0430
0xb7fe0430:  ""
(gdb) x/s 0x806f540
0x806f540 <CommandTable>:    "aJ\006\b\220'\005\b\001"
(gdb) 

Original comment by mike.gui...@gmail.com on 4 Feb 2012 at 12:39

GoogleCodeExporter commented 8 years ago
I could supply someone with a SSH login to do some testing as well....

Original comment by mike.gui...@gmail.com on 4 Feb 2012 at 3:52

GoogleCodeExporter commented 8 years ago
I'm having the same crash.  Fixed the segv by doing this.

if(devh) change to

if(devh && ret != -110)
{
  // usb_close(devh)
  // devh = NULL;
  CloseProxmark();
}

This fix does not however, make hf 14a snoop / list function.  It just removes 
the segv.  -110 seems to indicate we are already detached, so calling usb_close 
gets told to detach something that doesn't exists, causing the crash. (it seems)

After that the proxmark continues to have other problems that I haven't figured 
out yet.

Original comment by kmx26...@gmail.com on 26 Feb 2012 at 7:17

GoogleCodeExporter commented 8 years ago
So I've spent a lot of time debugging this, jtag etc.  It seem to be related to 
Linux usbcore.  If i keep the bus busy by plugging in another USB device on the 
same usb hub, the prox works all the time.

Additionally, works great on OSX without any problems, but same issue as above 
on Windows 7.

I've tried removing autosuspend and numerous other usbcore parameters.  But 
simple solution is to just plugin another USB device on the same hub.

Original comment by kmx26...@gmail.com on 9 Mar 2012 at 8:40

GoogleCodeExporter commented 8 years ago
Reworked client/ dir to use libusb-1.0.  Patch attached. based on svn r528

Known issues:
cli no longer works. Not sure what I broke, this code looks so simple.
Support for picking a proxmark if you have 2 or more was removed.  I only have 
one so couldn't test this.  Will add this back in shortly

Overview
Pretty much just reimplements proxusb.c/h using 1.0 calls.  However, I added 
support for using handles if you have them, instead of a global devh.  So 
required updating all the dependent calls.  

Seems to be pretty stable, and no more crashes like the above.  

Original comment by kmx26...@gmail.com on 12 Mar 2012 at 2:22

Attachments:

GoogleCodeExporter commented 8 years ago
Attached is a patch that applies to current trunk. 

I think it would be critical to upgrade the codebase against libusb 1.0. Who 
can look into it? Looking at development activity, it seems that proxmark3 has 
lived its life and is slowly getting ready for being retired?

Original comment by martin.paljak on 16 Jan 2013 at 2:51

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by verdult on 8 Mar 2013 at 8:42