株式会社NDIASは、2026年5月15日(金)18:00 JSTから2026年5月17日(日)18:00 JSTまで、社員有志で構成されるCTFチーム「cartagaitai」の協力により、車載機器およびIoTデバイスを主対象としたオンラインCTF(Capture The Flag)イベント「NDIAS Automotive/IoT CTF」を開催しました。
まず最初に、本大会に参加いただいた皆さま、本当にありがとうございました。初開催にもかかわらず、多くの方に参加いただき、問題に取り組んでいただけたことを大変嬉しく思います。上位チームの皆さまの高い技術力はもちろん、初めて車載・IoTセキュリティに触れた参加者の皆さまにも、本大会が学びのきっかけとなっていれば幸いです。
そして作問・運営のみなさまもありがとうございました。無事に終わることができて、ほっとしています。
本記事は、本大会の開催・運営を振り返ってまとめたものとなります。
.png?width=826&height=607&name=ndiasctf2026_top10%20(2).png)
- 問題設計
本大会では、何らかの形で車載・IoT機器に関係する全35問を出題しました。
車載・IoTセキュリティでは、単にソースコードやバイナリを読むだけでなく、通信、ハードウェアに近いデータや波形、制約のある実行環境などを考慮する必要があります。また、利用されるプロトコルも、一般的なITシステムで広く使われるものとは異なる場合があります。
本大会でも、そのような実践的な観点を問題設計に取り入れました。CAN通信、ファームウェア解析、組込み環境、波形解析など、車載・IoT機器に近い題
材を扱うことで、参加者が実際に対象を観察し、仮説を立て、試行錯誤しながら解法にたどり着ける構成を目指しました。
特にCAN通信に関する問題では、参加者がリアルタイムにサーバと通信できないと面白さが大きく損なわれます。そのため、CAN通信をTCPでトンネリングし、ユーザからの接続ごとに分離された環境を起動するためのインフラを新規に用意しました。
- 難易度バランス
問題の難易度は、参加者の経験・スキルに応じて幅広く楽しめるよう、以下のようなバランスを意識しました。
| 難易度 | 問題数 | 設計意図 |
| Tutorial | 3 | 問題環境や操作に慣れてもらうための練習用問題 |
| Easy | 17 | 初心者でも取り組みやすく、車載・IoTセキュリティに触れる入口となる問題 |
| Medium | 10 | ある程度の技術知識や解析経験を必要とする問題 |
| Hard | 5 | 高い解析力、実装力、発想力を要求する高難度問題 |
半数を超える問題は、CTFに慣れていない参加者でも、手を動かしながら学べることを重視して作問しました。一方で、中級者・上級者向けに、専門的な知識や深い解析を必要とする高難度問題も用意しました。
一部には、学習コストが高く、大会中にゼロからキャッチアップするのが難しい問題も含まれています。ただし、そのような問題であっても理不尽さはできる限り減らし、数チームが解ける程度の難易度を想定して設計しました。
-
学びのある問題作り
本大会では、参加者にとって「解いて終わり」ではなく、解いた後に技術的な学びが残ることを重視しました。CTFの本質は、遊びながら実践的に学べる点にあると考えているためです。
問題作成にあたっては、特に以下の点を意識しました。
・各問題に、参加者へ伝えたい「何か」を持たせること・車載・IoTセキュリティに近い考え方を求めること
・実際に解析対象を観察・試行錯誤する必要があること
・初学者でも段階的に理解できる導線を用意すること
・上級者にも十分な歯ごたえがある問題を含めること
作問者がそれぞれの問題に込めた意図や、伝えたかった技術的なポイントが、少しでも参加者に届いていれば幸いです。 -
AI対策
本大会では、AIを用いた単純な自動化だけでは容易に解けないよう、問題構成にも一定の工夫を取り入れました。AIの利用自体を制限するのではなく、「AIだけでは解けないが、人間がAIの助けを借りれば解ける」程度のバランスを目指して設計・作問しました。
しかし、作問・レビュー時点ではAIが解けなかった問題の一部が、大会直前にはAIに依頼するだけで解けるようになっていることも確認されました。生成AIの性能向上が非常に速く、作問側の想定を短期間で上回ってくる場面があったことは、今回の大きな発見の一つでした。修正が間に合わない問題については、そのまま出題する判断をしました。
また、完全自動化されたAIでは解きづらくするため、いくつかの施策を問題中に取り入れました。以下はその一例です。
(1) ファイルサイズの大きい問題を作成する。
(2) ダミーのフラグを複数用意し、誤判定を誘う。ただし、それがダミーであることは人間には明らかに分かるようにする。
(3) 可読文字列の間に不可視のパディングを含め、人間には読めるが、機械的には意味を取りづらくする。
(4) 画像にヒントやフラグを含め、単なるバイナリ列ではなくメディアファイルとして解釈する必要がある問題にする。
(5) 音声にヒントやフラグを含め、メディアとして再生・解釈しないと解けない問題にする。
(6) 明らかな攻撃対象経路を用意しつつ、想定解は別経路に置く。ただし、問題文中には人間が気付けるヒントを含める。
(7) QEMUによるエミュレーション、Docker内での動作、リモート環境への侵入後のピボットなど、特殊な実行環境を前提とする問題を含める。
(8) 専用ツールの利用が重要となる、ホワイトボックス暗号や波形解析の問題を採用する。
(9) 解析ツールが豊富なx86-64中心の問題だけでなく、ARMベースのバイナリ問題を多く採用する。
結果として、これらの施策の多くは最終的に突破されてしまったように見えます。出題側は一度問題を公開すると大きな修正が難しい一方で、参加者側は解析環境やAIの使い方を随時改善できます。この非対称性は、AI時代のCTF作問における難しさとして強く感じました。
一方で、大会中に特に効果が高かったと感じた施策は、明らかな攻撃対象経路を用意しつつ想定解を別経路に置く方法でした。AIは一見攻撃できそうな箇所に注力し、他の探索を十分に行わない傾向があるように見えました。
次に効果があったと感じたのは、音声ファイルを用いた問題です。ファイルシステム上のMP3ファイルを再生するだけで解ける非常にシンプルな問題であっても、相対的に解答数が少ない傾向を保ち続けたのです。これは推測ですが、現在のAIを用いた自動解析では、ファイルをメディアとして再生し、人間のように意味を解釈する処理がまだ十分に行われていないためだと考えています。
今回の作問を通じて、AI時代においても、対象を観察し、違和感に気付き、仮説を修正しながら進める人間の解析力は依然として重要であることを再確認しました。