2011年10月4日

[felica]FeliCa Liteのこと (1)

最近、忙しくて調べながら書く余裕がない。
なので、記憶に頼って書くことにする。

記憶に頼って書けそうなことと言えば、最近はFeliCa Liteのことくらいだ。


FeliCa Liteは、FeliCaの簡易仕様版みたいなところがある。
データについては暗号などのセキュリティ機能をカード側では持っていない。
3DESで計算した結果は取得できるので、それを使った「改ざんチェック」が行えるだけである。
その改ざんチェックも、カードデータが読み取る側が行う必要がある。
これが「片側認証」と言われるセキュリティである。

 

よって、用途として一番よいのは、データブロックには重要なデータを書かず、会員証のようなカード自身の正当性を確認する使い方ではないかと思う。
スイッチサイエンス社で、1枚350円くらいだ。

ただ、カード単体の値段で見ると、たぶんMifareの方が安いんじゃないかと思う。
UltraLightは64byteくらいのデータしか持てないけど、大量に仕入れたらかなり安くなりそうだ。
次世代のFeliCa Liteが出たら、もっと安くなってよいかも。

 

FeliCa Liteのデータは、200byteくらいだ。
ブロック数が13か14か忘れてしまった(でも調べない)。
1ブロックだけ、回数券風にカウントダウンするデータブロックがある。
今の値より小さな値しか書き込めなさそうなので、未だに試したことはない。

2011年9月30日

[pasori]NfcPcdライブラリの説明 (2)

https://github.com/hirokuma/NfcPcd

 

それでは、続きを。
見られてなくてもいいんだ、いいんだ。。。


このライブラリの特徴は、FeliCa Liteの片側認証をサポートしていること。
SONYさんのサイトにある、FeliCa Lite 個別化カード鍵標準生成アルゴリズムに対応したのだ。

http://www.sony.co.jp/Products/felica/business/tech-support/index.html#Lite04

24byteの個別化マスター鍵から、カード鍵CKを作り出すのだ。
当然、MACの計算もするので、片側認証もできる。
そのためには1次発行もしないといけないので、それもサポート。

ただ、1次発行をきちんとするとFeliCa Liteのシステムブロックに書き込みができなくなるので、ソース的にできるところまでしか実装していない。

 

片側認証をサポートすると、PaSoRiでカードエミュレーションしてIDmやデータ部を偽装できても、CKまでは難しい。
もちろん、カードを入手して、ランダムチャレンジを繰り返せば、そのカードのCKを得ることはできる。
が、各カードでCKが異なるので、被害があるのはそのカードだけに抑えられる。
(全カードでCKが同じなら、発行済みのカード全てが危険にさらされる。)

 

FeliCa Liteにそこまで求めるのか?と言われると困るのだけど、少なくとも「手持ちのFeliCaカードが家の鍵になります」よりは安全だろう。
携帯電話に専用アプリをインストールするタイプならまだしも、どんなFeliCaカードでもOKってことはIDmくらいしか見ないと考えてよいのではないだろうか。

 

と思ったが、FeliCaを使うサービスのセキュリティをSONYさんがチェックしないことはあり得るだろうか?
私が考えつくことくらい、ふさがれているような気がする。
まあ、そっちの方がいいんだけどね。

2011年9月29日

[pasori]NfcPcdライブラリの説明 (1)

https://github.com/hirokuma/NfcPcd

 

私にしてはがんばって作った、PaSoRiをAndroid 3.1以上で使うためのライブラリ。
ちょいと説明をしておこう(といいつつ、「1」なんて書いてしまった)。
もしかすると、使ってくれる人がいるかもしれんし・・・。


私が知らないライブラリを使うときに知りたいのは、どのくらい何をせんと動かないの?だ。

https://github.com/hirokuma/NfcPcd/blob/master/sample/src/com/nfcpcdsample/MainActivity.java

ソースファイルとしては、これくらい書けばとりあえず動く。
このソースは、ボタンを押すとNFC-Fとしてポーリングして、それでだめならFeliCaとしてポーリングして、それでもだめならNFC-Aとしてポーリングする、ということをやっている。
ポーリングするとIDmなりUIDなりが取得できるので、それを出力した後、搬送波を停止させている。

 

Android3.1以上にある「USB Host」機能を使っているが、そこはcom.blogpost.hiro99ma.pcd.UsbHostというクラスに処理をまとめて、あまり手間がかからないんじゃないかな、と思うようにしている。
なので、USB挿抜に関するListenerをimplementsせんといかん。
挿入は、実は通知がないみたいだ。

 

com.blogpost.hiro99ma.pcd.UsbHostでやっているのは、インテントフィルターの登録などだ。
もう少し融通が利いた方がいいのかもしれんが、よくわかってない。
 
とりあえず動かしてみよう、であれば簡単だと思うが、どうだろうねぇ。
 

2011年9月27日

[C++]参照もforward classでOKなの?

Qtの魅力は、画面作成をGUIでできることじゃなかろうか。
昔の私は「GUIで作ると汎用過ぎて描画が遅くなるじゃろう」と相手にしなかったのだが、歳をとった。
作りやすさと、メンテナンスの容易さ、そして組み込み機器の高速化など、いろいろな要因があるのじゃ。

 

まあ、それはいいや。

 

Qt Labのページを見ながら、ブラウザを作ってみた。
うん、書いてあるとおりにやるだけでたいがいのことはできそうだ。

さて、ここでURLを扱うQUrlというクラスを扱う必要があった。
引数なのだが、参照型だ。

func(const QUrl& url)

こんなの。
説明には「class QUrl; がいる」とあるのだが、ポインタならまだしも、参照も同じようにやれるのか?

まあ、やってみると確かにそうだった。
参照って、どういう解決のされ方をしてるんだろう?

ポインタの場合、引数はアドレス値を渡すだけだから、ポインタ型の一般的なサイズさえわかればいい。
だから名前解決するだけのforward class(クラスの前方参照、という訳でいいのか?)でよいのだ。

実体の場合、コピー渡しになるので、classのサイズがわからないとスタックを使う量が決まらない。
なので、includeが必要になる。

参照は、既に存在するメモリをそのまま使うので、スタックは必要ない。
そういう意味ではポインタと同じような扱いになりそうだ。アドレスを渡す必要もないけど、結果としてはアドレスなのかな?
あるいはレジスタでそのまま・・・とかはコンパイラレベルの話になりそうだ。

気にはなるが、もう寝よう。

2011年9月25日

[a500]フレキを修理してみよう

SANY0001

 

断線が確認できるのは、丸で囲んだところ。

これ以上引っ張り出せないので、このままやらんといかん。
うーん、難しい・・・。

このフレキは、LCDコントローラっぽいところにつながっている。
ピン数は8本なのだが、そのうち3本がつながってて太い線になっている。
ってことは、たぶん8bitデータバスになっていて、下位3bitはいらない(5bit制御?)ってことなのだろう。

 

いや・・・もっと冷静に考えねば。
普通は一番太い線はGNDではなかろうか。
いやいや、そもそもそんな推測をするよりも、全部ちゃんと接続しないといかんだろう。
ここで手抜きをしても意味がない。

ないけど・・・大変だ・・・。

2011年9月24日

[a500]フレキの位置が悪いこともいいたい

確かに、私はフレキに圧迫をかけ過ぎた。圧迫祭だった。
しかしこの構造はどうなの?と思う。

 

lcd

私が見たとき、すでにこんな断面だった。
作ってる側もフレキの折り曲げ部分が気になっているのだろう、補強したりしていた。
私のA500は、フレキの上にカプトンではなく黒いビニルテープみたいなものがあったのだが、なんとなくはがしそうになった形跡が見えた。
これはもしかすると、工場の人が作ったときに「まずい」と思って、ちょっとはがそうとした形跡じゃなかろうか。
まあ、蓋を外した時点でそういう推測がもう無意味なんだけどね。

フレキを折り曲げるとき、間に丸い棒みたいなものがあればここまでひどく折れ曲がることはないと思う。
けど、それをやるとコストが高くなるし、そもそも工場でそれをやるのは難しかろう。
そんなわけで、これは設計が悪いといわざるを得ない。

安いから仕方ないんだよ。
私が不良品扱いにしなかったのが悪かったんだ。
それはわかっているんだけど、もうちょっと製品の品質は高いと思ったんだけどなぁ。

[a500]反省の弁

買ったものを分解するのは、仕方ないことだ。
たくさんのものを分解し、たくさんのものを壊してしまっている。
しかし、壊した分、知識も増えていったと思う。
仕事で壊すより、自分のものを壊した方が精神的にもいいしね。
(いや、よく壊すけどさ。。)

 

さて、今回A500の液晶を使えなくしてしまった件の反省をしよう。

まず1つ思いつくのは、紙を挟むという考えが安易すぎたこと。
なぜフレキの上に紙を挟もうと思ったかというと、フレキを押すとバックライトがちかちかしたからだ。
よくわからないが、きっと圧迫される力が変化しないようにすればいいと思ったのだろう。
そして、それは最初うまくいったのだ。
しかし何度も蓋を付けたり外したりしているうちに、紙がフレキを押したり離したりして、負荷が高くかかってしまったのだろう。

いつしか、フレキは切断されてしまった。


しかし、私はフレキに詳しくない。
もしかすると、切断されていないのかもしれない。
それに、切断されているのならば接続すればいいじゃないの。

さっき、全部分解して、見た。
フレキの接続は私には厳しい。
液晶と切断の部分が近くて、どうしていいかわからん。
本数は少ないのだけど、ここは技術のなさが哀しい。

本体側っぽい基板とLCDとは、なんか太めのケーブルで接続されている。
ここが大丈夫なら画面は出そうな気がなんとなくするなあ。
もしフレキがバックライトの制御しかしていないのならば、本数が少ないのも頷ける。
LVDSはシリアルだから本数が少ないのだろうと思ってたけど、バスで照明レベルの制御をしているとか。

 

まあ、わからんけどね。
とりあえずヤケ酒を飲もう。

[a500]やはり初期不良で修理すべきだった・・・

液晶のバックライトが、A500の持ち方によってちかちかする。

まあ、それくらいだからいいと思っていたのだが・・・。


ネットの情報を見ながら、分解。

きっと、バックライト部分の接触が悪くなっているんだろう、くらいの気持ちだった。
分解は比較的簡単で、精密ドライバ2本でできた(少し傷はついたが、あまり気にしない)。

「持ち方によって」というのは、A500を電源ボタンを上にして持った場合の左下、USB付近の押さえ方次第なのだ。
なぜか、そこに力を軽くかけるだけでバックライトの付き方が変わる。
不思議なものだ。

分解してみると、そこにはUSBのコネクタしかない。
やはり押すとちかちかするし、USBのコネクタを外すと押してもどうもない。
しかし・・見たところUSBが関係していそうにない。

その下を見ると、保護テープっぽいものが少しめくれていた。
そこには、フレキがあった。
フレキを押すと、ちかちかしやすい。
うーん、フレキの接触不良は手が出せないな・・・。

圧迫しにくいように紙を挟んでやると、なんかよさそうだ。
よさそうだった。

その程度にして、さっさと蓋をつけなおした。


蓋をつけると、SDカード部分を覆うカバーが動かなくなってしまった。
どうやら、蓋に押さえつけられてしまったようだ。

しかたないので、蓋をまた外して、つけて、を3回くらい繰り返して、なんとか動くようになった。

そして電源を入れると・・・画面が表示されない・・・。
緊急事態だ。

きっと、蓋を外すときに精密ドライバで切ってしまったに違いない、と思ったのだが、どうもそうでもない。
紙を置いたフレキは、よく見るとL字になって角に沿っているのではなく、まったく折り曲げられているようなのだ。
そこに紙を置いて圧迫度が増してしまったために、完全に断線してしまったのではなかろうか。

とにかくまあ、広い液晶画面が使えなくなってしまったようだ。


HDMI出力は有効で、今はテレビに映し出して使っている。
マウスとキーボードが使えるので、そこまで困らないかもしれないが、効率は悪いな。

SDK for NFC Starter Kitを試す

3連休なので(といいつつ、昨日は仕事だったのだが。。)、SDK for NFC Starter Kitを試してみた。
SDK for NFC Starter Kitはこちらから。

作ったサンプルは、githubに置いた。
やるのは、Type-AとFeliCaのUIDを表示するだけ。

https://github.com/hirokuma/Felica1

こんなので正しいんだかどうだか・・・。


C#で作ったのだが、いろいろと手間がかかった。

サンプルをそのままビルドさせても動かなかったが、これは開発環境が推奨されているものじゃないからかも。
うちは、Visual C# 2010 Expressでやっているのだ。
DllImport周りに設定が必要だった。

C#でのメッセージ受付がよくわからずに困ってた時間が長い。
単にHWNDの取得方法を間違ってただけだった。

よくわからないのが、felicalib_nfc_stop_dev_access()直後にfelicalib_nfc_stop_poll_mode()を呼ぶと固まってしまうこと。
間にsleepを挟めばなんとかなったのだが、stop_dev_access()が非同期なのかな?

2011年9月20日

No funciona

SDカードなどのmount/unmountを実施するEjectSDアプリ。
昨日はアイコンだけ(機能に変化無し・・・)でアップしたのだが、コメントが増えていた。

 

No funciona en galaxy s

 

どうやら、GalaxySでは動きません、というスペイン語らしい。

スペイン語を1つ覚えた(のか?)のはよかったが、動かんのか・・・。

 

持っていないので確認できないのが困ったところだ。
まあ、まずは先にアイコン再描画を考えた方がいいのかもしれんが、別のこともやりたいしなぁ・・・。