パソリでMIFARE Ultralightが読み取れない

パソリのうち、古いもの、RC-S956チップセットを使った製品(RC-S330/RC-S360/RC-S370)は、NXP PN533互換コマンドでアクセスできるようなので、試してみています。

実際、FeliCaは簡単に読めました。

T: 00 00 FF 12 EE D4 42 10 06 xx xx xx xx xx xx xx xx 01 8B 00 01 80 00 E4 00
R: 00 00 FF 00 FF 00
R: 00 00 FF 20 E0 D5 43 00 1D 07 xx xx xx xx xx xx xx xx
00 00 01 00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 25 8B 00


しかし、MIFARE Ultralightは試行錯誤しているのですがエラーしか戻りません

PC/SC APIが使えればサンプルは色々あるのでもう少し楽なのかも知れませんが、パソリでPC/SC APIはPort-100(RC-S380)かららしいので。

失敗1


MIFAREのREADコマンドは [0x30 ADR] の2バイトらしい
InCommunicateThru D4 42 を使う
FeliCaと同様に送信してみた

T: 00 00 FF 06 FA D4 42 04 01 30 00 B5 00
R: 00 00 FF 00 FF 00
R: 00 00 FF 03 FD D5 43 01 E7 00

エラー0x01 タイムアウト
コマンドは無視されたもよう
D4 42のあとに長さを入れたのが邪魔だったもよう


失敗2


D4 42のあと長さは要らないかもしれないので削ってみる

T: 00 00 FF 05 FB D4 42 01 30 00 B9 00
R: 00 00 FF 00 FF 00
R: 00 00 FF 03 FD D5 43 01 E7 00

エラー0x01 タイムアウト
コマンドは無視されたもよう
これでもダメらしい


失敗3


D4 42のあとTgも要らないかもしれないので削ってみる

T: 00 00 FF 04 FC D4 42 30 00 BA 00
R: 00 00 FF 00 FF 00
R: 00 00 FF 03 FD D5 43 01 E7 00


エラー0x01 タイムアウト
コマンドは無視されたもよう
これでもダメらしい


失敗4


InCommunicateThru D4 42 ではダメかもしれないので、コマンドをInDataExchange D4 40に変えてみる

T: 00 00 FF 05 FB D4 40 01 30 00 BB 00
R: 00 00 FF 00 FF 00
R: 00 00 FF 03 FD D5 41 27 C3 00


エラー0x27
無視はされなくなったけれどコマンドが何か違うらしい
とはいえ [0x30 ADR] コマンドは他に引数も無さそうなので、対処がない。
やはりInDataExchange D4 40ではなくInCommunicateThru D4 42 を使う方が良さそうには思うものの、どちらでも正常には動作していない。

いろいろぐぐってみてもこれといった情報は得られず、とりあえず現状ではMIFAREはUltralightすらも読めていない。
コマンド30発行前に何かしらの初期化のようなものが必要なのかもしれないものの、そのあたりの情報も得られていない。

このあたりの知見のある方から情報をいただければ幸いです。

2018/09/23(日)15:14 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

ICカードこれひとつ 無料時の機能制限について

桁違いの大赤字を少しでも解消して、可能な限り早くに黒字化ができるように有料会員を増やす方向で考えており、そのため無料の場合に機能制限を掛ける方針で検討しています。

たとえ月100円でも多くの方に賛同をいただければ、このアプリは黒字化でき末永く維持することができます。


タブの制御


一番最初に「カード」タブを表示する (金額を確認するためには次の履歴タブに移動する必要が生じる)
一番最初に全画面広告のタブを表示する (枠が売れたら)


一番下の広告の制御


画面をタップしても消さないようにする。これにより、最下段に見えない領域が発生する。
最下段の説明も見えなくなるので、無料の時にはスナックバーなどで代替することも検討。


表示項目の制御


履歴タブ20件は維持、但しmanacaやSAPICAなどはポイント情報併記をしなくする方向で検討中
改札タブは3件中、最初の1件のみ表示 (残り2件は隠す)
入出場タブは検討中
物販定期券(大学生協電子マネー)は検討中
残高タブは何らかの制限を掛ける
チャージタブは最初の数件のみ表示する制限を掛ける
かざすタブは検討中
FeliCaポケットタブは検討中
NDEFタブは最初から有料機能

EX-IC指定席タブは既に死んでいる (EX-ICへの書き込みがなくなったので)
モバイルSuica特急券タブは検討中ながらサービス自体が死亡決定 (平成31年度末)
料金券タブは検討中
ポイントタブ(WAON、nanaco、岐阜大学学生証)は検討中

マナカタブは最初から有料機能
利用者タブ(記名式カードの個人情報)は検討中
カードタブは先頭に表示


制限された場所の代替表示


ドル袋マークあるいは説明文を出し、有料機能で全て見られる旨を説明する。
説明文をタップする等で申し込み画面に遷移できるようにもする。

その他の対策


数千人規模の会員を維持する必要があるため、手動登録は難しくなる。GooglePlayのアプリ内課金はまだ目処が立たないので、現在のクレジットカード課金を自動化できるよう処理について改良を加えてゆく。
資金的に余裕が出てきたらアプリ内課金に詳しい人に処理作成を依頼することとする。

2018/09/04(火)13:25 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

物販対応の今後について

増え続ける電子マネー対応店


大手コンビニだけをみても、
セブンイレブン2万店、ファミリーマート2万店弱、ローソン1万強
とされていて、大手だけで6万弱の店舗があるようです。

しかも各店、小さい所でも2台、大きいところだと5〜6台のレジがあり、仮に平均3台と仮定したとしても、20万台弱のレジが大手コンビニで稼働していることになり、それぞれに固有の物販端末番号があるわけです。

しかも昨今では、大手の飲食店やドラッグストア、スーパーマーケットなど、フランチャイズ店が次々と電子マネー対応しており、それを含めればその倍は軽く台数があると思われます。

ICカードこれひとつで物販を積極的に報告して下さる方は恐らく数名と思わます。
また弊社としても経費では落とせないので中の人が自腹を切ってせっせとあまり要らないものを買いながら端末番号の調査を続けているわけですが、まず店の数は多すぎますし、また使わない/使えない店で精算することは出来ないわけですから、そんな人数で立ち向かうにはちょっと力が弱いかと思うに至りました。

というのも「近くの店を探す」機能を搭載したことにより、対応しているのに表示されない店が大量に発生することになり、これをどうしたら良いのだろうかという点で考え込んでしまったわけです。


未対応の店は殆どの人が報告してくれない


プレミアムサービスに加入したのに店名が全く表示されません、といったクレームがたまに入ります。
店名は登録制であることを説明してFAQのリンクを付けてお返事を返すのですが、その後、実際に店が報告されてきたことは殆どありません。
積極的に店を報告して下さる方は殆どいないということになります。

つまるところ、「協力してもらう」という受け身の姿勢では店の情報は充実しないということができます。ではどうしたらよいのでしょうか。


仮案


金払ってまで協力してやらん、金払った以上は表示されて当然、という人は多いことでしょう。

そこで、そうではなく、
「普段使いの店を登録して活用する」
「そして、行く店に迷ったら『近くの店を探す』機能を活用する」
というように、愛用の店を登録して活用するというスタイルで案内したらどうだろうか、などと考えています。

少人数で殆どの情報を集めていくというのはかなり無理があるわけですし、知る人ぞ知るようなお店は知る人しか知らないわけですから、やはり人数が欲しいところです。
集合知として、多くの人がまんべんなく力を出し合って情報を集めていく仕組みを作ることが出来たら良いと考えているところです。

2018/09/02(日)13:56 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

MIFAREの読み取り

ICカードこれひとつ
FeliCaのビューアーとしてはほぼ完成の域に達し、機能面でも世界最高レベルのものを作ることができたと考えています。
しかしいくら国内で世界最高レベルのソフトウェアを提供しても、お金を出してくれる日本人は想定以上に少なくて、開発費の回収など夢、赤字が増え続ける状況は今後も続きそうです。

このままでは無理ですが、せっかくのアプリを廃棄するわけにもいかないので別の収入源を得られるよう海外進出も念頭に入れ、FeliCaだけでなくNFC-A、つまりMIFAREにも挑戦してみようと思うに至った今日この頃です。

手元にあるMIFARE


これまでかき集めたMIFAREなカードは次のようなものです。
・生のMIFARE Classic 1K ×3枚
・でんてつハイカード hi-card (MIFARE Classic 1K)
・aime (MIFARE Classic 1K)
・NESiCA (MIFARE Ultralight)
・バナパスポート (仕様不明、MIFAREのICタグと思われる)

MIFAREへの挑戦のはじめ


元々は「でんてつハイカード」を読むことができないかということから始まったMIFAREへの挑戦。
カードを壊してはいけないと思い入手した空のMIFARE Classic 1K含め、スマホやタブレット(Nexus 7)ではまったく読み取れず、最終的にNFCチップが対応していないので読めないという結論に至って数年放置されました。

aime、NESiCA、バナパスポートはゲームセンターのカードですが、最近になり対応できないか?という要望があったのでかき集めてみたものです。

MIFAREへの再挑戦


スマホでMIFARE Classicが満足に読めないので、案件もあったことからUSBのNFCカードリーダーを入手してアプリの対応に加えました。
FeliCaは無事に読み取れるようになったので、次はいよいよMIFAREへの挑戦です。

ここで分かったことは、認証の要らないMIFARE Ultralightはすんなり読み取れて、アプリにも無事に機能が追加できたことです。
しかしながら、MIFARE Classicはどう頑張っても読めません。空のものも。

MIFARE Classicはよく分からない


実際の読み込みコマンドは、MIFARE ClassicもMIFARE Ultralightも同じで良いはず。

現在は、Read Binary BlocksというAPDUコマンド FFh B0h 00h P2 Le という5バイトを使って、これでMIFARE Ultralightは正常に読めている。しかしMIFARE Classicは読めていない。


MIFARE Ultralightは認証が必要なので、まず鍵を登録する。
Load Authentication KeysというAPDUコマンド FFh 82h 00h P2 06h xx xx xx xx xx xx という11バイトを使う。
P2はキー番号。00hと01hの二つがあるあらしいがよく分からないので両方にデフォルトのffh ffh ffh ffh ffh ffh を登録してみる。これは読み込み処理の前に1回だけ実施。

次に認証をする。これはブロックごと。
AuthenticationというAPDUコマンド FFh 86h 00h 00h 05h 01h 00h B# KT K# という10バイトを使う。
B#は通しのブロック番号、KTは60hでKey-A、61hでKey-Bとして認証する。
K#はキー番号。00hか01h

でんてつハイカードのように他の番号がある場合、デフォルトのキーではErrorレスポンス 63 00h が返るが、生のカードでは正常に認証でき 90 00h が返ってきた。

そして、この認証後に先に書いたRead Binary BlocksというAPDUコマンドを実行すると、何やらLEDがピコピコするのでカードを読んでいるだろうと予想されるものの、Errorレスポンス 63 00h が返ってしまい、結局読めていない。

リーダーやライブラリーが悪いのか、コマンドの送り方が悪いのか、などはまだよく分からない。
どこかに解決のヒントがあれば良いのですが


(追記)読めました


デフォルトキーがffh ffh ffh ffh ffh ffh だという情報を得ていたのですが、これは正しくもあり間違いでもありました。

正確には、出荷状態は Key-Aは 00h 00h 00h 00h 00h 00h であり、Key-Bが ffh ffh ffh ffh ffh ffh だったのです。
ということで、プログラム自体は大きく変えた記憶はないですが認証させたり使用したりするキーを変えることで、無事に読み込み処理が完成しました。
MIFARE Classicも、カードリーダー(とNFCチップ)さえきちんとしていれば、ちゃんと読めることが分かりました。

2018/08/02(木)18:54 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

ICカードこれひとつの抜本的な仕様変更

設計


ICカードこれひとつは、最初の構想時点から全ての交通系ICカードに対応する前提で設計されていますので、その前提で仕様を練り上げプログラムが作られています。
しかしそれでも、各所に設計のまずいところがありました。

これまで設計が良くない所を少しずつ改良してきました。こうして最後に、極めてデンジャラス(さわるな危険)な箇所を残すのみとなったのです。

触るな危険


元々一種類のカードにしか対応していないアプリを強引に複数機能対応にした際の設計もかなり無理があり、いつかは改良しなければならない問題ですが、ここはあまりにも危険で本当に最後の最後にしか手を加えられない箇所です。設計がシビアなため、簡単には変更できません。

それよりも多少は手が付けられそうなところで、目に見える危険箇所は、改札タブと履歴タブの情報があります。
どちらも20件という上限が設定されていました。これは、配列で定義してしまったからです。
なぜ20件なのかというと、それは簡単で、Suicaは履歴を20件保持しているからです。ですので20件とした設計自体は妥当だったとは思いますが、やはり改良は必要な設計上の問題点でした。

なぜなら、カード履歴から1ヶ月分をまとめて一括で表示して欲しい、といった要望には、現状では応えることができないからです。20件より多くを扱うことができないからです。

改良成功


そこでこの制限を撤廃するため地道に準備を進めてきましたが、このたび遂に、改札も履歴も配列からリストに置き換えて、件数の上限を撤廃することに成功しました。

改札タブについては既に最新β版に投入していますが、致命的な問題は出ていないようです。
そして、今回は遂に履歴に手を加えました。
プログラムとして、配列とリストではデータの扱い方が全く違いますから、カード一種類ずつ順番に処理を置き換えつつ、動作テストをしながら念入りに変更しました。
念入りな動作テストの実施により、これまで見逃されていたバグの発見と修正もできましたが、当然ながら大規模な変更にともなう新たなバグが増えたかもしれません。

ただいつかはやらねばならない改良ですので、いつかは本流に投入し、この新しい処理をユーザーに利用してもらいながら、発見された不具合を修正していくという作業が必要となります。

投入時期


現時点では、バグ修正も合わせて実施していることから、いきなりですが次のバージョンから投入する予定でおります。
EclipseからAndroid Studioへの移行で発生した問題は概ね落ち着いたようですが、こちらはどうなるかまだ何とも言えません。
ただ、見た目が殆ど別アプリに変貌した「ICカードこれひとつ」ですので、正式リリースの段階で、せっかくですから見た目だけでなく内部処理もいきなりごっそり置き換えてしまうのも悪くないかなとは思っています。

2018/07/15(日)23:21 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

カレンダー

08 | 2018/09 | 10
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 - - - - - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterマストドン

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR