Pocket Changeの交通系チャージに不具合の疑い

解決済


本件は10月10日に解決した旨、連絡を受けております。
以下に5日に書いたものをそのまま残しておきますが、既に解決しておりますので、Pocket Changeは安心して利用できます。


はじめに


10月5日から、Pocket Changeは交通系電子マネーに対応しました。
京都駅のPocket Changeは動かなくなって久しいので、大阪の難波まで現物を見に行きました。
pocketchange.jpg


WAONとICOCAでそれぞれチャージを試しましたが、ICOCA(交通系電子マネー)のカードへの書き込みが期待と外れており、処理に不具合がある可能性が存在するため、ここにその状況を指摘しておきます。
同内容は既に「お問い合わせ」から報告をしています。

調査対象


大坂難波から徒歩移動可能な次の三箇所を確認しました。

ドン・キホーテ 道頓堀御堂筋店
関西ツーリストインフォメーションセンター 大丸心斎橋店
ホテルエキチカ長堀橋(旧ホテルロア)

WAONは恐らく問題ありませんが、交通系電子マネーについては、この三箇所全てで不正値をカードに書き込んでいました。

状況


交通系ICカードには、SPRWIDと呼ばれる物販端末を一意に特定する番号のうち一部が記録されます。
SPRWIDが分かれば、カード内に書かれる内容は計算だけで求められます。
しかし、レシートに印字されるSPRWIDと、実際にカードに記録されるべき番号が全く一致していませんでした。
これは、次のいずれかが想定されます。

①レシートに印刷されるSPRWIDが間違っている
②カードに書き込む値が間違っている

状況からの判断では、②カードに書き込む値が間違っている ものと思われました。

実際


3店舗で、それぞれ次のような結果となっています。

ドン・キホーテ 道頓堀御堂筋店
 レシートのSPRWID JW10721010990
 期待されるカード内番号 C8-6D2E
 実際のカード内番号 C8-8B8E

関西ツーリストインフォメーションセンター 大丸心斎橋店
 レシートのSPRWID JW10721010984
 期待されるカード内番号 C8-6D28
 実際のカード内番号 C8-71D5

ホテルエキチカ長堀橋(旧ホテルロア)
 レシートのSPRWID JW10721010982
 期待されるカード内番号 C8-6D26
 実際のカード内番号 C8-3DDD

それぞれで1回ずつしか試していませんので、実際にはチャージごとに異なる値が書き込まれている可能性もあります。

30台程度稼働しているらしいPocket Changeに、各契約カードごとに連番でSPRWIDが振られたと考えられ、うち近畿圏ではICOCAのJWから始まるSPRWIDが連番で振られていると見込まれます。
実際この3店は近い番号が付いています。
ということは、レシートに印刷されているSPRWIDに不審な点は見当たらず、恐らく正しいのだろうと判断できます。

一方、カードに書き込まれる値はデタラメで、計算からも導けません。結果として、交通系ICカードに不正値を書き込んでいると判断することができます。


利用者側の対策


一応確認に使ったICOCAは破損せず、不正値が書かれると言ってもカードがめちゃくちゃになるほどの内容ではありませんでした。
しかし動作が不正である以上、カードを破損する恐れもあるので、修正されたというアナウンスがあるまでは利用を控えるべきかと考えます。

2018/10/06(土)10:04 |Comments(0) |Trackback(0)

技術情報 | 電子マネー | 株式・投資・マネー | [編集]

▲ページトップ

パソリRC-S380への対応に成功

このたび、ICカードこれひとつはパソリ(PaSoRi)、以下パソリに対応することができた。

これにより、家電量販店で安価に販売されており、かつまた確定申告の電子申告などにも利用できるパソリを、ICカードこれひとつでも活用できるようになった。
仕様が無償では公開されていないこのパソリへの対応は大変だったものの、無事に解析と対応をすることができた。

種類


パソリは大きく二種類、古いRC-S956チップセットのものと、新しいPort-100チップセットのものとがある。

既に製造中止となった古いRC-S956チップセットのものは、RC-S330/RC-S360/RC-S370が該当するが、こちらは資料が豊富ですんなり対応できた。
一方Port-100チップセットのRC-S380は、資料が非常に乏しく苦労したものの、無事にコマンドを見つけ出し、遂に対応することができた。

安価に済ませる前提の開発であるため解析による実装となり、つまりソニーの認証などはない状態で作っているため動作については弊社が保証する必要があるものの、コマンドの送受信ができるのなら恐らく大丈夫だろうと思われる。

パソリ対応は、Android用カードビューアーとしては他にほぼ例がなく、ICカードこれひとつでの対応は、極めて強力な機能になると思われる。
これは、自信を持って、堂々プレミアムサービスとして提供をする。

以下に、開発で気付いた点をメモしておく。

コマンドの違い


RC-S956とPort-100はコマンドが違う。
どちらもNXP PN533互換のフレーム構造ではあるものの、相互に互換性はゼロで、RC-S956のコマンドをPort-100に投げても無視される。ACKすら返らない。

RC-S956


RC-S956は、NXP PN533でいうNormal information frameで動作する。
00 00 FF LEN LCS TFI … という形式になる。
コマンドもなぜかNXP PN533互換で作られていて、ゆえに無償で仕様が公開されているNXP PN533にならって実装をすれば、古いパソリに対応できることになる。

Port-100


一方Port-100は、Extended information frameでないと動かない。
00 00 FF FF FF LEN LEN LCS TFI … という形式になる。
なぜこのフレーム構造にする必要があったのか、実装を終えてみても分からない。長いフレームを送受信する必要があったのだろうが、解析しにくくすることが目的の可能性もあったのではなかろうか。

そしてここからが大問題で、TFIが異なる。

TFI


TFIは、そのフレームの方向を表わすためのバイトである。

RC-S956は、NXP PN533互換で、送信はD4h、受信はD5hである。
一方Port-100は独自拡張で、送信はD6h、受信はD7hであり、もってNXP PN533非互換となっている。

そして、送受信されるパケットデータも異なり、まずコマンド番号とコマンドの種類が全く違う。
Port-100は、NXP PN533とは全く異なるコマンドセットとなっている。

互換だと何かしら問題があったのか、Port-100では故意に仕様を変更したように見える。

424とはなんぞや


FeliCaの標準は212kbpsであるが、仕様上、212k/424k/848k/1.6Mまでが定義/予約されている。

ICOCAは212だけだが、大容量なためアプリの読み込みが遅いとクレームが多いSuicaは424に対応している。
なら424にして倍速読み込み!と行きたいところだったが、既知の範囲内で424にするコマンドを送っても、以降はコマンドエラーが返るだけとなり、通信ができなくなってしまった。
現時点では、424は使い方が分からないため使うことができない。


MIFAREはやっぱり読めない


Port-100は、MIFARE Ultra lightなどは対応していて当然読めるはずなのだが、今のところRC-S956と同様、読み込みには成功していない。

設定が間違っているのかもしれないし、送信するコマンドが間違っているのかもしれないし、理由は分からないがまだまだ調査・研究をしないとパソリでMIFAREを読み取るのは難しいようである。

2018/09/30(日)21:37 |Comments(0) |Trackback(0)

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

▲ページトップ

パソリで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は試行錯誤しているのですがエラーしか戻りません

失敗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)

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

▲ページトップ

カレンダー

09 | 2018/10 | 11
- 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