Open 7homasSutter opened 4 years ago
Awesome!
I have some FeliCa card but no idea of about it. This whole part is uncharted so getting support into proxmark3 is of essential value. Without it, no research :)
I also suggest bringing in multiple minor PR, instead of a huge massive PR with all functions at once. Much easier for us to analyse it that way. :) And it also brings curious ppl to the repo and might encourage them to be involved.
Two commands are reading for testing:
hf felica reader
: This should read now a felica light and standard cards and print the id's.
[usb] pm3 --> hf felica reader
[+] FeliCa tag info
IDm 01 10 09 10 C1 1B C4 07
- CODE 01 10
- NFCID2 09 10 C1 1B C4 07
Parameter (PAD) | 05 31 43 45 46 82 B7 FF
- IC CODE 05 31
- MRT 43 45 46 82 B7 FF
SERVICE CODE 04 00
hf felica raw
: The command should now be able to communicate with FeliCa standard cards.
hf felica raw HEX -c
if so we need to change the order depending on the card type.Some commands you can test with felica raw that should give you a response:
hf felica raw 06 00 ff ff 00 00 09 21
: Polling command with CRC
hf felica raw 06 00 ff ff 00 00 -c
: Polling command without CRC
B2 4D 12 01 01 10 09 10 C1 1B C4 07 05 31 43 45 46 82 B7 FF B9 EB
hf felica raw 0D 02 01 10 09 10 c1 1b c4 07 01 FF FF -c
: Example Service Request Command. You need to add you own IDm in order to test it. Here an Explanation of the bytes from my card:
As Response you should get some octets (Client Received 17 octets) with the response code 03: B2 4D 0D 03 01 10 09 10 C1 1B C4 07 01 03 00 63 1E
I will now make the styling and if someone can test that I would like to directly make a pull-request so that we can finished the first command and go over to the next one.
We implemented some cleaning up commands. if you run , the code style and whitespaces will be unified as we like it :) and just make a PR, your changes is better than what exists today
make style
Testing hf felica reader
:
Btw NXP TagInfo doesn't show me the "service code 020B" shown by felica reader
but it shows an additional Primary System Code of either 12FC or 88B4. I guess all my FeliCa are formatted for NDEF btw.
Don't forget to drop a line in CHANGELOG.md for perpetual glory!
Makes it easier for us if you do it in all PR's...
Testing hf felica raw
I guess there are errors in your testing instructions, hf felica raw 06 00 ff ff 00 00
needs -c
and IDm is bytes 5-12.
hf felica raw 06 00 ff ff 00 00 -c
works but hf felica raw 0D 02 <IDm> 01 FF FF -c
fails, I get zeroesMay I suggest to add "sniffing" to the list of planned features? It can help debugging issues e.g. when comparing frames transmitted by libnfc or a phone to the ones transmitted by a proxmark.
Testing
hf felica raw
I guess there are errors in your testing instructions,hf felica raw 06 00 ff ff 00 00
needs-c
and IDm is bytes 5-12.
- FeliCa RC-S833 => ok, all raw commands work
- FeliCa RC-S915 => ok, all raw commands work
- FeliCa RC-S888 / RC-S962 => get always zeroes
- FeliCa RC-S886 / RC-S965 => get always zeroes
- FeliCa Lite-S RC-S966 =>
hf felica raw 06 00 ff ff 00 00 -c
works buthf felica raw 0D 02 <IDm> 01 FF FF -c
fails, I get zeroes
hw dbg 4
--> Activates debug level 4hf list raw
shows the frames btw.Thanks for testing!
ok I'll test. FTR RC-S888 and RC-S886 is what's engraved on the tags, RC-S962 and RC-S965 is how NXP TagInfo identifies them on my phone.
no much to see, timeout
#db# FeliCa_sendraw Enter
#db# Start iso18092_setup
#db# No card selection
#db# Transmit Frame (no CRC shown):
#db# b2 4d 06 00 ff ff 00 00
#db# Buffer Length: 10
#db# Sending frame:
#db# b2 4d 06 00 ff ff 00 00
#db# 09 21
#db# WaitForFelicaReply Start
#db# timeout set: 2120
#db# Error: Timeout! STATE_UNSYNCD
#db# Received Frame Code: 0
#db# 00 00 00 00 00 00 00 00
#db# 00 00 00 00 00 00 00 00
#db# 00
#db# FeliCa_sendraw Exit
#db# switch_off
sniff works but truncates tag response to first 16 bytes (and crc info is wrong if answer is longer)
ok it seems to be a modulation/antenna problem. With the original dual antenna on tags 3 and 4, even when I sniff my phone I typically only see the reader data. Only once I captured tag data with tag 4, and that time there was no reader data captured. While sniffing tag 5 worked flawlessly (except for the truncated responses).
I'm now trying with the large HF antenna.
hf felica reader
:
hf felica raw
So I can't get a stable communication. And to get a (wrong) reply I've to be at a very specific distance. So I guess it has all to do with the low level demodulation of Felica radio signal.
FYI apparently NXP TagInfo is polling FeliCa cards with the equivalent of these commands:
hf felica raw 08 00 ff ff 01 00 3a 10 -c
hf felica raw 08 00 ff ff 01 03 0a 73 -c
hf felica raw 08 00 12 fc 00 00 ed 1d -c
hf felica raw 08 00 ff ff 02 00 6f 43 -c
FeliCa Lite-S RC-S966 => hf felica raw 06 00 ff ff 00 00 -c works but hf felica raw 0D 02
01 FF FF -c fails, I get zeroes
Ok, this is fine. From the user manual I see that Felica-Light-S does not has the second command for requesting services - so no problemo here.
No response at all can mean two things I think:
The field cannot sync with the card and therefore we get no data. At the beginning, when I was implementing my card I got the same problem where the last bytes got cut off and I got always a CRC error. With some pure luck probably I manage to read my card, I know exactly where this happens in the code (see the TODO with race condition), but I don't know how to configure the modulation accordingly to get it stable.
The frame is not recognised by the card because it has a wrong structure. So maybe the polling command has a different structure for some chips.
hf felica raw 06 00 ff ff 00 00 21 09
FYI apparently NXP TagInfo is polling FeliCa cards with the equivalent of these commands:
From these commands I can see that NXP TagInfo defines a request code and time slot for the polling command. From the FeliCa user manual I can see that this is possible, but as far as I understand not necessary. I just used the wildcards (FF FF), which should work as long as only one card is within antenna range.
As I sniffed the commands sent by NXP TagInfo and could replay them against the cards, I'm pretty sure it's not a logical problem of malformed frames.
maybe add an option to felica raw
to automatically add the first length byte ?
hf felica raw 06 00 ff ff 00 00 -c
=> hf felica raw 00 ff ff 00 00 -c -n
oh wait, when I replay a command to dump part of the Lite-S memory, it works fine until I activate the hw dbg 4 and then, bim, no answer. So activating debug does also sth to the frames being sent (content or timing)
maybe add an option to
felica raw
to automatically add the first length byte ?hf felica raw 06 00 ff ff 00 00 -c
=>hf felica raw 00 ff ff 00 00 -c -n
Yeah I think that is a good idea. I added that to the list.
oh wait, when I replay a command to dump part of the Lite-S memory, it works fine until I activate the hw dbg 4 and then, bim, no answer. So activating debug does also sth to the frames being sent (content or timing)
Yes, the dbprintfs() change the timing somehow and therefore we get out of sync with the card and can't read anything anymore. Took me some time to figure this out.
dbprintf / dbpstring is way to slow, it will most definitly mess up comms.
You enable parts of it when you wanna analyze like what you are sending and don't care about the response. Or when you wanna see the raw response etc.
The tracelog is good to see what actually got transceived but depends more of how well the decoding of FeliCa frames went. iClass does a mix up, to log those but I wouldn't use it too much.
Yes! My Octopus card came alive.
[usb] pm3 --> hf fel reader
[+] FeliCa tag info
IDm 01 01 08 01 B5 16 D9 20
- CODE 01 01
- NFCID2 08 01 B5 16 D9 20
Parameter (PAD) | 01 20 22 04 27 67 4E FF
- IC CODE 01 20
- MRT 22 04 27 67 4E FF
SERVICE CODE 4C 09
[usb] pm3 --> hf fel list [+] Recorded Activity (TraceLen = 193 bytes)
[=] ISO18092 / FeliCa - Timings are not as accurate
Gap | Src | Data | CRC | Annotation |
--------|-----|---------------------------------|----------|-------------------|
6993 | Rdr | 0a 00 b2 4d 06 00 ff ff |ff ff NG| Search syscode Req
| | 00 00 09 21 00 00 d1 48 | |
255 | Rdr | 00 |00 51 NG| Poll Req
30289 | Rdr | 0a 00 b2 4d 06 00 ff ff |00 48 OK| Search syscode Req
| | 00 00 09 21 00 00 d1 a3 | |
| | 0c 00 00 a3 0a 00 b2 4d | |
| | 06 00 ff ff 00 00 09 21 | |
| | 00 00 51 d1 10 00 80 d0 | |
| | 0a 00 b2 4d 06 00 ff ff | |
| | 00 00 09 21 00 00 d1 fe | |
| | 14 00 00 fe 0a 00 b2 4d | |
@7homasSutter send me an email, let find a easy way to communicate. Like signal etc. I will push some changes to the 'hf search'.
Re: "Search Service Code", the command is not publicly undocumented, but there are details in nfcpy's implementation which I've summarised here.
This will tell you what Service codes exist within a System. You can make dumps faster by skipping Services that have ACLs on them.
One other gotcha, is that when I tested with an old Octopus Card (pre-2004), it wouldn't respond to either Request System Code or Search Service Code commands. This may not be the case for recently-issued Octopus cards. I'd recommend trying with a Japanese IC card, they have a pretty good variety of Services on the card.
Re: "Search Service Code", the command is not publicly undocumented, but there are details in nfcpy's implementation which I've summarised here.
That's actually really cool to know. That will help a lot when we will implement the dump commands.
This will tell you what Service codes exist within a System. You can make dumps faster by skipping Services that have ACLs on them.
One other gotcha, is that when I tested with an old Octopus Card (pre-2004), it wouldn't respond to either Request System Code or Search Service Code commands. This may not be the case for recently-issued Octopus cards. I'd recommend trying with a Japanese IC card, they have a pretty good variety of Services on the card.
Yes I think we've got still an Issue with old Octopus Cards. I've got one of these too.
Hi everyone,
I just uploaded an attempt to reverse engineer the Auth1 command. My Hypothesis: From looking into the FeliCa documents it's possible that they just use standard 3DES encryption for older cards. So I implemented a command (auth1) to test it. My problem is that I do not have a blank FeliCa card with known keys and therefore I cannot test if it myself. FeliCa cards do not response at all in case of a wrong key.
If someone has a Blank FeliCa Standard card you can help me testing this. It's not that simple to test for it, but I try to explain it step by step:
EDIT: KEY LENGTH
hf felica reader
: In order to cache the card IDmhf felica auth1 01 0000 01 8B00 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
: Authentication1 Command
01
: Number of Areas (between 1 and 8), but just use 1 at the moment0000
: Area Code List (Little Endian). This depends on the card. By default there is always an area 0000. Try 0000, 0001, 010001
: Number of Service (between 1 and 8), but just use 01 at the moment.8B00
: Service Code (Little Endian). Depends on the card. I don't know if blank cards have default services. The easiest way to get all services at the moment is just using an Android app like "NXP TagInfo" and scanning the card. Then you should see all the service numbers and you can just pick one for testing.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
: The master secret. If you got a blank card you may know already the key length for the 3DES master secret (if so tell me please). The point is 3DES can use three or two keys for encryption and I don't know which one is used. So for testing I implemented both possibilities. You can use a 16 byte or 24 byte long master secret.Thanks for any help.
@7homasSutter the key argument in the example is 8 bytes and the command seems to accept only 8 and 12 bytes. How to provide 16 and 24 bytes 3DES keys ?
Quick tests:, trying all combinations of
hf felica auth1 01 [0000|0001|0100] 01 [8b00|020b|0b02|12fc|fc12|88b4|b488] [FFFFFFFFFFFFFFFF|FFFFFFFFFFFFFFFFFFFFFFFF]
RC-S833 & RC-S915
hf felica auth1 ...
[+] Client Received 22 octets
[+] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[!!] Received incorrect Frame Format!
[!!] Got no Response from card
RC-S962 card timeout
RC-S965 card timeout
RC-S966 Lite : any combination gives the same answer, no matter what's the provided key:
[=] Used last known IDm.
[=] 3DES Master Secret: 11 22 33 44 55 66 77 88
[=] 3DES ENCRYPTED M1c: 4C D1 88 36 BE B9 E6 B8
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 FC 12 B6 01 0D A1 A5 3A 93 18 27 10
[+] Client Received 30 octets
[+] B2 4D 1A 11 01 2E 34 E8 29 CE 1A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E 03
AUTH1 SUCCESS!
B2 4D 1A 11 01 2E 34 E8 29 CE 1A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E 03 43 00 02 0B 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 35 64 63 32 63 37 63 33 20 32 30 31 39 2D 31 31 2D 31 37 20 31 34 3A 31 39 3A 32 37 0A 20 20 20 20 20 20 20 6F 73 3A 20 52 52 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 35 38 38 63 32 34 62 35 20 32 30 31 39 2D 31 32 2D 31 36 20 31 32 3A 35 36 3A 34 36 0A 20 20 63 6F 6D 70 69 6C 65 64 20 77 69 74 68 20 47 43 43 20 37 2E 33 2E 31 20 32 30 31 38 30 36 32 32 20 28 72 65 6C 65 61 73 65 29 20 5B 41 52 4D 2F 65 6D 62 65 64 64 65 64 2D 37 2D 62 72 61 6E 63 68 20 72 65 76 69 73 69 6F 6E 20 32 36 31 39 30 37 5D 0A 0A 20 5B 20 46 50 47 41 20 5D 0A 20 20 4C 46 20 69 6D 61 67 65 20 62 75 69 6C 74 20 66 6F 72 20 32 73
All attemts give the same "successful" answer, only ClientSend AUTH1 Frame changes, eg
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 FC 12 B6 01 0D A1 A5 3A 93 18 61 06
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 00 01 8B 00 22 C7 35 1B DC 6D B3 97 2C 6C
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 8B 00 22 C7 35 1B DC 6D B3 97 2F 19
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 8B 00 22 C7 35 1B DC 6D B3 97 69 0F
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 00 01 02 0B 22 C7 35 1B DC 6D B3 97 E9 ED
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 02 0B 22 C7 35 1B DC 6D B3 97 EA 98
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 02 0B 22 C7 35 1B DC 6D B3 97 AC 8E
In https://www.commoncriteriaportal.org/files/epfiles/CRP165.pdf their 3DES is defined as "Triple DES operation. A 3DES encryption uses two keys in an EncryptDecrypt-Encrypt sequence."
RC-S966 Lite : any combination gives the same answer, no matter what's the provided key:
[=] Used last known IDm. [=] 3DES Master Secret: 11 22 33 44 55 66 77 88 [=] 3DES ENCRYPTED M1c: 4C D1 88 36 BE B9 E6 B8 [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 FC 12 B6 01 0D A1 A5 3A 93 18 27 10 [+] Client Received 30 octets [+] B2 4D 1A 11 01 2E 34 E8 29 CE 1A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E 03 AUTH1 SUCCESS! B2 4D 1A 11 01 2E 34 E8 29 CE 1A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E 03 43 00 02 0B 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 35 64 63 32 63 37 63 33 20 32 30 31 39 2D 31 31 2D 31 37 20 31 34 3A 31 39 3A 32 37 0A 20 20 20 20 20 20 20 6F 73 3A 20 52 52 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 35 38 38 63 32 34 62 35 20 32 30 31 39 2D 31 32 2D 31 36 20 31 32 3A 35 36 3A 34 36 0A 20 20 63 6F 6D 70 69 6C 65 64 20 77 69 74 68 20 47 43 43 20 37 2E 33 2E 31 20 32 30 31 38 30 36 32 32 20 28 72 65 6C 65 61 73 65 29 20 5B 41 52 4D 2F 65 6D 62 65 64 64 65 64 2D 37 2D 62 72 61 6E 63 68 20 72 65 76 69 73 69 6F 6E 20 32 36 31 39 30 37 5D 0A 0A 20 5B 20 46 50 47 41 20 5D 0A 20 20 4C 46 20 69 6D 61 67 65 20 62 75 69 6C 74 20 66 6F 72 20 32 73
All attemts give the same "successful" answer, only ClientSend AUTH1 Frame changes, eg
[=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 FC 12 B6 01 0D A1 A5 3A 93 18 61 06 [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 00 01 8B 00 22 C7 35 1B DC 6D B3 97 2C 6C [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 8B 00 22 C7 35 1B DC 6D B3 97 2F 19 [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 8B 00 22 C7 35 1B DC 6D B3 97 69 0F [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 00 01 02 0B 22 C7 35 1B DC 6D B3 97 E9 ED [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 00 01 01 02 0B 22 C7 35 1B DC 6D B3 97 EA 98 [=] Client Send AUTH1 Frame: 18 10 01 2E 34 E8 29 CE 1A 77 01 01 00 01 02 0B 22 C7 35 1B DC 6D B3 97 AC 8E
That's really interesting, since FeliCa Lite card does not have the auth1 command in the reference. I actually think the card should not know this command at all and you should not get any response at all with a FeliCa Lite card.
A 3DES encryption uses two keys in an EncryptDecrypt-Encrypt sequence.
Yes, I think they just split the master secret into the two keys. If I'm correct one DES Key is 64bit = 8 Byte = (FFFFFFFF) and if two or three keys are used 16byte = (FFFFFFFFAAAAAAAA) or 24byte = (FFFFFFFFAAAAAAAAFFFFFFFF). Or did I made a wrong assumption there?
Or did I made a wrong assumption there?
Yes FFFFFFFF is 4 bytes in hex :D
hahah oh lol yes of course! My bad...I'm stupid :D
RC-S833 & RC-S915: Now I always get an answer, no matter the key
[usb] pm3 --> hf felica auth1 01 0000 01 FFFF 11223344556677881122334455667788
=] Used last known IDm.
[=] 3DES Master Secret: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88
[=] 3DES ENCRYPTED M1c: 17 8F 59 F8 57 8E 0D 3F
[=] Client Send AUTH1 Frame: 18 10 01 01 05 01 31 08 4B 0D 01 00 00 01 FF FF 17 8F 59 F8 57 8E 0D 3F 63 B5
[+] Client Received 30 octets
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B 3C 06 61 8E 60 60 1F 75 33 77
AUTH1 SUCCESS!
B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B 3C 06 61 8E 60 60 1F 75 33 77 8A 8A 02 0B 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 35 64 63 32 63 37 63 33 20 32 30 31 39 2D 31 31 2D 31 37 20 31 34 3A 31 39 3A 32 37 0A 20 20 20 20 20 20 20 6F 73 3A 20 52 52 47 2F 49 63 65 6D 61 6E 2F 6D 61 73 74 65 72 2F 65 30 62 32 36 37 62 34 20 32 30 31 39 2D 31 32 2D 31 36 20 31 34 3A 33 31 3A 30 38 0A 20 20 63 6F 6D 70 69 6C 65 64 20 77 69 74 68 20 47 43 43 20 37 2E 33 2E 31 20 32 30 31 38 30 36 32 32 20 28 72 65 6C 65 61 73 65 29 20 5B 41 52 4D 2F 65 6D 62 65 64 64 65 64 2D 37 2D 62 72 61 6E 63 68 20 72 65 76 69 73 69 6F 6E 20 32 36 31 39 30 37 5D 0A 0A 20 5B 20 46 50 47 41 20 5D 0A 20 20 4C 46 20 69 6D 61 67 65 20 62 75 69 6C 74 20 66 6F 72 20 32 73
Repeating the same command shows different answers
RC-S833
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B 3C 06 61 8E 60 60 1F 75 33 77
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B FC DD 77 4D 2D 64 40 31 E5 73
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B 4E 09 EA B6 92 0E AE 01 7E 15
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B C2 D0 FC B7 AF 11 B0 1A 3C AE
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B A9 99 63 A8 60 6D 89 35 5B 3E
[+] B2 4D 1A 11 01 01 05 01 31 08 4B 0D 50 83 A1 40 90 B6 21 8B F3 92 6D EF E5 F2 20 38 FF 28
RC-S915:
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 FD 15 0A 09 C7 D7 BE 4D 98 A4
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 97 15 B7 26 91 10 24 DC C9 BF
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 59 5C 1E B2 E5 C0 C3 11 C0 4D
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 5F 1A F1 66 F5 96 12 B2 98 C6
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 30 90 CD 73 5C BB 86 4D 80 20
[+] B2 4D 1A 11 01 01 06 01 36 05 35 22 42 67 D2 A0 A8 80 17 82 70 FA B8 8D FF FD 72 16 2A FB
(updated code with latest merge)
Thanks for testing! I have no idea why that works with the FFFF wild card for service code. That's some really strange behavior for that authentication command.
First example RC-S833: From the length of the frame I would say that's a correct auth1 response there:
B2 4D = Sync
1A = Length
11 = Auth1 Response Code
01 01 05 01 31 08 4B 0D = IDm
50 83 A1 40 90 B6 21 8B = M2c
3C 06 61 8E 60 60 1F 75 = M3c
33 77 = CRC
M3c changes every time, because that's the random challenge generate by the card. M2c is constant, because that's the response to the readers (our) challenge which I set to a constant value instead of a random one.
The strange thing is that the tag actually sends us a response even if we do not provide a specific service code and a correct key. I don't understand which service is now getting authenticated. It could be that Area 0000 service FFFF is not a wild card, maybe it's some special service that exists on all cards. Or maybe if we use a wild card an unencrypted service responses to our authentication attempt.
I tried the same on my Suica card and I've got a response as well, but with a totally different structure:
B2 4D 1A 11 01 10 09 10 C1 1B C4 07 46 27 54 4E 5F E0 A8 BB 97 EB 3D 32 68 EF 2F 9A 6E 82 B7 FF 04 00 47 2F 49 63 65 6D 61 6E 2F 66 65 6C 69 63 61 5F 73 75 70 70 6F 72 74 2F 61 62 32 30 37 38 66 30 2D 64 69 72 74 79 2D 75 6E 63 6C 65 61 6E 20 32 30 31 39 2D 31 30 2D 31 34 20 30 39 3A 33 31 3A 34 39 0A 20 20 20 20 20 20 20 6F 73 3A 20 52 52 47 2F 49 63 65 6D 61 6E 2F 66 65 6C 69 63 61 5F 73 75 70 70 6F 72 74 5F 72 65 71 75 65 73 74 5F 73 79 73 74 65 6D 5F 63 6F 64 65 2F 2E 2E 2E 2D 75 6E 63 6C 65 61 6E 20 32 30 31 39 2D 31 31 2D 30 34 20 30 39 3A 30 37 3A 33 30 0A 20 20 63 6F 6D 70 69 6C 65 64 20 77 69 74 68 20 47 43 43 20 35 2E 34 2E 31 20 32 30 31 36 30 39 31 39 20 28 72 65 6C 65 61 73 65 29 20 5B 41 52 4D 2F 65 6D 62 65 64 64 65 64 2D 35 2D 62 72 61 6E 63
I don't know what my Suica card responses, because the beginning is a correct looking frame, but the response is much too long for an authentication1 response. Could be a bug, I don't know.
What I could do from your responses is implementing the auth2 command and see what happens if we provide some wrong responses to that M3c.
Yes the responses seem abnormally long to me, and we get answers no matter what's the key or the service code.
Ok I see there's a bug with the output of the buffer my response actually contains as well a correct frame:
B2 4D 1A 11 01 10 09 10 C1 1B C4 07 2B 07 A8 0D D1 DC 33 84 DF 09 9B D9 A6 5A F8 B3 E3 68
And the rest is just some proxmark bytes. It's possible to use 0000 instead of FFFF as well and it always returns an auth1 response.
I confirm on my RC-S833: SC 0000 and FFFF give answer, not the other values I tried (8b00 your example, 020b|0b02 taginfo PSC, 12fc|fc12 old NFC SC?, 88b4|b488 newer NFC SC?)
I tried using a Suica (Felica standard) and also give same answer using 0000 or FFFF and fill up with 0's
I'm using RRG/Iceman/felica_support_authV1/47a416a3 2019-12-17 11:13:47
branch
[usb] pm3 --> hf felica reader
[+] FeliCa tag info
[+] IDm 01 10 03 10 A4 12 ED 23
[+] - CODE 01 10
[+] - NFCID2 03 10 A4 12 ED 23
[+] Parameter (PAD) | 10 0B 4B 42 84 85 D0 FF
[+] - IC CODE 10 0B
[+] - MRT 4B 42 84 85 D0 FF
[+] SERVICE CODE 00 00
[usb] pm3 --> hf felica auth1 01 0000 01 FFFF 11223344556677881122334455667788
[=] Used last known IDm.
[=] 3DES Master Secret: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88
[=] 3DES ENCRYPTED M1c: 17 8F 59 F8 57 8E 0D 3F
[=] Client Send AUTH1 Frame: 18 10 01 10 03 10 A4 12 ED 23 01 00 00 01 FF FF 17 8F 59 F8 57 8E 0D 3F 24 21
[+] Client Received 30 octets
[+] B2 4D 1A 11 01 10 03 10 A4 12 ED 23 9C BD DF 2B FD A3 60 22 57 68 2E F1 05 E4 6C 74 8F BB
AUTH1 SUCCESS!
B2 4D 1A 11 01 10 03 10 A4 12 ED 23 9C BD DF 2B FD A3 60 22 57 68 2E F1 05 E4 6C 74 8F BB D0 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I notice Felica Lite (RC-S886 card/RC-S965 chip) doesn't work, reader
or raw 06 00 ff ff 00 00 -c
[usb] pm3 --> hf felica reader
[!] card timeout
[usb] pm3 --> hf felica list
[+] Recorded Activity (TraceLen = 400 bytes)
[=]
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
ISO18092 / FeliCa - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 6784 | Rdr |b2 4d 06 00 ff ff 00 00 09 21 | ok | POLLING
273792 | 292224 | Rdr |b2 4d 06 00 ff ff 00 00 09 21 | ok | POLLING
547584 | 577664 | Rdr |b2 4d 06 00 ff ff 00 00 09 21 | ok | POLLING
[usb] pm3 --> hf felica raw 06 00 ff ff 00 00 -c
[+] Data: 06 00 FF FF 00 00 09 21
[+] Client Received 30 octets
[+] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[!!] Received incorrect Frame Format!
Tested it with nfcpy
using Pasori RC-S330 reader and I can read the card
>>> tag = clf.connect(rdwr={'on-connect': lambda tag: False})
>>> print(tag)
Type3Tag 'FeliCa Lite (RC-S965)' ID=0127007884094EDC PMM=00F0000002060300 SYS=88B4
Also sending raw 06 00 ff ff 00 00
from phone (NFC Tools App) work too
Some memory bugs that cppchecker and coverity scan found has been addressed.
Trying to convert hf felica
to use cliparser, realising it also needs to use NG commands and logic re-arrangements in order to make the sending / receving commands easier to understand and less error-prone.
Hello there!
I started to work on the FeliCa Standard card support and I will work on this for a couple of weeks. To keep you up to date with my progress I opened this issue and reference the commit id's.
Protocol Commands:
Card Issue Commands:
Management Commands:
Proxmark Specific Commands:
Another reason for opening this issue is, I own only one FeliCa Card and I don't know the keys of the card. So testing all the commands (which will need encryption) is probably impossible for me alone, but maybe someone in the community has some cards with known keys and can then test it. So when I'm ready for testing these commands I will announce it here in this issue as well.
If you have anything I should know, do not hesitate to contact me directly.
Cheers Tom