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
Hello!
I'm dealing with the Mifare simulator but it just refuses every authentication attempt. I've read the code from iso14443a.c but get no clue why it's not working.
I'm using last rev. and an ACR122 as a reader.
My goal is to fully emulate a mfc in stand alone mode, so any help would be very appreciated.
Thanks!
cheers, Moebius.-
Offline
Hi,
old topic, but did it ever come to any conclusion? I haven't looked at simulation before, but I'm having the same problem. I set the debuglevel up a bit, and found this.
proxmark3> hf mf dbg 4
proxmark3> hf mf sim
uid:00 00 00 00
#db# Started. 7buid=0
#db# --> WORK. anticol1 time: 4
#db# --> WORK. anticol1 time: 4
#db# AUTH FAILED. cardRr=ed662b34, succ=be3d8bcc
#db# --> WORK. anticol1 time: 5
#db# --> WORK. anticol1 time: 4
#db# AUTH FAILED. cardRr=70edf922, succ=be3d8bcc
#db# --> WORK. anticol1 time: 4
#db# --> WORK. anticol1 time: 4
#db# AUTH FAILED. cardRr=d37740f9, succ=be3d8bcc
#db# --> WORK. anticol1 time: 5
#db# --> WORK. anticol1 time: 4
#db# AUTH FAILED. cardRr=bdbbedab, succ=be3d8bcc
#db# --> WORK. anticol1 time: 5
#db# --> WORK. anticol1 time: 4
#db# AUTH FAILED. cardRr=b6a98fa1, succ=be3d8bcc
So, there's a mismatch between what the pm3 considers the prng-successor, and what the reader considers to be correct. Excerpt from the code in armsrc/iso14443a.c :
case MFEMUL_AUTH1:{
if (len == 8) {
// --- crypto
//rn_enc = bytes_to_num(receivedCmd, 4);
//cardRn = rn_enc ^ crypto1_word(pcs, rn_enc , 1);
cardRr = bytes_to_num(&receivedCmd[4], 4) ^ crypto1_word(pcs, 0, 0);
// test if auth OK
if (cardRr != prng_successor(nonce, 64)){
if (MF_DBGLEVEL >= 4) Dbprintf("AUTH FAILED. cardRr=%08x, succ=%08x", cardRr, prng_successor(nonce, 64));
cardSTATE_TO_IDLE();
break;
}
Offline
Regarding the previous topic:
http://www.proxmark.org/forum/viewtopic.php?id=1525
I did a "svn diff -r 554:555" and yeah, only the "unused" variables where commented out...
I also looked at it, and the following has been commented out:
cardRn = rn_enc ^ crypto1_word(pcs, rn_enc , 1)
While the return value is unused, the operation crypto1_word(pcs, rn_enc,1) looks like it modifies the cryptostate which pcs is pointing at. So, removing that could have consequences, afaict. Haven't been able to verify if that's the problem though. I'm not all too familiar with crypto/crapto, if anyone has any ideas about this it'd be appreciated.
Offline
hey holiman... I'm going to take a look at it.
Offline
I used the Proxmark3 for the very first time today and stumbled across the same problem. I tried holiman's proposal and restored the call to the crypto1_word() function. Afaict, this works fine for me. Thanks a lot for pointing this out!
Offline
@ff, which reader are you using?
Offline
@ff - strange, it does not work for me
What software version are you using? Could you post the output of 'hw ver' ?
Offline
Here's the version I used:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 839 2014-01-09 17:09:20
#db# os: svn 839-unclean 2014-01-21 14:07:53
#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
I made the change to the source code and flashed the FPGA and OS images (not sure which one was actually necessary). I'm using the SCL3711 reader on a Kali Linux 1.0.6. I verified that the emulation is working by reading the content of the emulated card with nfc-mfclassic.
Offline
Just following this thread as I also have never been able to use the PM3 as an emulator (neither Mifare nor em4x nor HID nor Legic...). Would be nice though, especially for the cards that cannot be cloned like Legic.
Offline
I also got it working now. I had previously used rev 836, without piwis modification. I updated everything now (but kept my modification)
rn_enc = bytes_to_num(receivedCmd, 4);
crypto1_word(pcs, rn_enc , 1);
After that, it seems to work. So, for now, I'll just assume that the problem is solved with r839 + my latest modification, now committed as r840. Please test...
Offline
I'm doing some major work on simulation, found a few issues. One of them was pretty subtle: trace trailer sneaked into rAUTH, so instead of sending 0,1,2,3, to the tag, it sent 4,4,4,4. Why would that happen?
static uint8_t rAUTH_NT[] = {0x01, 0x02, 0x03, 0x04};
...much later...
memset(rAUTH_NT, 0x44, 4);
... end of function...
}
Little known fact (at least, I didn't know it until I looked it up): A static variable inside a function keeps its value between invocations. So the rAUTH was destroyed after one simulation, and never reset. Just a funny bug, I'll commit when I've ironed out the remaining ones.
Offline
Great work man, thank you.
Please also have a look at this issue: http://proxmark.org/forum/viewtopic.php?id=1797
Last edited by asper (2014-01-23 23:26:13)
Offline
Yes, I could also confirm it. I haven't looked at it, but if it is within the FPGA-portion of the pm3, then I'm out of my league...
However, a major update is coming to simulation, with a few new features for hacking mifare-based entry-systems.
Oh, and that thing with static, I wonder if that problem is located in other places aswell...
Offline
I made some major changes, but I'm still having problems. To ensure that the problems did not stem from my changes, I checked out the latest head and flashed it.
#./proxmark3 /dev/ttyACM3
proxmark3> hf mf eclr
proxmark3> hf mf eget 0
data[0]:e6 84 87 f3 16 88 04 00 46 8e 45 55 4d 70 41 04
data[1]:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
data[2]:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf sim
uid:00 00 00 00 , numreads:0, flags:0 (0x00)
#db# Started. 7buid=0
Also, I connected the antenna to a ACR122U reader:
#nfc-mfclassic r a deleteme.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): e6 84 87 f3
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |....................................................nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
!
Error: authentication failed for block 0x0b
[~/tools/proxmark3-martin2/client]
#nfc-mfclassic r a deleteme.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): e6 84 87 f3
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |................................................................|
Done, 64 of 64 blocks read.
Writing data to file: deleteme.mfd ...Done.
As you can see, it first failed at block 0x0b. On a second attempt, without restarting the simulation, it managed to read everything.
Here's the communication, but since the error occurs rather late, it wasn't captured in the:
proxmark3> hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: : 26
+ 270: 0: TAG 04! 00!
+ 800: : 93 20
+ 540: 0: TAG e6 84 87 f3 16
+ 2340: : 93 70 e6 84 87 f3 16 5e 35
+ 380: 0: TAG 08! b6 dd!
+ 10128: : e0 50 bc a5
+ 210: 0: TAG 04
+ 10170: : 26
+ 280: 0: TAG 04! 00!
+ 800: : 93 20
+ 540: 0: TAG e6 84 87 f3 16
+ 2330: : 93 70 e6 84 87 f3 16 5e 35
+ 390: 0: TAG 08! b6 dd!
+ 12950: : 60 3f 81 b2
+ 670: 0: TAG 01 02! 03! 04
+ 780: : 9b 7c bf a8 17 b2 88 13 !crc
+ 950: 0: TAG 56 d7! 20! f5
+ 5428: : 43 06 09 f0 !crc
+ 2570: 0: TAG 96 de! c3! 81 54! 33 34 c2! e2 da! 7f 53! 98 87 f7 a7! 99 19 !crc
+ 8440: : 48 d2 0e 29 !crc
+ 2580: 0: TAG 7f 41! 70! 31 0b 87! 12 66! 8c! 57 ba! 45! 4e d9 d1! 67 b3! 47! !crc
+ 8380: : 3a c6 24 4e !crc
+ 2570: 0: TAG 49 52! a8! 19 9b bb! 31 33! 3b a9! 65! c5! a5! 21! b5 41! d1 8c! !crc
+ 8328: : 52 b2 cc c1 !crc
+ 2570: 0: TAG a8! 67 6e! 21! be ed 63! ce! b0! 59! 8e d6! 43 cc! 92! 49 23! 59! !crc
+ 10520: : d9 81 a1 cc !crc
....
I stopped the simulation, and did it again:
#nfc-mfclassic r a deleteme.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): e6 84 87 f3
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
!
Error: authentication failed for block 0x3f
This time it failed on block 0x3f. Which means that it should fit into the trace-buffer.
proxmark3> hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: : 26
+ 270: 0: TAG 04! 00!
+ 810: : 93 20
+ 540: 0: TAG e6 84 87 f3 16
+ 2340: : 93 70 e6 84 87 f3 16 5e 35
+ 380: 0: TAG 08! b6 dd!
+ 10068: : e0 50 bc a5
+ 210: 0: TAG 04
+ 10120: : 26
+ 280: 0: TAG 04! 00!
+ 800: : 93 20
+ 550: 0: TAG e6 84 87 f3 16
+ 2320: : 93 70 e6 84 87 f3 16 5e 35
+ 390: 0: TAG 08! b6 dd!
+ 12950: : 60 3f 81 b2
I can keep going, sometimes it works, other times:
Error: authentication failed for block 0x33
or
Error: authentication failed for block 0x37
It appears to be pretty random. I intentionally did not use 'hf mf dbg 4' or anything similar, because I want to rule out the possibility that USB-communication causes delays within the pm3 which makes it miss data in the communication with the reader.
So, if anyone has a pm3 and a reader, could you please help me troubleshoot this same scenario? Just 'hf mf eclr', 'hf mf sim' and read with 'nfc-mfclassic r a deleteme.mfd'. It'd be interesting to see if this has always been an issue, or if it is a recent development.
Offline
I think I've found the solutions now, there are a couple of bugs. I'll try to commit separate patches for each one.
* The trace buffer was not cleared correctly in the simulator.
* Too much USB debugging causes failures due to timeouts.
* 'static'-problem with comprimised atqa isn't fixed in head.
Offline
I've now added r841/r842. It fixes most issues with simulation, but the thing is that I also today had to return my borrowed reader, so until I get my second pm3 (via gaucho) or gets another one, I am not able to test the simulation-stuff anymore. So, this is a call for testers...
Changes:
- Now supports 4-byte or 7-byte UID from commandline (earlier, it said it did take UID from cmdline, but it actually ignored it)
- Now saves to tracebuffer ok, was broken since a while back.
- Bug with corrupted ATQA fixed.
- Support for interactive mode, useful when invoked from scripts.
- Support for 'quit after N reads', also useful in scripts. Tells the simulator to quit simulating after the reader has read N blocks. This can be used to simulate a series of cards with different content via scripting (more on that later)
- Support for reader-only-attack. I haven't tested this, I just implemented it today, and am not able to test... Someone, please test it, I'd like to know if it works It's supposed to give you the command line parameters on how to invoke
I think that's mostly it. All testing and feedback appreciated, esp since I'm currently unable to test it.
Offline
Hi holiman, is this simulate command example correct: hf mf sim u 00000000 n 1 i x ? (I am asking this because I am improving the Windows GUI interface).
Offline
Asper, yes, that is syntactically correct. All parameters are optional (but their internal ordering must be maintained).
Offline
how i can launch reader only attack?
which commands?
Offline
It should be as easy as :
1. 'hf mf eclr' (clear out whatever data was there before)
2. 'hf mf sim x'
3. Hold it up against the reader a few seconds.
4. Press pm3-button.
5. at this point, you should get some commandline parameters on how to go forward.
6. You may have to go into the tools/mfkey directory and do 'make' to build the cracker
7. use the commandline given to you, test if it works
Offline
proxmark3> #db# Collected two pairs of AR/NR which can be used to extract keys from reader:
proxmark3> #db# ../tools/mfkey/mfkey32 00000000 00000000 00000000 00000000
proxmark3> #db# Emulator stopped. Tracing: 1 trace length: 3010
Doesn`t work.
BUT in log reader got this messages
proxmark3> #db# Reader authenticating for block 63 (0x3f) with key 0
proxmark3> #db# Reader reading block 63 (0x3f)
proxmark3> #db# Reader reading block 62 (0x3e)
proxmark3> #db# Reader reading block 61 (0x3d)
proxmark3> #db# Reader reading block 60 (0x3c)
proxmark3> #db# Reader doing nested authentication for block 59 (0x3b) with key 0
proxmark3> #db# Reader reading block 59 (0x3b)
proxmark3> #db# Reader reading block 58 (0x3a)
proxmark3> #db# Reader reading block 57 (0x39)
proxmark3> #db# Reader reading block 56 (0x38)
proxmark3> #db# Reader doing nested authentication for block 55 (0x37) with key 0
How to list log in DECRYPTED state (need recover key from nested authentication) fro example block 59) ?
-How i can load dump to simulator (it says eml not found)
Last edited by clayer (2014-02-04 15:52:42)
Offline
proxmark3> #db# Collected two pairs of AR/NR which can be used to extract keys from reader:
proxmark3> #db# ../tools/mfkey/mfkey32 00000000 00000000 00000000 00000000
proxmark3> #db# Emulator stopped. Tracing: 1 trace length: 3010
That's a bug! I'll look at it.
BUT in log reader got this messages
proxmark3> #db# Reader authenticating for block 63 (0x3f) with key 0
proxmark3> #db# Reader reading block 63 (0x3f)
proxmark3> #db# Reader reading block 62 (0x3e)
proxmark3> #db# Reader reading block 61 (0x3d)
proxmark3> #db# Reader reading block 60 (0x3c)
proxmark3> #db# Reader doing nested authentication for block 59 (0x3b) with key 0
proxmark3> #db# Reader reading block 59 (0x3b)
proxmark3> #db# Reader reading block 58 (0x3a)
proxmark3> #db# Reader reading block 57 (0x39)
proxmark3> #db# Reader reading block 56 (0x38)
proxmark3> #db# Reader doing nested authentication for block 55 (0x37) with key 0
I must say I don't understand what you've done here. It looks as if you've simulated a card, (with default keys 0xFFFFFFFFFFFF, if you did 'hf mf eclr').
The reader used the keys to read at least two sectors, thus - you already know the A-key (key 0) to at least those sectors. In mifare, the A-key is the first 12 bytes of the fourth block in each sector, that is, block 63, block 59, block 55 etc.
Offline
clayer wrote:proxmark3> #db# Collected two pairs of AR/NR which can be used to extract keys from reader:
proxmark3> #db# ../tools/mfkey/mfkey32 00000000 00000000 00000000 00000000
proxmark3> #db# Emulator stopped. Tracing: 1 trace length: 3010That's a bug! I'll look at it.
clayer wrote:BUT in log reader got this messages
proxmark3> #db# Reader authenticating for block 63 (0x3f) with key 0
proxmark3> #db# Reader reading block 63 (0x3f)
proxmark3> #db# Reader reading block 62 (0x3e)
proxmark3> #db# Reader reading block 61 (0x3d)
proxmark3> #db# Reader reading block 60 (0x3c)
proxmark3> #db# Reader doing nested authentication for block 59 (0x3b) with key 0
proxmark3> #db# Reader reading block 59 (0x3b)
proxmark3> #db# Reader reading block 58 (0x3a)
proxmark3> #db# Reader reading block 57 (0x39)
proxmark3> #db# Reader reading block 56 (0x38)
proxmark3> #db# Reader doing nested authentication for block 55 (0x37) with key 0I must say I don't understand what you've done here. It looks as if you've simulated a card, (with default keys 0xFFFFFFFFFFFF, if you did 'hf mf eclr').
The reader used the keys to read at least two sectors, thus - you already know the A-key (key 0) to at least those sectors. In mifare, the A-key is the first 12 bytes of the fourth block in each sector, that is, block 63, block 59, block 55 etc.
It is log of hf mf sim command.
One more issue that simualted tag nonce is always 01 02 03 04
Does it normal in case (i`ve read that must be 2 unsucessful auths with DIFFERENT tag nonces (?))
and hf 14a snoop on SVN 842sdoesn`t works
here log
proxmark3> hf 14a snoop
proxmark3>
proxmark3> #db# COMMAND FINISHED
proxmark3> #db# maxDataLen=21, Uart.state=0, Uart.byteCnt=0
proxmark3> #db# Uart.byteCntMax=20, traceLen=cb0, Uart.output[0]=000000ff
seems after sending command finish command.
Hardware is ok 100% (on svn 807 works fine).
when i try to load eml file to simulator i get error
proxmark3> hf mf eload 3.eml
File not found or locked.
proxmark3>
3.eml file is located in same foler where is Proxmark.
And ugrently needed get key form nested authencation (using snoop).
Please correct i`ll test.
Tahnks.
Offline
It is log of hf mf sim command.
One more issue that simualted tag nonce is always 01 02 03 04
Does it normal in case (i`ve read that must be 2 unsucessful auths with DIFFERENT tag nonces (?))
That's as it should be. Not required to be 2 unsuccessfull auths with different nonces. (Different AR/NR though)
and hf 14a snoop on SVN 842sdoesn`t works
here log
Yes, we know: http://www.proxmark.org/forum/viewtopic.php?pid=9482#p9482
File not found or locked.
proxmark3>
3.eml file is located in same foler where is Proxmark.
Don't write ".eml", just "hf mf eload 3". Yeah, I know, not super user friendly...
And ugrently needed get key form nested authencation (using snoop).
Well, it definitely can be done, and probably isn't very difficult (all parts of the crypto is already implemented in various forms, simulation, reader etc). I don't plan to implement that myself in the very near future though.
Offline
And ugrently needed get key form nested authencation (using snoop).
Well, it definitely can be done, and probably isn't very difficult (all parts of the crypto is already implemented in various forms, simulation, reader etc). I don't plan to implement that myself in the very near future though.
can write only algo how to do this that i can do this using paper and calculator for example, no need super user interface for blondies for now
Last edited by clayer (2014-02-04 21:35:29)
Offline
You can start by checking how both the tag and reader does it's encryption, in iso14443a.c. Go from there. That's what I'd do, at least, if you've got implementations for both sides, complete with traces, it should be possible to piece it together. Sorry, I don't have any better advice
Offline
clayer wrote:proxmark3> #db# Collected two pairs of AR/NR which can be used to extract keys from reader:
proxmark3> #db# ../tools/mfkey/mfkey32 00000000 00000000 00000000 00000000
proxmark3> #db# Emulator stopped. Tracing: 1 trace length: 3010That's a bug! I'll look at it.
Submitted a patch; r843.
Offline
I hadn't really looked at "hf mf sniff before" - the only time I tested it, it didn't work (being fixed by piwi now). But, as you may have already noticed, CmdHF14AMfSniff seem to do exactly what you (clayer) want, from what it looks like in the sources atleast.
Offline
Hey! I'm testing the simulator and while trying to authenticate to a sector (specifying a block number), it now works. But, when reading one block from the sector I'm authenticating, I can only read the one I used to do the auth, if I want to read the other blocks within the same sector, It's not working.
A real card will let you read every block from the sector you have authenticated without the need of a reauth.
It would be also nice to include a little help of the new "sim" command. The parameters that @asper showed a few posts above can be found only by reading part of the code...
And @holiman, GREAT work!
Thanks everybody.
Offline
Hey! I'm testing the simulator and while trying to authenticate to a sector (specifying a block number), it now works. But, when reading one block from the sector I'm authenticating, I can only read the one I used to do the auth, if I want to read the other blocks within the same sector, It's not working.
A real card will let you read every block from the sector you have authenticated without the need of a reauth.
That's strange, it's not what I experienced. Could you "prove it", e.g showing some debug printouts or protocol listings?
It would be also nice to include a little help of the new "sim" command. The parameters that @asper showed a few posts above can be found only by reading part of the code...
And @holiman, GREAT work!
Thanks everybody.
Try 'hf mf sim h' ...
Offline
Hey @Holiman!
I'm using ACR122u and its proprietary software to test the simulator. I will try to test it using my SCL3711 and libnfc and tell you. How can I give you the listings? I don't know if "hf 14a list" would work to "prove it"
Oh! "hf mf sim h" hehe, cool, this is because all params are optional. I was expecting of a help by only typing "hf mf sim", but that's fine!
I'll be testing the reader only attack too. I've noticed that you are fixing the nonce so my modification is not needed here. The two different card nonces modification is a little bit more real, but using a simulator you can do whatever you want on the first nonce being sent.
Offline
I also tested it using the ACR122u (I think, no longer have access to it) - it worked well there. Used libnfc to do the reading. You can use 'hf mf dbg 4' to get more output, but 'hf mf dbg 2' should suffice.'hf 14a list' works fine.
Regarding reader only attack, I added that when I no longer had the reader. So, I didn't want to modify too much, just took what was already there and threw it back to the computer.
Offline
I hadn't really looked at "hf mf sniff before" - the only time I tested it, it didn't work (being fixed by piwi now). But, as you may have already noticed, CmdHF14AMfSniff seem to do exactly what you (clayer) want, from what it looks like in the sources atleast.
Maybe i can get somewhere r596 (and i need to downgrade proxmark to old USB interface to get it worked (?)
Because r597 cant decode nested authencation(((
http://code.google.com/p/proxmark3/source/list?path=/trunk/client/cmdhfmf.c&start=606
Offline
I've now added r841/r842. It fixes most issues with simulation, but the thing is that I also today had to return my borrowed reader, so until I get my second pm3 (via gaucho) or gets another one, I am not able to test the simulation-stuff anymore. So, this is a call for testers...
Changes:
- Now supports 4-byte or 7-byte UID from commandline (earlier, it said it did take UID from cmdline, but it actually ignored it)
- Now saves to tracebuffer ok, was broken since a while back.
- Bug with corrupted ATQA fixed.
- Support for interactive mode, useful when invoked from scripts.
- Support for 'quit after N reads', also useful in scripts. Tells the simulator to quit simulating after the reader has read N blocks. This can be used to simulate a series of cards with different content via scripting (more on that later)
- Support for reader-only-attack. I haven't tested this, I just implemented it today, and am not able to test... Someone, please test it, I'd like to know if it works It's supposed to give you the command line parameters on how to invokeI think that's mostly it. All testing and feedback appreciated, esp since I'm currently unable to test it.
Is there a reason for NOT enabling interactive mode and reader only attack? I.e. could we get rid of the options i and x?
I will then implement the key extraction in the client instead of the hint to use external program.
Offline
Is there a reason for NOT enabling interactive mode and reader only attack? I.e. could we get rid of the options i and x?
I will then implement the key extraction in the client instead of the hint to use external program.
Well, I don't mind interactive mode being default, neither x-mode.
However, if you add so it automatically cracks the key, I'm not sure. If it takes half a minute of cracking a key I already know each time I run it, it may be a bit of a nuisance. So in that case maybe I wouldn't want it to be default.
Offline
Pages: 1