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.
Pages: 1
Hi
I flashed pm3-bin-840 in my proxmark3.(Before, I Checkout svn 840 Version and make with Mingw32(Proxmark Environment, Windows Version))
anyway, I had an error occurs when i use "hf 14a snoop"
hw ver
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 842 2014-02-02 04:16:42
#db# os: svn 842 2014-02-02 04:16:51
#db# FPGA image built on 2013/11/19 at 18:17:10
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
hf 14a snoop
#db# blew circular buffer! dataLen=0x191
#db# maxDataLen=191, Uart.state=0, Uart.byteCnt=0
#db# Uart.byteCntMax=20, traceLen=0, Uart.output[0]=00000000
Can I fix the error?
Thanks.
Offline
Try latest r842.
Offline
I flashed svn-840, but same results...
hf 14a snoop
#db# blew circular buffer! dataLen=0x191
#db# maxDataLen=191, Uart.state=0, Uart.byteCnt=0
#db# Uart.byteCntMax=20, traceLen=0, Uart.output[0]=000000f0
hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
svn 835 is not have problems, but svn 836 ~ 84X versions have same problem.
How can i fix this error???
Offline
I flashed svn-840, but same results...
Maybe you mean r842 ?
Offline
yes.
i flashed 830~84X(Recent Version)
the 836~84X is occur same error.
How can i fix this error??
I used windows 8 64bit, and mingw32(Proxmark3 Environment)
Offline
I think this is dued to holiman recent changes, I hope he will read this thread and fix that.
Offline
I don't really think this is on me .. I haven't touched the snoop-stuff. However, there's another report of malfunctioning snoop here: http://www.proxmark.org/forum/viewtopic.php?pid=9222#p9222 , however, that one does not seem to be exactly the same.. I'll take a quick look though, but I don't have anything much to snoop on...
Offline
I get the same error
proxmark3> hf 14a snoop
#db# blew circular buffer! dataLen=0x191
#db# maxDataLen=191, Uart.state=0, Uart.byteCnt=0
#db# Uart.byteCntMax=20, traceLen=0, Uart.output[0]=00000098
However, looking at the code :
if(dataLen > 400) {
Dbprintf("blew circular buffer! dataLen=0x%x", dataLen);
goto done;
}
It appears that we're getting 0x191 bytes, which is 401 in decimal. I don't know where the value 400 comes from, but something somewhere appears to have started using an extra byte, or something like it. Don't have time to test it right now, but if I had I'd test to change 400 to 401 and see what happens..
Offline
Blush! The sniffing/snooping problems are most probably a result of my changes to the Manchester-Decoder in SVN839 and has nothing to do with the value 400 (although I agree to holiman that it is arbitrary - should be DMA_BUFFER_SIZE). I have broken it - let me fix it.
Offline
Sorry holiman, I was not pointing the finger on you
Thank you piwi, waiting for r843 !
Offline
Blush! The sniffing/snooping problems are most probably a result of my changes to the Manchester-Decoder in SVN839 and has nothing to do with the value 400 (although I agree to holiman that it is arbitrary - should be DMA_BUFFER_SIZE). I have broken it - let me fix it.
I believe you are right. I posted on your commit threat that the snoop was broken (SVN 839: increased ISO14443A reading distance and anticollision post #12)
Be aware thought, that in my case I did not get any error about the buffer. It just ended with no data.
I am however on a linux machine, so that may make a difference.
Offline
In fact there are two issues I have to solve.
I "simplified" the Manchester Decoder too much. As of SVN839 it is not able any more to reliably sync on external readers' timing (as is required with sniffing, snooping or simulating). This is the reason that you get no data at all. Good news: I have a working solution for that one.
I am in the middle of implementing better tracing capabilities. "hf 14a list" will show meaningful timing information, i.e. start of transfer, end of transfer, and the waiting times (frame delay times) between consecutive transfers. This added some overhead to Miller Decoder and Manchester Decoder. During snooping/sniffing the FPGA delivers both reader and tag data at once (i.e. we have the double data rate compared to other operations) plus we need to run both Miller Decoding and Manchester Decoding at the same time. As I stated above, "hf 14a snoop" can cope with that but the little additional logic in "hf mf sniff" to interprete the sniffed data is the piece which breaks the timing, i.e. data is delivered faster than it can be consumed which results in the circular buffer overflow. I am fishing for a few microseconds...
Offline
Hello! Any news on having the snoop command running again properly?
Thanks guys!
Offline
Please hold fire. I have a working revision but would like to do some more testing and delete quite a few dbprintf()'s. BTW: there is life without a Proxmark.
Offline
Please hold fire. I have a working revision but would like to do some more testing and delete quite a few dbprintf()'s. BTW: there is life without a Proxmark.
haahha, no problem @piwi! I'm asking because I'm going to deliver a little workshop and I wanted to show this functionality and don't want to switch between svn versions, that's all.
keep us posted when it's fixed.
thanks for all your hard work here.
Offline
Piwi: Would it be possible to test your new code even if you still feel you need to test it more and clean it up?
As far as I understand with the commit where you bugged the snooper (no blame here), the sensibility should be much better. I am in a situation where I am having problems with lost communication data with snooping on a system where I should check for and demonstrate bad security.
It looks very much like a sensitivity problem.
So I am very much hoping your new code will make this better.
As I should make this demonstration at latest tomorrow I thought if it would be possible to get hand on your latest code somehow. I do not expect it to be cleaned up and can live with debug messages.
Please do not take this as any kind of "demand". I have done some open source development myself and understand it is your time and you have a of other things in your life (at least I hope that ;-) )
Thank you for your hard work,
Jesper
Offline
OK. Try r845 and see http://www.proxmark.org/forum/viewtopic … 9721#p9721.
Don't expect too much from the increased sensitivity. If the system you are auditing works with their "normal" cards it should also work with the PM - even without the increased sensitivity.
Offline
I have tried the new code with the snoop command and it works again :-)
However I still have problems with lost data (as you predicted).
I am sorry if this gets too much of topic for this thread. If this is a problem just let me know where to post instead.
I am not able to get easily to the system I audit (it is in another country), but I have made a little test setup.
Using an acr122 usb device I read a card with nfc-mfclassic from libnfc (I already have the keys for this card). Then put the proxmark3 antenna in between to snoop.
It is very clear I do not get all data as when I do my hf 14a list I see places where I get e.g. 2 tag lines after each other with no interleaving reader line.
Another observation is that if I align the antenna with the card, I loose a lot of data, while if I turn it to be 45-90 degrees off I get much better data.
Any suggestion to what the problem is and/or what I should do to make it work?
Also is there any proxmark command to save the full communication dump from a snoop on the pc?
Offline
@sax, try the hf mf sniff command if it's a mifare classic type of card.
Offline
Thank you, at first hand it looks a lot better.
Going to try to get a communication dump out of libnfc now to make a full verification.
Getting back with the result when I manage to modify libnfc for that.
So it looks like snoop is working far worse than sniff for some reason.
What are the reason for 2 different commands to do the same anyway?
Are there a simple way to save the communication dump to a file or do I need to cut it out of my proxmark log?
Offline
hey @sax, the 14a snoop command sniffs a "generic" 14a comm. The other one is for mifare (classic?) specific cards. I'm not sure about this because tbh I dind't that part of the code, I'm just guessing.
Regarding your last question, copy&paste? try in "data" section., maybe you'll find something there to save it.
good luck!
Offline
So it looks like snoop is working far worse than sniff for some reason.
It doesn't - it only looks like. hf mf sniff "interpretes" the sniffed data and simply throws away data it cannot interprete.
What are the reason for 2 different commands to do the same anyway?
Because Mifare is different from generic ISO14443a. It has the crypto and proprietary commands to read and write sectors. hf mf sniff interpretes this data and even decodes crypted data if you want.
Are there a simple way to save the communication dump to a file or do I need to cut it out of my proxmark log?
Use the l or d option with hf mf sniff.
Offline
I have now tried several things and still have trouble getting full dumps.
I have found out the quality of the dump is very dependend on the precise placement of the antenna. Both in regards to orientation and distance to card/reader.
I use the antenna you can buy from http://proxmark3.com/item_hfapcb.html
One problem with this antenna is the switch+plug witch limits the placement possibilities when sandwiched between reader and card for sniffing.
Do any of you people use that antenna or do you use homemade optimized antennas?
Should I make an antenna like described in http://code.google.com/p/proxmark3/wiki/Antennas for getting better results?
Offline
Let's start from the beginning.
Please post the output of hw ver and hw tune
Offline
Sorry for the long response time, I have been busy with something else.
I have tried several versions of the firmware. Right now I am on rev 848 (flashing arm+fpga together).
Also I always start a "session" by doing a hw tune while holding the antenna in free air.
After reading up on antennas, I have realized that hw tune result is actually a little low. On the wiki it is stated it should be >10V. I have never had it that high.
I have tried to turn the switch on the antenna, but then I get down in the 5-6V range, so I have it at the best setting.
I just thought the antenna bought together with the proxmark would fit and did not give it further thought. My fault.
Here is my output as requested:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 709 2013-05-02 09:37:12
#db# os: svn 848-unclean 2014-03-07 11:23:15
#db# FPGA image built on 2014/02/25 at 07:43:59
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> hw tune
#db# Measuring antenna characteristics, please wait...
#db# Measuring complete, sending report back to host
# LF antenna: 0.00 V @ 125.00 kHz
# LF antenna: 0.00 V @ 134.00 kHz
# LF optimal: 0.00 V @ 12000.00 kHz
# HF antenna: 8.77 V @ 13.56 MHz
# Your LF antenna is unusable.
Offline
Pages: 1