Proxmark3 community
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.
Announcement
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
#1 2017-04-05 03:02:14
- philosophy
- Contributor
- Registered: 2017-04-05
- Posts: 6
Can not simulate iCLASS credentials with proxmark
Hello,
I'm probably doing something stupid here but I am having trouble simulating iCLASS credentials with my Proxmark3.
Reader: R90 Legacy
Simulator: Proxmark 3 RDV 2 - tried all options for "hf iclass sim <>"
It seems that when I try to simulate iCLASS cards with my proxmark, my R90 reader never gets a valid read. This is odd to me since I can write an iCLASS card with the same proxmark that will then read properly on my R90. Any tips on troubleshooting this issue?
Other thoughts:
The R90 is legacy iCLASS with the default master key. It is not configured for an HS/Elite key, nor is it an SE reader.
Also, I have successfully simulated iCLASS cards before with this very same proxmark, but that was on other readers. I'm not sure why it's not working on my own readers.
Offline
#2 2017-04-05 06:48:18
- 0xFFFF
- Administrator
- From: Vic - Australia
- Registered: 2011-05-31
- Posts: 632
Re: Can not simulate iCLASS credentials with proxmark
Not enough information.
Wild guess - Could be a revision thing?
I think carl55 has bumped in to this before with Rev C IIRC.
What is the full part number of the R90?
Post production revision stickers etc...
Offline
#3 2017-04-05 06:56:22
- philosophy
- Contributor
- Registered: 2017-04-05
- Posts: 6
Re: Can not simulate iCLASS credentials with proxmark
Not enough information.
Wild guess - Could be a revision thing?
I think carl55 has bumped in to this before with Rev C IIRC.What is the full part number of the R90?
Post production revision stickers etc...
My R90 is the following:
6150AKT0000
Here is a picture of the product sticker:
Offline
#4 2017-04-05 15:12:38
- carl55
- Contributor
- From: Arizona USA
- Registered: 2010-07-04
- Posts: 175
Re: Can not simulate iCLASS credentials with proxmark
I really don't have a clue what might be going on with the PM3 and R90.
I built a custom standalone iclass spoofer/simulator circuit a couple of years ago that worked fine with all iclass readers except the R90. I was never able to find the root problem since I was never able to successfully sniff (and analyze) the communication sequence. I believe that sniffing the high power electromagnetic field produced by the R90 requires a special RF analog front end circuit. Unfortunately I never had the time to pursue this any further.
Offline
#5 2017-04-05 15:31:17
- philosophy
- Contributor
- Registered: 2017-04-05
- Posts: 6
Re: Can not simulate iCLASS credentials with proxmark
I really don't have a clue what might be going on with the PM3 and R90.
I built a custom standalone iclass spoofer/simulator circuit a couple of years ago that worked fine with all iclass readers except the R90. I was never able to find the root problem since I was never able to successfully sniff (and analyze) the communication sequence. I believe that sniffing the high power electromagnetic field produced by the R90 requires a special RF analog front end circuit. Unfortunately I never had the time to pursue this any further.
If it is of any help, I also am not able to get a valid read on an RW300 (6111AGN0000), however, I can get a valid read on another multiCLASS reader (unsure of the model/part number)
Offline
#6 2017-06-22 01:41:06
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
I cannot seem to get sim working with a legacy R10 reader. Various info from the reader label:
6100CKN0000-<redacted, possibly a serial number>
R10CKNN
CRE11RDR4A02-06.00
SRD Model: R-640X-300
JQ6-R-640X-300
(C) 2001-2011
I am using a cheap clone of the "PM3 Easy" I bought on eBay. Antenna characteristics:
proxmark3> hw tune
Measuring antenna characteristics, please wait...#db# DownloadFPGA(len: 42096)
......
# LF antenna: 35.20 V @ 125.00 kHz
# LF antenna: 33.83 V @ 134.00 kHz
# LF optimal: 36.71 V @ 127.66 kHz
# HF antenna: 30.77 V @ 13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.I mentioned in another thread I am curious if they have done anything dodgy in this clone like change amplifier gains to artificially increase the antenna performance reported by the firmware. It's probably unlikely though as that would require actual thought as opposed to just blindly stealing the design.
I held the PM3 against the R10 reader and ran:
proxmark3> hf iclass sim 2
#db# DownloadFPGA(len: 42096)
#db# Going into attack mode, 15 CSNS sent
#db# Simulating CSN 000b0ffff7ff12e0
Waiting for a response from the proxmark...
Don't forget to cancel its operation first by pressing on the buttonIt just sits there and doesn't collect any data. I added debug print statements into armsrc/iclass.c:doIClassSimulation and reflashed to see if it was receiving any reader commands at all and it doesn't seem to be. I am able to read the unprotected blocks (CSN/config/etc) from iclass keyfobs with this device with no troubles.
I can also read the mifare classic cards that were bundled with my PM3.
I also tried holding it against my Omnikey 5321 v2 CL SAM (newer design with NXP CLRC632) with ContactlessDemoVC.exe open and then running:
hf iclass sim 1Nothing happens there either.
Anyone have any thoughts? I'm not even sure what hardware Rev the R10 reader is. I think we may have a couple of R30/R40 readers around too, I'll have to try sim against those too but they're in less convenient locations...
edit: forgot to mention that I also tried rolling back to the v3.0.1 tag and reflashing - got the same results.
edit 2: The reader is a Rev C according to this page 
Last edited by mollusc (2017-06-22 02:07:16)
Offline
#7 2017-06-22 08:03:34
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: Can not simulate iCLASS credentials with proxmark
How does the tracelog look like when you run these commands? And didn't @dot.com say something about how to put the antennas of pm3 rdv3.0 easy...
hf list iclassOffline
#8 2017-06-22 10:24:01
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
proxmark3> hf iclass sim 1
#db# Simulating CSN 031fec8af7ff12e0
<waved over omnikey for a while>
#db# Button pressed
#db# Done...
proxmark3> hf list iclass
Recorded Activity (TraceLen = 0 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|Same result after running "hf iclass sim 2" and holding it over the R10 reader.
I also ran these commands while holding it over the R10 reader.
proxmark3> hf iclass snoop
#db# cancelled_a
#db# 1 0 0
#db# 20 f0 0
proxmark3> data samples
Reading 39999 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data plotI did the same thing with no reader present. What's super weird is that the "noise" in the plot with no reader is identical to the "noise" in the plot in front of the reader. The only difference is that I can see what appear to be reader signals overlaid on top. I'm either using these commands wrong or what I'm seeing here are digital signals coupling to the HF antenna quite badly.
plots here
If you flick back and forth between the two images you'll see what appears to be a signal on top of the "noise"
edit: Just occurred to me that I'm using the ribbon-style USB cable that came with the device. Perhaps it isn't very well shielded... I'll run some more experiments tomorrow.
Last edited by mollusc (2017-06-22 12:37:26)
Offline
#9 2017-06-22 13:51:37
- Dot.Com
- Contributor
- From: Hong Kong
- Registered: 2016-10-05
- Posts: 180
- Website
Re: Can not simulate iCLASS credentials with proxmark
My first sim2 was done on pm3 rdv2. Took me 10 sec to attack the reader successfully.
Ran Ioclass Sim2 afterwhich.
Point to note: I placed the HF antenna right over the iclass reader. (1-1.5cm distance)
I tried again last month with my pm3 easy (I gave my rdv2 away) Kind of regretted it.
The pm3 easy will halt and get an error.
I face the same problem with some other property reader even with my rdv2 previously.
So i am guessing one is the reader have been fixed to prevent iclass ioclass attack or You need a very strong antenna for HF to do so I believe.
Not going to comment much about this further.
Keep trying.
Last edited by Dot.Com (2017-06-22 13:57:45)
Offline
#10 2017-06-23 01:35:49
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
OK, so in summary the issue could either be the type of reader or the PM3 easy (or both 
). I initially thought the antenna should be reasonably strong based on the tuning info. It is just a PCB antenna though. Annoyingly if I want to try an external antenna I'm going to have to cut traces and solder directly to the copper. I guess you get what you pay for! I might also try and fashion some kind of shielding over the digital sections of the board - the output I was getting from "hf iclass snoop" with nothing in front of the antenna was way too reproducible to just be noise.
yet another edit: I worked out that "hf iclass snoop" uses the "bigbuf" differently from "hf snoop". So the plots were probably just showing the data from an earlier "hf snoop" plus a bit of data written over the top by "hf iclass snoop". Makes a lot more sense - the data was not just similar but identical!
edit 2: Well, I had a look at what's actually on the PCB and for the most part, the main ICs match the original PM3 schematic pretty well. There is some hardware not present though. No TLV3502 comparator for CROSS_LO/CROSS_HI, no AD8052 op-amp for LO_RAW/HI_RAW. But they've been clever about only getting rid of signals the current verilog/firmware doesn't use. I assume most of this clever design originates from Elechouse.
Also, as suspected, the resistor divider (R41 and R42) feeding the signal AMPL_HI to the ADC on the MCU has a different ratio to the original schematic. Originally it was 10MOhm, 1 MOhm (see comments for MAX_ADC_HF_VOLTAGE). On this board it is 10MOhm, 2 MOhm. This makes the firmware report hf antenna voltage is 83% higher than it actually is! Don't know if the original Elechouse design did this too or if this is an extra "feature" of this board. TL;DR I'm really getting a hf antenna voltage of about 16.4V rather than 30V. Which is still not bad for a PCB antenna but possibly an indicator the antenna isn't strong enough to run sim successfully..
After looking more closely at the PCB antenna, it's actually attached to the antenna ports in series with a resistor on each side. So I can just desolder those rather than needing to cut traces. Will have to try and make my own external antenna...
edit 3: Avoiding a double-post...
Made some progress this weekend. I fixed the resistor divider and managed to hack a homemade antenna and a trimmer capacitor onto the PM3 easy. I did end up needing to cut a couple of traces though. The new antenna is made of .65mm copper I salvaged from an inductor. Loop diameter is 100mm and I used 6 turns. Estimated inductance ~8uH, depending on what formula you use, so I matched it with a trim cap able to do 6.2pF - 30pF. Finally all those electrical engineering subjects I took are useful for something!
In the current setup I can only tune the hf antenna to 5V - this is most likely because my new antenna has a different resistance to the old one which is impacting the Q factor of the RLC circuit. So it's lousy as a reader because it's probably spewing out broadband noise (although I can still get it to work). It seems to work a lot better in sim mode though. I can run "hf sim 14a 1" and get my omnikey to detect it as a card. So clearly the much larger loop area/more turns/higher inductance is giving me much better coupling than before to the reader. My theory is that although the antenna is a low Q factor, it doesn't matter as much in sim mode because the reader is emitting a nice clean signal and less filtering is required. Probably the main need for filtering in sim mode is to get rid of switching noise generated by the PM3. In contrast, when you are transmitting the PM3 is relying on the resonance of the RLC circuit to notch filter the square wave output by the coil drivers. Even then, you seemingly can get away with a lot because the cards are well tuned and can filter out quite a lot of sideband noise.
Anyway, so I tried "hf iclass sim 2" again and it still didn't work but at least something happened:
proxmark3> hf iclass sim 2
#db# Going into attack mode, 15 CSNS sent
#db# Simulating CSN 000b0ffff7ff12e0
Waiting for a response from the proxmark...
Don't forget to cancel its operation first by pressing on the button
#db# Button pressed
Mac responses: 0 MACs obtained (should be 15)
Saved data to 'iclass_mac_attack-1.bin'
proxmark3> hf list iclass
Recorded Activity (TraceLen = 340 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 0 | Rdr | 0a | | ACTALL
464 | 464 | Tag | 0f | |
44729408 | 44729408 | Rdr | 0a | | ACTALL
44729776 | 44729776 | Tag | 0f | |
47450896 | 47450896 | Rdr | 0a | | ACTALL
47451280 | 47451280 | Tag | 0f | |
47464048 | 47464048 | Rdr | 0c | | IDENTIFY
47467184 | 47467184 | Tag | 60 e1 e1 ff fe 5f 02 1c b1 96 | ok |
174846208 | 174846208 | Rdr | 0a | | ACTALL
174846592 | 174846592 | Tag | 0f | |
191109360 | 191109360 | Rdr | 0a | | ACTALL
191109728 | 191109728 | Tag | 0f | |
197893344 | 197893344 | Rdr | 0a | | ACTALL
197893712 | 197893712 | Tag | 0f | |
248039248 | 248039248 | Rdr | 0a | | ACTALL
248039680 | 248039680 | Tag | 0f | |
313140352 | 313140352 | Rdr | 0a | | ACTALL
313140720 | 313140720 | Tag | 0f | |
330757600 | 330757600 | Rdr | 0a | | ACTALL
330758032 | 330758032 | Tag | 0f | |
473132816 | 473132816 | Rdr | 0a | | ACTALL
473133168 | 473133168 | Tag | 0f | |
639912448 | 639912448 | Rdr | 0a | | ACTALL
639912800 | 639912800 | Tag | 0f | |
650729312 | 650729312 | Rdr | 0a | | ACTALL
650729744 | 650729744 | Tag | 0f | |
658867504 | 658867504 | Rdr | 0a | | ACTALL
658867936 | 658867936 | Tag | 0f | |
676483936 | 676483936 | Rdr | 0a | | ACTALL
676484304 | 676484304 | Tag | 0f | |
676496608 | 676496608 | Rdr | 0c | | IDENTIFY
676499728 | 676499728 | Tag | 60 e1 e1 ff fe 5f 02 1c b1 96 | ok | I think my antenna still needs more work because it looks like the tag is struggling to respond to the ACTALL request. Occasionally it works but then the response to IDENTIFY gets missed. If it's not the antenna, the other possibility is that they have tightened the timing requirements on the Rev C readers. I'll see if I can capture something with "hf iclass snoop" with a real card authenticating to the reader.
Last edited by mollusc (2017-06-26 01:57:31)
Offline
#11 2017-07-03 02:33:18
- tayuto
- Contributor
- Registered: 2017-03-02
- Posts: 5
Re: Can not simulate iCLASS credentials with proxmark
Hi mollusc,
I have a PM3 Easy from Elechouse and I have the similar problem like you. Following the guidance from elechouse, I put the lf antenna on the back of the hf to improve the stability. But although PM3 could send card num to the reader, no response was detected and as a result, PM3 keeps sending the same CSN again and again...
Do you have any ideas of that? Thanks.
My PCB components:
Offline
#12 2017-07-03 03:01:14
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
I'm still working on it, if I find something that works well I'll post a guide here!
So far:
- I've removed everything except the base PCB because I'm not working with LF atm.
- I have hacked the resistor divider on my board so that it reports the correct voltage for "hf tune". Your Elechouse PM3 RDV2 Easy may not need this mod.
- I've tweaked my homemade antenna so that I get can get it tuned to 23V (my first antenna only got to 5V). But to do this I had to reduce the length of copper in the coil so it is less inductive now. It actually performs worse when I try to do "iclass sim 2" - doesn't even detect the reader.
Current theory:
The R10 reader may not be that well tuned to 13.56MHz. I notice the new SE readers advertise an "auto-tune" feature so it could be that the old ones are susceptible to frequency drift due to temperature/manufacturing tolerances. The fact that my low Q-factor (wider bandwidth) antenna worked better than my higher Q-factor (narrow bandwidth) antenna supports this theory. If anyone has ever characterised the antenna in an iclass/picopass tag and found it to be relatively low-Q that would also support my theory, because the tags clearly have no issue with the reader.
Things I plan to try:
- I'll try to add a new tuning command that allows me to check receive voltage with the PM3 in front of the reader. If my theory about the reader being a bit out of tune is correct, this will allow me to shift the centre frequency of my antenna with a trim cap and get it in tune. Will take me a bit of time here to get the FPGA tools set up etc.
- I'll try putting a trim pot across my high-q antenna to reduce Q and increase its bandwidth a little.
- I'll try another high inductance antenna for stronger coupling to the reader, but I need to work out how to impedance match it properly so I can improve the Q factor a little
- I may also try hacking the Verilog for tag sim to use deeper modulation to increase the chance the reader "sees" my responses.
- (Unsure if viable) It would be fun to try and set up a new isochronous USB endpoint to stream ADC data in real time. No idea whether this would be doable at a useful sample rate. Also unlikely to work without major changes to the current ARM code. Probably not my highest priority as it's likely to take many hrs to implement.
Also, I've been meaning to get some kind of scope, this project may be the excuse I needed as there are probably a few other things I could check with that!
Offline
#13 2017-07-03 03:01:31
- 0xFFFF
- Administrator
- From: Vic - Australia
- Registered: 2011-05-31
- Posts: 632
Re: Can not simulate iCLASS credentials with proxmark
Did someone grind the surface of the ICs on an open source design?
Perhaps the 'Easy' should be relabeled as '!Easy'?
Offline
#14 2017-07-03 03:12:56
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
Hah, interesting. Mine is a cheap clone and they didn't bother to grind off any ICs. PCB layout looks slightly different to mine. FWIW none of the ICs on mine were any different to what's on the schematic in the repo. Except of course for the ones that are missing! (and maybe the diodes in the peak detectors, but they seem to be doing their job OK)
Offline
#15 2017-07-03 06:39:42
- brantz
- Contributor
- Registered: 2014-03-19
- Posts: 50
Re: Can not simulate iCLASS credentials with proxmark
OK, so in summary the issue could either be the type of reader or the PM3 easy (or both
yet another edit: I worked out that "hf iclass snoop" uses the "bigbuf" differently from "hf snoop". So the plots were probably just showing the data from an earlier "hf snoop" plus a bit of data written over the top by "hf iclass snoop". Makes a lot more sense - the data was not just similar but identical!
edit 2: Well, I had a look at what's actually on the PCB and for the most part, the main ICs match the original PM3 schematic pretty well. There is some hardware not present though. No TLV3502 comparator for CROSS_LO/CROSS_HI, no AD8052 op-amp for LO_RAW/HI_RAW. But they've been clever about only getting rid of signals the current verilog/firmware doesn't use. I assume most of this clever design originates from Elechouse.
Also, as suspected, the resistor divider (R41 and R42) feeding the signal AMPL_HI to the ADC on the MCU has a different ratio to the original schematic. Originally it was 10MOhm, 1 MOhm (see comments for MAX_ADC_HF_VOLTAGE). On this board it is 10MOhm, 2 MOhm. This makes the firmware report hf antenna voltage is 83% higher than it actually is! Don't know if the original Elechouse design did this too or if this is an extra "feature" of this board. TL;DR I'm really getting a hf antenna voltage of about 16.4V rather than 30V. Which is still not bad for a PCB antenna but possibly an indicator the antenna isn't strong enough to run sim successfully..
After looking more closely at the PCB antenna, it's actually attached to the antenna ports in series with a resistor on each side. So I can just desolder those rather than needing to cut traces. Will have to try and make my own external antenna...
edit 3: Avoiding a double-post...
Made some progress this weekend. I fixed the resistor divider and managed to hack a homemade antenna and a trimmer capacitor onto the PM3 easy. I did end up needing to cut a couple of traces though. The new antenna is made of .65mm copper I salvaged from an inductor. Loop diameter is 100mm and I used 6 turns. Estimated inductance ~8uH, depending on what formula you use, so I matched it with a trim cap able to do 6.2pF - 30pF. Finally all those electrical engineering subjects I took are useful for something!
In the current setup I can only tune the hf antenna to 5V - this is most likely because my new antenna has a different resistance to the old one which is impacting the Q factor of the RLC circuit. So it's lousy as a reader because it's probably spewing out broadband noise (although I can still get it to work). It seems to work a lot better in sim mode though. I can run "hf sim 14a 1" and get my omnikey to detect it as a card. So clearly the much larger loop area/more turns/higher inductance is giving me much better coupling than before to the reader. My theory is that although the antenna is a low Q factor, it doesn't matter as much in sim mode because the reader is emitting a nice clean signal and less filtering is required. Probably the main need for filtering in sim mode is to get rid of switching noise generated by the PM3. In contrast, when you are transmitting the PM3 is relying on the resonance of the RLC circuit to notch filter the square wave output by the coil drivers. Even then, you seemingly can get away with a lot because the cards are well tuned and can filter out quite a lot of sideband noise.
Anyway, so I tried "hf iclass sim 2" again and it still didn't work but at least something happened:
proxmark3> hf iclass sim 2 #db# Going into attack mode, 15 CSNS sent #db# Simulating CSN 000b0ffff7ff12e0 Waiting for a response from the proxmark... Don't forget to cancel its operation first by pressing on the button #db# Button pressed Mac responses: 0 MACs obtained (should be 15) Saved data to 'iclass_mac_attack-1.bin' proxmark3> hf list iclass Recorded Activity (TraceLen = 340 bytes) Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer iso14443a - All times are in carrier periods (1/13.56Mhz) iClass - Timings are not as accurate Start | End | Src | Data (! denotes parity error) | CRC | Annotation | ------------|------------|-----|-----------------------------------------------------------------|-----|--------------------| 0 | 0 | Rdr | 0a | | ACTALL 464 | 464 | Tag | 0f | | 44729408 | 44729408 | Rdr | 0a | | ACTALL 44729776 | 44729776 | Tag | 0f | | 47450896 | 47450896 | Rdr | 0a | | ACTALL 47451280 | 47451280 | Tag | 0f | | 47464048 | 47464048 | Rdr | 0c | | IDENTIFY 47467184 | 47467184 | Tag | 60 e1 e1 ff fe 5f 02 1c b1 96 | ok | 174846208 | 174846208 | Rdr | 0a | | ACTALL 174846592 | 174846592 | Tag | 0f | | 191109360 | 191109360 | Rdr | 0a | | ACTALL 191109728 | 191109728 | Tag | 0f | | 197893344 | 197893344 | Rdr | 0a | | ACTALL 197893712 | 197893712 | Tag | 0f | | 248039248 | 248039248 | Rdr | 0a | | ACTALL 248039680 | 248039680 | Tag | 0f | | 313140352 | 313140352 | Rdr | 0a | | ACTALL 313140720 | 313140720 | Tag | 0f | | 330757600 | 330757600 | Rdr | 0a | | ACTALL 330758032 | 330758032 | Tag | 0f | | 473132816 | 473132816 | Rdr | 0a | | ACTALL 473133168 | 473133168 | Tag | 0f | | 639912448 | 639912448 | Rdr | 0a | | ACTALL 639912800 | 639912800 | Tag | 0f | | 650729312 | 650729312 | Rdr | 0a | | ACTALL 650729744 | 650729744 | Tag | 0f | | 658867504 | 658867504 | Rdr | 0a | | ACTALL 658867936 | 658867936 | Tag | 0f | | 676483936 | 676483936 | Rdr | 0a | | ACTALL 676484304 | 676484304 | Tag | 0f | | 676496608 | 676496608 | Rdr | 0c | | IDENTIFY 676499728 | 676499728 | Tag | 60 e1 e1 ff fe 5f 02 1c b1 96 | ok |I think my antenna still needs more work because it looks like the tag is struggling to respond to the ACTALL request. Occasionally it works but then the response to IDENTIFY gets missed. If it's not the antenna, the other possibility is that they have tightened the timing requirements on the Rev C readers. I'll see if I can capture something with "hf iclass snoop" with a real card authenticating to the reader.
Hi mollusc,
How could we have the same tag respond from spoofing? lol, are we playing with the same reader??
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 96 | Rdr |0c | | IDENTIFY
4240533296 | 4240533296 | Tag |0f | |
4240581824 | 4240581824 | Rdr |0c | | IDENTIFY
4240584864 | 4240584864 | Tag |60 e1 e1 ff fe 5f 02 1c b1 96 | ok |
4240627984 | 4240627984 | Rdr |81 60 e1 e1 ff fe 5f 02 1c | | SELECTAs I remember that "0c" from reader is to ask anti-collision serial number from tag. and the tag should response "ACSN + CRC"
but "60 e1 e1 ff fe 5f 02 1c b1 96” is definitely not it.
Last edited by brantz (2017-07-03 06:42:34)
Offline
#16 2017-07-03 07:21:45
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
Are you sure that's not the expected sequence? ACSN is a function of the CSN we are spoofing so that will always be the same regardless of the reader (the CSNs are a hardcoded array in the pm3 client). You'll notice that your log has a SELECT response from the reader whereas mine didn't get that far. A few commands after that the reader should give you a MAC which is the info you need to crack the master key.
Offline
#17 2017-07-03 17:13:28
- Go_tus
- Contributor
- Registered: 2015-06-03
- Posts: 81
Re: Can not simulate iCLASS credentials with proxmark
uh I am not so sure, if this will help you guys out.
I made a modified sub functions in simulation in iclass.c file
its sort of incomplete due to lack of skills and time but I think will give an idea about the protocol.
It can talk to reader with sim 2 and also running sim 2 to handle another iclass protocol (omikey reader)
Credit to The Prime....
int doIClassSimulation( int simulationMode, uint8_t *reader_mac_buf)
{
// free eventually allocated BigBuf memory
BigBuf_free_keep_EM();
uint8_t *csn = BigBuf_get_EM_addr();
uint8_t *emulator = csn;
uint8_t sof_data[] = { 0x0F} ;
// CSN followed by two CRC bytes
uint8_t anticoll_data[10] = { 0 };
uint8_t csn_data[10] = { 0 };
uint8_t card_challenge_data[8] = {0xfe,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
// block 0 csn
uint8_t block0[10];
// block 1 config
uint8_t block1[10] = {0x12,0xFF,0xFF,0xFF,0x7F,0x1F,0xFF,0x3C,0x00,0x00};
// block 2 cc
uint8_t block2[10] = {0xfe,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00};
// block 3 credit key
uint8_t block3[10] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00};
// block 4 debit key
uint8_t block4[10] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00};
// block 5 AA
uint8_t block5[10] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00};
// other blocks
uint8_t block6[10] = {0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00};
// int i;
memcpy(csn_data,csn,sizeof(csn_data));
Dbprintf("Simulating CSN %02x%02x%02x%02x%02x%02x%02x%02x",csn[0],csn[1],csn[2],csn[3],csn[4],csn[5],csn[6],csn[7]);
// Construct anticollision-CSN
rotateCSN(csn_data,anticoll_data);
ComputeCrc14443(CRC_ICLASS, csn_data, 8, &csn_data[8], &csn_data[9]);
// Compute CRC on both CSNs
ComputeCrc14443(CRC_ICLASS, anticoll_data, 8, &anticoll_data[8], &anticoll_data[9]);
ComputeCrc14443(CRC_ICLASS, csn_data, 8, &csn_data[8], &csn_data[9]);
memcpy(block0,csn_data,10);
ComputeCrc14443(CRC_ICLASS, block1, 8, &block1[8], &block1[9]);
ComputeCrc14443(CRC_ICLASS, block2, 8, &block2[8], &block2[9]);
ComputeCrc14443(CRC_ICLASS, block3, 8, &block3[8], &block3[9]);
ComputeCrc14443(CRC_ICLASS, block4, 8, &block4[8], &block4[9]);
ComputeCrc14443(CRC_ICLASS, block5, 8, &block5[8], &block5[9]);
ComputeCrc14443(CRC_ICLASS, block6, 8, &block6[8], &block6[9]);
int exitLoop = 0;
// Reader 0a
// Tag 0f
// Reader 0c
// Tag anticoll. CSN
// Reader 81 anticoll. CSN
// Tag CSN
uint8_t *modulated_response;
int modulated_response_size = 0;
uint8_t* trace_data = NULL;
int trace_data_size = 0;
// Respond SOF -- takes 1 bytes
uint8_t *resp_sof = BigBuf_malloc(2);
int resp_sof_Len;
// Anticollision CSN (rotated CSN)
// 22: Takes 2 bytes for SOF/EOF and 10 * 2 = 20 bytes (2 bytes/byte)
uint8_t *resp_anticoll = BigBuf_malloc(22);
int resp_anticoll_len;
// CSN
// 22: Takes 2 bytes for SOF/EOF and 10 * 2 = 20 bytes (2 bytes/byte)
uint8_t *resp_csn = BigBuf_malloc(22);
int resp_csn_len;
// e-Purse
// 18: Takes 2 bytes for SOF/EOF and 8 * 2 = 16 bytes (2 bytes/bit)
uint8_t *resp_cc = BigBuf_malloc(18);
int resp_cc_len;
uint8_t *resp_block0 = BigBuf_malloc(22);
int resp_block0_len;
uint8_t *resp_block1 = BigBuf_malloc(22);
int resp_block1_len;
uint8_t *resp_block2 = BigBuf_malloc(22);
int resp_block2_len;
uint8_t *resp_block3 = BigBuf_malloc(22);
int resp_block3_len;
uint8_t *resp_block4 = BigBuf_malloc(22);
int resp_block4_len;
uint8_t *resp_block5 = BigBuf_malloc(22);
int resp_block5_len;
uint8_t *resp_block6 = BigBuf_malloc(22);
int resp_block6_len;
uint8_t *receivedCmd = BigBuf_malloc(MAX_FRAME_SIZE);
int len;
// Prepare card messages
ToSendMax = 0;
// First card answer: SOF
CodeIClassTagSOF();
memcpy(resp_sof, ToSend, ToSendMax);
resp_sof_Len = ToSendMax;
// Anticollision CSN
CodeIClassTagAnswer(anticoll_data, sizeof(anticoll_data));
memcpy(resp_anticoll, ToSend, ToSendMax);
resp_anticoll_len = ToSendMax;
// CSN
CodeIClassTagAnswer(csn_data, sizeof(csn_data));
memcpy(resp_csn, ToSend, ToSendMax);
resp_csn_len = ToSendMax;
// e-Purse
CodeIClassTagAnswer(card_challenge_data, sizeof(card_challenge_data));
memcpy(resp_cc, ToSend, ToSendMax);
resp_cc_len = ToSendMax;
// block 0
CodeIClassTagAnswer(block0, sizeof(block0));
memcpy(resp_block0, ToSend, ToSendMax);
resp_block0_len = ToSendMax;
// block 1
CodeIClassTagAnswer(block1, sizeof(block1));
memcpy(resp_block1, ToSend, ToSendMax);
resp_block1_len = ToSendMax;
// block 2
CodeIClassTagAnswer(block2, sizeof(block2));
memcpy(resp_block2, ToSend, ToSendMax);
resp_block2_len = ToSendMax;
// block 3
CodeIClassTagAnswer(block3, sizeof(block3));
memcpy(resp_block3, ToSend, ToSendMax);
resp_block3_len = ToSendMax;
// block 4
CodeIClassTagAnswer(block4, sizeof(block4));
memcpy(resp_block4, ToSend, ToSendMax);
resp_block4_len = ToSendMax;
// block 5
CodeIClassTagAnswer(block5, sizeof(block5));
memcpy(resp_block5, ToSend, ToSendMax);
resp_block5_len = ToSendMax;
// block 6
CodeIClassTagAnswer(block6, sizeof(block6));
memcpy(resp_block6, ToSend, ToSendMax);
resp_block6_len = ToSendMax;
//This is used for responding to READ-block commands or other data which is dynamically generated
//First the 'trace'-data, not encoded for FPGA
uint8_t *data_generic_trace = BigBuf_malloc(8 + 2);//8 bytes data + 2byte CRC is max tag answer
//Then storage for the modulated data
//Each bit is doubled when modulated for FPGA, and we also have SOF and EOF (2 bytes)
uint8_t *data_response = BigBuf_malloc( (8+2) * 2 + 2);
// Start from off (no field generated)
//FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF);
//SpinDelay(200);
FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_ISO14443A | FPGA_HF_ISO14443A_TAGSIM_LISTEN);
SpinDelay(100);
StartCountSspClk();
// We need to listen to the high-frequency, peak-detected path.
SetAdcMuxFor(GPIO_MUXSEL_HIPKD);
FpgaSetupSsc();
// To control where we are in the protocol
int cmdsRecvd = 0;
uint32_t time_0 = GetCountSspClk();
uint32_t t2r_time =0;
uint32_t r2t_time =0;
LED_A_ON();
bool buttonPressed = false;
uint8_t response_delay = 1;
while(!exitLoop) {
response_delay = 1;
LED_B_OFF();
//Signal tracer
// Can be used to get a trigger for an oscilloscope..
LED_C_OFF();
if(!GetIClassCommandFromReader(receivedCmd, &len, 100)) {
buttonPressed = true;
break;
}
r2t_time = GetCountSspClk();
//Signal tracer
LED_C_ON();
Dbprintf("len %d cmd %02x %02x %02x %02x %02x %02x %02x %02x",len,receivedCmd[0],receivedCmd[1],receivedCmd[3],receivedCmd[3],receivedCmd[4],receivedCmd[5],receivedCmd[6],receivedCmd[7]);
// Okay, look at the command now.
if((receivedCmd[0] == ICLASS_CMD_ACTALL) || (receivedCmd[0] == 0x0a) || (receivedCmd[0] == 0xA0)) {
// Reader in anticollission phase
Dbprintf("Send SOF");
modulated_response = resp_sof;
modulated_response_size = resp_sof_Len; //order = 1;
SendIClassAnswer(modulated_response, modulated_response_size, response_delay);
trace_data = sof_data;
trace_data_size = sizeof(sof_data);
}
if((receivedCmd[0] == ICLASS_CMD_READ_OR_IDENTIFY) || (receivedCmd[0] == 0x0c)) {
if (len == 1){
/// DbpString("Reader requests anticollission CSN len 1:");
// Reader asks for anticollission CSN
modulated_response = resp_anticoll; modulated_response_size = resp_anticoll_len; //order = 2;
trace_data = anticoll_data;
trace_data_size = sizeof(anticoll_data);
DbpString("Reader requests anticollission CSN:");
} else {
uint16_t blk = receivedCmd[1];
Dbprintf("Read len 4 block %d",blk);
if (blk == 0){
// Read block 0 (CSN)
modulated_response = resp_block0;
modulated_response_size = resp_block0_len;
trace_data = block0;
trace_data_size = sizeof(block0);
} else if (blk == 1){
modulated_response = resp_block1;
modulated_response_size = resp_block1_len;
trace_data = block1;
trace_data_size = sizeof(block1);
} else if (blk == 2){
modulated_response = resp_block2;
modulated_response_size = resp_block2_len;
trace_data = block2;
trace_data_size = sizeof(block2);
} else if (blk == 3){
modulated_response = resp_block3;
modulated_response_size = resp_block3_len;
trace_data = block3;
trace_data_size = sizeof(block3);
} else if (blk == 4){
modulated_response = resp_block4;
modulated_response_size = resp_block4_len;
trace_data = block4;
trace_data_size = sizeof(block4);
} else if (blk == 5){
modulated_response = resp_block5;
modulated_response_size = resp_block5_len;
trace_data = block5;
trace_data_size = sizeof(block5);
} else {
modulated_response = resp_block6;
modulated_response_size = resp_block6_len;
trace_data = block6;
trace_data_size = sizeof(block6);
}
}
} else if((receivedCmd[0] == ICLASS_CMD_SELECT) || (receivedCmd[0] == 0x81)) {
// Reader selects anticollission CSN.
// Tag sends the corresponding real CSN
Dbprintf("answer select command");
modulated_response = resp_csn; modulated_response_size = resp_csn_len; //order = 3;
trace_data = csn_data;
trace_data_size = sizeof(csn_data);
//DbpString("Reader selects anticollission CSN:");
} else if(receivedCmd[0] == ICLASS_CMD_READCHECK_KD) {
// Read e-purse (88 02)
modulated_response = resp_cc; modulated_response_size = resp_cc_len; //order = 4;
trace_data = card_challenge_data;
trace_data_size = sizeof(card_challenge_data);
LED_B_ON();
} else if(receivedCmd[0] == ICLASS_CMD_CHECK) {
// Reader random and reader MAC!!!
if(simulationMode == MODE_FULLSIM)
{/*
//NR, from reader, is in receivedCmd +1
opt_doTagMAC_2(cipher_state,receivedCmd+1,data_generic_trace,diversified_key);
trace_data = data_generic_trace;
trace_data_size = 4;
CodeIClassTagAnswer(trace_data , trace_data_size);
memcpy(data_response, ToSend, ToSendMax);
modulated_response = data_response;
modulated_response_size = ToSendMax;
response_delay = 0;//We need to hurry here...
//exitLoop = true; */
}else
{ //Not fullsim, we don't respond
// We do not know what to answer, so lets keep quiet
modulated_response = resp_sof; modulated_response_size = 0;
trace_data = NULL;
trace_data_size = 0;
if (simulationMode == MODE_EXIT_AFTER_MAC){
// dbprintf:ing ...
Dbprintf("CSN: %02x %02x %02x %02x %02x %02x %02x %02x"
,csn[0],csn[1],csn[2],csn[3],csn[4],csn[5],csn[6],csn[7]);
Dbprintf("RDR: (len=%02d): %02x %02x %02x %02x %02x %02x %02x %02x %02x",len,
receivedCmd[0], receivedCmd[1], receivedCmd[2],
receivedCmd[3], receivedCmd[4], receivedCmd[5],
receivedCmd[6], receivedCmd[7], receivedCmd[8]);
if (reader_mac_buf != NULL)
{
memcpy(reader_mac_buf,receivedCmd+1,8);
}
exitLoop = true;
}
}
} else if(receivedCmd[0] == ICLASS_CMD_HALT && len == 1) {
// Reader ends the session
modulated_response = resp_sof; modulated_response_size = 0; //order = 0;
trace_data = NULL;
trace_data_size = 0;
} else if(simulationMode == MODE_FULLSIM && receivedCmd[0] == ICLASS_CMD_READ_OR_IDENTIFY && len == 4){
//Read block
uint16_t blk = receivedCmd[1];
//Take the data...
memcpy(data_generic_trace, emulator+(blk << 3),8);
//Add crc
AppendCrc(data_generic_trace, 8);
trace_data = data_generic_trace;
trace_data_size = 10;
CodeIClassTagAnswer(trace_data , trace_data_size);
memcpy(data_response, ToSend, ToSendMax);
modulated_response = data_response;
modulated_response_size = ToSendMax;
}else if(receivedCmd[0] == ICLASS_CMD_UPDATE && simulationMode == MODE_FULLSIM)
{//Probably the reader wants to update the nonce. Let's just ignore that for now.
// OBS! If this is implemented, don't forget to regenerate the cipher_state
//We're expected to respond with the data+crc, exactly what's already in the receivedcmd
//receivedcmd is now UPDATE 1b | ADDRESS 1b| DATA 8b| Signature 4b or CRC 2b|
//Take the data...
memcpy(data_generic_trace, receivedCmd+2,8);
//Add crc
AppendCrc(data_generic_trace, 8);
trace_data = data_generic_trace;
trace_data_size = 10;
CodeIClassTagAnswer(trace_data , trace_data_size);
memcpy(data_response, ToSend, ToSendMax);
modulated_response = data_response;
modulated_response_size = ToSendMax;
}
else if(receivedCmd[0] == ICLASS_CMD_PAGESEL)
{//Pagesel
//Pagesel enables to select a page in the selected chip memory and return its configuration block
//Chips with a single page will not answer to this command
// It appears we're fine ignoring this.
//Otherwise, we should answer 8bytes (block) + 2bytes CRC
}
else {
// #db# Unknown command received from reader (len=5): 26 1 0 f6 a 44 44 44 44
// Never seen this command before
Dbprintf("Unknown command received from reader (len=%d): %x %x %x %x %x %x %x %x %x",
len,
receivedCmd[0], receivedCmd[1], receivedCmd[2],
receivedCmd[3], receivedCmd[4], receivedCmd[5],
receivedCmd[6], receivedCmd[7], receivedCmd[8]);
// Do not respond
modulated_response = resp_sof; modulated_response_size = 0; //order = 0;
trace_data = NULL;
trace_data_size = 0;
}
if(cmdsRecvd > 100) {
//DbpString("100 commands later...");
//break;
}
else {
cmdsRecvd++;
}
/**
A legit tag has about 380us delay between reader EOT and tag SOF.
**/
if(modulated_response_size > 0) {
SendIClassAnswer(modulated_response, modulated_response_size, response_delay);
t2r_time = GetCountSspClk();
}
if (tracing) {
uint8_t parity[MAX_PARITY_SIZE];
GetParity(receivedCmd, len, parity);
LogTrace(receivedCmd,len, (r2t_time-time_0)<< 4, (r2t_time-time_0) << 4, parity, TRUE);
if (trace_data != NULL) {
GetParity(trace_data, trace_data_size, parity);
LogTrace(trace_data, trace_data_size, (t2r_time-time_0) << 4, (t2r_time-time_0) << 4, parity, FALSE);
}
if(!tracing) {
DbpString("Trace full");
//break;
}
}
modulated_response_size = 0;
}
//Dbprintf("%x", cmdsRecvd);
LED_A_OFF();
LED_B_OFF();
LED_C_OFF();
if(buttonPressed)
{
DbpString("Button pressed");
}
return buttonPressed;
}Last edited by Go_tus (2017-07-03 17:28:56)
Offline
#18 2017-07-04 04:39:41
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
Hmm, that code doesn't look too different to the current code in the repo. Major difference seems to be hardcoded tag data, but the latest sim code can do this if you run "hf iclass sim eload" + "hf iclass sim 3". I also notice that your code recognises 0xA0 as the ACTALL command in addition to 0x0A, whereas the current code only recognises 0x0A. Seems unlikely to be significant because nobody has mentioned A0 turning up as an unrecognised command in their tracelog.
Can't see anything in there to suggest it can "handle another iclass protocol (omnikey reader)". The commands it is looking for are still the same.
On that note though, I haven't worked out how the omnikey reads iclass. The picopass 2KS datasheet claims the tags respond to either "ISO 15693 Manchester coding" or "ISO 14443 Type B BPSK coding". The HID wall-mounted readers appear to use 15693 (based on the Manchester encoding/decoding routines in the PM3 firmware). Confusingly though, the PM3 puts the FPGA in 14443A mode when handling iclass. Is that just to reuse the ASK demodulation?
I also found when I tried to snoop communication between an iclass tag and my omnikey that I could only see anything if I used "hf 14a snoop". None of "hf 15 snoop" or "hf 14b snoop" or "hf iclass snoop" worked. Am I missing something or is the picopass tag actually able to operate in 14a mode?!
Offline
#19 2017-07-05 15:19:40
- Go_tus
- Contributor
- Registered: 2015-06-03
- Posts: 81
Re: Can not simulate iCLASS credentials with proxmark
it also handles Read len 4 command.
which the reader send read len 4 to read a block of data with the giving block number.
Offline
#20 2017-07-06 02:11:51
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: Can not simulate iCLASS credentials with proxmark
it also handles Read len 4 command.
which the reader send read len 4 to read a block of data with the giving block number.
Ah OK, I must have missed that. Thanks!
So, I was able to patch the "hf tune" command so I could do a crude check of my receive strength rather than transmit strength. If I get around to it I'll submit a pull request adding this as an option so others can use it, it turned out modifying the FPGA wasn't necessary.
Got an interesting result when I held it in front of the R10 reader. My theory about it being out of tune is probably wrong. But it seems to send out a few bursts looking for a tag and then goes silent for a while:
#db# 5884 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 15207 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17157 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17334 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17441 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17547 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17653 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 17724 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 8472 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV
#db# 0 mV When I hold it in front of the Omnikey I just get a continuous reading of ~20V.
Unsure if this is different behaviour to other readers and why it works this way. It could just be a power saving feature. Either way, it could be that the timing requirements have tightened since it appears the tag has a certain amount of time to respond before the carrier is switched off. I think I need to capture some actual signals or at least a tracelog to know for sure though.
If it's just a timing thing then I'm willing to put in some work to reduce the latency. Hopefully it can be optimised ARM side, otherwise it'll need a custom state-machine implemented on the FPGA...
edit: New theory - maybe it is just pulsing and measuring the loading on its coil before it starts sending anything. This is consistent with my observation that a larger coil seemed to work better. this document talks about a "sniff card" part of the sequence before it "wakes up" the card. It is not an iClass reader specifically, but it still may have been designed in a similar way. So perhaps if I mess around with the configuration of the coil drivers I can make it a big enough load that the reader "sees" it and proceeds to sending out the ACTALL requests.
edit 2: Not really sure what I was thinking there, but the fact that I'm getting those voltages means I'm obviously putting a load on the reader! If they were actively trying to stop us I guess they could go the other way and detect if the load is higher than expected... Or maybe the circuitry just can't handle the load from the PM3. More thought/investigation required...
relevant link
Last edited by mollusc (2017-07-06 05:37:43)
Offline
#21 2017-08-03 15:17:12
- brantz
- Contributor
- Registered: 2014-03-19
- Posts: 50
Re: Can not simulate iCLASS credentials with proxmark
I have 2 R10 readers, version 6100CKN.
After comparing to RevA and RevB readers, I noticed that "iclass sim 2" can't get anything out from RevC readers, though it only took about 5-10mins to get 15 valid MACs collected from RevA/B readers (both configured in HS mode).
I use PM3 V2 from elechouse, I can tell it tries really hard to interact with RevC reader, LED C flashes outrageously, LED B occasionally lights up, but LED A never blink.
Has anyone else experience this?
@Dot.Com
You mentioned that you got the 15 MACs collected in just 10 seconds, from my experience, if it goes that quick, the reader must be in legacy mode, and the MACs you collected will not get you pass loclass calculation and verification.
Last edited by brantz (2017-08-04 08:51:16)
Offline
#22 2017-08-04 05:59:05
- Dot.Com
- Contributor
- From: Hong Kong
- Registered: 2016-10-05
- Posts: 180
- Website
Re: Can not simulate iCLASS credentials with proxmark
I am pretty sure it was elite system as the password coming out are different from the legacy password 
I don't think loclass attack works on legacy system.
Well, we have confirmed the new elite se system doesn't react to loclass attack. So there is no way to solve it now.
Offline
#23 2017-08-04 06:27:23
- brantz
- Contributor
- Registered: 2014-03-19
- Posts: 50
Re: Can not simulate iCLASS credentials with proxmark
made a silly mistake before
Last edited by brantz (2017-08-14 07:59:47)
Offline
Pages: 1