LEGO　USB TOWERのHack

はじめに

RIS2.0には、USB接続のIR Tower "LEGO USB TOWER"が含まれます。

これに関する、非公式の有象無象を置くページです。

Hackingが、犯罪だと思っている方、HackerとCrackerの区別がつかない方、違いを知っていながら、わざと誤用している方は、この先「侵入」しないでください。Hackerを正しく理解する予定の方は、先にこちらをどうぞ。

また、「USB TowerとRCX」が通信できないなど、基礎的なトラブルで困っている方は、別のページを作りましたので、そちらを先に読んでください。

Auto offするか？

COM Port接続のIR Towerは送信後、数秒経過すると自動的に電源が切れました。電源の切り忘れを防ぎ、電池の寿命を延ばすのには、非常に有効でしたが、受信動作も止まってしまうため、RCXからMessageなどを送信し、パソコンが受信状態でこれを待って動作するような連携プログラムは、正しく動作できませんでした。

USB TOWERは、USB BUSから電源を取っているため、電池は必要ありません。しかし、緑のLEDは送信終了するとやはりすぐ消える様です。やはり待ちうけ受信は出来ないのでしょうか？

MindStorms情報局のQ&A掲示板に寄せられた質問に私が実験して判明したことを再録します。

これを調査するため、まず、受信だけを行うプログラムを作成しました。そして、MessageをおくるNQC ProgramをRCXにのせ、受信プログラムでこのメッセージを受信しながら、反応を調査しました。

LEGO USB TOWERの場合、緑のランプが消えていても受信待ちになっていれば、IR Packetを受信すると緑のランプが点灯し、プログラムは正しく受信することが出来ます。

また、legotower1をOpenし受信待ちにしただけでは、LEDは点灯しません。

受信待ちになっていない場合も、正しいパケットを受けると、一瞬LEDが点灯しますが、すぐ消灯します。この場合は、続けてパケットを送っても、消灯して、次に受信待ちになるまで、点灯することはありません。

こうして、受信待ちでないとき、データーを受信したのち、プログラムを起動し、受信待ちに移行すると、その時点では、パケットを受信していなくても、LEDが点灯しデーターを取得できます。ただし、このデーターは壊れたパケットでした。

まとめると、

  1. LEGO USB TOWERはPCに接続した状態では、緑LEDの点灯の有無にかかわらず、能動状態にある。
  2. このLEDは、データー送信、受信、ホストへの受信パケットの転送で点灯するらしく、単にOpenしただけでは点灯しない。
  3. 受信バッファーがあり、受信待ちでない場合もデーターが蓄積されるが、この容量は小さく、すぐに溢れるらしい。受信データーを利用する場合、最初に得られたデーターは、openする前に受信した壊れたデーターであることを想定し、プログラムを製作する必要がある。

　

ScoutとLEGO USB TOWER

LEGO USB TOWERをRCXと通信させると、COM IR Towerとは、多少挙動が違いますが、データーには異常なく通信できることは、上記からも解るとおりです。ところがRDSに付属するSCOUTでは、どうもデーターにエラーを生じる様だということが分かりました。NQCをUSB LEGO Towerで使えるようパッチしても、RCXではうまくいくのに、Scoutはエラーが頻繁に起こりうまくプログラムをDownload出来ないのです。

エラーの正体を探るため実験を行いました。

まず、Pingを投げて、返事をダンプするだけのプログラムを作り、どのような応答をするか調べました。

正常に通信できるRCXのROM firm と異常が起きるScoutを比較します。また、USB LEGO Towerの出力によっても差が出るか調べました。「RCXのL」のようにDUTとTowerの出力を表すことにします。

Ping Packetを100個投げ、その応答パケットを多い順に並べました。

実験はわざとエラーを起き易い状態にするため、Tower / DUT(Device Under Test:　被検査機器)を20cm離し、角度を付けて光軸をずらしています。

発生回数　: 応答で示します。

RCXのL

76 55 ff 00 ef 10 ef 10
6 55 ff ef 10 ef 10
5 55 ff 00 ef 10 ef
4 55 ff 00 ef ef 10
2 55 ff 00 10 ef 10

RCXのM

68 55 ff 00 ef 10 ef 10
4 ff 00 ef 10 ef 10
4 55 ff 00 ef ef 10
4 55 ff 00 ef 10 ef
4 55 ff 00 ef 10 10
2 55 ff ef ef 10
2 55 ff 00 10 ef 10

RCXのS

48 55 ff 00 ef 10 ef 10
11 55 ff ef 10 ef 10
9 55 ff 00 ef ef 10
8 55 ff 00 ef 10 ef
4 ff 00 ef 10 ef 10
4 55 ff 00 10 ef 10
3 55 00 ef 10 ef 10
2 55 ff 00 ef ef
2 55 ff 00 ef 10 10

ScoutのL

35 ed 00 ef 10 ef 10
28 b5 00 ef 10 ef 10
16 00 ef 10 ef 10
10 55 ff 00 ef 10 ef 10
8 d5 00 ef 10 ef 10
2 ff 00 ef 10 ef 10

ScoutのM

50 ed 00 ef 10 ef 10
19 00 ef 10 ef 10
10 b5 00 ef 10 ef 10
7 d5 00 ef 10 ef 10
5 fb 00 ef 10 ef 10
2 ff 00 ef 10 ef 10
2 f6 00 ef 10 ef 10
2 55 ff 00 ef 10 ef 10

ScoutのS

55 55 ff 00 ef 10 ef 10
36 d5 00 ef 10 ef 10
5 00 ef 10 ef 10
2 ff 00 ef 10 ef 10

つまり、55 ff 00以外にff 00 / ed 00 / b5 00 / d5 00を、ヘッダーとして見とめてしまえば、成功率が高まる事が予想されます。

実際NQCにパッチをして、上記のものも正しいヘッダーと認めてしまうように改造し、Towerをshortにして光軸を合わせれば、10中8,9プログラムのDownloadに成功します。

予想される原因なのですが送受切り替えのタイミングというよりUSB Towerの、IR LEDと受信モジュールの干渉が大きい様に思います。

RCXとScoutの応答時間の差異は影響していると思いますが、それだけでは、IRT側の送信強度で、受信状態に変化が起こることを、説明しにくいと思います。

私が予想したモデルは以下の通りです。

受信モジュールはAGCといって入射した信号の強度によって、出力を一定にするようゲインを自動調節する仕組みが入っています。

COM　IRTに比べUSB IRTは送信指向性を向上させるため、3個のLEDを多方向に向けて付けました。これにより発射した赤外線が、自分の受信モジュールに強く受信される様になりました。

赤外線信号は振幅変調(on/off)で送られるため、AGCは符号速度よりかなり遅く応答する様にしなければなりません。自分の信号で送信中はゲインを最低にしていた、IRTの受信モジュールは、Scoutが送信を開始する時期になっても、受信に適したゲインまで戻る事ができず、受信シグナルの先頭部がエラーになる。

このモデルなら送信強度が強いほど、AGCが強くかかる事で、Long Modeのほうがデーター欠損が多い現象を説明できるかと思います。AGCのかかり具合を外部から観測できれば直接実証できるのですが受信モジュールは1 chip ICなので、これは観測不能です。

このことを、BBSで発表すると、JinSatoさんより、「LEDの光がIR受信モジュールに直接入らないようにして実験すれば...」という、アイデアを頂きました。

早速実験しました。

ケースを開けレシーバーの下にアルミホイルを挟み、わざとlong rangeにしてScoutと前同様Pingを送って通信させた場合と、そのまま、位置を変えず、アルミホイルを引き抜いた時の比較です。

シールドあり

99 55 ff 00 ef 10 ef 10
1 ff 00 ef 10 ef 10

シールドなし

36 d5 00 ef 10 ef 10
26 00 ef 10 ef 10
24 55 ff 00 ef 10 ef 10
7 ff 00 ef 10 ef 10
7 b5 00 ef 10 ef 10

直接赤外線が受信モジュールに入らないようにすると劇的にエラーが減ることから、上記の仮説は、かなり強力な傍証を得ました。この現象をその他の原因と結びつけるのは、かなり無理があると思います。

以上の実験考察は、実際には、MindStorms情報局の「やってみよう」BBSで発表したものを後でまとめなおしたものです。

多くの有用なアドバイスを下さった、JinSatoさん、清水友人さん、ききょうやさんにあらためて感謝します。

さて、上記を書いたのは、2001年1月でしたが、2003年1月にKYUSHIMA Masahiroさんより、実際アルミホイルでシールドしようとしたが、回路をショートさせ危険だったとのレポートを頂きました。ご連絡に感謝します。

私は実験に一時的に使うため、安直にアルミホイルを直に使いましたが、恒久的にこの改造を行うのなら、かなり危険です。かといって、黒く見える合成樹脂は、意外と赤外線が透過します。

安全で効果の高い方法として、ビニール袋に両面テープでアルミホイルを貼り付け、そのビニールの裏側にも両面テープをつけて、基板に貼り付けるのが、良いかと思います。とはいえ、純正品に改造をくわえることには変わりないので、実施する場合は、ご自身の責任において行ってください。

何台つなげるか？

USB接続は、HUBを繋げば、PCに設けられたPortの数にかかわらず、拡張して多数接続可能です。1 portに１つの機器しか繋げない、COM Portとは違い、LEGO Towerも同時にたくさん繋ぐ事ができるのではないか？そんな期待ができます。

とはいえ、今のところUSB LEGO Towerを単体で追加購入する事はできないので、個人で多数のLEGO Towerを集めて実験するのはちょっと困難です。

そこで、「お気軽コンテスト」の打ち上げオフ会として恒例の「もんじゃストーム」の開催に合わせて、有志の方にLEGO Towerを持ってきていただき、公開実験する事になりました。

桐林さん撮影

OSAMUさん撮影

2001年１月13日、5台のLEGO TowerをHUBに接続し、実験しました。

NQC usbパッチ付き

ききょうやさんが、NQCをUSB対応にしたものを使いまず実験しました。5台のうち、3台がアクセス可能で、それぞれ、

で接続出来ました。

コントロールパネルの「USB LEGO タワー」で確認すると、3台は正常に動作可能で、残り2台も認識はされているのですが、エラーで使用できない状態になっている事が分かります。

USB Plugをいろいろなタイミングで挿しなおしましたが、使用できるようにはなりませんでした。1台のパソコンによる、1時の試験ですので、他のパソコンやOS、環境によっては、状況が変わる可能性は残っていますが、この時の実験結果としては、同時3台が接続台数の限界でした。

同時OPEN

NQCでは、当然1つのIR Towerだけを使いますので、3台接続できるといっても、起動する度に別のIR Towerにアクセスしました。本当に同時にアクセスできるか、調べようと思い、別に簡単なプログラムを用意して、実験しました。ななしのさんが、作ったUSB LEGO TowerのVLL送信プログラムvll.cをもんじゃストームの前の晩に、大幅かつ、いいかげんにhackしてでっち上げたものです。

実際に走らせると、3台のLEGO Towerがopenでき、同時にVLL信号を送信可能でした。

謝辞

この実験は、貴重なUSB LEGO IR TOWERをお貸し下さった方はもちろん、実験にお付き合いくださった、もんじゃストーム参加者の皆さんのご協力で実施できました。あらためて感謝いたします。

中身

内部写真です。クリックすると拡大して見られます。

　

　

USB Snoopyの飼い方

中身は見えても、USB Targetは1 Chip CPUでほとんどの処理をしてしまうため、あまり面白いものではありません。だからと言って、CPUからプログラムを盗み出すような、お下品なHackは、いやですね(^o^)

正統流Hacker（かどうかは知らないけど）は、USB DeviceとHost　PCの話を聞いて中身の動作を理解しましょう。もちろん素手で、そのようなことは出来ませんし、専用機器のUSB アナライザーは、高価ですのでおいそれとはいきません。

しかし、先人がソフト的にWindowsとUSB Targetの会話を傍受するツールを作って公開してくださってます。ありがたく利用することにしました。

USB Snoopyと言うツールで、

http://www.jps.net/~koma/

から、Downloadできます。

展開すると、dbgview, filter, uiと言うフォルダーと、readme.txtが出来ます。当然readme.txtをしっかり読んでいただきたいのですが、Quick Startの手順だけまとめましょう。

  1. filter\Debug\UsbSnoop.sysをWindows\System32\Driversにコピーする。
  2. ui\Release\SniffUSB.exeとdbgviewを使い易いところへ移動するか、ui\Release\SniffUSB.exeとdbgview\Dbgview.exeにショートカットを作り、適当な場所に並べておく。
  3. DbgviewとSniffUSBを起動する。
  4. SniffUSBの窓には、そのマシンで使ったことがある、USB Deviceがリストされているはずであり、VID_0694&PID_0001 LEGO TOWERも見えるはず。
  5. VID/PIDの内、傍受したいものをクリックして選び、Installを押す。
  6. その後、そのデバイスとの通信は、Dbgviewの窓にDumpされる。

簡単ですよね。

当然の事ながら、LEGO TOWERとの通信だけをDumpし、それも出来るだけ、プリミティブな操作を記録していきます。

まず、私はコントロールパネルで「LEGO USB タワー」を使い、IR Powerの切り替え、IR / VLLの切り替えをしてみました。いらない部分を取り、Excel Fileにしたものを公開します。

色が異なる部分が、違いがあるところですが、多くはPipeのアドレスが違うなどで、結局コマンドとしては、

URB_FUNCTION_VENDOR_DEVICEでValueを変えるのみです。(Line 15, Line 80)

Value = YYXX

XX

01 IR / VLL切り替え
02 Power切り替え

YY01

01 VLL Mode
02 IR Mode

YY02

01 short
02 Midium
03 Long

以上の様に、現在のところ想像してます。

linuxに接続したときどのように認識されるかここにlogをおいておきます。

MindStorms SDK2.5

これまで書いた内容は、2001年1月現在の情報です。

その後、2002年12月に、LEGO社は、MindStorms SDK2.5を公開しました。

これには、USB Tower APIに関する詳細な資料が含まれていて、もはやUSB Snoopyで解析する必要はなくなりました。SDK2.5については、別のページで説明しようと思います。

MindStormsの洞窟に戻る

Google