Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Hi,
I'd like to sniff RFID communication. Everything works fine, except the sample time window:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: master/v1.1.0-24-g92d255d-suspect 2014-10-14 21:38:36
#db# os: master/v1.1.0-24-g92d255d-suspect 2014-10-14 21:38:38
#db# HF FPGA image built on 2014/ 6/19 at 21:26: 2
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> hf 14a snoop
#db# COMMAND FINISHED
#db# maxDataLen=6, Uart.state=0, Uart.len=3
#db# traceLen=2997, Uart.output[0]=000000a2
proxmark3>
The communication is not even halfway and still active though the proxmark finishes. Is the buffer length limited? Can you help me with tips 'n tricks for tracing the whole conversation?
Thanks,
Jeroen
Offline
Indeed, the trace buffer is limited to 12000 bytes which is already a good portion of the available 64K SRAM. And this is not only for traced data but for timing information as well. It is usually enough for a few block reads/writes. You could try hf mf sniff instead (if you are sniffing communication with a Mifare card) which records essential information only.
From a developers point of view there is a lot of room for improvement as well:
the trace buffer isn't used very efficiently - especially by the "end time" stamps which I had implemented some time ago.
16KBytes are reserved as DMA buffer which is a huge waste of available memory and could be better used for the trace buffer. In your example 6bytes ("maxDataLen=6") would have been enough.
all buffer sizes are defined in sizeof(uint32_t) units but used as sizeof(uint8_t) units, i.e. only a quarter of the reserved buffer memory is used.
Offline
Indeed, the trace buffer is limited to 12000 bytes which is already a good portion of the available 64K SRAM. And this is not only for traced data but for timing information as well. It is usually enough for a few block reads/writes. You could try hf mf sniff instead (if you are sniffing communication with a Mifare card) which records essential information only.
From a developers point of view there is a lot of room for improvement as well:
the trace buffer isn't used very efficiently - especially by the "end time" stamps which I had implemented some time ago.
16KBytes are reserved as DMA buffer which is a huge waste of available memory and could be better used for the trace buffer. In your example 6bytes ("maxDataLen=6") would have been enough.
all buffer sizes are defined in sizeof(uint32_t) units but used as sizeof(uint8_t) units, i.e. only a quarter of the reserved buffer memory is used.
Thanks for the detailed feedback.
Are you aware of devices that can monitor longer conversations / perform continuously monitoring for a normal price tag? Thanks!
Cheers,
Jeroen
Offline