RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
3.72k stars 998 forks source link

battery / fpc / swapping between #859

Open iceman1001 opened 5 years ago

iceman1001 commented 5 years ago

use case scenario,

  1. hook up device on usb, run 'hf mf sim u 11223344' device is now simulating 1k mifare.
  2. turn on battery
  3. unconnect usb device still runs simulation, readers pics it up.
  4. turn on bt,
  5. from pm3 client, try to connect to pm3 over bt. this will fail, since the sim loop doesn't look for messages over fpc? (usb_valida..) even so, the last command (hf mf sim) was sent as usb, and device will only answer back to that.
doegox commented 5 years ago

Relates to doegox/proxmark-internal#90 doegox/proxmark-internal#96 and doegox/proxmark-internal#76

doegox commented 5 years ago

Not the only issue but USB comm can interrupt sim and hook again because sim looks for BUTTON and usb_poll_validate_length(). So at least we also need to check for USART data to allow sim to be interrupted.

Edit: done

doegox commented 5 years ago

chicken & egg:

Other possibilities:

doegox commented 5 years ago

We still need to smooth all scenarii but for info with last commits now the original use case is working if we change the MF_DBGLEVEL:

[usb] pm3 --> hf mf dbg 0
#db# Debug level: 0          
[usb] pm3 --> hf mf sim u 11223344
[=] Mifare   | 4 byte UID  11 22 33 44            
[=] Options [ numreads: 0, flags: 2 (0x02) ]          
#db# 4B UID: 11223344          

Unplugging USB without quitting client

[!] Communicating with Proxmark3 device failed           
[=] Running in OFFLINE mode. Use "hw connect" to reconnect

[offline] pm3 --> hw connect p /dev/rfcomm0
Port:: /dev/rfcomm0  Baud:: 115200
[=] Using UART port /dev/rfcomm0           
[=] Communicating with PM3 over FPC UART           
[=] PM3 UART serial baudrate: 115200 

[fpc] pm3 --> hw ping
[=] Ping sent          
[+] Ping response received           
iceman1001 commented 5 years ago

hf mf dbg 0, and sim still pushes messages.

#db# 4B UID: 11223344

The idea should also be that once the client connects to device again,
the debug messages from standalone mode should start sending again.

Hard to keep track of all use-cases

doegox commented 5 years ago

yeah but that #db# 4B UID comes immediately before you get a chance to pull USB so that's fine ;)

iceman1001 commented 5 years ago

It should be guarded by MF_DBG_LEVEL > 0... :) It shouldn't always print.

doegox commented 5 years ago

true