DMCAに調査目的でのリバースエンジニアリングが例外に追加されそう

DMCA updated – toaster penetration testing gets green light in America • The Registerによると、アメリカの法律であるDMCA(デジタルミレニアム著作権法)の例外に、調査目的でのリバースエンジニアリング等のセキュリティテストが2年以内に追加されるようだ。具体的には以下の項目である。

  • The use of electronic literary works in conjunction with assistive technologies.
  • Jailbreaking phones and tablets to enable interoperability or remove unwanted software.
  • Efforts to access automobile software.
  • Efforts to make non-functioning video games accessible.
  • Efforts to bypass 3D printer materials controls.
  • Efforts by patients to access data in personal medical devices.
  • Attempts to reverse-engineer software for security research.

脱獄や車のシステムへのアクセス、ゲームのチート、3Dプリンタの制御のバイパス、患者による医療機器のデータへのアクセス、調査目的でのリバースエンジニアリングが製品の保護の例外になる。

日本では、著作権法47条の3 第1項に「プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において利用するために必要と認められる限度において、当該著作物の複製又は翻案をすることができる。」とあるものの明記はされておらず、(平成20年第7回)議事録 | 資料1|文化庁のように議論されている段階のようだ。現在の進捗はよく分からない。

IDAにカラースキーマ(.clr)を適用する

メニューバーの Options から Colors を選択すると以下の画面が出てくる。 f:id:TAKEmaru:20161029010134p:plain importボタンを押してファイルを選択すれば適用できる。

おすすめカラースキーマeugeii/ida-consonance: Consonance, a dark color scheme for IDA.

完全にやり方を忘れていたので備忘録。

CODE BLUE 2016とAV TOKYOに行った。

去年はカスペルスキー大先生の学生支援枠で参加していたCODE BLUEに学生スタッフとして参加した。今年のスタッフはスーツ着なくてよくなっていたり、スタッフ数が倍になっていたりで、去年のスタッフのみなさんに比べてかなり楽になっていたらしい。有名なエンジニアの方がすぐ近くを歩いていたりしていて、異常な環境だった。

f:id:TAKEmaru:20161023191722j:plain

2日目の日中は業務なかったのでコンテストに行ったところチームメンバーに恵まれて2位になった。F.TRON社のINTΦ(INT ZERO)はセキュアでつよくてめっちゃ面白いのでソースを見てみたい。めっちゃつよくてヒントが出るまではルールの穴を突くくらいしかなかった。

AV TOKYOの開始4時間前がチェックアウトだったので、せっかくだしAV TOKYOも行った。 CODE BLUEで聞いたHouse of Einherjarの話をもう一回聞けてよかったし、バグハンターの話とかil2cppの話も面白かった。ああいうクラブ?みたいな環境で話を聞くのは新鮮で面白かった。

f:id:TAKEmaru:20161022143251j:plain なぜか天井にディスプレイがあった。

精進します。

サイバーエージェントの長期インターンに行ってきた

8/16から9/21までサイバーエージェントの長期インターンに行っていたので感想を書く。

インターン以外でも最高の夏🍉は過ごせる!!

f:id:TAKEmaru:20160922111330j:plain

面接

インフラかサーバサイドやりたいけど、インフラは自信ないとか言ってたら、「OpenStackって知ってる?」って聞かれて「名前しか知らないです」って言ったのでサーバーサイドの方面で選考が進むことになった。 某コンテンツ系サービスのバックエンド見たかったけど、精鋭が揃っているらしく、goを業務で書いたことがないときびしいと言われたので、某メディア系のサービスの中の人とエンジニア面接して無事にメディアサービス (エンジニア対象)に採用されることになった。goのバイナリ読んだりしてたけど、あんまり書いてなかったし、しゃあない。

エンジニア面接のあとすぐ人事の方から電話がかかってきて「Androidもできたよね!?」って聞かれて、Oss Stars~Android編~ に誘われた。 全然できないんだよなーとおもいつつも「じゃあせっかくなんで行きますー」って言って Oss Stars~Android編~ の方も行くことになった。

人事の方が異常に丁寧で、エンジニア面接に入る前にどうゆうサービスに興味あるか、嫌いなサービスはなにか、使える言語はなにか、使いたくない言語はなにかとか細かに聞いてくれてマッチングをいいかんじにしてくれて、神だった。ふつーは絶対、嫌いなサービスまで聞かないと思う。

ぼくは普通に開発してただけだけど、音波解析とかDCに納入するクソ高いNICの性能評価とかをやってる人もいて、そういうことを希望しても面白かったかなーと思う。

業務

SPAなサービスだったので、95%くらいフロントを触って、5%くらいサーバーサイドを触るみたいなかんじで業務が進んだ。 前にJSをまじめに書いたときはES5にjQueryを使って書いていたので、ES7にReact、Reduxでの開発は大変だった。また、かなり特殊な構成で、慣れるのに非常に時間かかったし、そういう意味でも大変だった。序盤は人権問題に直面していたけど、メンターが異常にやさしくて助かった。感謝。業務では人権が保証される。社内で評判の構成らしく他サービスでのフロント刷新の際、参考にされるらしい。けど、React、Reduxの他に、社員の方の自作ライブラリとか、forkしてカスタムしたライブラリとか使われてて、プライベートで真似して開発するのは難しそうだと思った。

単純に文法とかライブラリのことだけじゃなくて、Atomic DesignとかIsomorphic JavaScriptとかの設計の概念とかサーバー構成の裏事情とか負荷試験のこととか教えてもらえて勉強になった。 n十万行のコードとか触ったことがなかったので、そういう意味でもいい経験になったし、多少は自信がついたので、OSSのコードとか読んでいきたい。

インターンに行ったタイミングが悪く、どでかいリリースの真っ最中で社員のみなさんはものすごく忙しそうだった。 段階的に公開(n%公開)していって、LBの負荷が異常に上がったりした段階で切り戻している姿を見たり、「このリリースが遅れたら一日当たりいくらの損失が出ますか!?」というパワーワードを聞いたりして、「これが現場か!!!!!」となった。毎日ISUCON状態。

上記のどでかいリリースの打ち上げは、タクシー🚕で店まで移動して、どでかいソファとどでかいスクリーンとどでかいスピーカーとカラオケとキッチンが配備されている個室がある店で行われた。「これがWebの力💰💴💸か!!!」となった。

業務の他にもスタジオ見学したり、セキュリティチームの人と会わせてもらえたりして勉強になった。

ネットにはこういう不穏な記事(サイバーエージェント社の内定式がリア充すぎると話題に 【画像あり】 | ニュース2ちゃんねる)もあるけど、普通にいい会社だった。というかエンジニアがあんなにチャラい訳がない。や、総合職の話はしらない。

様子

以下は様子です。

f:id:TAKEmaru:20160821201917j:plain f:id:TAKEmaru:20160905143609j:plain 休日は温泉♨を攻めた。東京は小さい銭湯でも黒湯あるし、露天風呂あるしすごい。

f:id:TAKEmaru:20160917193246j:plain はじめて九州料理食べた。写真は冷や汁

f:id:TAKEmaru:20160923063250j:plain f:id:TAKEmaru:20160917160102j:plain オシャレマクロスデルタにいったはずがCCさくら🌸のlimited storeがあって優勝した。もうOIOIにはオタクのイメージしかない。

f:id:TAKEmaru:20160920203811j:plain BABYMETALの東京ドームライブも行った。

f:id:TAKEmaru:20160922114434j:plain 帰る日にふぐ🐡食べた。神だった。とらふぐ亭 渋谷店 (とらふぐてい) - 神泉/ふぐ [食べログ]

おわりに

長期インターンでは短期インターンと違って実際の業務に組み込まれるので、非常に勉強になるのでよかった。某先輩(神)の言う通りだった。

メンターとチームのみなさまと人事のみなさまには感謝しております。この経験を今後につなげていきたいですね。

androidでpwnできる環境を作ってみる

ndk-buildにより作成したプログラムをandroid上で待ち受けさせる。arm環境でpwnするときに使える。

準備

プログラムを用意する

ソース

/* test.c */
# include <stdio.h>

int main(void) {
  printf("Hello, world!\n");
  return 0;
}

ビルドスクリプト

Application.mkを作成する。

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := test
LOCAL_SRC_FILES := test.c

include $(BUILD_EXECUTABLE)

ここではやっていないが、APP_CFLAGS += -fno-stack-protector を書くことでSSPを無効にできる。

ビルドする

$ ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Application.mk
$ adb push libs/arm64-v8a/test /data/local/tmp/
$ adb shell
shell@android:/data/local/tmp $ ./test
Hello, world!

socatを入れる

androidにはsocatコマンドが入っていないので、socat for android - Post #28からzipをダウンロードしてadbで入れる。

$ adb push ~/downloads/socat-2.0.0-b7-armv7-a /data/local/tmp/

やってみる

adbで端末に接続し、socatで待ち受ける。

$ adb forward tcp:10001 tcp:10001
$ adb shell
shell@android:/data/local/tmp $ cd /data/local/tmp/
shell@android:/data/local/tmp $ ./test
Hello, world!
shell@android:/data/local/tmp $ ip a
...
21: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 30:5a:3a:aa:56:33 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.67/24 brd 192.168.3.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::325a:3aff:feaa:5633/64 scope link 
       valid_lft forever preferred_lft forever
shell@android:/data/local/tmp $ ./socat TCP4-LISTEN:10001,fork EXEC:./test

別のshellからnetcatで接続する。

$ nc 192.168.3.67 10001
Hello, world!

無事に接続できた。

社会...

給料日







次の日

催促したら入金はされた。





これが社会か

某イベントで某社に声をかけられてapkの脆弱性診断のバイトをやっていたが社会はきびしい。

やっぱ、名刺交換している人全員にスカウトメール送るような会社はやばかった。エンジニアが優秀そうでも経理とか事務とか人事がダメだとつらい。

gccでlibc抜きでコンパイルを通す

Hello from a libc-free world! (Part 1) (Ksplice Blog) がおもしろかったのでやっていく。

libcありのとき

コード

よくあるhello worldのコード

$ cat hello_with_libc.c
# include <stdio.h>

int main()
{
  printf("Hello World\n");
  return 0;
}

コンパイル

$ gcc hello_with_libc.c -o hello_with_libc
$ ./hello_with_libc 
Hello World
$ wc -c ./hello_with_libc 
8561 ./hello_with_libc

もちろん問題なくコンパイルできる

libcなしのとき

コード

libcを使わないコードを書いた。

$ cat hello_no_libc.c
int main()
{
  char *str = "Hello World";
  return 0;
}

コンパイル

$ gcc -nostdlib hello_no_libc.c -o hello_no_libc
/usr/bin/ld: 警告: エントリシンボル _start が見つかりません。デフォルトとして 0000000000400144 を使用します
$ ./hello_no_libc
Segmentation fault (コアダンプ)

-nostdlibをつけてlibcを含まずに、コンパイルするとエントリポイントが見つからないと怒られる。 ELF形式のエントリポイントはcrt1.oで定義されているのでリンクしてみる。

$ gcc -Os -c hello_no_libc.c
$ ld /usr/lib/x86_64-linux-gnu/crt1.o -o hello_no_libc hello_no_libc.o
ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): 再配置 0 が無効なシンボル索引 11 を持っています
ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): 再配置 1 が無効なシンボル索引 12 を持っています
...
ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): 再配置 18 が無効なシンボル索引 13 を持っています
ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): 再配置 19 が無効なシンボル索引 21 を持っています
ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_line): 再配置 0 が無効なシンボル索引 2 を持っています
/usr/lib/x86_64-linux-gnu/crt1.o: 関数 `_start' 内:
(.text+0x12): `__libc_csu_fini' に対する定義されていない参照です
/usr/lib/x86_64-linux-gnu/crt1.o: 関数 `_start' 内:
(.text+0x19): `__libc_csu_init' に対する定義されていない参照です
/usr/lib/x86_64-linux-gnu/crt1.o: 関数 `_start' 内:
(.text+0x25): `__libc_start_main' に対する定義されていない参照です

libc_csu_fini、libc_csu_init、libc_start_mainがないと怒られた。これらはmain関数が呼ばれる前に呼ばれる関数でlibcのセットアップを行う。crt1.oに頼らず、main関数を呼ぶエントリポイントを書く必要がある。

$ cat stubstart.s 
.globl _start

_start:
    call main
    mov  $60, %eax # exit
    xor  %rdi, %rdi   
    syscall

stubstart.sはmain関数を呼んだ後、exitのシステムコールを呼び出し終了する_start関数を書いたものである。 これがエントリポイントとなる。

$ gcc -nostdlib stubstart.s hello_no_libc.c -o hello_no_libc
$ ./hello_no_libc
$ wc -c ./hello_no_libc 
1613 ./hello_no_libc

無事にコンパイルが通り実行できるようになった。冒頭でコンパイルしたHello worldの8561byteに比べ、libcがない分、1613byteとサイズが小さくなったことも確認できる。