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)

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

▲ページトップ

Android開発のメモ

今回は気付いた点のメモで、しかもあまりよく分かっていない。
このためAndroid開発者に何らかのヒントを与えるかもしれないが、誤った情報を与えるかもしれない。

伝統的なライフサイクル


Androidの伝統的なライフサイクルだと、Activityは次のような流れになるらしい。

Activity#onCreate(Bundle savedInstanceState)

Activity#onStart()

Activity#onPostCreate()

Activity#onResume()

Activity#onPostResume()

アクティビティの稼働

画面回転などをすると、またActivity#onCreate()からやり直す。
ただし最初の起動時Bundle savedInstanceStateはnullだが、画面回転時は非nullとなるため区別可能で、これをみて初期化方法を変えることができる。

現状はonCreate()の動きがおかしい


今回、AndroidStudioで作り直すにあたりTabLayoutを使うためAppCompatActivityを用いたが、その影響かは不明ながら従来と動きが違う。
まず画面回転をさせても、AppCompatActivity#onCreate()は呼ばれないようだ。

加えて、Intentで他のAppCompatActivityな別画面を呼び出したあと、□ボタンを押しアプリを強制終了させ、再度アプリを起動させると、更に問題が生じる。
なぜかAppCompatActivity#onCreate(Bundle savedInstanceState)のBundle savedInstanceStateが非nullであり、つまり何かが残っている。

savedInstanceStateはあまり深く考えたことがないので、アプリ再起動でなぜ非nullになるのか、なぜ前回のなにかが残ってしまうのかは全く分からないのだが、結果として非nullなので非null=画面回転とみなすと確実に誤動作してくれるし、状態遷移が乱れるので画面表示もおかしくなるしで、きわめてありがたくない。

ということで、onCreate()の呼び出され方や、Bundleが従来と違い期待通りにはなっていないことがわかった。onCreate()内の処理方法は全体的に見直さないといけないようだ。


今後のメモ


画面回転でonCreate()が呼ばれないのであれば、画面作成はonCreate()にこだわる理由がない。
onCreate()内で重い処理するとANRが発生しやすいし、new Thread()… とか連ねるのもいかがなものかとは思っていた。
なので、処理はまとめてonStart()またはonResume()に移動させた方が良いのかもしれない。
どちらの方が良いのかは今後考える。


追記 (H30/7/13)


android:configChanges="orientation|screenSize" があると画面回転してもonCreate()は走らない、というコメントをいただいたので、削って試してみた。
Eclipseの時にはあってもonCreate()が走っていた気がしたが何かが違っていたのかもしれない。
これで画面回転でもonCreate()が動くことを確認したが、これは副次的な発見であって、今回の目的は別にこれではない。

次に、ロングタップして物販報告の選択画面などを開き(別Activity)、□ボタンからアプリを終了させ、アイコンタップでアプリを再起動させたところ、これでもなおonCreate()のBundleが非nullで起動する現象は再現していた。

どこに原因があるのかさっぱり分からないが、アプリ起動時すらBundleが非nullになるという前提で処理を組んでいかねばならないのは間違いがないようだ。

2018/07/12(木)20:59 |Comments(2) |Trackback(0)

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

▲ページトップ

「電子マネーのチャージ機」という業態

電子マネー


「電子マネーのチャージ機」がありますが、これの日本標準産業分類の番号は何だろうか、を以前から考えていました。

チャージ機という目に見える装置に目を奪われがちですが、この装置は「電子マネー業」という業態の一部であるとみなすと、電子マネーとはどういう業態として分類できるのか、という解を得る必要があるのだろうと思われます。

様々な電子マネーが乱立する中でも、これはまだ新しい業態なので日本標準産業分類で明確な分類がない、という結論ではありますが、現状ではどこに分類できるだろうかというあたりを考えていきます。

金融業としてみなしてみる


電子マネーも金券の一種であり資金決済に関する法律が適用されるわけなので、大分類Jの「金融業,保険業」としてまずは考えてみます。Jは次の62から67です。

J 62 銀行業
J 63 協同組織金融業
J 64 貸金業,クレジットカード業等非預金信用機関
J 65 金融商品取引業,商品先物取引業
J 66 補助的金融業等
J 67 保険業(保険媒介代理業,保険サービス業を含む)

電子マネーは、iDやPiTaPaなどのように後払いであれば単なるクレジットカードであり業務はクレジットカード業に他ならないと思います。
しかし今回はチャージ機が必要となる、プリペイド式の交通系電子マネーやWAON/nanaco/楽天Edy等流通系電子マネーです。前払い電子マネーの場合は信用不要ですから貸金業(64)でないことは明らかです。
また金融機関(62, 63)でも、保険業(67)でも、金融商品取引(65)でもないのは明らかなので、残るのは次しかありません

J 66 補助的金融業等

次のような業態が分類されています。

中分類 66  補助的金融業等
 660  管理,補助的経済活動を行う事業所(66補助的金融業等)
  6600  主として管理事務を行う本社等
  6609  その他の管理,補助的経済活動を行う事業所
 661  補助的金融業,金融附帯業
  6611  短資業
  6612  手形交換所
  6613  両替業
  6614  信用保証機関
  6615  信用保証再保険機関
  6616  預・貯金等保険機関
  6617  金融商品取引所
  6618  商品取引所
  6619  その他の補助的金融業,金融附帯業
 662  信託業
  6621  運用型信託業
  6622  管理型信託業
 663  金融代理業
  6631  金融商品仲介業
  6632  信託契約代理業
  6639  その他の金融代理業

ここにも適当なものがないような気がします。
該当がないといことで、選ぶなら6619その他の補助的金融業,金融附帯業 とするしかなさそうです。

そこで「その他の補助的金融業,金融附帯業」がどういった業態を想定しているのか調べたところ、
公共工事前払金保証会社;前払式証票発行業者(発行・決済業のもの);債権管理回収業者(サービサー);整理回収機構

といった解釈が見つかりました。

電子マネーは金券、商品券、プリペイドカードの一種であるので「前払式証票発行業者」が適当ではないかと思われます。

ちなみに金融庁のサイトに「前払式支払手段(商品券・プリペイドカード等)・資金移動業・仮想通貨交換業関係について」というページがありましたが、ここを見ると、どうやら仮想通貨などもこのカテゴリーに入るように見えます。

ということで、「電子マネーのチャージ機」とは「前払式証票発行業者」であり、日本標準産業分類の番号は、現状では「6619」が適切、と判断するに至りました。


サービス業としてみなしてみる


結論は出ましたが、考え方を変えて、これを未知のサービス業とみなすことにしてみました。

未知のサービス業は次が該当します。Rは88から96です。
R サービス業(他に分類されないもの)

R 88 廃棄物処理業
R 89 自動車整備業
R 90 機械等修理業(別掲を除く)
R 91 職業紹介・労働者派遣業
R 92 その他の事業サービス業
R 93 政治・経済・文化団体
R 94 宗教
R 95 その他のサービス業
R 96 外国公務


この中ではR 92 その他の事業サービス業 くらいしか見込みがないので、ここを確認しましょう。

中分類 92  その他の事業サービス業
 920  管理,補助的経済活動を行う事業所(92その他の事業サービス業)
  9200  主として管理事務を行う本社等
  9209  その他の管理,補助的経済活動を行う事業所
 921  速記・ワープロ入力・複写業
  9211  速記・ワープロ入力業
  9212  複写業
 922  建物サービス業
  9221  ビルメンテナンス業
  9229  その他の建物サービス業
 923  警備業
  9231  警備業
 929  他に分類されない事業サービス業
  9291  ディスプレイ業
  9292  産業用設備洗浄業
  9293  看板書き業
  9294  コールセンター業
  9299  他に分類されないその他の事業サービス業

ここでも結局は、9299他に分類されないその他の事業サービス業 くらいしか見込みがないようです。

「他に分類されないその他の事業サービス業」がどういった業態を想定しているのか調べたところ、
新聞切抜業;鉄くず破砕請負業;船舶解体請負業;集金業;取立業;陸送業;商品展示所;パーティ請負業;バンケットサービス業;レッカー車業;温泉供給業;はく(箔)押し業(印刷物以外のものに行うもの);圧縮ガス充てん業;液化ガス充てん業;液化石油ガス(LPG)充てん業;プリペイドカード等カードシステム業;トレーディングスタンプ業;メーリングサービス業;サンプル配布業;ポスティング業;ちんどん屋;自家用自動車管理業

といった解釈が見つかりました。

金融でななくサービス業としてみなした場合は、「他に分類されないその他の事業サービス業」であり、番号は「9299」にせざるを得ないようです。

2018/06/22(金)13:31 |Comments(0) |Trackback(0)

製造開発 | 電子マネー | 株式・投資・マネー | [編集]

▲ページトップ

こどもの国線におけるICカード改札の動き

こどもの国線は起点・終点を含めて全3駅、かつ起点の長津田駅には自動改札がありません。

長津田駅 ‐ 恩田駅 ‐ こどもの国駅

切符の場合、長津田駅発の場合は降車駅の精算機で収受→精算済証で出場、長津田駅着の場合は乗車駅で自動改札機に通して乗車したのち、長津田駅ではきっぷ回収箱への投入となりますが、全線均一運賃のため、大きな問題は生じていないようです。

PASMO他での動きについては、全国のICカードこれひとつ開発において動きが報告されてきましたので、ここにまとめておきます。

恩田駅


入場 長津田駅出場扱い(恩田駅入場は記録されない)
出場 恩田駅出場扱い


こどもの国駅


入場 長津田駅出場扱い(こどもの国駅入場は記録されない)
出場 こどもの国駅降車扱い


動き方


恩田駅、こどもの国駅、いずれの駅でも特殊な動きをするようです。

恩田駅→こどもの国駅の場合、報告からの推測では次のような記録がされるようです。
①恩田駅乗車時 長津田駅出場を記録(運賃154円)
②こどもの国駅降車時 こどもの国駅出場を記録(運賃154円)

こどもの国駅→恩田駅の場合も、同じです。
①こどもの国駅乗車時 長津田駅出場を記録(運賃154円)
②恩田駅降車時 恩田駅出場を記録(運賃154円)

特に乗り継ぎのような記録はされませんが、運賃については154円×2というわけではもちろんなく、②で①の運賃を打ち消して上書きする扱いになっています。


長津田駅の駅番号


恩田駅、こどもの国駅、いずれの駅でも乗車時は長津田駅の駅番号で、乗車駅の改札機番号をカードに書き込みます。
ですので、乗車については、駅の特定はできず、改札機の特定もできないということになります。

2018/01/22(月)19:40 |Comments(0) |Trackback(0)

地域振興 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

カレンダー

07 | 2018/08 | 09
- - - 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 31 -

プロフィール

miraicorp

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

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

twitterツイッター

管理用

検索フォーム

お知らせ

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

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

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

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

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

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

RSSリンクの表示

QRコード

QR