趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。
バッファオーバーフローを突く例で紹介したページで使われていたツールは何だろう、という疑問からスタート。ページの内容からコードの分岐状況を解析ツールがあるのではないかと思ったので。
で、件のページの「TOOLS」には、IDA Proという文字が。
そこから調べたことをメモメモ。
ということで試してみるにはBackTrackをインストールして、さらにIDA Pro Freeをインストールしてみるのが良さげな感じ。
他にもイメージファイルの中からファイルシステムのイメージなんかを抜き出すBinwalkなんかも役に立つ感じがする。
組み込みシステム（この例はルータ）に対するバッファオーバーフローを突く例を見かけたので紹介します。
/DEV/TTYS0というサイトで、tenda製の-Link社W302Rというモバイルルータを突く例がブログの記事になっています。
ファームウェアにはGoAhead社のWebServerが組み込まれているんだけど、かなりカスタマイズされていて、HTTPの受信の前に別スレッドで違う処理をしている。で、その別処理の中では、
・UDP7329番ポートを作成して受信を待つ
・受信したパケットを解析して先頭のマジックワードを確認し、その後の内容に応じた処理をする
ということがされていて、その中に『後続の文字列をコマンドとしてルート権限で実行して送り返してくる』ものがあるということだそうです。（実際、ncコマンドでルートシェルを起動したスクリーンキャプチャも示されています。）
パケット受信はLAN側だけで行われているので、WAN側からの脆弱性にはならないようですが、WPSがブルートフォースアタックに対する処置なしに許可されているので、WPSのクラッキングが可能で、それ故、所有者の気づかないところで外部からルート権限でコマンド実行することも可能になっている、ということみたいです。
まあ、障害解析なんかで使うために用意されているものなのでしょうが、ここまで解析する人もいるので要注意、ってことでしょうねぇ。
たまたま見かけたYouTubeビデオ。スノーボードの滑走面にシートヒーターを内蔵してバッテリで加熱。滑走性を高めてよりスピードが出るようにしよう、ということらしい。
滑走前に通電して温度を測ると華氏128度＝摂氏53℃くらいでワックスが融ける温度・・・ということみたいですなぁ・・。
他にもいろんなスノーボードを作って楽しそう(^^;
メーカーの日本語のFacebookのページがありました・・・
https://ja-jp.facebook.com/SignalSnowboardsJAPAN
Androidの本体側も不安でしたので、USBマスストレージとして認識する状態でディスクイメージを吸い上げ、ファイル抽出したところ、JPEGだけで１万個近いファイルがでてきました。（細々としたファイルも含めると１０万個くらい？）
PhotoRecが８０近いディレクトリを作ってしまったので、一括して処理しないと面倒です。なので、JPEGのみを集めてくることにしました。
＃どうでもいいけど、本体もFATで処理できてしまった・・・。FATフォーマットなの？
$ ./testdisk-7.0-WIP/photorec_static Copy-Of-HONTAI.IMG
$ cd OUTPUT-HONTAI/
$ ls
recup_dir.1 recup_dir.24 recup_dir.39 recup_dir.53 recup_dir.68
recup_dir.10 recup_dir.25 recup_dir.4 recup_dir.54 recup_dir.69
recup_dir.11 recup_dir.26 recup_dir.40 recup_dir.55 recup_dir.7
recup_dir.12 recup_dir.27 recup_dir.41 recup_dir.56 recup_dir.70
recup_dir.13 recup_dir.28 recup_dir.42 recup_dir.57 recup_dir.71
recup_dir.14 recup_dir.29 recup_dir.43 recup_dir.58 recup_dir.72
recup_dir.15 recup_dir.3 recup_dir.44 recup_dir.59 recup_dir.73
recup_dir.16 recup_dir.30 recup_dir.45 recup_dir.6 recup_dir.74
recup_dir.17 recup_dir.31 recup_dir.46 recup_dir.60 recup_dir.75
recup_dir.18 recup_dir.32 recup_dir.47 recup_dir.61 recup_dir.76
recup_dir.19 recup_dir.33 recup_dir.48 recup_dir.62 recup_dir.77
recup_dir.2 recup_dir.34 recup_dir.49 recup_dir.63 recup_dir.8
recup_dir.20 recup_dir.35 recup_dir.5 recup_dir.64 recup_dir.9
recup_dir.21 recup_dir.36 recup_dir.50 recup_dir.65
recup_dir.22 recup_dir.37 recup_dir.51 recup_dir.66
recup_dir.23 recup_dir.38 recup_dir.52 recup_dir.67
$ mkdir ALLJPG_F
$ i=1; for f in recup_*/f*.jpg ; do g=00000$i.jpg; mv $f ALLJPG_F/JPGF_${g:(-10)}; i=$((i+1)); done
$ mkdir ALLJPG_T
$ i=1; for f in recup_*/t*.jpg ; do g=00000$i.jpg; mv $f ALLJPG_T/JPGT_${g:(-10)}; i=$((i+1)); done
$ mkdir ALLJPG_E
$ i=1; for f in recup_*/*.jpg ; do g=00000$i.jpg; mv $f ALLJPG_E/JPGE_${g:(-10)}; i=$((i+1)); done
（この行はファイルがないのでエラーになるはず。もしファイルがある場合に回収するためのもの。）
$ mkdir ALLPNG
$ i=1; for f in recup_*/*.png ; do g=00000$i.png; mv $f ALLPNG/PNG_${g:(-10)}; i=$((i+1)); done
冒頭のファイル抽出はSDカードの場合と何も変わらないので説明は省略します。
最後の8行でファイルを6桁の連番を付けながら、各ディレクトリに集めてきます。この部分はこちらのサイトを参考にさせていただきました。
うちの嫁のAndroid機で撮影してあったMicroSDカード上の写真がすべて消失するという事件が起きました。
LINEでありえない人（この人がLINEなんぞやるわけない・・・実際にアリバイの証人まで居たりする）からメッセージが届いた後、しばらくして消失に気づいた、という状況です。どうも、かなりおかしい状況のような気がします。なんとなくバックドアとかルートキットの匂いがします。LINE自体が問題なのか、LINEを狙ったアプリをインストールしてしまっているのかはわかりませんが。
＜追伸＞
FATフォーマットなので、FATテーブルの書き込みに失敗しただけなのかもしれません。ただ、書き込み失敗でSDカード丸ごと初期化というのも不思議な気がしますが・・・。
それはさておき、とにかく画像ファイルの救出を試みましたので、その記録です。
なにはともあれ、現在の状態を保存します。この手の作業ではオリジナルには手を加えないのが鉄則です。なので、SystemRescueCDで起動したPCにて、
% mkdir /media/HDD % mount -t ext4 /dev/sdx1 /media/HDD % dd if=/dev/sdy of=/media/HDD/SDCARD.IMG
として、ディスクイメージを吸い出します。ここで、/dev/sdxはイメージファイル保存用のHDDのUSBハードディスク、/dev/sdyが救出対象となるSDカードです。吸い出したらSDカードは大切に保管し、さらに、
% cp SDCARD.IMG Copy-Of-SDCARD.IMG
として、イメージファイルのコピーを作成します。このコピーに対して色々トライしていきます。
（実際には、さらにこのコピーをLinuxMint13マシンのローカルHDDにコピーしておきます）
% mkdir /media/FAT % mount -t vfat Copy-Of-SDCARD.IMG /media/FAT
として、/media/FATにイメージファイルをマウントして観察します。どうやら、SDカード上のファイルが全消去されたか、論理フォーマットされてしまっているかのようにファイルが何もなくなっていました。SDカードはFATフォーマットなのでアクセス権が及ばないはず。SDカードへのアクセスを許可したアプリからは、おそらくどんなアプリからも全消去とか不正な参照・書き換えなどが可能なのではないかという気がします。
途中、試行錯誤と紆余曲折があったのですが、ここでは端折って、最終的な救出方法のみ記載します。ツールとしてはPhotoRecとTestDiskを使用し、環境としてはLinuxMint13 x64で行いました。
まず、SynapticでTestDiskを検索してインストールします。さらに、PhotoRecをこちらからダウンロードしました。PhotoRecにもTestDiskが同梱されているようですが、先にTestDiskはインストールしてしまっています。（なので、実際どちらが動作したかわかりません）
PhotoRecは展開するとスタティックリンクされた実行ファイルが出てくるので、このディレクトリを丸ごと ~/TEMPに移動し、イメージファイル（Copy-Of-SDCARD.IMG）も~/TEMPの下にコピーします。さらに、救出したファイルを保存するディレクトリを作成しておきます。
カレントディレクトリを ~/TEMPに移動してから、
$ ./testdisk-7.0-WIP/photorec_static Copy-Of-SDCARD.IMG
として起動します。下の方に「rootじゃないといくつかのディスクが見えないよ」という表示が出ますが、イメージファイルに対する操作なので問題ありません。
そのまま「Proceed」を選択したまま「Enter」を押します。
次にどのパーティションを対象にするか聞いてきますが、そのままで問題ありません。「Search」を選択したまま「Enter」を押します。
次にファイルシステムを聞いてきますが、FATがすでに選択されているのでそのままで問題ありません。「Other」を選択したまま「Enter」を押します。
次に消去されたファイルのみをサーチするのかどうか聞いてきますが、今回はSDカード内のファイルをすべてサルベージしたいので、「Whole」を選択して「Enter」を押します。
次にサルベージしたファイルの保存先を聞いてくるので、適当な箇所を選んで「c」を押します。
するとサルベージが始まります。（適当なサイズ毎にサブディレクトリが切られるようです）
しばらくすると終了します。今回は４５００個のファイルが救出されました。
出来上がったファイルはファイル名がグチャグチャになっています。幸い、EXIF情報は生きている（というか生きてないとJPEGファイルとして成り立ちませんが・・・）ようですので、EXIFに基づいて撮影日時に基づいたファイル名に修正します。
ファイル名が修正できれば、写真のグループ分けも容易になるはずです。
各サブディレクトリにて、
$ jhead -n%Y%m%d-%H%M%S f*.jpg
として、ファイル名を修正していきます。fで始まるファイル名は大きな写真のようですので、まず修正されたファイルを集めます。その後、各サブディレクトリにて改めて
$ jhead -n%y%m%d-%H%M%S *.jpg
として残りのファイルのファイル名を修正してファイルを回収します。
完全にはファイル名が修正できないので、適当に手作業を加えながら、画像回収を完了させました。
Linuxばかり使っていて、すっかり存在を忘れていたデスクトップＰＣが3台(^^;あるのですが、それぞれWindowsXP Pro(32bit)、Windows7 Pro(64bit)、Windows 8 Pro(XPからバージョンアップしたので32bit)が入っています。
WindowsXPはいわゆるオンラインバンキングやオンライントレードのための専用機として用意（でも今年入ってからは全然使ってない）していてネットワークもこいつだけは共有などはかけずに他とは遮断しています。で、WindowsXPのサポート期限も切れてしまったので、このGWに購入してあったWindows8にバージョンアップしました。手順は別に驚くようなことはなく、ひたすら時間がかかるだけです。さらに、先にWindows8にバージョンアップしてあったPC（こちらは元々はWindows版開発ツールを動かすための環境）と併せてWindows8.1にバージョンアップしてみました。
Windows8.1にバージョンアップをかける前にひたすら更新を適用して、最後にパーティション領域を変更してC：のサイズを100GB程度に縮小しました。この状態でイメージのバックアップを取っておきます。こうすれば、今は1TBや500GBの3.5インチHDDでの運用ですが、HDD故障時などに120GB程度のSSDに換装が容易になるはず・・・と思っています。（ライセンス再認証などで困る可能性が少なくなるはず・・・と思うのですがどうなのでしょう？）
バックアップが済んだら、アップデート自体はストアアプリの中に最初にアップデートが出てくるのでアップデートするだけなのですが、ここで困ったことがいくつか。
オンラインは便利なようで落とし穴もたくさんあるはずです。トレンドを追わなければならないMicrosoftの立場も理解はしますが、半ば騙してでもオンラインアカウントに切り替えさせよう、という姿勢はちょっと嫌ですねぇ。
インストールの過程で興味深いのはWindows8→ひたすらアップデート→8.1とアップデートしていく段階で要所要所でディスクのクリーンアップ（古いバージョンのWindowsなどの不要なシステムファイルの削除を含む）をしつつ進めていたのですが、ディスクの使用領域が減っていくことです。Windows8のインストール直後（もちろんクリーンアップ後）で25GBくらいだったのが、Windows8.1にバージョンアップした後では15GB以下に減少しています。
さて、それぞれ環境があたらしくなったところで、もうしばらく稼働してもらいましょう。
IdeaPad S10-2をとりあえずLinuxマシンとしても復活させるため、LMDEに代えてLinuxMint16をインストールしました。
こんなもんかな。昔に比べてずいぶんと追加でインストールするものが減った感じ。
＃結構、こちらの説明、参考になります。よくわからずに使ってる部分も多いので。感謝。
忙しくてどうしようもない状況で、久しぶりの更新です。
程々に小さくメールやWebには十分なレベルということでIdeaPad S10-2を出張に持って行くのですが、電池がヘタって来て電池の持ちが悪くなって来たので互換バッテリを購入しました。稼働時間が回復してラッキーと思っていたら、今度は60GBのSSDにWindows8とLinuxMint13では空き容量が少なく感じたので、120GBのSSD（Crucial CT120M500SSD1）に置き換えてみました。
・・・・が、これがハマりました。Windows8の再インストールは問題なかったのですが、落ち着いたら起動時にブルーバックが発生するようになってしまいました。再起動すると問題なく動作するのですが。ブルーバック時のコードはGoogle先生に聞いてみると「途中でディスクが見えなくなる」場合に発生するもののようです。さらに、よく観察していると、Windows8でもLinuxMintでも稼働時間がかなり短くなっています。
これらのことから、消費電力が大きくて起動中に動作が不安定になっているのではないかと考えました。泣く泣く、60GBの元のSSDに戻すことにしました。（ちなみに、Crucial CT120M500SSD1はラベルに「5V 1.7A」の表記があり、確かに大食いのようです）
まず、Windows8環境を構築します。
次に、LinuxMint環境をインストールします。今回はLinux Mint Debian Edition（LMDE） 201403のMATE Edition 32bitをインストールすることにしました。理由はローリングリリースなので長期で使えそう・・・という理由です。
ここまできたところで、気づきました。
・・・・無線LANドライバがいない・・・。Debianはオープンソース純血主義なので、無線LANと相性が悪いのでした・・・。
（無線は各国の法規制を守るためにはソース公開が事実上できなかったりするので困るんですね。勝手に出力UPされたりオフバンドされても困るので。）
やっぱりその辺、妥協しているUbuntuベースの方が簡単だったりするんですよねー。LinuxMint17を待って入れ替えですかね。
TV録画機用に仕立てたCeleron847のWindows8 ProfessionalのマシンがタイマーでのS3からの復帰でBIOSがディスクを認識せず立ち上がらなくなってしまいました。その状態ではコールドブートもできません。しかし、いろいろ悪戦苦闘していると立ち上がる場合もあるようで、なんだろうと思っていたら使用中にフリーズするようになりました。
どうやらこのマシンに入っているWesternDigitalのCaviarGreenシリーズ（うちのはWD15EARS）は低速病と言われる不具合が多発しているようです。
参考：WD Caviar Green WD15EADS の低速病が起こったり直ったり
で、どうやらしばらく電源をOFFしておくとしばらくは復旧するような傾向を掴んだので、いろいろ試してみました。
なので、とにかく起動した際にシステムバックアップとシステム修復ディスクを何回かのトライの後に作成することができました。（再インストールして環境再構築するのは嫌なので・・・）
ちなみに、HDDから起動できない状態でUSBメモリに入れたSystemRescueCDで起動するとぱっと見は何事もなかったようにアクセスできる感じです。（データ救出のために使っただけなので、きちんと速度が出ているかはわかりません）
で、とりあえず手持ちの320GBのHDDにシステムパーティション（約120GB）だけでも復旧させてみようと思ったら・・・「サイズが小さくて入りません」・・・だと。実使用領域は30GBにも満たないはずなのに・・・。うーむ。
それよりもFreeNASマシンに入っている2TB×3台（2台でZFSミラー、残り1台がバックアップ）のうち、2台がWD CaviarGreenだったりします。こいつら何とかしないと・・・。
ちなみに、このマシンもWD5000AAKXだったりするんですが、最近妙にGoogle Chromeが重かったりします。他にも時々不思議に重い挙動が・・・？
CaviarGreenではなく2.5inchのBlueなんですが関係あるんでしょうか？？
たまたま久しぶりにKickstarterをみてみたら、ブレッドボードで使うワイヤーを好きな長さで作るための治具、その名も「Wire Stripping Gauge」というのが出ていました。こちらは日本の方が出資を募っているようで下記の製品紹介ビデオも日本語です。Kickstarterの中にリンク先にWebサイトもありました。
ビデオをみてもわかるとおり、グチャグチャになりがちなブレッドボード（例えばこんなの）をブレッドボードのままで綺麗につくることができるというのが素晴らしいです。ビデオをみると、もう完成度の高い試作品もあり使い方もきちんと説明されていますので、リスクも低そうです。
そしてこちらにてKickstarterのアカウント登録からAmazon.com経由での出資方法まで説明があったので、つい$23のセットをポチッとしてしまいました(^^;。届くのが楽しみです。
＃他にもKickstarterのアカウント登録などについてこんな記事もありました。
ちなみに出資期限は日本時間の2月3日午後11時までのようです。