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
I have previously been able to simulate mifare classic 1K cards, having written a procedure for b486. I recently updated to the latest build from Git:
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: master/v1.1.0-2-g991f13f-suspect 2014-07-25 05:48:23
#db# os: master/v1.1.0-2-g991f13f-suspect 2014-07-25 05:51:23
#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
I can read the keys and create the eml file, both using my old procedure (hf mf mifare, hf mf nested 1 0 a ffffffffffff t, hf mf ecfill A, hf mf sim) and using the mifare_autopwn script.
When I either read the card contents straight from the card, or eloading from an eml, and simulate the card (hf mf sim), then present the antenna to the reader, I see the following in console:
uid:N/A, numreads:0, flags:0 (0x00)
#db# 4B UID: 3a10bfbc
#db# Reader authenticating for block 4 (0x04) with key 0
#db# Reader authenticating for block 4 (0x04) with key 0
#db# Reader authenticating for block 4 (0x04) with key 0
... spammed to the console as long as I hold the antenna in range, with no recognition by the reader. On my card sectors 0, 1, and 15 contain interesting data.
Any suggestions?
Thanks,
tjhowse.
Offline
Did you see any error/debug messages during ecfill?
Can you please provide the trace (output of hf 14a list) after hf mf sim.
Offline
There were no errors shown during ecfill, just "#db# EMUL FULL SECTORS FINISHED", with hf mf dbg 4. If the card isn't in range this step fails, so it is actually doing some communication.
...
#db# Reader authenticating for block 4 (0x04) with key 0
#db# Reader authenticating for block 4 (0x04) with key 0
#db# Emulator stopped. Tracing: 0 trace length: 2994
Recorded Activity
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data
-----------|-----------|-----|--------
0 | 1056 | Rdr | 26
2356 | 4724 | Tag | 04 00
15104 | 17568 | Rdr | 93 20
19124 | 25012 | Tag | 3a 10 bf bc 29
40320 | 50848 | Rdr | 93 70 3a 10 bf bc 29 cc 6d
52404 | 57076 | Tag | 08 b6 dd 00
162688 | 167456 | Rdr | 60 04 d1 3d
210228 | 214964 | Tag | 01 02 03 04
274048 | 275104 | Rdr | 26
276404 | 278772 | Tag | 04 00
289152 | 291616 | Rdr | 93 20
293172 | 299060 | Tag | 3a 10 bf bc 29
314368 | 324896 | Rdr | 93 70 3a 10 bf bc 29 cc 6d
326452 | 331124 | Tag | 08 b6 dd 00
436736 | 441504 | Rdr | 60 04 d1 3d
495284 | 500020 | Tag | 01 02 03 04
...This output was from an old version circa 2012. I reverted to that in an attempt get it working, but it was exactly the same.
I'm beginning to think there might be something wrong with my hardware.
Thanks,
tjhowse.
Offline
This output was from an old version circa 2012. I reverted to that in an attempt get it working, but it was exactly the same.
Definitely not. The timing output has been added to hf 14a list much later. I therefore assume that the trace is from a current version (nobody likes to debug 2 years old revisions anyway).
Your (simulated) tag responds correctly to the authentication request (60 04) with the (not very random) tag nonce (01 02 03 04). However, the reader doesn't react to that - it should send nr/ar but instead starts over with a REQA (26) again. There is a noticeable delay between the authentication request and the reply with the tag nonce (210228 - 167456 = 42772 Carrier Clock Cycles @ 13.56 MHz, = 3.15ms). Its even more on the second try. According to Mifare specs this should be < 1ms and I would assume that your reader cares about the spec and times out.
If this assumption holds, then we would need to more than triple the simulation speed... let me have a closer look at it.
I'm beginning to think there might be something wrong with my hardware.
I don't think so. The trace shows that the communication between reader and PM3 is OK.
Offline
I can easily imagine restoring the wrong proxspace backup, one in which I'd updated the SVN but not anything else, or something like that. That would explain the version problem.
In any case I'm using the latest everything from Git currently.
For reference I'm trying to authenticate to a BQT Solutions BT900 / DF900. This was working roughly a year ago, with the (then) current bootrom/fpga/os/client.
Thanks,
tjhowse.
Offline
Can't edit my post, it seems. The last time I am certain I was able to emulate a card on this system was 2012-11-05.
Thanks,
tjhowse.
Offline
I can confirm that the PM3 definitely used to work with BQT readers and cards. I did not take note of the revision I used when I did this work.
Offline
The timing issue was caused by the debug messages ("Reader authenticating for block...") themselves. It simply took too much time to send them to the client via USB.
I fixed it by changing the required debug level to 4 (can be set with hf mf dbg 4) to print those and similar messages. Pushed to github master. Please give it a try.
Offline
Updated to github master. Works perfectly.
Thanks very much for your contribution piwi! You make open source great.
Thanks,
tjhowse.
Offline
Pages: 1