NFC: initial support for NFC-F (FeliCa) #2093
Conversation
Smartcardfocus used to carry them but not anymore. However I found this https://www.amazon.co.jp/gp/product/B009L0R2Z6/ on Amazon Japan. They seem to ship to outside Japan as well. It's a bit pricey except not really (single card price in line with some of the DESFires that I saw) and given that no open source FeliCa stuff really exist I think it might be a good investment. |
|
@dogtopus Unfortunately, they are of little usefulness due to the lack of documentation around authentication, let alone issuance (actually preparing the cards for authenticated uses). I actually have some cards both newer and old generation just in case, but what would really be nice is some code or software one could analyse for a clean-room implementation, but one price quote is around 230000 JPY. |
|
@nullableVoidPtr So if I understand correctly, the problem is less about finding blanks, but more about the fact that we don't know much about FeliCa Standard application management and how to access the encrypted portion of the card, similar to how DESFire was before libfreefare? (I guess it doesn't really matter for Flipper usage since Flipper never supported managing DESFire applications nor accessing encrypted DESFire applications either even though libfreefare is a thing. Although I'm kinda curious: Are FeliCa Standard encrypted applications ever used outside transit networks and payment? Even the SDKs Sony provide (probably under NDA but definitely not directly public) support only unencrypted applications.) |
Eh, bit of both; we don't know how to access the cards even if we know the encryption keys, which we don't have and would only know if we issued it in the first place. There may be card printers/issuing machines which attempt to automate this process whose drivers may be useful for an analysis. Indeed, the point of this (admittedly slightly inactive fork) is just to read as much data. We may be able to issue Lite or Lite-S cards from a Flipper as that process is entirely public and documented.
In practice, basically transport cards which serve as de-facto cash cards. There may be uses of HCE-F or on Android or Mobile FeliCa in general which may fall out of this domain. |
IIRC Lite-S is more analogous to Ultralight in terms of application, cost and openness. So read/write/emulate (given that the Flipper NFC hardware supports all the nuances needed to do so) would be great. Besides that, NFC-F IDm emulation would also be a great addition to bring feature parity to Flipper's support of NFC-A.
(Looks at SmartMX with DESFire partition) Yeah that would be a possibility.
Does eTax actually require Standard features or just IDm is enough? I saw sellers advertise some Lite-S cards being eTax compatible.
Interesting. I knew that Blackboard Transact uses DESFire. I guess it also supports FeliCa?
Looks like it's something supported by hardware (maybe similar to FIDO2) rather than just an application. |
The goal is to gradually split out NfcWorkerEventReadFelica into more specific decoders, and have the generic NFC-F info screen display info for tags that don't have a specific decoder, similar to how NFC-A works currently.
Move all arrays to allocating actual data rather than pointers to simplify construction and destruction. Also moved to M_EACH for iterating over arrays for less boilerplate code. Also did some function renaming for extra clarity. root_area is now a node type for simplified area traversal (coming soon).
|
I'm in japan and have easy access to felica cards. Tell me what is needed and I am happy to contribute. This is a capability that the hacker scene here really wants, so anything that speeds it up is doable. |
Monolithic NDEF tags are similar to Lites as they don't respond to most commands. The IC code is 0xff and default system code is 12fc. They usually respond to read requests on read-only open random service #0 and seems to terminate the read with an access denied status code instead of invalid block address. The Lite data viewer is largely based on @nullableVoidPtr's work.
This allows the reader to try out common monolithic systems (i.e. tag doesn't respond to Request System Code but has 1 common systems on the tag) (currently handles Lite and NDEF) when the tag doesn't support Request System Code and the IC code is unknown to the reader. Things that are left out from this commit and are in future TODO: - Improve performance by checking obvious IC codes in the magic detection routine - Update the FelicaData struct to include a monolithic system flag - Update felica_print_card_stat to depend on monolithic system flag and system code instead of IC code to determine what stat format to use - Make the NFC stack respect to PMm (low priority, need rebase)
- Move MRT calculation to felica.c and add a version for furi. - Move felica_read_card to nfc_worker as the new nfcf reader. - Add a new is_monolithic flag under FelicaData to differentiate between Lite cards and Lite systems. - Fix stat printing. Now stat printing determines card type by is_monolithic flag and the type of the first system.
Now we use furi_hal_nfc_tx_rx to do exchange since furi_hal_nfc_tx_rx_full isn't technically compatible with NFC-F. They also use the timeout values properly derived from PMm.
Currently only system IDm is displayed. More info can be trivially added later if they can be extracted.
Looks like NFC-DEP is software-defined and can be anything rather than just NDEF, therefore this check no longer makes sense.
Rebase to latest dev for PR preparation.
Some scenes won't clean it before writing, so we'll take care of it. Saves a bit of memory too.
|
Had a question, looking at this reddit comment it seems that emulating NFC-F isn't possible. Is this true? |
Wait this doesn't really make sense. Cycle-accurate anti-collision makes it a hard real-time task and most hosts won't be able to do it. This would significantly reduce this chip's usefulness on anything other than a very beefy Cortex-R processor. You might as well bitbang at that point. I don't believe that this won't be handled on the NFC chip itself. @Astrrra Care to elaborate further? ( |
|
The chip itself appears to have API for FeliCa TXRX anyways, and we used it to read cards but maybe they meant how long the timeout the reader waits on a response? @0chroma Towards emulation though, no; again, red-tape and encryption keys holds us back from emulating most applications like SuiCa and AmusementIC. (Side note on arcades: DDR/Konami eAmuse readers appears to be a unique case and could probably be fooled as IIRC it can use any arbitrary IDM from a FeliCa (like a FeliCa enabled cell phone) and hence can work with Flipper using basic UID emulation, but this may not needed as there is already NFCA emulation) |
I think they meant FeliCa user manual section 2.3.5.
eAmusement only checks for IDm for login and IIRC most Amusement IC terminals check for IDm and a public Lite-S block. Besides that there are apparently smart locks that only look for IDm. That's plenty of use cases already without the keys. |
I did some tests with an iphone to see how mobile emulation works with an on-device pasmo card. The flipper reads it as NFC-A, but the UID changes on each scan (ATQA 0004, SAK: 20). When using my android phone with NFC Tools it reads it as Felica, UID is stable. Not sure if that info helps at all, but it seems like for something like eamuse to work, you'd need to emulate more than just an NFC-A UID. |
|
@0chroma The NFC type detection is broken currently, and if you read modern mobile FeliCa it will read the EMV side instead which would be NFC-A with random UID. |
I just assume this includes Aime (the non-Amusement IC side)? |
|
So now #2961 is a thing. Do we need to keep going or FeliCa support will be developed in-house instead? |
|
Hello everyone! |
What's new
Verification
Checklist (For Reviewer)