********************************************************************** セッションS5-c 分科会３テーマ：分解 Theハマナ４コーディネータ：二上貴夫氏（東陽テクニカ／SESSAME／東海大学）日時：2007/8/31 15:10〜17:00 参加人数：54名（終了時） ********************************************************************** 補足：本セッションは，株式会社ヴィッツの新人教育プログラムで開発されたソースコードに対して『リバースエンジニアリング』という検証手法を適用し，開発成果物が妥当なものであったかを，参加者から意見を募りながら，議論・検証を行うものであった．また，新人教育プログラムとしてHamana-4の開発に携わった新人２名，および，教育を施した側である株式会社ヴィッツのメンバーもセッションに出席し，司会および参加者から質問を受けることも多かった．このため，議論の性格上，発言者をいくつかに分類して議事録を残すべきと判断した．よって，本議事録では，発言者をコーディネータ二上氏を＜司会＞，Hamana-4のソースコードを記述したヴィッツの新人２名を＜新人＞，株式会社ヴィッツの方々を＜ヴィッツ＞，Hamana-4のソースコードにリバースエンジニアリングの手法を適用し，スライドを用いて解説した講演者を＜講演者＞，その他の会場に出席した参加者を＜参加者＞として，それぞれ分類して表記する．＝＝＝＜司会＞はじめの挨拶本セッションの企画理由は，Hamana-4で開発された成果物に対する議論をしたいからである． Hamanaは，最初の一回は東海大学で企画されたものである．そのときは，打ち上げ時に太陽熱でやられてしまい，目標の半分程度のデータ採取に終わった．後継の２〜４では株式会社ヴィッツの新人教育としてコーディング／開発が行われた．本セッションで採用しているリバースエンジニアリングは，日本では企業・学科ともにそれほど存在していない．工学分野では検査の専門・研究者はいる．ソフトウェア工学分野ではまだ存在していないのが現状であり，これから伸びる分野であると思われる． Hamanaは教育的観点もある．データ採取という目的を達成することも大事だが，書いたコードがどうだったのかを議論するのも新人教育として大事になるのではということを，このセッションを開くにあたって考えた．このことから，開発に携わった新人２名にも在籍を委託した．新人の作ったプロダクトに対するIB&B，リバースエンジニアリングを行い，参加者と一緒に議論を重ねていきたい．（資料を配布）＜講演者＞去年はSESSAMIでのポスター発表としてSWESTに参加した．今年は，ヴィッツの新人チームの作成したソースコード一式を頂き，リバースエンジニアリングによって解析した． Hamana-4の主な動作としては，ロケットを打ち上げ，データをサンプリングし，EEPROM にデータを格納して出力し，EEPROMを消去することである．今回は，ロケットを打ち上げている間の，データをサンプリングしてEEPROMに格納する部分を解析対象とした．＜講演者＞リバースエンジニアリングにおいて用いるツールの説明を行う．ソースコードしかない状態では議論のために分かりにくいという問題があるため，もう少し抽象度を上げるため，構造図やアーキテクチャテンプレートなどのいくつかのツールを用いる．構造図は，モジュールの呼び出し関係などを表現したものである．アーキテクチャテンプレートは，物理層などの各レイヤごとにエリアをはっきりさせ，整理して可視化したものである．（例として，スイッチの切換えによってLEDの点滅を制御するシステムを挙げて説明する．）リバースエンジニアリングを適用する前に，ソースコードに対して静的な解析を行った．まず，プロファイリングを行った．ソースコード数は3675行，１関数でもせいぜい200行程度であった．モジュールごとにうまくファイルが分割されているという印象を受けた．ファイル数は， .cで13，.hで56（OS関連のヘッダ含む）であった．次に，タスク図を描き，どのようなタスクがあるのか，依存関係は存在するかを調べた．どのタスクも独立性が高く保って動いているという印象を受けた．総タスク数は８個だった．同時に動作する可能性のある部分を洗い出し，動的に危険となる部分が無いかを調べた．＜司会＞タスクの切り分けは自分たちでやったのか？＜新人＞自分たちで要求などを分析して行った．＜司会＞普通はこれは誰がやる仕事か．＜ヴィッツ＞ソフトウェアをデザインする人間になる．今回はHamana-4の実行委員長をやっていたので，詳細は分からない．＜司会＞これは入社２〜３ヶ月目の人間でできることなのか？ちょっと予想外で信じられない．普通にはできないだろう．文科系の学校を出て，新人教育を受けただけで，このタスク構造図を描いた．＜参加者＞ネットで調べたりしたのか？＜新人＞特に調べていない．入社後の集中講義でRTOSを使った簡単なプログラミングを勉強した．周期ハンドラによってLEDを点滅するプログラムを例として，役割ごとにタスクを分けるということを習った．＜司会＞良い答えになっている＜ヴィッツ＞最初の２週間の集中講義で詰めれるだけの知識を詰め込んだ．＜司会＞教育が上手ということか．＜講演者＞（タスク図のスライドの説明を再開する）具体的には，mode_task / pre_task / call_task / memory_task / measure_task / pc_task / flush_task / check_taskの8タスクが存在していた．ロケットの打ち上げ中に動くタスクを把握している．まず，mode_taskについて，アーキテクチャテンプレートを適用した．＜参加者＞資料の字で書いてあるものは関数名か？＜講演者＞そうなっている．印刷の都合上，字が小さくて申し訳ない．＜参加者＞レイヤーが３層しか分けられていないのは妥当なのか？＜参加者＞レイヤーを綺麗に分けたいのだろう．それがCで良いは疑問であるが．個人のセンスによる部分がある．階層化して図にすると，レイヤーが多いほうがいいと思う．＜参加者＞今のレイヤーが果たして足りているのかという議論は別？＜講演者＞リバースエンジニアリングでは，静的な構造として綺麗にレイヤーが分けられているかが重要となる．ソースコードは差し置いて議論したい．＜参加者＞３層で十分だという議論ではない？＜講演者＞今回の今の議論ではこれでいいだろう．＜参加者＞今はミニマム３層として考えているのでは．まだ定量的なことが決まっていない．物理／論理で２層は基本．そこからどう考えていくか．タスクの関連がどうかで増やしていく方向の考えになるのでは．＜参加者＞言いたいことはまだいっぱいあるが，時間にご協力をと止められそうなので，やめておく．＜司会＞そろそろ言おうかと思っていた．（会場内，笑い）＜講演者＞（スライドの説明を再開） .cファイルと関数の関係を調べた．ファイルごとの関数定義を図に表し，図の関数の後ろから線がある場合は呼び出し側，前からは被呼び出し側となっている． "sfrh83069.h"をincludeしているファイルの一覧を示した．もう少し整理したほうがいいかもと感じた．＜司会＞ includeをもう少し整理したらというのは＜講演者＞物理的な変更が，上のレベルに影響を及ぼす可能性があるため．＜司会＞新人の意見は？＜新人＞デバイスドライバやDIPなども考えて・・・（答えに詰まる）＜司会＞ついやっちゃいましたという感じ？＜参加者＞難しい判断になると思う．物理的なDIPスイッチということを考えたら，あまりこうやりたくないとも思う．＜司会＞それはなぜ？＜参加者＞ Cの限界．ある信号が特定の範囲だけに影響を及ぼすことができない．可視性の局所化ができない．どっちの存在が多いかという問題．＜司会＞それはどっち？＜参加者＞ケースバイケースになる．＜司会＞新人の方々，理解できた？ある開発周期になるとこういう問題がたいてい起きる．＜新人＞ DIPのポートが何番かというのをsfrに書いてある．ワンクッションおきたかったが，時間的な制約もあり実現できなかった．＜参加者＞ケースバイケースになるんだろう．最上位のHWを書きたいのなら書いてもいいのでは．可視性が保てるならという条件はあるが．＜参加者＞直接includeしているのが問題では．ワンクッションおけば後の処理もすっきりする．＜参加者＞アドホックにやるという方法もある．＜司会＞ includeのリバースも重要であるが，そういう技術はまだあまり存在しない．ケースバイケースでいろいろやるというのも考えられる．合理性が見えてこないようなら，リバースしたら見れるという方法もあるということだ．＜講演者＞（スライドの説明を再開）ファイルのinclude関係について．物理層にあるファイルが，上位層のヘッダファイルをincludeしている．このようにした理由を聞きたい．＜参加者＞同じものを２回includeしているということか？そもそもout_of〜〜が何をしているものなのか？＜講演者＞コンバータの入出力だと思われる．＜新人＞設計の担当が違うのでちょっと分からない．＜参加者＞悩ましい関係だ．依存の方向が１方向になっていない．＜新人＞ "state.c"のほうは物理層の"hw.c"を呼び出している．実際の処理とは関係ないのかもしれない．＜参加者＞不要なincludeになるということか．＜司会＞では新人に出題を．実際の処理に使っていないなら問題ないと言うことだろう．では，これを消したら将来起きうる問題は？１行残すコストは別にして考えて．＜新人＞・・・＜参加者＞１行残すチーム，includeをすっきりしているチーム，どっちが良いのかという問題になる．＜司会＞では，ヴィッツの超ベテランに聞いてみよう．＜ヴィッツ＞ちょっと判断できない．＜参加者＞１行残すほうが適切かも．＜司会＞将来この部分を使う可能性があるのならという議論になる．例えば，この物理層だけを他のシステムに流用していくと？コンパイルが通らなくなる．これを考えるとリバースエンジニアリングの価値が出てくる．＜参加者＞物理層をそのまま他のシステムに持っていくのは幻想では？＜司会＞この場合だったら問題になるのは明らか．＜参加者＞わざとエラーを出力してからソースを読んでというのは？＜司会＞エラーを出す前にソースを読もうよ．議論の本筋に戻ろう．＜講演者＞（スライドの再開）静的解析は以上で，次のステップに移る．タスク間で共用される変数を調べた．グローバルデータはどのようなものがあるか，並行するタスクはあるのかを動的に調べる．＜参加者＞このスライドは，資料のどこに対応している？＜講演者＞配布資料には記載していない．例えば，変数ad_state ← ←タスクmeasure_task ←タスクmemory_task これが大丈夫なのかは，今は議論の対象ではない．次に，リアルタイム性を検証する．（スライドの図を説明）このときに，ワーストケースで本当にデッドラインに間に合うかの検討が必要になると思う．次に，あるドライバが使われていないことを発見した．チップ自身がWrite Enableになるのを待っている関数である． whileループで，信号が変わらなかったら永久に抜けられないコードになっている．＜参加者＞使われていない関数としてあったということか？＜講演者＞あった．資料には記載していないが，危険であるという指摘として紹介した．＜新人＞使うには危ないという認識はあった．＜参加者＞ポーリングするのが悪いという見方もある．逆に，ポーリングしなければいけないというケースもある．＜司会＞このことをプロダクトとして残すか？ソフトウェアとして手段が無いという絶体絶命のときに使うこともあるだろう．＜参加者＞一般的な用途で言えばどうなるか？＜司会＞このA/Dの場合ではという議論をしたい．＜参加者＞この用途は？＜司会＞ Hamana-4だ．＜参加者＞これはマイコンのA/Dを抽象化したレイヤーである．では，このレイヤーを移植して，出力にタッチパネルを使うという議論は有効か？＜司会＞駄目だ．Hamana-4にパネルはないから．＜参加者＞具体的な場合の議論についてということか．＜司会＞具体的な件についてどうでしょうという議論をしたいわけではない．今回は，Hamana-4のリバースエンジニアリングに関して議論したい．＜司会＞講演者に．このループの用途が良く分からないのが問題ということか．＜講演者＞このループに入ると非常に危ないと言っただけ．これが駄目とは言っていない．指摘しないと危険な事項である．＜ヴィッツ＞タイムアウトをとることも認識している．しかし，まずは新人教育として成果物を出したい．彼らは新人ということもあり，あえてその認識を教えていない部分もある．＜講演者＞関数e2p_stateをみて，このタスクの動きが危なくないのかをさらに解析した．＜参加者＞これは何の関数？＜講演者＞これはEEPROMを制御する関数．名前の付け方にちょっと言いたいこともあるかもしれないが，それは今の問題ではない． openとcloseの方法が対応していないことを指摘した．これは新人も気づいていたようだ．次に，タスクの凝集度について． ad_stateはmemory_taskから１回呼ばれている．しかし，memory_taskは，本当はad_state の値を必要としていない．例外処理をもう少し検討した方が良かったのではと感じた．同じ話がe2pについてもいえる．＜司会＞ちょっとそこで，こそこそ話しているのでマイクを向けたい．＜ヴィッツ＞最近ソフトを書いていなかったので，議論が新鮮に感じる．こういうときに例外処理をすればいいのかと再認識させられた．＜参加者＞ここで，初期化前にcall_taskを呼んでいるが？＜講演者＞ pre_taskが最初にハンドラをなめていって初期化している．そのままスリープさせて必要に応じて値を読むようにしておけば良かったのでは．＜講演者＞ここまでの結論としては，・静的な解析の結果では，ちょっと疑問もあるが綺麗にタスクが分かれているのでは・動的な解析では，危険なループがあるなど若干の問題を指摘した．タイミング的には問題があるのではという部分もあった．＜司会＞ここで一回区切ります．何か質問・意見等があれば．＜参加者＞どの状態でどのタスクが起きているのかという対応表があっても良かったのでは．並行して走っているタスクは１つにまとめたくなるという議論もある．＜講演者＞今回は，優先度やリアルタイム性の満足については言及していない．リアルタイム要求は，周期で動いているmeasure_taskがあるくらいだったので．＜司会＞ RTOSの１つの観点として，タスクの優先度なども考慮してタスクを分ける．今回は優先度を気にしないでいいタスクが多い．新人たちはタスクという粒度で分割して，タスクユニットテストを作りたかった．機能的に理解しやすい．リバースエンジニアリングを行って，絵にしたことでこの議論ができるようになった．＜参加者＞ツールの機能についての質問．普通はタスクと関数がマトリクス上になる．このことは解析ツールで把握できるのか？＜講演者＞タスクレンジも考慮したツールが必要になるのかも．＜参加者＞リバースツールや設計について感想を．設計では，形式的に違反しているという議論になりがち．リバースエンジニアリングでこれを導けるのか．ソースから読み取れない部分は人間が設計して残しておくべきではないか．＜司会＞そういったことは，ソフト工学屋さんが形式的にやってほしい．今回の議論は，リバースエンジニアリングをしたことで成立した．＜司会＞ここで一区切り．残りの時間で，次の議論をしたい．午前の発表（セッションS2-c）で，Hamana-4の結果として，データが短い時間しか取れず，データ採取を開始後しばらくしてリセットが掛かったのでは？という問題がある．昨日の徹夜部屋でも，なぜこの問題が発生したのかを議論していた．まだ解決していないので，これを皆さんで議論したい．＜講演者＞（スクリーンにソースコードを映し出し，概要を説明．） measure_taskは10ms割込みである．データ採取の最初のほうはうまく動作している．途中からロギングした結果は良いのだが，メモリからデータを吐き出すあたりからどうも怪しいぞ？というところまでが，昨日の徹夜部屋での議論となっている．＜司会＞（タスクの依存関係をホワイトボードに描いていく）＜参加者＞データキューがあふれたときなどのエラーチェックは全てやって，問題なかったのか？＜新人＞全て行い，問題もなかった．＜参加者＞ここで，私ならどうするかという話は・・・＜司会＞ベテランがどうやるかという議論はしない．ここは，新人の成果物にリバースして，どうすれば解決するかという議論がしたい．＜講演者＞ ROMから読み出した結果がおかしいらしい．＜参加者＞アドレスの位置指定などの読み出し自体は正しいのか？＜新人＞先頭位置は正しい．メモリ番地指定も正しい．ある地点から突然乱れた値が出てくる．そこからゼロではない一定の値が出てくる．センサが動作していないわけでもない．＜講演者＞他の点で気になる人は？＜参加者＞ RTOSについて詳しくないので，違う視点から．つまりHWの不良では？ HW的に何枚か基盤の候補があれば，それを試してみるとかあるのでは？そもそも，正常データのサンプルはあるのか？＜司会＞ HWの不良に対する対策は？＜新人＞本当はもう１個HWを準備する予定だったが，時間の関係で実現できなかった．２個目はもう基盤がくり抜かれて，会社で実装を待っている段階．＜新人＞（スクリーンに，午前のセッションで示したグラフの，元データのEXCELファイルを表示）＜司会＞後ろの席の方のために，口頭で表を説明する．データ値が正常ならば，00とFFが入るはず．EXCELにも10進の255が入っている．異常なときには，411などの値が入っている．今やっている作業は一種のリバースといえる．データリバースである．カラムがずれたのか？書込み／読出し位置が違ったのか？取り出す位置の指定がずれていったのかも？＜参加者＞自分ならまず前半のタスクを全部止めて・・・＜司会＞それは次のステップになる．まずはリバースして，問題を起こしている犯人を捜したい．＜司会＞データ範囲としてどういう確認をした？＜ヴィッツ＞デバッグツールをつくった担当はここにはいないが，おそらく全バイトを書いていて確認しているはず．タスクスタックは壊れていないことは確認している．＜司会＞あとはどのデータが分かればハマナ4.5ができるのか？という指摘がある人は．＜参加者＞このEXCELの表はいくつもあるのか？何度もデータを取ったのか？＜講演者＞徹夜部屋で何度も試している．＜参加者＞いつも同じ場所で動作がおかしくなるのか？つまり，再現性があるのか？＜新人＞今，３回の結果をみたが，同じ場所である可能性がある．＜参加者＞自分の分科会でブラックボックステストをやった．結果からどんな演算をしているかを推測するテスト．デバッグは出てきたものを予測するのも大事，内部をチェックするのも大事になる．＜司会＞他には？＜参加者＞発射前のテストはしたか？打ち上げる前のものは正常なデータだったのか？＜新人＞・・・＜ヴィッツ＞つまり，一回でも打つ前にテストしたかという質問だ．＜司会＞いつまともに動くようになった？＜新人＞一週間前になる．＜司会＞ローカル試射はやったのか？＜新人＞やっていない．check_taskが発射当日にようやく出来て，試している時間が無かった．＜司会＞アポロの例を話す． 11は，発射の時間まで時間がなく，テストを全くせずにとにかく飛ばした．結果的には成功したが，あとで解析したら本当に危機一髪の成功だということが分かった．途中で落雷に遭い，停電していた．それでも，次の12は停電のテストもせずに発射した．これも成功した．しかし，13号では失敗．後で美談として語られているが，これまでのツケを払う形になった．