No Such Blog or Diary

«Prev || 1 | 2 | 3 |...| 941 | 942 | 943 |...| 1251 | 1252 | 1253 || Next»

NetWalkerを見てきた

帰宅後に三度研究室行く用事が出来たから,ついでに秋葉原まで行ってSHARPの小型LinuxマシンNetWalkerをヨドバシでさわってきた.(帰りにむちゃくちゃな雨に降られたけど…)

ARM系のプロセッサ積んで,Ubuntu 9.04 が入ってて,4GBのフラッシュメモリがストレージで,解像度1024x600のタッチスクリーンな5インチディスプレイ.そんでサイズはDSを一回り大きくしたくらいで重さ400g.10時間駆動.ついでにオプティカルポイントとかいう(マウスをひっくり返したような仕組みの?)光学式ポインティングデバイスが右手の親指位置にあり,左手の親指位置には左右のマウスボタン.ぶっちゃけオプティカルポイントは十字キーな気分で全体としても携帯ゲーム機感覚で持てる.let'snoteでも左右の縁を掴んで矢印キーを右手親指にZあたりを左手親指にゲーム機感覚で持てるけど,サイズ的にNetWalkerのがしっくりくる.

で,ハード的には面白そうなんだけど,ソフト的には微妙な不満というか不安が.とりあえず,ターミナルの初回起動に20秒も待たされたのはいただけない.二回目以降の起動は5秒くらいだったからフラッシュからの読み込みに時間食ったのかもしれないけど結構ストレス.存在しないコマンドを打ち込んだときのフリーズも長くなるのでイヤになる.そして metacity とかいうウィンドウマネージャが何故か CPU を 100% 近く食いまくっていたのも気になる.何かの間違いだったのか常にこうなのか? あとは ARM 故に使えないパッケージがどれくらいあるのかがちと不安.まあ,前もってパッケージ調べておけばよいかもしれないし,いざとなったらクロスコンパイルで自前で用意すりゃいいのだけど.

あと,キーボードは微妙かもしれない.サイズ的にしょうがないけどブラインドタッチとか不可能っぽい.親指だけでブラインドタッチとかならできるかもしれないけど.そんで,記号類のキーが上のほうに小さくなって固まっていたり,Fnキーを押す必要もあったりするのでいろいろ仕事しにくい.パイプとアンダースコアがFn+Shiftなのがね….どうせまともに作業するには外付けキーボード使わないと駄目だろうから,いっそのこと全体的にもっと小さくして欲しかった.

つーことで,2万円台なら買うかなぁくらいの感想(今のところkakaku.comでもまだ3万後半).

キーボードの代わりに二つ目のタッチスクリーン置いてくれないかな? ソフトウェアキーボードでいいじゃん.そんで5インチディスプレイの周りの縁もなくしてコンパクトになったら文句なし.

後日談:結局CPU喰いまくられてたのは異常な挙動だったらしい.別のを見たらCPUが暇してたから.あと,ターミナルの起動とかももう少し速めだった.ということで,気づいたらぽちってた.

サーキュラーPL

表裏で効果が違うのね.正しい方向ならフィルタ回すと液晶ディスプレイの画面が真っ暗になる(IPSで試した).でも逆向きだと回しても何も変化しない.直線偏光させた直後に円偏光にしてるらしいから,順番変えたら効果も変わるわな. 

カロリーメイト(メープル味)

所詮カロリーメイトということか… メープル味ってよりメープル風味な気がする.香りはあるけど味が想像より薄かった.

それはさておき,パイナップルは美味しく頂きました.そしてパイナップルの芯はマジで硬くて食えないことがよく分かりました.

メールに添付したファイルのパスワードをどう伝えるか?

さて,一応は個人情報の載っている資料だからとメールで送る際にはパスワードを掛けてくださいと言われたのだけど… パスワード自体はどう伝えたものか? メールで送る?

そもそも想定されている情報漏えいのシナリオって何だろう? 送り先のPCには暗号化を解いたファイルが置かれるはずなので,送り先のPCからファイルが盗まれることに対してはパスワードの意味がない.故に,メールの盗聴への対策にパスワードを掛けると考えていいだろう.ということは,パスワード自体をメールで送るというのはアウトだよなぁ.

さてどうしたものか? 送り先と自分は分かるが一般の他人が分からないクイズの答えをパスワードとしてメールでクイズを送る.パスワードは電話・FAXで伝える.相手の公開鍵で暗号化.そもそもメールで送らずにUSBメモリの手渡し.

良い手が思いつかない…

疲れた…

自転車でちょっと遠出してコスモス畑を見に行ったら,台風でなぎ倒されて悲惨なことになってるコスモス畑があっただけだった.疲れ倍増…

物理ディスク上のパーティションを個別にVMwareのディスクとして使うのを手動でやろうか

VMware Workstation 使って新しいVM作れば簡単に出来るんだけど,貧乏人としては自前でmvdkファイルをどうにか書きたいなと.ネットで検索すると,物理ディスク全体を仮想ディスクにする方法はちらほら見られるけれど,パーティション単位で扱っている方法が見つからない.ディスク丸ごとだとちと怖いのでどうにかしたい.

ということで,実際に VMware Workstation で物理パーティションにアクセスする仮想ディスクを作って,その内容と fdisk の情報から自前でmvdkファイルを書くための情報を推測してみた.

とりあえず fdisk の情報.先頭にリカバリ情報のパーティションがあり,そのあとに二つのNTFSパーティションが置かれている.

Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000021
 
デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1275    10241406   27  不明
/dev/sda2   *        1276       13417    97530615    7  HPFS/NTFS
/dev/sda3           13418       38913   204796620    7  HPFS/NTFS

そんで,最初のパーティションを仮想ディスクとする生成された vmdk ファイル.

# Disk DescriptorFile
version=1
encoding="Shift_JIS"
CID=edce33f3
parentCID=ffffffff
createType="partitionedDevice"
 
# Extent description
RW 63 FLAT "partition-pt.vmdk" 0
RW 20482812 FLAT "\\.\PhysicalDrive0" 63
RW 195061230 ZERO 
RW 409593240 ZERO 
RW 5103 ZERO 
 
# The Disk Data Base 
#DDB
 
ddb.virtualHWVersion = "7"
ddb.uuid = "60 00 C2 9f 15 8c 38 89-2c be 12 94 46 3a 8c ea"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.geometry.biosCylinders = "1024"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosSectors = "63"
ddb.adapterType = "ide"

まず,パーティション単位で仮想ディスクとするには partitionedDevice というタイプを指定するらしい.そんで, Extent description にディスクのパーティション構造らしきものが書かれるらしい.

最初の行はディスク先頭のMBRを含む63セクタでしょう.多分RWの後の数字がセクタ数.そしてこの部分は物理ディスク上に書き込まれては困るので別ファイル(partition-pt.vmdk)に内容を置くと.ファイル名手前の FLAT はよく分からんけどデータの保存の形か何かかね? そんで最後の数字の 0 は開始セクタ番号か何かでしょう(イメージ中のセクタ数と考えるのが妥当か?).ところで行先頭のRWはread/writeなのかrawなのか?

んで,次の行が最初のパーティションを使うためのエントリのはず.RWの後の数字がfdiskで見たブロック数の倍になっているからパーティションのセクタ数で良いっぽい.ついで FLAT は相変わらず.そして最初のディスクなので先ほどのファイル名の変わりに"\\.\PhysicalDrive0"が置かれ,開始セクタと思われる63が続くと.

残りの行は各パーティションのセクタ数と ZERO が書かれるらしい.ZEROは使用しない領域を表すのかね?

DDBは仮想ディスクとしてのスペックなのであまり気にしない.ネット上に転がってる物理ディスク全体を仮想ディスクにする場合と同じ値みたいだし.

例がひとつでは分かりにくいので,三つ目のパーティションを使った仮想ディスクの vmdk ファイルも生成.

# Disk DescriptorFile
version=1
encoding="Shift_JIS"
CID=e82adf55
parentCID=ffffffff
createType="partitionedDevice"
 
# Extent description
RW 63 FLAT "Ubuntu-pt.vmdk" 0
RW 20482812 ZERO 
RW 195061230 ZERO 
RW 409593240 FLAT "\\.\PhysicalDrive0" 215544105
RW 5103 ZERO 
 
# The Disk Data Base 
#DDB
 
ddb.virtualHWVersion = "7"
ddb.uuid = "60 00 C2 95 b8 17 da cc-f3 65 27 46 17 81 e6 07"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.geometry.biosCylinders = "1024"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosSectors = "63"
ddb.adapterType = "ide"

Extent description のエントリが少し変わった.最初の63セクタは同じ(ファイル名は違うけど).そして,今度は第一パーティションを使用しないので2行目が ZERO になった.変わりに,第三パーティションに対応する4行目が FLAT "\\.\PhysicalDrive0" になった.最後の数字は上三行のセクタ数の合計になっているので,パーティションの開始セクタ位置ってことで良いっぽい.

ということで,物理ディスク上のパーティションを使うvmdkファイルを書くポイントのまとめ.

  • createType="partitionedDevice" とする
  • Extent description をパーティションテーブルに沿って書く.各エントリは,RWの後にサイズをセクタ数で指定し,使用するパーティションなら FLAT の後にファイル名と開始セクタ位置を書き,使わないなら ZEROと書く.ファイル名は"\\.\PhysicalDrive0"とかで物理ディスク行き,通常ファイル名でローカルなファイルっぽい.サイズ(セクタ数)は,([End] - [Start]) * [sectors/track] * [heads] で求まる.例えば二番目のパーティションは 195061230 = (13417 - 1276 + 1) * 63 * 255.ただし,最初のパーティションはMBRがあるため 63 セクタ分引かれる(20482812 = (1275 - 1 + 1) * 63 * 255 - 63).

TODO: 拡張パーティションとかどうするんだろう? 本当に使えるのかこれ?

ということで,拡張パーティション入りの場合のExtent description と fdiskの出力 .

RW 63 FLAT "ubun2-pt.vmdk" 0
RW 20482812 ZERO 
RW 195061230 ZERO 
RW 376033455 ZERO 
RW 63 FLAT "ubun2-pt.vmdk" 63
RW 24579387 ZERO 
RW 63 FLAT "ubun2-pt.vmdk" 126
RW 8980272 FLAT "\\.\PhysicalDrive0" 616157073
RW 5103 ZERO 
/dev/sda1               1        1275    10241406   27  不明
/dev/sda2   *        1276       13417    97530615    7  HPFS/NTFS
/dev/sda3           13418       36824   188016727+   7  HPFS/NTFS
/dev/sda4           36825       38913    16779892+   5  拡張領域
/dev/sda5           36825       38354    12289693+  83  Linux
/dev/sda6           38355       38913     4490136   83  Linux

拡張パーティションの持つ拡張パーティションブートレコードもローカルのファイルに持っておくらしい.拡張パーティションになっていようがいまいが,使うパーティションの最後の数字は先頭セクタ番号(それまでのセクタ数の合計)となるらしい.注意点は,拡張パーティション内の領域にある論理パーティションの場合には,RWの後のサイズ(セクタ数)が拡張パーティションブートレコードの分(63セクタ)を引いたサイズになること.例えば,上の例では 8980272 = (38913 - 38355 + 1) * 63 * 255 - 63 となっている.

うーん,パーティションテーブルの中身はどうすればいいのだろうか? dd で元のディスクのテーブルを抜き出したけど不正だと怒られた.よーわからん.

と思ったら抜き出すアドレス間違ってただけだった.元ディスクのパーティションテーブルを抜き出して一つのファイルにまとめてやれば問題ないらしい.

ということで,生成のためのスクリプトとサンプル入力をメモっておく:genvmdk.sh, genvmdk.awk, diskinfo.txt.使うにはメインのスクリプトに入力を食わせる.

./genvmdk.sh < diskinfo.txt

これで仮想ディスク本体の disk.vmdk とパーティションテーブル生成スクリプト gen-pt.sh ができる.あとは

sudo bash gen-pt.sh

とかして dd でパーティションテーブルを抜き取ってきて disk-pt.vmdk ができる.

スクリプトへの入力は,ヘッド数,トラックあたりのセクタ数,ディスク全体のデバイスファイル,仮想ディスクからアクセス可能なパーティション(今のところ一個だけ),fdiskの出力たち.

«Prev || 1 | 2 | 3 |...| 941 | 942 | 943 |...| 1251 | 1252 | 1253 || Next»
Search
Feeds

Page Top