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.
I work with legacy iclass reader.
I am trying to simulate a tag in order to understand how my reader works (the 'SNIFF' command does not work on my proxymark3 easy).
The problem is that after the 'CHECK' reader command, the proxmark responds with the correctly calculated MAC, but after that the reader breaks the session.
I will give two sessions as an example.
1 - the proxmark acts as a reader and executes the 'hf iclass readblk b 14 ...' command to read the 14th block:
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 0 | Rdr |0a | | ACTALL
448 | 448 | Tag |0f! | |
3280 | 3280 | Rdr |0c | | IDENTIFY
6064 | 6064 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
9920 | 9920 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
12720 | 12720 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
15680 | 15680 | Rdr |18 02 | | READCHECK[Kc](2)
17952 | 17952 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
21808 | 21808 | Rdr |05 00 00 00 00 57 2c 19 ef | | CHECK
23056 | 23056 | Tag |25 2c 20 78! | ok |
26272 | 26272 | Rdr |0c 14 d6 65 | ok | READ(20)
29072 | 29072 | Tag |00! 00! 00! 00! 00! 00! 00! 00! 8f 72! | ok |
As you can see from the example, authentication was successful.
2- the proxmark acts as a tag and executes the simulation command (I changed the code from the repository a bit in order to add the features I need). Please note that at first my reader tries to authenticate with 2 false MACs.
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 62048 | Rdr |0a | | ACTALL
69005984 | 69009840 | Tag |0f! | |
69006464 | 69018512 | Rdr |0c | | IDENTIFY
69015632 | 69078032 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
69018768 | 69052912 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
69062336 | 69078096 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
69065536 | 69108288 | Rdr |0a | | ACTALL
69295552 | 69337504 | Tag |0f! | |
69296016 | 69346192 | Rdr |0c | | IDENTIFY
69305184 | 69340176 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
69308320 | 69315040 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
69351872 | 69405776 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
69355072 | 69412944 | Rdr |0a | | ACTALL
76246720 | 76284336 | Tag |0f! | |
76247200 | 76293008 | Rdr |0c | | IDENTIFY
76256368 | 76286992 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
76259504 | 76261872 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
76303072 | 76352480 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
76306160 | 76317248 | Rdr |0a | | ACTALL
76536160 | 76546496 | Tag |0f! | |
76536656 | 76555168 | Rdr |0c | | IDENTIFY
76545840 | 76549120 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
76548960 | 76589552 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
76592528 | 76614624 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
76595616 | 76605776 | Rdr |0c 01 fa 22 | ok | READ(1)
76852016 | 76876832 | Tag |12! ff! ff! ff! f9! 9f! ff! 3c! 94 ed! | ok |
76855168 | 76864096 | Rdr |0c 01 fa 22 | ok | READ(1)
77107744 | 77138992 | Tag |12! ff! ff! ff! f9! 9f! ff! 3c! 94 ed! | ok |
77110912 | 77126368 | Rdr |0a | | ACTALL
78608784 | 78643584 | Tag |0f! | |
78609216 | 78652304 | Rdr |0c | | IDENTIFY
78618384 | 78646288 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
78621520 | 78686688 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
78665072 | 78711792 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
78668176 | 78670912 | Rdr |18 02 | | READCHECK[Kc](2)
78761504 | 78776864 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
78764144 | 78785904 | Rdr |05 25 e5 07 1f 57 8a 74 6b | | CHECK
79045568 | 79109792 | Rdr |0a | | ACTALL
80495264 | 80544208 | Tag |0f! | |
80495776 | 80552848 | Rdr |0c | | IDENTIFY
80504944 | 80546832 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
80508080 | 80521696 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
80551632 | 80612320 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
80554720 | 80582976 | Rdr |18 02 | | READCHECK[Kc](2)
80659568 | 80677408 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
80662208 | 80684272 | Rdr |05 c1 eb 07 0b c6 a1 94 b8 | | CHECK
80941456 | 80964256 | Rdr |0a | | ACTALL
82410592 | 82444720 | Tag |0f! | |
82411072 | 82453392 | Rdr |0c | | IDENTIFY
82420240 | 82447376 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
82423376 | 82487776 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
82466928 | 82512880 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
82470032 | 82472000 | Rdr |18 02 | | READCHECK[Kc](2)
82563360 | 82577968 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
82566016 | 82586720 | Rdr |05 a5 6d 2a 88 63 ef 79 05 | | CHECK
82856304 | 82904704 | Tag |5d 83 bb! d3 | ok |
82858016 | 82883552 | Rdr |0a | | ACTALL
84280384 | 84345200 | Tag |0f! | |
84280800 | 84288400 | Rdr |0c | | IDENTIFY
84289968 | 84347920 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
84293104 | 84322800 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
84336672 | 84347872 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
84339760 | 84372544 | Rdr |18 02 | | READCHECK[Kc](2)
84433088 | 84478496 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
84435728 | 84487024 | Rdr |05 42 41 36 b4 e8 45 fa f7 | | CHECK
84716640 | 84770720 | Rdr |0a | | ACTALL
86191168 | 86245728 | Tag |0f! | |
86191568 | 86254464 | Rdr |0c | | IDENTIFY
86200720 | 86248464 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
86203856 | 86223328 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
86247408 | 86248416 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
86250496 | 86275136 | Rdr |18 02 | | READCHECK[Kc](2)
86345872 | 86379040 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
86348512 | 86387552 | Rdr |05 95 7c 3b a6 a6 b8 f8 d5 | | CHECK
As you can see in both examples, the same СSN and CC are used.
However, in the second case, the reader is not authenticated.
In my opinion, the problem is the response time of the tag after the 'check' command.
I would like someone to confirm my assumption or refute it.
If my assumption is correct, is there any way to change the response time to the check command?
I also ask for help in calculating from the 'hf iclass list' how much time (in milliseconds) elapsed between the reader request and the tag response.
Thank!
Last edited by sherhannn79 (2019-09-25 14:41:16)
Offline
I looked at your data posted above and I agree with your theory.
I actually ran into that same problem back in 2015 when I was building my own iclass spoofer.
In order to get it to work I had to implement the mac cipher algorithm in a CPLD so I could get it calculated and respond to the reader within the required timeframe which I measured to be 2.4 msec or less for a RevC R10 iClass reader. Newer version readers may have a narrower response window.
Holiman was coding the iclass sim function for the PM3 at that time and managed to obtain a 2 msec response time. It seemed to work fine at that time. I have not tried it with any of the latest SE readers so I don't know if it still works properly or not.
Below is the thread where it was previously discussed.(See posts #103 & #104)
http://www.proxmark.org/forum/viewtopic.php?id=1905&p=3
Offline
Thanks as always for your help, Carl!
Could you tell me how to correctly calculate the number of microseconds (milliseconds) that have passed since the request of the reader and the response of the tag in the listing 'hf iclass list'?
Offline
To my knowledge, all times shown are based on 13.56 Mhz carrier periods which are about 74 nsec. Unfortunately I have never trusted those times since they never seem to agree with actual hardware measurements that I get with external test equipment (e.g. oscilloscope, logic analyzer).
Based on the ISO15693 timing specification, it takes approximately 300 usec for the reader to transmit a byte of information. As a result, transmitting the check command, nonce and mac should take about 2.7 milliseconds.
If I look at an actual logic analyzer trace, the reader will send the next command in about 4 msec if the card responds with a correct MAC, otherwise it will restart the ACTALL sequence in about 6 msec if the card does not send an authentication response.
Offline
Reader sends wrong macs? Sounds like the reader is in keyroll mode.
Offline
@iceman
I do not think that my reader is in rolling mode (there is a similar function in its settings, but it is disabled). I can assume that the reason the reader behaves this way may be that this is not a standard iclass reader, but a vFlex.
After numerous experiments, I managed to find out something. I have two revisions reader (new and old). So, it turned out that the readers of the new revision are waiting for an answer to the command check not 330 microseconds, but ~280! And the proxmark manages to answer in only ~300 microseconds. Accordingly, I miss "only" 30 microseconds
When I tried to simulate a tag with an old reader, authentication succeeded! The old reader is waiting for a response to a check command of 330 microseconds. Unfortunately, the old reader is not suitable for my purposes.
I would be grateful for the help in answering the question: are there any ways to increase the speed of calculating the MAC? I mean hardware settings, as it seems to me at the software level, Holiman did everything possible.
Last edited by sherhannn79 (2019-08-19 09:07:56)
Offline
That is some interesting finds! just to be sure, you are using latest RRG/Iceman fw/client?
Offline
@iceman
Proxmark3 RFID instrument
[ CLIENT ]
client: iceman
[ ARM ]
bootrom: /-suspect 2019-05-04 22:09:08
os: iceman/master/ice_v3.1.0-1081-g52a291b3-dirty-unclean 2019-08-19 13:28:59
[ FPGA ]
LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23
[ Hardware ]
--= uC: AT91SAM7S512 Rev B
--= Embedded Processor: ARM7TDMI
--= Nonvolatile Program Memory Size: 512K bytes, Used: 235942 bytes (45%) Free: 288346 bytes (55%)
--= Second Nonvolatile Program Memory Size: None
--= Internal SRAM Size: 64K bytes
--= Architecture Identifier: AT91SAM7Sxx Series
--= Nonvolatile Program Memory Type: Embedded Flash Memory
Iceman, I use your assembly, with my minor modifications.
Offline
aha... nop.
https://github.com/rfidresearchgroup/proxmark3
Which device do you have?
Offline
aha... nop.
https://github.com/rfidresearchgroup/proxmark3
Which device do you have?
As far as I understand, I have PM3 Proxmark3 Easy (V3.0), Chinese copy.
Offline
I see different timings here, can you please clarify? Does the tag need to respond in the range of 300us (that would be according to the ISO 15693 standard, which specifies 309,2us to 313,9us for "Read alike" requests) or in the range of 2ms?
The timings in the iClass traces are indeed sometimes weird (same start and end in reader mode, jumping back in tag mode) and I would therefore not necessarily trust them.
Speeding up Holiman's optimized code may indeed be a challenge. An FPGA implementation of the MAC calculation might help.
Offline
I measured time to execute opt_doTagMAC_2() is in fact 403us. Measured using Get_SSP_Clock().
Need to speed up quite a lot.
Offline
I again spent a lot of time experimenting. Now I can say that I may have come to false conclusions in my post #6 and apologize if this is so. I think this is due to the fact that, as many have already noted, measuring time using proxmark logs is a rather confusing thing. For me, for example, the moment is not clear, why a new reader command (Start Rdr) in many cases starts earlier than the tag has time to replay to the previous reader command (End Tag).
I also came to the conclusion that successful authentication with the reader of the old revision probably occurs not only because the reader waits longer for a response from the tag to the check command, but because in principle my proxmark when working with the reader of the old revision responds faster to all commands, compared to working with a reader of a new revision. Maybe in my non-professional opinion, this is due to the fact that a more powerful antenna is installed in the reader of the old revision.
In any case, I will give an example of tracing the one old reader (successful authentication) and two new readers (failed authentication). Maybe someone according to it will describe the problem more correctly.
1. Old reader + proxmark as a tag
19864240 | 19916096 | Rdr |0a | | ACTALL
28835872 | 28836288 | Tag |0f! | |
28836352 | 28844304 | Rdr |0c | | IDENTIFY
28844848 | 28904560 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
28848064 | 28880752 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
28893024 | 28904512 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
28896192 | 28928320 | Rdr |88 02 | | READCHECK[Kd](2)
28988736 | 29035072 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
28991392 | 29013360 | Rdr |05 71 da 33 20 4e 5a 49 4f | | CHECK
29109056 | 29165120 | Tag |19 e6 9e 17! | ok |
29110688 | 29136992 | Rdr |0c 06 45 56 | ok | READ(6)
29150272 | 29166640 | Tag |03! 03! 03! 03! 00! 03! e0 17! 43 23 | ok |
29153424 | 29194464 | Rdr |0c 07 cc 47 | ok | READ(7)
29184944 | 29232112 | Tag |a1 bb! d9! f5 ce 77! b6! 60! 4b e5 | ok |
29188032 | 29200224 | Rdr |0c 08 3b bf | ok | READ(8)
29356384 | 29363264 | Tag |2a d4! c8 21! 1f 99! 68 71! 52 99! | ok |
29359552 | 29396832 | Rdr |0c 09 b2 ae | ok | READ(9)
29527904 | 29559856 | Tag |2a d4! c8 21! 1f 99! 68 71! 52 99! | ok |
29531056 | 29584480 | Rdr |0a | | ACTALL
2. New reader (rev.1) + proxmark as a tag . Example with credit key
174798976 | 174802368 | Rdr |0a | | ACTALL
176258672 | 176292208 | Tag |0f! | |
176259088 | 176300944 | Rdr |0c | | IDENTIFY
176268256 | 176294928 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
176271392 | 176335344 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
176314960 | 176360416 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
176318048 | 176321472 | Rdr |18 02 | | READCHECK[Kc](2)
176413296 | 176425440 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
176415872 | 176432240 | Rdr |05 2c fa 74 ea bc c4 19 0e | | CHECK
176693024 | 176752176 | Tag |d7! f7 10 91 | ok |
176694656 | 176740336 | Rdr |0a | | ACTALL
3. New reader (rev.2) + proxmark as a tag.
144246000 | 144294768 | Rdr |0a | | ACTALL
148228208 | 148242880 | Tag |0f! | |
148228656 | 148236752 | Rdr |0c | | IDENTIFY
148354064 | 148376624 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
148357184 | 148381360 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
148561664 | 148573248 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
148564800 | 148627472 | Rdr |0c 01 fa 22 | ok | READ(1)
148884320 | 148900896 | Tag |12! ff! ff! ff! f9! 9f! ff! 3c! 94 ed! | ok |
148887424 | 148913312 | Rdr |0c 05 de 64 | ok | READ(5)
149165120 | 149228624 | Tag |ff! ff! ff! ff! ff! ff! ff! ff! ea f5! | ok |
149168272 | 149213984 | Rdr |88 02 | | READCHECK[Kd](2)
149353424 | 149359104 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
149355984 | 149414976 | Rdr |05 e6 78 9f 73 cb 75 db b8 | | CHECK
149616656 | 149620368 | Tag |9d 29 81! ac! | ok |
149618336 | 149623984 | Rdr |88 02 | | READCHECK[Kd](2)
149754736 | 149817920 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
149757360 | 149789232 | Rdr |05 fb 3b 33 cd 48 7e 3c ce | | CHECK
149999088 | 150013568 | Tag |b3 b3 63! b2! | ok |
150000752 | 150017056 | Rdr |88 02 | | READCHECK[Kd](2)
150137008 | 150145536 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
150139568 | 150200624 | Rdr |05 65 9b 05 e3 2b c2 12 f8 | | CHECK
150399472 | 150406784 | Tag |61 39! 2d! 7a
Offline
Regardless of absolute figures I think that you were on the right track. And carl55 somehow confirmed your conclusion when he said that he had to implement the cipher in a CPLD in order to be fast enough.
I had a closer look at Holiman's optimized_cipher and I do see some room for improvement. Let's see how fast we can make it ...
Offline
I managed to bring it down to 270us but have no iclass readers/tags to test. Can you please test https://github.com/Proxmark/proxmark3/pull/861.
I am wondering if the timing in iclass.c works well at all? Looks like it is only possible to delay an answer in byte increments (151us). What are the experiences with iclass commands in general?
Offline
@piwi, thanks for the helping! I had a couple of days off. I have embedded your changes in my assembly. I will try to test the assembly as soon as possible.
Last edited by sherhannn79 (2019-08-26 13:56:36)
Offline
I did testing new changes. Here are the primary findings:
1. After making changes to the assembly from the Iceman, the situation with authentication has not changed in any way (the old reader is authenticated, but two new ones are not).
2. After making changes to the official assembly and using it, the situation has changed. I was able to authenticate with the reader rev.2 .
Here the trace:
41997584 | 41997584 | Rdr | 0a | | ACTALL
41998032 | 41998032 | Tag | 0f | |
46033184 | 46033184 | Rdr | 0c | | IDENTIFY
46036256 | 46036256 | Tag | 48 4e 03 60 ff 5f 02 5c 84 71 | ok |
46109232 | 46109232 | Rdr | 81 48 4e 03 60 ff 5f 02 5c | | SELECT
46112336 | 46112336 | Tag | 42 72 1a 00 fb ff 12 e0 ba 61 | ok |
46391504 | 46391504 | Rdr | 0c 01 fa 22 | ok | READ(1)
46395008 | 46395008 | Tag | 12 ff ff ff f9 9f ff 3c 94 ed | ok |
46709600 | 46709600 | Rdr | 0c 05 de 64 | ok | READ(5)
46713200 | 46713200 | Tag | ff ff ff ff ff ff ff ff ea f5 | ok |
47522128 | 47522128 | Rdr | 88 02 | | READCHECK[Kd](2)
47524736 | 47524736 | Tag | ff ff ff ff 7f ff ff ff | ok |
47900848 | 47900848 | Rdr | 05 08 ab 2b 1e 67 bf 9a 1e | | CHECK
47907904 | 47907904 | Tag | 63 80 a2 d8 | ok |
48273088 | 48273088 | Rdr | 87 02 ff ff ff ff 7e ff ff ff 33 01 ea a4 | | UPDATE(2)
48276608 | 48276608 | Tag | ff ff ff ff 7e ff ff ff 3f c4 | ok |
49116064 | 49116064 | Rdr | 0c 06 45 56 | ok | READ(6)
However, on this assembly, the proxmark does not work with the old reader and with the reader rev.1 . These readers do not see the proxmark at all. Iclass list is empty.
Offline
Are you using RRG/ceman repo?
Offline
Are you using RRG/ceman repo?
Sorry, Iceman, I used [Deprecated] Iceman fork, not RRG/iceman repo.
Offline
Then I strongly suggest you head over to RRG/Iceman and compiled for your device. (read advance compilation page if you dont have a RDV4) and run your iclass test again.
Offline
Ок, thanks to all! Now I have little free time. I can test again in a couple of days.
Last edited by sherhannn79 (2019-08-28 18:49:35)
Offline
Somehow I had expected something like that. There is no effective control of the tag response timing yet.
Offline
The behavior of simulation tag of the proxmark with the original assembly haunts me. Why does it work normally with a reader of one revision, and two readers with other revisions do not communicate with the proxmark at all (the proxmark does not accept the same command)? Is there any simple explanation for this?
Although all my readers communicate with the proxmark when using the assembly from the Iceman.
Last edited by sherhannn79 (2019-08-28 22:43:12)
Offline
Well, a simple explanation would be: the iclass sim code is bad (or as iceman would put it: it needs some love) on both repositories and works by chance only . Give me some time...
Offline
At the wireless CTF at DEFCON, there was some flags involving using a Proxmark3 to simulate iclass.
on my iclass SE reader, it worked but on legacy iclass reader it didnt. One patch later, easy fix, and hf iclass sim2,3 works like a charm on both legacy reader and iclass SE. So I must but wonder why you have issues. I was using a RDV4. I would say its field tested.
The ppl with rdv3 easy (cheap chinese clone) has issues when simulating HF. Either piwi can find settings that work with different kinds of hardware, making the fpga code even more tolerating for bad signals or the forum standard answer, get better antennas applies.
Offline
The traces are excellent. I therefore would exclude antenna issues.
Offline
The iclass implementation sure would need some love regarding timings. Like 14443a is very good, come to think about it, it was piwi who made those timings great back then.
Using piwi's optimized deviceside mac operations, the authentication phase usually works withing 2-3times. We loop it in three times.
Before it got on the third time or fail. After it works on 2,3 attempt. Gives a more stable end user experience.
Offline
I compiled the assembly from RRG / Iceman repo with a line 'PLATFORM=PM3OTHER' in the Makefile.platform.
Here is the log of the start of the proxmark and the 'hw status', 'hw version' and 'hw tune' commands - https://www.sendspace.com/file/helle8.
After entering the 'hf iclass eload f iclass_tagdump.bin', a line '[+] loaded 2064 bytes from binary file iclass_tagdump.bin ' is displayed, after that the proxmark crashes (the prompt MinGW is displayed).
Last edited by sherhannn79 (2019-08-31 12:22:33)
Offline
Create GH issue. We rewritten the file structure with the new make install functionality. You pulled today yes?
Offline
I downloaded the zip file 4 hours ago. Direct work with github does not work for me. Unfortunately I can not understand the meaning of the phrase: 'Create GH issue'.
Offline
Create a Github issue, the place where you report bugs on a repository. Try download again, I pushed a minor fix.
Offline
I reloaded 'RRG' repo and compiled. The previous error has been resolved. But, unfortunately, the situation with authentication as compared to '[Deprecated] Iceman fork' has not changed. I can only authenticate with the reader of the old revision. With readers rev.1 and rev.2, authentication fails. Trace example of reader rev.2:
5157680 | 5166832 | Rdr |0a | | ACTALL
9013792 | 9044464 | Tag |0f! | |
9014272 | 9022544 | Rdr |0c | | IDENTIFY
9058384 | 9112720 | Tag |48! 4e! 03! 60! ff! 5f! 02 5c! 84! 71! | ok |
9061584 | 9112240 | Rdr |81 48 4e 03 60 ff 5f 02 5c | | SELECT
9129840 | 9178208 | Tag |42! 72! 1a 00! fb ff! 12! e0 ba 61 | ok |
9132992 | 9183616 | Rdr |0c 01 fa 22 | ok | READ(1)
9403712 | 9440368 | Tag |12! ff! ff! ff! 7f 1f ff! 3c! 8c 87! | ok |
9406880 | 9444112 | Rdr |0c 05 de 64 | ok | READ(5)
9675952 | 9702432 | Tag |ff! ff! ff! ff! ff! ff! ff! ff! ea f5! | ok |
9679040 | 9716368 | Rdr |88 02 | | READCHECK[Kd](2)
9827168 | 9833056 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
9829808 | 9864240 | Rdr |05 25 1f 06 15 85 c3 05 23 | | CHECK
10064096 | 10094112 | Tag |82! c8 61 47! | ok |
10065648 | 10101648 | Rdr |88 02 | | READCHECK[Kd](2)
10205840 | 10226272 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
10208480 | 10215328 | Rdr |05 c9 54 2d 74 f0 06 2c 6a | | CHECK
10466176 | 10487408 | Tag |ec 68 7c 0f! | ok |
10467808 | 10492848 | Rdr |88 02 | | READCHECK[Kd](2)
10605984 | 10619488 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
10608624 | 10671536 | Rdr |05 20 22 80 00 6b 4e 79 1d | | CHECK
10863776 | 10880592 | Tag |f3! 8f 87! 80 | ok |
10865376 | 10888592 | Rdr |88 02 | | READCHECK[Kd](2)
11006080 | 11012704 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
11008720 | 11066816 | Rdr |05 b8 9b d1 ed 5f 0b 1a d0 | | CHECK
11265936 | 11273808 | Tag |b0 f5! 3b 66! | ok |
11267536 | 11280160 | Rdr |88 02 | | READCHECK[Kd](2)
11406592 | 11471392 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
11409168 | 11459376 | Rdr |05 27 b8 f0 4f 64 fa 2a 42 | | CHECK
11665728 | 11666976 | Tag |4a e2! 72! 4a | ok |
11667280 | 11673632 | Rdr |88 02 | | READCHECK[Kd](2)
11806592 | 11864608 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
11809168 | 11852208 | Rdr |05 b1 45 d0 6e b2 f1 cc 7f | | CHECK
12065344 | 12125792 | Tag |15 4f 29 b7! | ok |
12066960 | 12130848 | Rdr |88 02 | | READCHECK[Kd](2)
12204736 | 12257824 | Tag |ff! ff! ff! ff! 7f ff! ff! ff! | ok |
12207312 | 12247344 | Rdr |05 d8 f4 86 58 df 9f d4 2d | | CHECK
12465408 | 12518944 | Tag |c3! 48! 2f 7a | ok |
12466960 | 12525472 | Rdr |88 02 | | READCHECK[Kd](2)
Last edited by sherhannn79 (2019-09-01 09:13:03)
Offline
Which commands are you using?
Offline
Which commands are you using?
1. hf iclass eload
2. hf iclass sim 3
Offline
Taking one of your authentication requests, verifies it tries to use HID AA1.
hf iclass look u 42721a00fbff12e0 p FFFFFFFF7FFFFFFF m 251f061585c30523 f dictionaries/iclass_default_keys.dic
What is your reader configured to do?
Offline
Share a dump of your credentials? I only need the 0-6 blocks,
Offline
Email sent.. My reader is configured to read new card.
Last edited by sherhannn79 (2019-09-01 10:45:46)
Offline
While looking for "test vehicles" to test my changes to 'hf iclass sim' I found two readers in my junk box which at least reacted to the PM3 in hf iclass sim:
Omnikey 5321 v2
Omnikey 5427 CK
The first shows the issues described here, the second doesn't. I therefore can at least confirm the issue and will be able to see if my changes can solve it.
However, because I am new to iCLASS I would need someone please to tell me which kind of iCLASS tags these readers support? Is 'hf iclass loclass' supposed to work? Is 'hf iclass lookup' supposed to work? Can these readers be configured to read one or the other type of credentials?
Offline
Taking one of your authentication requests, verifies it tries to use HID AA1.
The way it is.
Offline
Not much about which tags, with iClass its more a question how is the reader configured.
Offline
Understood. I thought because these readers are USB readers and not PACS readers, that they probably come in a default legacy iCLASS configuration and can be reconfigured to iCLASS Elite with a Kcus of any choice? Anyone experience with these readers?
Offline
While looking for "test vehicles" to test my changes to 'hf iclass sim' I found two readers in my junk box which at least reacted to the PM3 in hf iclass sim:
Omnikey 5321 v2
Omnikey 5427 CK
The first shows the issues described here, the second doesn't. I therefore can at least confirm the issue and will be able to see if my changes can solve it.
However, because I am new to iCLASS I would need someone please to tell me which kind of iCLASS tags these readers support? Is 'hf iclass loclass' supposed to work? Is 'hf iclass lookup' supposed to work? Can these readers be configured to read one or the other type of credentials?
In my opinion, the easiest way to check for the presence of the problem described above is as follows: in any assembly (original or Iceman), enter a 'hf iclass sim 0 031fec8af7ff12e0' and bring the proxmark against the reader. If the reader reacts at least somehow (sound or LED), then there is no problem, otherwise there is a problem.
Unfortunately I do not have Omnikey readers.
Offline
I made some changes from the official repository:
1. Instead of the OutOfNDecoding function, I used the functions from the Iceman repository (uart_samples, uart_bit ...). And I tried to optimize them a bit to reduce the time of execution.
2. I tried to optimize the functions GetIClassCommandFromReader, CodeIClassTagAnswer, encode4Bits to reduce execution time.
The result is as follows:
1. Authentication with an old revision reader: two successful attempts out of three.
2. Authentication with reader rev.1, provided that the proxmark is located closest to the reader's antenna (a deviation of one millimeter matters): one successful attempt out of six.
3. Authentication with reader rev.2 passes without problems.
Last edited by sherhannn79 (2019-09-10 16:19:32)
Offline
I have pushed my latest commits to https://github.com/Proxmark/proxmark3/pull/862 FYI. Tag response timing is perfect now. The times in 'hf list iclass' are reliable now. But reader command decoding is not yet reliable enough (misses some commands). Therefore not yet time to merge.
Offline
OK. Done. https://github.com/Proxmark/proxmark3/pull/862 should be ready to merge. Added much more functionality to iClass simulation. Still to be done:
check access rights/authentication before allowing reads.
writes (update)
Maybe you can add your additions as well?
Offline
@piwi
I tested your changes a bit. All my readers work with this assembly. However, as you mentioned, there are misses (problems) when reading certain commands. I will give two examples.
The first one with my build (the reader answered positively): https://www.sendspace.com/file/79gszz
The second with your changes (the reader answered negatively): https://www.sendspace.com/file/hstaoi
Last edited by sherhannn79 (2019-09-25 11:34:48)
Offline
You seem to have multiclass readers. They poll for different card technologies. The 0x26 INVENTORY command polls for standard ISO15693 cards. I assume that the wrong 0x00 0x00 ... sequences are polling sequences for other card technologies because they happen around the same time than the 0x26 commands. These obviously confuse the decoder which is trying to detect even distorted reader signals. I may need to make it stricter...
Offline
@piwi
Here https://www.sendspace.com/file/cawp5p is the trace of work your assembly with reader rev.1. There is no 0x26 command. Unfortunately, authentication fails.
With this reader on my assembly, it turns out to authenticate one of six times.
Last edited by sherhannn79 (2019-09-25 12:59:20)
Offline
Pushed a new commit with a more strict decoding which should avoid the messages on unhandled commands. And the 0x26 commands are now silently ignored.
Offline
@piwi
Here https://www.sendspace.com/file/cawp5p is the trace of work your assembly with reader rev.1. There is no 0x26 command. Unfortunately, authentication fails.
With this reader on my assembly, it turns out to authenticate one of six times.
The timing in the trace looks good. Maybe an issue with my authentication code? I feel that a combination of your and my code should do the trick...
Offline