本書では、ShuttleのNAS「KD22」 の情報を細々と掲載する。 例によって2Drive NASをRAID1以外で使うなんて怖くて怖くて！という理由で、 ここでは基本的にRAID1(ミラーリング)構成 のみを対象とし、RAID0などその他のモードは試していないことに注意。 ここで示した殆どの情報は、KD20、KD21でも共通に使えるはず。
なお、ファームウェアは2.02.20140721(2014/08/18現在最新)で確認している。
KD22は色々エンジニア心をくすぐる設計なんで、ずっと中を見てみたいと思ってた。 ら、Tsukumoが新品をお安く売ってた(※つまりモノがあんまよくないという証左)ので、 ヒャッハー！ということで購入してしまったよ！13000円で本体入手できたと思えば まぁ遊びとしてはよかったんじゃなかろうか、と。 HDL2-Aでは大体もう遊び尽くしちゃったしー。
このページの情報は一切無保証で、誤っている可能性もあることを 先に了承すること。このページを見て操作した挙句、アナタに何か不利益な ことが起こったとしても、我輩は一切それに関知しない。何もかも自己責任。
本機は、ARM Linuxを採用している。
内部にフラッシュメモリがあり、OS起動用の領域はそこに格納されている。
従って、二つのHDDが両方破損しても、起動はできるしWebUIでアクセスも可能。
このへんはHDL2-Aに比較するとよくできててユーザに優しいところ。
初期状態(RAID1でフォーマット)でのCrystalDiskMarkの結果はこんな。writeの方が
高速なのが、つまり「書き込みキャッシュされてるから瞬断には弱い」ということを
如実に表している。UPSが欲しいところ。
HDL2-Aと同じ安物HUB経由してるが、それにしても110MB/s(RAID1かどうかは不明)とか
ゆってんだからもう少し頑張ってほしかった。
これだと(HDDの性能差とか考慮したとしても)HDL2-Aの方がオトクな気がする。
向こうは4TBx2のHDDは公式には載せられないけれど。
電源Onからアクセス可能になるまでは一分15秒程度、結構起動は高速。 少なくともHDL2-Aみたいに三分もかかったりはしない。助かる。 停止も一分以内には止まるのでよろし。
…ところで停止方法は(WebUI経由じゃないときは)電源ボタン長押しでいいのかね？ そして電源ボタンちょっと押しの時の動作(電源ランプは消えるが動いてるっぽい)は なんなんだ…？。マニュアルにも書いてないようなんだけど。
起動時のdmesgはこちら。色々わかって面白い。 ttyS0が存在するし、kernel commandlineにconsole=ttyS0,115200があるから、 デフォルトでシリアルに情報は出てるんだね、というのがわかったり。ウッホゥ。
でも残念、SATAは3Gbps接続なんですな。6Gbpsはやっぱ無理かー。 SSDに交換して爆速！とかちょっとやってみたかった(※SMB経由なら意味がない)。
ちょっとゴニョゴニョした結果、以下のように構成されていることが分かった、 四つflashがあって、それぞれ以下のようにイメージが記録されている。
実際KD22上で/proc/mtdを見るとこんなカンジ。
> cat /proc/mtd dev: size erasesize name mtd0: 00100000 00010000 "spi_flash" mtd1: 00800000 00020000 "kernel" mtd2: 00600000 00020000 "initrd" mtd3: 07200000 00020000 "rootfs" |
rootfs(/dev/mtd3)は、rootfs.ubiファイルをそのまま流し込んだもの。
ゴニョゴニョして入手したrootfs.ubiファイルは、
以下のような手順を実行することで、
nandsimモジュールとubifsを使って(nandsimとubifsが使用可能な)フツーのLinux上で
mount可能。我輩はCentOS6で確認した。
mtd-utilsをどっかから入手したりしないといけなくて少々面倒だけど。
あ、(KD22ではなく)KD21のrootfs.ubiはここから入手できたりする。中はほとんど同じなので見てみるといいかも。
そしてここからが大事な話なんだけど、実は中を見ると…うッ貴様は！？うわなにをするやめふじこ！(深刻なエラーが発生しました)。
# # 128MiB, 2048 bytes/page であることに注意 # modprobe nandsim first_id_byte=0xec second_id_byte=0xa1 third_id_byte=0x00 fourth_id_byte=0x15 # ubiformat -s 2048 -f /tmp/rootfs.ubi /dev/mtd0 # modprobe ubi # ubiattach /dev/ubi_ctrl -m 0 -O 2048 # mount -t ubifs -r /dev/ubi0_0 /mnt |
フツーのLinux上でのmtdinfoとubinfoの出力はこんな。ここでは便宜上デバイス名が /dev/mtd0になってることに注意。
# mtdinfo /dev/mtd0 -u mtd0 Name: NAND simulator partition 0 Type: nand Eraseblock size: 131072 bytes, 128.0 KiB Amount of eraseblocks: 1024 (134217728 bytes, 128.0 MiB) Minimum input/output unit size: 2048 bytes Sub-page size: 512 bytes OOB size: 64 bytes Character device major/minor: 90:0 Bad blocks are allowed: true Device is writable: true Default UBI VID header offset: 512 Default UBI data offset: 2048 Default UBI LEB size: 129024 bytes, 126.0 KiB Maximum UBI volumes count: 128 # ubinfo -a UBI version: 1 Count of UBI devices: 1 UBI control device major/minor: 10:59 Present UBI devices: ubi0 ubi0 Volumes count: 1 Logical eraseblock size: 126976 bytes, 124.0 KiB Total amount of logical eraseblocks: 1024 (130023424 bytes, 124.0 MiB) Amount of available logical eraseblocks: 0 (0 bytes) Maximum count of volumes 128 Count of bad physical eraseblocks: 0 Count of reserved physical eraseblocks: 10 Current maximum erase counter value: 3 Minimum input/output unit size: 2048 bytes Character device major/minor: 250:0 Present volumes: 0 Volume ID: 0 (on ubi0) Type: dynamic Alignment: 1 Size: 1010 LEBs (128245760 bytes, 122.3 MiB) State: OK Name: rootfs Character device major/minor: 250:1 |
今回は、Seagate 4TB(ST4000DM000)と HGST 4TB(0S03361=HDS5C4040ALE630)をつっこんで構築してみた。この二つは いずれも同じセクタ数(=7814037168(512byte/Sectorの場合))なので、相互に 交換できて便利。
KD22でディスクをつっこんでRAID1で初期化すると、ディスクのパーティションは 以下のように作成された(Seagate側)。4TBなので最初からGPT。
# parted -s /dev/sda print Model: ATA ST4000DM000-1F21 (scsi) Disk /dev/sda: 4001GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 16.8MB 226MB 210MB primary raid 2 226MB 331MB 105MB primary 3 331MB 1405MB 1074MB primary raid 4 1405MB 4001GB 3999GB DataVol raid |
セクタ単位で表示するとこんなカンジ。スタートセクタは全て8で割り切れるので、 ちゃんと4KB/SectorのHDDにもコピーできる。ちうか、ST4000DM000って512byte/sector だったのん？partedからは見えないだけなのかな。
# parted -s /dev/sda u s print Model: ATA ST4000DM000-1F21 (scsi) Disk /dev/sda: 7814037167s Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 32768s 442367s 409600s primary raid 2 442368s 647167s 204800s primary 3 647168s 2744319s 2097152s primary raid 4 2744320s 7814035455s 7811291136s DataVol raid |
パーティション構成は以下の通り。
フォーマット直後、４番目のデータパーティションを別のLinuxシステム上で確認 したら、disk と.omninas.tmpというディレクトリしか存在しなかった。そして、 .omninas.tmpの下にはTwonkyサーバ( DLNA サーバ)用のファイルが存在した。なるほどなるほど。 これ以下の具体的なファイルリストはヤバそうなので出さない。
# ls -al . total 4 drwxr-xr-x 4 libuuid root 48 Jan 1 2013 . drwxr-xr-x 4 root root 0 Aug 18 03:31 .. drwxrwxrwx 3 root root 28 Aug 16 23:25 .omninas.tmp drwxrwxrwx 19 root root 4096 Aug 17 15:58 disk total 4 # cd .omninas.tmp # ls -al . drwxrwxrwx 3 root root 28 Aug 16 23:25 . drwxr-xr-x 4 libuuid root 48 Jan 1 2013 .. drwxrwxrwx 9 root root 4096 Aug 17 00:29 .twonky |
DTCP-IPが同時にサポートされているかどうかは未調査。誰か我輩に 確認可能なREGZAとか送ってください。 あ、HDDは4TB以上でBlu-rayが読めるヤツがいいです(傲慢)。
上で述べたように、データパーティションは４番目のでっかいパーティション。 ここは、LinuxのSoftwareRAID(md ... Linux Multi-Disk)でRAID0またはRAID1を 構成した上でxfsでフォーマットされている。
具体的には、md version 1.2が利用されており、パーティション先頭にこんな データがある(xxはUUIDなので削除)。md名称として、ホスト名+":1"を書き込むみたい。 0x100000からはxfsが始まる。
# dd if=/dev/sda4 | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 fc 4e 2b a9 01 00 00 00 00 00 00 00 00 00 00 00 |.N+.............| 00001010 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx |................| 00001020 6b 64 32 32 2d 73 6e 61 72 61 79 2e 6d 79 64 6f |kd22-snaray.mydo| 00001030 6d 61 69 6e 2e 63 6f 6d 3a 31 00 00 00 00 00 00 |main.com:1......| 00001040 b4 76 e2 50 00 00 00 00 01 00 00 00 00 00 00 00 |.v.P............| 00001050 f0 ce 96 d1 01 00 00 00 00 00 00 00 02 00 00 00 |................| 00001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001080 00 08 00 00 00 00 00 00 00 d0 96 d1 01 00 00 00 |................| 00001090 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000010a0 01 00 00 00 00 00 00 00 3f 15 dd 3f 77 ce 89 cd |........?..?w...| 000010b0 2c cb 3a ef 2e c5 00 30 00 00 00 00 00 00 00 00 |,.:....0........| 000010c0 0c ef f0 53 00 00 00 00 02 00 00 00 00 00 00 00 |...S............| 000010d0 ff ff ff ff ff ff ff ff dd 22 e6 ad 80 01 00 00 |........."......| 000010e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001100 00 00 01 00 fe ff fe ff fe ff fe ff fe ff fe ff |................| 00001110 fe ff fe ff fe ff fe ff fe ff fe ff fe ff fe ff |................| * 00001400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00100000 58 46 53 42 00 00 10 00 00 00 00 00 3a 32 d9 de |XFSB........:2..| 00100010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| (snip) |
0x1000からの "fc 4e 2b a9" が、mdのマジックナンバー。メジャー番号はその次の 4byte(=0x00000001)で、先頭から 0x1000(=4096)の位置にあるので、これは md version 1.2 であることがわかる。詳細知りたい人は RAID superblock formats参照。
このmdマジックナンバーは「パーティション先頭+4096byte」に存在する。 ということは、"mdadm --assemble /dev/md0 <デバイス>" でmdを有効にしない限り、 xfsでmountすることもできないということだ。しかも困ったことに、一方のHDDだけで mdを有効化すると、mdヘッダ中のctimeが変わってしまい、もう一方と整合性が 取れなくなってしまって、次にKD22に接続して電源Onした時に、 RAID0ならRAID崩壊、RAID1ならRAID再構築が自動的に開始されちゃうという めんどくささ。だから、よくわかんない状態でLinux PCに接続するとかしないほうが いいと思う。
ただ、md version 1.2であるおかげで、 ディスクサイズの上限は4TBをらくらく超えることができる。 このあたりはHDL2-Aよりもイイ。
最初に言っておくが、「分解はしないほうがいい」。ポリシー的なこともあるし、 保証の話もあるが、それよりもなによりも、KD22の分解は異様に難しいから。 どうやっても本体に傷つけちゃうし、一部爪は絶対破損しちゃうし。 やっぱこう、世界にKD2xの分解記事がほとんどないのは、分解が難しいからだろうなぁ、と思う。 だから、 どうしてもファンが壊れて交換しないとだめだとか、そういう理由が無い限りは 分解しないことを強くおススメする。
…ということを前提に、以下分解手順とか。この手順は、KD20、KD21共に共通のはず。
でもなー、解析するためにシリアルポートがどこにあるかとか知りたいんだよなー…。
分解の最初にして最大の関門がコレ。正面向かって右側の板(後ろに回りこんでる)を 外すこと。これがもうケース叩き割りたくなるくらい難しい。 ネジ二本と爪で固定されてるんだが、爪の数が尋常じゃない。 コの字型のアルミケースが広がるのを防ぐための「広がるのを防ぐ爪」と、 ガワが外れるのを防ぐための「ガワを留める爪」の二種類があって、 それぞれが反対方向にガッチリハマっているため。 こんなの傷付けずにバラすの無理って！
まず、前面蓋の蝶番部分の奥に見えるネジを二本外す。 このネジは、フロントパネル(蓋じゃなくてHDD収める部分ね)と右ガワとケース内の プレス板の三つを固定させるために使われていて短い。 まぁコレは外すだけだから楽。
そしてここからが本番。 後で外したガワは見せるとして、実際には右ガワは後ろから外す。 後面の「アルミケース＋プラスチックホルダとガワの間」にマイナスドライバなどを ツッコんで、赤印裏にある三つの爪(ガワからケース内部方向に向かって伸びている)を 外し、ネットワークとUSBの端子がガワに引っかかるのを注意深く避けながら、 矢印方向に向かって3mmくらいスライドさせる。
ほらもうイヤになってきたでしょ！？ この時点で、プラスチック部分にはマイナスドライバーで著しい傷がつくこと間違いなし。
側面から見ると、赤印部分の８箇所で、右ガワがケースに爪で固定されている。 こちらは爪の出方が背面とはオスメス逆で、 「ケースから出た爪が右ガワの□型にハマっている」ことに注意。 だから、こっちを外す時は、爪部分を狙ってまっすぐ「水平方向に」マイナスドライバーをネジこめれば綺麗に外れる。んだけど、まぁ無理。いくつかの爪が破損することは諦めるが吉。
というか、正直この爪は要らんかったんじゃないかと思う。 だってケース前方でネジで固定されてるんだから。分解させたくないのかしらん。 そりゃそうか。
外した右ガワを見るとこんなカンジ。もうこれが外れれば大体全部分解は 終わったものと考えていいんじゃないか。 「やり遂げた男の顔」になってもいいと思う。爪の位置を赤印で示した。 全部で１１箇所。なんで素数なんだ。 前面の蓋は右ガワに付いているんですな。
やっぱ右ガワってハメ殺しだよなー、と思う。 ケースメーカーらしいといえばらしい複雑っぷり。箱根の寄木細工かぃ。
右ガワ背面を外したらこんなカンジ。全然分解できてないように見える…。 こっちは、背面側爪がメス(□型)であること、側面側がオスであることが、 写真から判るだろうか。
前面パネルは比較的楽。爪に注意しつつ前方方向に引っ張れば外れる。 ただし、爪は相変わらずあるし脆いので、まぁ注意してくだされ。 スイッチと接続されたコネクタが向かって左下にある。 今回は面倒だから爪から外すだけにした。
左ガワ(コの字型のアルミケース部分+プラスチック)は、 前後二本ずつ、計四本の長いネジ(赤印...写真では既に抜いてあるけど)で固定されているだけ。 右ガワに比較すると異様に素直。 ただ、このネジは、HDDホルダと左ガワと左ガワに固定されてるプラスチック部分の三つを固定しているので、かなり長いことに注意。 特に後ろ側は、緩めるにもスゴい長いこと回さないとダメなんだよね。
この四本を抜き、ケースに貼られている「無線LANの基盤」をケースから剥がすと、 左ガワが外れる。 基盤は細いマイナスドライバを接着面にゆっくり入れていけば剥がれる。 シールも再利用可能。
マザーボードは底部にあり、ここからライザーでHDDのSATA端子が立ち上がっている。 HDDホルダ部分のプレス板は、底部とネジ４本でつながっているだけなので、 左右のネジ四本(プレス板に矢印がある)を外すことで分解できる。 無線LANのケーブルがギリギリの長さなので、切らないように注意。
外す前に、後部のファンの下、薄いシールド板部分の写真を撮っておくことをおススメする。 シールド板から爪が出てて、これが本体に「互い違いに」ハマっていて、 組み立てるときにどうハマっていたかがわかんなくなるため。 別に正確に組み立てなくても破損とかはないけど、 気持ちよく元通りに組み立てるには必要だと思う。 …とか書いておきながら、自分は写真撮るの忘れたという。
やっとここまできたので、こころゆくまでマザーボードを眺めてみよう。 右下に「KD22」の刻印があるので、このマザーはわざわざKD22用に作成されたものだと いうことがわかる。Shuttleの本気度が伝わる一品。 右下に写ってる足は心霊現象じゃなくて我輩の足なのでご安心を。
本当は、内部解析用にシリアル端子とか無いかしら、と思ったのが分解の きっかけだったのだが、ざっと見たところそんなのはなさそう。 マザーボード背面を見る元気は既になかったので、今回はここまで。
KD22を普通に動かしつつ、別のマシンから、KD22が外向けにサービスしている ポートが無いか確認。sshで入ってLISTENをgrepしただけ。 結果見ると、TCPではtelnetもsshも使えないですな。アタリマエか。 UDPの開いてるポートが少ない！
kd22-snaray> netstat -anp | grep "LISTEN\|0.0.0.0:\*" tcp 0 0 ###.###.###.###:9443 0.0.0.0:* LISTEN 20277/twonkyserver tcp 0 0 127.0.0.1:9443 0.0.0.0:* LISTEN 20277/twonkyserver tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 2764/lpd Waiting tcp 0 0 0.0.0.0:59619 0.0.0.0:* LISTEN 2694/responder tcp 0 0 0.0.0.0:548 0.0.0.0:* LISTEN 2325/afpd tcp 0 0 0.0.0.0:3689 0.0.0.0:* LISTEN 2732/mt-daapd tcp 0 0 ###.###.###.###:9010 0.0.0.0:* LISTEN 20277/twonkyserver tcp 0 0 127.0.0.1:9010 0.0.0.0:* LISTEN 20277/twonkyserver tcp 0 0 127.0.0.1:4700 0.0.0.0:* LISTEN 2326/cnid_metad tcp 0 0 :::3200 :::* LISTEN 3103/httpd tcp 0 0 :::139 :::* LISTEN 2310/smbd tcp 0 0 :::80 :::* LISTEN 3103/httpd tcp 0 0 :::443 :::* LISTEN 3103/httpd tcp 0 0 :::445 :::* LISTEN 2310/smbd udp 0 0 ###.###.###.###:1030 0.0.0.0:* 20277/twonkyserver udp 0 0 127.0.0.1:1030 0.0.0.0:* 20277/twonkyserver udp 0 0 0.0.0.0:39469 0.0.0.0:* 2731/mt-daapd udp 8960 0 ###.###.###.###:1900 0.0.0.0:* 20277/twonkyserver udp 0 0 239.255.255.250:1900 0.0.0.0:* 20277/twonkyserver udp 0 0 ###.###.###.255:137 0.0.0.0:* 2307/nmbd udp 0 0 ###.###.###.###:137 0.0.0.0:* 2307/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 2307/nmbd udp 0 0 0.0.0.0:42378 0.0.0.0:* 2718/mDNSResponderP udp 0 0 ###.###.###.255:138 0.0.0.0:* 2307/nmbd udp 0 0 ###.###.###.###:138 0.0.0.0:* 2307/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 2307/nmbd udp 0 0 ###.###.###.255:8100 0.0.0.0:* 2701/responder udp 0 0 0.0.0.0:60105 0.0.0.0:* 20277/twonkyserver udp 0 0 0.0.0.0:5353 0.0.0.0:* 20277/twonkyserver udp 0 0 0.0.0.0:5353 0.0.0.0:* 2731/mt-daapd udp 0 0 0.0.0.0:5353 0.0.0.0:* 2718/mDNSResponderP unix 2 [ ACC ] STREAM LISTENING 4371 2764/lpd Waiting /var/run/lprng |
KD22上に存在する、でっかいvmdkファイルを持つVMwareの仮想マシンを起動しようとすると、 以下のようなエラーが表示される。
テキスト検索する人のために、テキストも残しておこう。
VMware Player はこの VM に必要な仮想ディスクのうちの 1 つを開け ませんでした。仮想ディスクのサイズがホスト ファイル システムでサポートさ れている最大ファイル サイズを超えています。一部のリモート ファイル シス テムは、サーバ上のファイル システムではサポートされていても 2 GB より 大きいファイルをサポートしていません。 ファイルサイズが大き過ぎます ディスク「D:\VMware\Ubuntu 64bit\Ubuntu 64bit.vmdk」、または このディスクが依存するスナップショット ディスクを開くことができません。 モジュール DiskEarly のパワーオンが失敗しました。 仮想マシンの起動に失敗しました。 |
多分、KD22のsambaが古いとか設定が悪いからだと思うが、どうしようもない。 VMware側、仮想マシンの.vmxファイルに一行追加することで回避可能なことが わかったので、ここではそれをご紹介。
diskLib.sparseMaxFileSizeCheck= "false" |
なんで直るのかはよくわからない。設定するパラメータ名からは、「Sparseファイルの 最大サイズをチェックしないようにする」ようだが…なんでHDL2-Aでは こんなパラメータ無しに動くんだか。Shuttle EUに(英語で)報告だけはしといたので、 そのうち直ってくれるかもしれない。HDL2-Aでは起こらないのも謎。
4TB HDDx2のRAID1の再構築にかかる時間は、13〜14時間程度だった。長いよ！ もちろん、RAID1なので、再構築中にもアクセスはできるから困らないけれど、 それにしても長いよねぇ…。言えば「RAID1の再構築」って、右と左のHDDの 内容全部コピーするってことだから、4TB/13時間=89.6MB/s でそのくらいかかるのは わかるけどねぇ…。
WebUIの管理ツールからsmart情報が見れるのだが、 後方ファンの運転を「自動」にしておくと、 ほとんどアクセスしてなくてもコンスタントに50℃を超える(室温28℃時)。 後方ファンは常にOnにしておいたほうがいいと思う。 しかし、Onにしといても、同じ条件で40℃までしか下がらない…。
吸気口は正面から見て右側下部にスリットとして用意されているが、ホコリで 目詰まりしそうだ。
分解した時に確認した。APISTEKのMODEL SA7202L(DC12V 0.15A)だった。 70x70x15mmのフツーのファン。 KD20のファンとは違うんだな…。 でも配線は、刺さってるのをケース側面から見て左から赤・黒・青で、 フツーのファンと同じ模様。 KD20の変態ファン配線とはちょい違うみたい。なんでやのん。
頒布されているファームウェアはopensslで暗号化されているので、 パスワードがわかれば以下のコマンドで複号化でき、 元のファイル名どおりtar+gz形式となる。パスワードがわかればな！
# openssl enc -des3 -d -a -k <パスワード> -in <元ファイル> -out <複号済ファイル> |
なんで気づいたかというと、base64で一段階デコードできて、先頭に"Salt__"という 文字列が見えたから。あー、ソレはopensslで暗号化したデータですわー、という ところ。あとはごそごそ解析したら分かったというかそんな。
結論：できる。ちょい難しいしトリッキーだけど。
rootfs.ubiをごそごそしてたら、/bin/sshdなんてのを発見。あまつさえ、 /etc/rc.d/sshd.shなんてのもあるし。これはもう神が有効にせよとゆってるに 相違ない！ということで有効にする方法ないかなー、と調べてみる。 カッコいい方法がこちらにあるのだが、 残念ながら現在のファームウェアでは既に対策済み(セキュリティホールだし)のため、 この方法は使用できない。
色々やってみて、我輩はKD22上でsshdを有効化できた。rootでlogin可能。 上で紹介したdmesgはそれで取得したもの。方法は以下の通り。 KD2xで共通して使えるはず。
2014/11/23追記。別のホールを使った ハックが発表された。結局、どうにかして一度rootのpasswordを設定しなきゃ いけないというアレはあるけれど、http://IPADDR/admin/ssh.php をちゃんと使って いるのは偉い。我輩、このphpスクリプトの存在は知ってたんだけど、 IDはわかった(=root)がパスワード(決めうち)がわかんなくて使ってなかった。 ら、root/backdoorって！ちょっと安直すぎやしないかShuttleの中の人。 コメント読むと作ってるのは中国人らしいので、まぁそんなもんかなという気は しないでもないけれど。グローバルに展開されるphpスクリプトのコメントが 中国語というのもスゴいものがありますなぁ。
USBシリアルを繋いでシリアルコンソールを使えるようにした人も居るねぇ… ハックして遊べる機械は楽しいよね！