search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
3.81k stars 1.01k forks source link

[feature] FeliCa Standard Support #442

Open 7homasSutter opened 4 years ago

7homasSutter commented 4 years ago

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

iceman1001 commented 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 :)

iceman1001 commented 4 years ago

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.

7homasSutter commented 4 years ago

Two commands are reading for testing:

  1. 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

  2. hf felica raw: The command should now be able to communicate with FeliCa standard cards.

    • I needed to change the order of CRC bytes for the standard cards. I'm not sure if this broke the FeliCa Light support (parameter c). Would be cool if someone could check if the parameter c works with FeliCa Light 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

        • You should get back a polling response frame looking similar but different: B2 4D 12 01 01 10 09 10 C1 1B C4 07 05 31 43 45 46 82 B7 FF B9 EB
          • From this response you can take the IDm (01 01 10 09 10 C1 1B C4 07)(Byte 5 to 12) for the next command.

      • 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:

        • 0D = Length = Payload + 1
        • 02 = Command Id = Service Request Command
        • 01 10 09 10 c1 1b c4 07 = IDm (Put your own IDm here instead)
        • 01 = Number of Node
        • FF FF = Node Code List

      • 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

        • B2 4D = Sync Bytes
        • 0D = Length
        • 03 = Response Code = Request Service Response
        • 01 10 09 10 C1 1B C4 07 = IDm
        • 01 = Number of Node
        • 03 00 = Node Key Version List
        • 63 1E = CRC

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.

iceman1001 commented 4 years ago

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

doegox commented 4 years ago

Testing hf felica reader:

doegox commented 4 years ago

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.

iceman1001 commented 4 years ago

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...

doegox commented 4 years ago

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.

doegox commented 4 years ago

May 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.

7homasSutter commented 4 years ago

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 but hf felica raw 0D 02 <IDm> 01 FF FF -c fails, I get zeroes

Thanks for testing!

doegox commented 4 years ago

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.

doegox commented 4 years ago

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
doegox commented 4 years ago

sniff works but truncates tag response to first 16 bytes (and crc info is wrong if answer is longer)

doegox commented 4 years ago

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.

doegox commented 4 years ago

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
7homasSutter commented 4 years ago

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:

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.

doegox commented 4 years ago

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.

doegox commented 4 years ago

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)

7homasSutter commented 4 years ago

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.

iceman1001 commented 4 years ago

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.

iceman1001 commented 4 years ago

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  |        |
iceman1001 commented 4 years ago

@7homasSutter send me an email, let find a easy way to communicate. Like signal etc. I will push some changes to the 'hf search'.

micolous commented 4 years ago

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.

7homasSutter commented 4 years ago

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.

7homasSutter commented 4 years ago

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

  1. hf felica reader : In order to cache the card IDm
  2. hf felica auth1 01 0000 01 8B00 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF : Authentication1 Command
    • 01 : Number of Areas (between 1 and 8), but just use 1 at the moment
    • 0000 : Area Code List (Little Endian). This depends on the card. By default there is always an area 0000. Try 0000, 0001, 0100
    • 01 : 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.
  3. You should get an "Authentication Successful!" message if the test succeeded. In case of an error we just get no response from the card or zeros. In that case try again with another area or service code.

Thanks for any help.

doegox commented 4 years ago

@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 ?

doegox commented 4 years ago

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
doegox commented 4 years ago

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."

7homasSutter commented 4 years ago

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?

doegox commented 4 years ago

Or did I made a wrong assumption there?

Yes FFFFFFFF is 4 bytes in hex :D

7homasSutter commented 4 years ago

hahah oh lol yes of course! My bad...I'm stupid :D

doegox commented 4 years ago

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)

7homasSutter commented 4 years ago

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.

doegox commented 4 years ago

Yes the responses seem abnormally long to me, and we get answers no matter what's the key or the service code.

7homasSutter commented 4 years ago

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.

doegox commented 4 years ago

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?)

ekiojp commented 4 years ago

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

iceman1001 commented 3 years ago

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.