トップ «前の日記(2004年04月10日) 最新 次の日記(2004年04月14日)» 編集
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|10|12|
2009|02|03|06|07|10|11|12|
2010|01|02|03|04|07|09|10|11|12|
2011|01|03|04|05|06|07|08|10|
2012|01|06|08|09|10|12|
2013|01|02|03|04|07|09|11|12|
2014|01|03|04|05|06|09|
2015|04|
2016|01|08|
ここは旧えびめもです。えびめも2に移行します(2016/12/1)

2004年04月13日

うわあ

更新が一週間も空いてしまいました。

Ken Thompson氏

古い話ですが、今日 Ken Thompson氏の有名なback door事件を知った(氏はUNIXを作った男の一人である)。backdoorとは、システムやプログラムの作者が、作者しか知りえない秘密の手順を組み込んでおき、あとでそのシステムへ侵入するための裏口を作っておくことである。広い意味で言えばゲームの裏技やアクションゲームの主人公の無限増殖などもこの類のものだろう。

氏は初期の(1970年代初頭の)UNIXシステムのlogin コマンドにバックドアを仕込んでおき、ログイン名ktと、とあるパスワードを入力すると、そのアカウントが存在しなくてもシステムに侵入できる仕掛けを入れておいた。しかもそれを氏が1984年に論文で発表するまで誰も見破れなかった。というのだ。

その恐るべき手法は次の通りである。もし login.c にバックドアを記述しておいたらすぐに見つかってしまうだろう。氏はCコンパイラに仕掛けを作りこんでおき、login.cをコンパイルするときに、バックドアコードを挟み込むような特殊な仕掛けを用意しておいたのだ。それにもう一案、これだけではCコンパイラのソースコードを見たときにインチキが発覚してしまう。そこで、Cコンパイラをコンパイルするにはコンパイラが必要だという点に着目し、Cコンパイラのソースコードの中に、『"login.c を見つけたら書き換える"コードを挟み込むコード』を挟み込んだ。そしてそのコンパイラでコンパイルすると、コンパイルされた新しいコンパイラにもlogin.cを書き換えるバイナリコードが含まれるようになったのだ。そうすると、コンパイラのソースコードにはlogin.cを書き換えるというインチキ部分が無くても、コンパイラのバイナリの中には未来永劫login.cにバックドアを挟み込むインチキ部分が含まれるようになったのだ。

この恐るべきhackに関しては1985年(実に今から20年前)に論文が出ている模様なので、興味のある諸兄は読んでみると面白いと思う。

http://www.acm.org/classics/sep95/

そしてそこでの教訓は、オープンソースだからといって安全だと過信してはいけない。ということだ。上記の例では、login.c のソースコードのどこをどう見てもバックドアなど発見できない。同じように linux-2.4.24.tar.gz のどこを見てもバックドアを発見できないかもしれない。しかし、自分のマシンのgccコンパイラに、バックドアを書き込むコードが含まれているとしたら。そしてそれが gcc-3.0.3.tar.gz を見ても発見できないとしたら(gcc-3.0.3.tar.gzを書き換えるコードがgccに入っていたとしたら)。ソースコードには見えないhackがこの世に存在する可能性を頭に入れておいて損は無いだろう。

May the Source be with you.

本物のプログラマは pascal を使わない

さて、伝説の本物のプログラマの話に影響を受けたところで、これまた懐かしい『本物のプログラマは pascal を使わない(bit誌1985)』をlinkしておく。

http://www.ne.phy.saitama-u.ac.jp/~okamura/misc/real-progstory-j.html
ここで語られている本物のプログラマは真の漢だと尊敬できるhackerだ。そういえば、tkane君やおいらも、高校時代に

 0000: C3 00 00
を自作Z80ボードに書き込んでM1とRDのクロックを計測してマイコンが走っているかを確認したりしたもんだ。本物のプログラマは道具に頼らない。上記の論文の中には「4Mバイトのコアダンプからバグを見つける」といった神業も紹介されているが、
本物のプログラマはコンピュータの前に居なくても、遠隔地にいる人間にレジスタを読み上げさせ、
バグの箇所を推測し、遠距離電話だけでシステムを修復させることができる
といった姿は真に尊敬し目指したい目標だ。
・本物のプログラマはビーチで砂にフローチャートを描く
にはなりたくないな。笑
パーティでは部屋の片すみでオペレーティング・システムのセキュリティと
それをどうやって破るかを話しているのが,本物のプログラマである. 
笑えないなぁ。あ、久しぶりに本物のプログラマ達と飲みたくなってきたなぁ。秋葉原のPROTOどうですか?無線LANあるし。笑

さて、本物のプログラマは道具に頼らない。ソースコードデバッカなど、デバックができないヤツが使うもんだ。

デバッグなどLED 1個あれば十分
と意気込んでいても、現実には効率が悪すぎるよね(A^^;;
実際に今友人がH8マイコンのコーディングをしていて、シリアルポートは全部使用されていてprintfデバックもできないと悩んでいるので、アイディアを考えてみよう。7セグLEDでもつければステータスを1つ表示できるけど、7セグLEDをつなぐだけのbitの余裕も無い(し、配線がめんどくさい)。そこでだ。1byte程度のステータスを出力する方法を考えてみた。
・未使用D/Aポートを使い、テスターで電圧を読む! (工作もいらず簡単)
・ソフトウェア シリアルポートで手クロックでデバックメッセージを出力する
・タイマカウンターを使い、周波数出力をして周波数カウンターでステータスを読む(正確だね16bitくらい行けそう)
・D/Aが無いならタイマカウンターでPWM出力をしてコンデンサで平滑してテスターで電圧を読む。
・てかむしろ1bit D/Aで AUDIO出力して音声出力!!
いくらでもできるじゃーん。
がんばれ