SDK for NFC Starter KitでMifare Classic 1Kに読み書きするサンプルだ。
github
https://github.com/hirokuma/NfcStarterKitWrap/tree/master/ClassicReadWrite
さて、Mifare ClassicはUltralightとは結構異なる。
ドキュメントは、このあたりがよかろうか。
探せばたくさん出てくるので、検索してくだされ。
http://www.nxp.com/documents/data_sheet/MF1S50YYX.pdf
コマンドはだいたい同じなのだが、Writeは0xA0になる。
16byte書き込みだ。
つまり、メモリマップも異なるということである。
セクタとブロックで管理されていて、セクタは0~15、ブロックは0~3。
ブロック3は特殊用途で、鍵などが管理されている。
コマンドで指定する場合はセクタとブロックではなく、アドレスを指定する。
アドレスは、セクタ*4+ブロックになる(資料がどっかいった)。
そして、ReadやWriteをする前にAuthentication(認証)が必要だ。
この部分も汎用的に作ろうとしたのだが、読めば読むほど大変なことがわかった。
Classicカードは出荷状態では「鍵A or B認証」で、鍵は「FF FF FF FF FF FF」になっている。
・・・らしいのだが、出荷時は「transport configuration」なるものになっているらしく、鍵Bは使えないらしい。
なので、鍵Aを使って認証する。
そこを起点としてデータアクセスして、鍵AやBの設定などを行うことになる。
鍵情報はブロック3に入っている。
つまり・・・アドレスは連続しているけれどもブロック3で分断されることになる。
NDEFなんかはどうするんだろうね?
各セクタにはブロックが4つあり、それぞれ認証方法を設定することができる。
ドキュメントの、Access conditions、というやつだ。
ここが非常にめんどくさいと思う。
Access conditionは、ブロック3(sector trail、と呼ばれる)の6~8byteにある。
この3byteの各ビットが意味を持っていて、解析すると各ブロックのC1, C2, C3というデータが得られる。
このC1, C2, C3というデータの組とアクセス方法を対照する表があり、そこから指定したブロックをどのように認証させればよいかがわかる、という手順になっている。
例えば出荷状態では、6~8byteは「FF 07 80」という値になっている。
これを解析すると、以下の情報が得られる。
C1
|
C2
|
C3
| |
ブロック0
|
0
|
0
|
0
|
ブロック1
|
0
|
0
|
0
|
ブロック2
|
0
|
0
|
0
|
Sector Trail
|
0
|
0
|
1
|
ブロック0~2は全部0なのでドキュメントのTable 8を見ると、「read・・・key A|B」「write・・・key A|B」となる。
つまり、鍵AかBで認証すればよい、とわかる(ただtransport configurationなので鍵Bは使えない)。
Sector TrailはTable 7から、鍵Aの
疑わしいので、鍵B「FF FF FF FF FF FF」で認証させてみたが、エラーになった。
まあ、書いてあるんだからそうなんだろうけどさ。
小心者なので、まだSector Trailに書き込むのはやってない。
また今回は取り上げないが、ブロック0~2はデータブロックとしてだけではなく、value blockという使い方もできる。
ドキュメントにはだいたいやれることが書かれていると思うので、SDK for NFC Starter Kitで遊んでみるとよいであろう。
完
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。