いろんな技術に触れたい

日頃色々触れた技術を自分なりにまとめておきたいと思ってます。難しいものほどブログ書く時間がかかるのが問題・・・

バスオフ攻撃(bus-off attack)について解説します

f:id:Tokina:20180119033302p:plain

こんにちは。

どうも、(バーチャル)論文読みおじさんです(適当)。

突然ですが、今回は自動車への攻撃手法の一つであるバスオフ攻撃(bus-off attack)についての解説をします。


といっても、バスオフ攻撃を初めて発表した論文についてまとめたので、そちらのスライドとその補足といった形になります。

この論文についてまとめている人がいないようでしたので、もしかしたら誰かの参考になると期待して・・・



早速ですが、バスオフ攻撃についてまとめたスライドを貼っておきます。


バスオフ攻撃の論文について / Where does it available?

バスオフ攻撃についての論文ですが、(ACM) CCSというセキュリティに関するカンファレンスの2016年にて発表されたError handling of in-vehicle networks makes them vulnerableがそれになります。


下記リンクのAgendaより参照できます。
ACM CCS 2016 | ACM CCS 2016 Website

Cho, Kyong-Tak, and Kang G. Shin, "Error handling of in-vehicle networks makes them vulnerable," Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, 2016.


また、以下でその論文のPDFを入手することが可能です。
Error Handling of In-vehicle Networks Makes Them Vulnerable


アブスト / Abstract

Contemporary vehicles are getting equipped with an increasing number of Electronic Control Units (ECUs) and wireless connectivities. Although these have enhanced vehicle safety and efficiency, they are accompanied with new vulnerabilities. In this paper, we unveil a new important vulnerability applicable to several in-vehicle networks including Control Area Network (CAN), the de facto standard in-vehicle network protocol. Specifically, we propose a new type of Denial-of-Service (DoS), called the bus-off attack, which exploits the error-handling scheme of in-vehicle networks to disconnect or shut down good/uncompromised ECUs. This is an important attack that must be thwarted, since the attack, once an ECU is compromised, is easy to be mounted on safety-critical ECUs while its prevention is very difficult. In addition to the discovery of this new vulnerability, we analyze its feasibility using actual in-vehicle network traffic, and demonstrate the attack on a CAN bus prototype as well as on two real vehicles. Based on our analysis and experimental results, we also propose and evaluate a mechanism to detect and prevent the bus-off attack.

つまり、私達は新しい攻撃可能性であるバスオフ攻撃を発見したよ、実際に実験してその防御の手法を考えてみたよ、ということです。

バスオフ攻撃ってなんですか? / What's the bus-off attack on vehicle?

バスオフ攻撃を理解する前に、CAN(Controller Area Network)とそのエラー処理について理解をしなければなりません。

ここではその理解を助けるための補足のリンクを紹介しておきます。

monoist.atmarkit.co.jp


上記記事にて、バスオフについての記載があります。(以下、引用です)

送信エラーカウンタの値
•0~96:警告リミット以下の『アクティブ』。エラーカウンタ値が「96」を超えるとCANコントローラは警告(エラーフラグのセット、割り込み)を発する。
•97~127:ノードは『アクティブ』。エラーカウンタ値がこのエリアにある場合、バスは重度の障害を持っていることになる。
•128~255:ノードは『パッシブ』(ほとんどのCANコントローラはこの領域への変化についてマイコンに報告しない)。また、送信待機を行う。
•255:エラーカウンタがこの値への到達後、ノードは『バスオフ』となりバスから切り離される(バスへの送信アクセスが不可となる)。マイコンはこの領域への移行を知ることができる。


これが大事です。
ECUは通常Active Error modeにいるのですが、送信エラーカウンタ(TEC)が127を超えるとPassive Error modeになります。
さらにエラーカウンタが255を超えるとバスオフ状態になってしまうのです。

f:id:Tokina:20180119032900p:plain
ECUの送信エラーカウンタによる状態遷移

このバスオフ状態になると、ネットワークから切断され、ECUのシャットダウンなどにつながってしまいます。

これを強制的に引き起こすのがバスオフ攻撃です。

この論文の攻撃手法 / The new method to bus-off attack


実際、このバスオフ攻撃の実現の可能性はもともと考えられていました。

この論文の”新規性”はバスオフ攻撃を実現するための新しい手法を提案していることにあります。

それはバスオフ攻撃を行う際のメッセージ衝突のタイミングです。
私のスライドの34ページ目(4.3 Tx Synchronization)からがそれに該当します。


簡単に言うと、強制的にノードのメッセージ送信をバッファさせ、アイドル状態になるのを待たせます。
バスがアイドルになると同時に攻撃者もメッセージを送信することでエラーを起こします。

これにより、攻撃対象のノードの送信エラーカウンタ(TEC)を増加させ、バスオフ状態にします。

実車での評価について / Evaluation using Actually Car

こちらの論文ではOBDポートから実際にバスオフ攻撃を行った評価まで行っています。

実車は以下の2台です。

  • 2013 Honda Accord
  • 2016 Hyundai Sonata

実車トラフィックは流れているメッセージの周期などが複雑であるため、プロトタイプほどうまくはいっていません。

しかしそれでもかなり実用性(?)のある結果となっています。



おまけ(その他バスオフ攻撃に関する論文について)

  • SCIS 2016 1E2-2

ラズベリーパイからのスタッフエラー注入によるCAN ECUへのバスオフ攻撃
◎亀岡 良太(立命館大学)、久保田 貴也(立命館大学)、汐崎 充(立命館大学)、白畑 正芳(立命館大学)、倉地 亮(名古屋大学)、藤野 毅(立命館大学)

プログラム|SCIS2017 暗号と情報セキュリティシンポジウム

  • マルチメディア,分散,協調とモバイル(DICOMO2017)シンポジウム 2017 pp. 1163-1168

特定のCANメッセージを送信するECUに対するバスオフ攻撃を利用したなりすまし攻撃
◎家平 和輝 (広島市立大学情報科学部), 井上 博之 (広島市立大学大学院情報科学研究科/CCDS), 石田 賢治 (広島市立大学大学院情報科学研究科)

DICOMO2017 プログラム





以上が自動車の攻撃手法の一つであるバスオフ攻撃についての紹介になります。

スライドが長いですが、興味のある方は目を通して見てください。

参考になれば幸いです。

自動車ってどうやってハッキングするんですか? [IoTSecJP #2 振り返り]

f:id:Tokina:20180108153711p:plain

こんにちは。

本記事は主にIoTSecJP #2でお話させて頂いたスライドを補足したいと思います。

まずは、今回の機会を頂いた黒林檎氏に感謝します!ありがとうございました。


さて、早速ですが、私のスライドを貼っておきます。 ※表示がちょっと崩れてしまっています



公開用に一部秘匿しています。

補足

Jeepのハッキング例について

2015年にJeepがハッキングされ、自動車のハッキング事例が脚光を浴びたのが記憶に新しいと思います。
ハッキングを成功させたのはチャーリー・ミラー(Charlie Miller)氏とクリス・ヴァラセク(Chris Valasek)氏です。
Jeepに搭載されているインフォテインメントシステム(ナビ)には3G回線と接続する機能が搭載されていました。しかし、最初からSSH可能なポートが開いていたそうです。
そこで、その脆弱性をついて遠隔操作を可能にしました。

彼らをレビューした動画がYoutubeにありました。


Hackers Remotely Kill a Jeep on the Highway—With Me in It

実際に遠隔から、実際に走行している自動車のホーンを鳴らすなど、遠隔操作を実現しています。

ジョージ・ホッツ (george Hotz)氏のCODE BLUEでの登壇内容について

今回、攻撃にターゲットを据えた話をするにあたって、折角の機会なのでジョージ氏が公開しているopenpilotについて調べてみました。
openpilotは実際にGithubに公開されています。

GitHub - commaai/openpilot: open source driving agent

彼の開発したシステムの内容をまとめますと、以下のようになると思います。
これから分かるように、各社のCANIDの解析結果がopendbcとして公開されてしまっているので、これは結構やばいのでは・・・?

f:id:Tokina:20180111031118p:plain
Geoge Hotz氏のopenpilot関係性まとめ

openpilotはオートクルーズを模擬するようなものなのですが、そのためには実際にCANメッセージなりすますことで、実際のECUをなりすまします。
しかし、各社搭載しているECUが異なる、乃ちCAN IDが異なるため、その各社同士の違いを吸収するのがopendbcになります。
openpilotは変換されたメッセージを解釈することで、自動運転を実現します。

※追記


@yubedrumsさんより、OBDドングルとの接続方法について補足頂きました。ありがとうございます!

実践!自動車ミニハックについて

例の脆弱そうなOBDドングルを実際に使ってみた例です。
コマンドを実行して、実際にCANメッセージをモニタできている様子の動画を添付しておきます。

http://himitu23-blog.tumblr.com/post/169458387666/obdドングルで自動車のcanメッセージを覗いたりする様子です

シミュレータとアナライザについて

最後に少し質問を頂いたので、メモとして残しておきます。

実際の自動車でなくても、CANの応答を確認するためのツールとしてECUシミュレータというものがあります。
少しお高いですが、、、

www.opsoc.co.jp


また、アナライザ(OBDからCANをモニタするツールとして)は下から上まで様々あります。
送信/受信バッファがある程度あるものですと、なかなか高価なものになると思います。

恐らくRasperry Pi + PiCANのセットが一番安く上がるのではないのかと思います。
ソフトウェアとしてはcan-utilsが利用できます。

skpang.co.uk

github.com

最後に

今回はBus PiratesやBluetoothハックなど、今アツイところの話をたくさん聞けたので大満足です

秋葉原にいっていろいろとあさりたいと思います!笑

自動車セキュリティの今について自分なりにまとめてみる

f:id:Tokina:20171208133818j:plain
東京モーターショー2017より

こんにちわ。
メリークリスマスまであと2週間とちょっとですね。(この記事は2017年12月8日のものです)

この記事は私の研究室のアドベントカレンダーの第三回目の記事にあたります。


皆さんはお車をお持ちでしょうか?
運転免許はお持ちでしょうか?
運転経験はいかほどでしょうか?

「自動車のセキュリティって聞いてどう感じますか?」

たぶんそんなのずっと先のことだよ、とか
そんなの実際に起こるわけないよ、など感じる方がほとんどだと思います。

そこで、自分の経験から自動車セキュリティについて、それが一体どんなものかまとめてみたいと思います。

今回はとても長いので「続きから読む」機能をつけておきます!

続きを読む

Write Up - Practical CAN bus hacking

f:id:Tokina:20171113184354p:plain

こんにちわ。

ライトアップ書きます書きました!忘れないうちに・・・
分かる人には分かるレベルで書こうと思います。
書いていたらまた来年も出たくなってきました。


さて、皆さんもごぞんじCODE BLUEに参加してきました。
今回学生スタッフの応募をしていたのは知っていたのですが、CAN HackのCTFに出てみないかとお声掛けいただいたので、折角の機会なのでチャレンジした次第です。
SecHack365の人や、その他の知り合いの人がたくさんいて楽しい限りでした。皆さんお疲れ様でしたー!


codeblue.jp


CODE BLUEでは複数のCTFが同時に開催されています。
私が参加したのは、Practical CAN bus hackingというCTFです。

f:id:Tokina:20171113184930g:plain

みなさんは実際のCANバスをハッキングしたことがありますか?CANバスのハッキングとは、どんなものだと思いますか?難しい?高価なデバイスが必要?答えを知るために、ぜひ私達のCTFに参加し、あなた自身の手で私達のラジコンカーをハッキングしてみて下さい!


え、CANなのにCTF?

私も初めての参加なのでそう思いました。だってCANは16進数との格闘ですし・・・

それでは、ぬるっとらいとあっぷかきます

参加メンバー

今回、広島市立大学が主体で協力していただきました
そこで、某I先生の働きかけにより、Trillium 株式会社さんと協力して挑みました。

www.trillium.co.jp


もうひとり、筑波大学の友人と合わせて2チーム結成しました。
私のチームは、「私、広島市立大学学部生、Trilliumさん」です。

ちなみに、Trilliumさんの社員さんは外国の方が多くおられるので、皆さん英語でコミュニケーションをとります。
もちろん、CTFも英語でした・・・
私英語そんなとくいではないです。

CTFの環境

「CANのCTFって一体どんな感じでやるんだ???」

参加したことないので、何が必要か、どんな環境かわからずに参加しました。

当日行って、初めて目にしたことになりますね

f:id:Tokina:20171114135454j:plain
Practical CAN bus hacking のCTF環境

こんな感じでした。
なるほど、なるほど・・・

Raspberry PiにPiCANシールドを載せ、そのRaspPiが実際のラジコンカーのような動作を実現しているようです。
このPiCANボードは私もよく触っていたので懐かしかったですね。

わかりやすく図にするとこんな感じです。CANレベルでしかアクセスできません!※解析用ラズパイにはSSHできます。


f:id:Tokina:20171114140911p:plain
CTF環境のイメージ

解析対象もラズパイなのですが、挙動から察するに何かと通信しているみたいでした。
解析対象はCAN以外でアクセスすることが(当たり前ですが)禁止されていました。

使用機器

解析に使用した機器についても簡単にまとめておきます。

  • neo VI Fire (またはValueCAN)& Vehicle Spy 

アナライズに最適なツールです。CANoeよりアナライズに適しているのは間違いないです。
得意なのはリアルタイム解析です。
スクリプトは書けますが不便です。あと一つのメッセージ送るのも面倒です。

  • MicroPecker

ログ分析に最適です。
ログエディターが超優秀なのです。今回はあまりその機能は使いませんでしたが。
スクリプトは作れません。簡単なトリガのみなら設定可能です。

  • CANtact

持っていきましたが使えませんでした。(ケーブルが足りず)
MacPythonスクリプトが使えますし、VMLinuxで通常のCAN-utilsを走らせることができます。
まぁ次のラズパイにSSHすれば良いのですが、SSH環境がないときのためでもありました。

解析対象のラズパイに接続されていた参加者共通の解析機器です。基本的にこのラズパイを利用して解析を進めていく形になります。
標準的なCAN-utilsが使用可能でした。


個人的に本当はCANoeを使いたかったのですが、てにはいりませんでした!w
え、きゃんぬーしらない?

jp.vector.com


とても高いらしいですよ。私も某自動車会社でしか触ったことないです。
ただ、とてもとても便利です。手に入る方は是非使ってみてね。
CANoeが得意なのは(CAPLと呼ばれる)スクリプトです。

事前知識

CANについては皆さんご存知だと思います(ということにしておきます)

今回の環境ではCAN IDとしてExt. IDが使用されていました。通常よりも長い宛先アドレスIDを持つものです。
このExt. IDでは通常のCAN IDの2倍、乃ち4byteが利用可能です。
今回開催者が用意したCAN IDの定義は以下でした。

0xYYYYZZZZ
YYYY - 送信元アドレス
ZZZZ - 送信先アドレス
0000 - ブロードキャスト

通常CAN IDには送信元は存在しないはずなのですが、このような使い方も十分想定できますね。
また、データ部については以下のように定義されていました。

data[0]: データ長(data[0]以降の読み取ってほしいデータ長)
data[1]: コマンド
data[2-7]: コマンドの変数など

例えば
0x01010123#0101
はID: 0101からID: 0123に向けて、コマンド01を送信すると言った感じです。
01コマンドは確かSHUTDOWNでした。


ちなみにこんな感じでやってました。

f:id:Tokina:20171114141656j:plain
共通解析器のラズパイでモニタしている様子

Problem - Capture the Flag

f:id:Tokina:20171114144426p:plain

解けたのだけあっぷします!
もっと解けた人のWriteUpよみたい、、、

ちなみにcandump –d –x –e –a can0 | grep 01240101
のように0101でメッセージを送信し、返信のみを取り出すと以下のようにFlagが降ってきます。以降、Flagが降ってくるというときはこんな感じだと思ってください。


f:id:Tokina:20171114151656p:plain

拡大したものなのでぼやけてしまっていますね

CTF work shop 1

これは超簡単です。確かハートビートを書けでした。
例えば解析用ラズパイでcandumpコマンドをASCII表示つきで見ればわかりやすいかと思います。
写真を取っていなかったのですが、、

現在流れているメッセージを何らかのアナライザでモニタすると、以下のようなメッセージを見つけることが出来ました。

0x12340000#4D55474944455355
4d 55 47 49 44 45 53 55はASCIIでMUGIDESU、ですね?

これからID: 1234はMUGIDESUをブロードキャストしていることがわかります。
定期的にブロードキャストしているのでハートビートですね。

CTF work shop 2

MUGIDESUさんにHiMugiと送ります。
何故か割りとつまりましたが、一度対象のECUを再起動するとうまくいきました

あるIDに対して、以下のようなメッセージを送信する。

The data must contain the following string
'\x07\x08HiMugi' . Don't forget to read the answer from the ECU for the flag!

MUGIDESUといっているIDに対してHiMugiと送りたいので、以下をcansendすればOKです。自分をID: 0101とします。
01011234#48694d756769

これでFlagが降ってきます。

CTF work shop 3

コマンドを理解した上で、MUGIDESUをシャットダウンします。

つまり、以下を送信します。
01011234#0101

これでFlagが降ってきます。

CTF-1

ECUの情報を取り出せるか、というものでした。
EngineとSteeringのECUに対して情報取得コマンドを投げると、分割されたFlagっぽいものが返ってきます。

例えば0121と0124に対して情報取得を意味する03を投げます。※0101を自身のIDだとします
01010121#0103
01010124#0103

Flagが降ってくるのでデータの読む所に注意してくっつけます。

CTF-2

これはなんか全然覚えていません。
ブロードキャストをなりすませ!というものでした。
たしかブロードキャストID: 0000を上手くつかってEngineの値を増やすことが出来たらFlagが降ってきました。
一度成功するとFlagが降ってくるので、それを見落とさないようにしましょう。

CTF-3

ここから2日目に突入するので一度問題を持ち帰りました。
CTF-3はユーロビートでした。ちょっとよくわからなかったですが、他の問題をやっていくうちにわかりました。
車内に音楽再生のユーロビートがあるので、乗っ取っていじってやろう、というものでした。
結局解かなかったですが。。

CTF-4

これ、2日目に一番つまりました。
EngineのECUとのセキュアなセッションを開く際のやり取りをSniffしたので、これを基にセキュアセッションを確立せよ、というものです。
ちなみにCAN界隈ではSecurity Accessと呼んでいます。
1日目の夜に色々調べたりしたのですが、他のチームが解く速度を察するにそこまで難しいものではないはずです。
ヒントを使ったのですが、使う意味があまりありませんでした。

そして何も出来ない午前を過ごし、MiroPeckerで大量にロギングし、ログ分析をしていて気づきました。
そう、同じシード値が使いまわされていたのです。
シード値は問い合わせる度に変更されるので、そこに注意しつつSniffしたものと同じシード値が返ってきたらSniffしたものと同じ鍵を送信する、それだけでした。
このためのPythonスクリプトを後輩に書いてもらって、どうにかなりました。

SecurityAccessを取得し、この状態じゃないと実行できないコマンドを送ればFlagが降ってきます。

CTF-5

「例」としてSteeringのECUとSecurity Accessのやりとりを示すので、どうですか?みたいなやつです
そう、例なので、CTF-4と同じやり方ではありません。
また、その他のチームの解く速度から察するにBrute Forceではなさそうでした。

ヒントを使いました。(あとから考えると、これも使わなくてよかったとは思うのですが)
ヒントは「ビットシフト」

例を見ると、どうやらシードを右にあるビットだけシフトさせると鍵になっていることが分かりました。
これをもとに、シード値を問い合わせる➔鍵を送信する
これでSuccessし、CTF-4と同じようにこの状態のみ有効なコマンドでFlagが降ってきます。

ちなみに残り7分のところでFlagが降ってきました笑

CTF-6

これがあとちょっとだったはずなのに、解けませんでした。
問題はFirmwareをdumpせよ、というものです。ヒントもありません。

通常、CANでDumpといえばOBDのISOTP標準、もしくは物理的にアクセスを試みてFirmwareをdumpするはずなのに、、
うーんうーんと悩んだ結果、やっぱりCTF-4で取得したSecurity Accessの状態でREAD BY ADDRESSしたアドレスを何かするんだと思います。
これをTrilliumさんが挑んでくれていたのですが、どうにもなりませんでした。

CTF-7~

これ以降解くことが出来たチームはいなかったと思います。あまり覚えていませんが、、
これ以降はFirmwareをDumpすることが必須となっているので、まったくわかりません。
もっと勉強します!

結果

f:id:Tokina:20171114151805p:plain
チームTrilliumの最終的なChallengeの画面

f:id:Tokina:20171114141343j:plain

私達のチームはTrilliumとUMR with Tです。私はTrillium側なので残念ながら5位でした。
一位はイエラエセキュリティさんです。強すぎます・・・。次回は勝ちたい。。。!
あとヒントを使わなければチームUMRに勝てたのに。。。

最後に

CTFということで、実際の自動車の解析と直結しているわけではなかったのですが、とてもおもしろいものでした。
普段(?)は実車リバースエンジニアリングしたり、ふにゃふにゃしたりしているので、正直今回のCTFは別物でした。
そもそも送信元アドレスあるなんて。。。

また、某自動車会社に行った際の経験を少しでも活かすことができたと思います。
その自動車会社の人も来られていたので、世界は狭いなあと実感しましたね。
結構自動車関連で知ってる人がちらほらと増えてきているような気がします。そうでもない?

また、今回協力していただいたTrilliumさんにも非常に感謝です!実は日曜日に英検の二次試験があったのでとてもちょうどよかったです!
今後とも機会があれば一緒にお仕事などさせてもらいたいです。


実はCANtactという面白いCANツールをお借りする機会があったので、そちらについても記事をかきたい!


あとCBで講演してる方で、Toyota Crypto 300といってToyotaの鍵生成の仕組みを知りたいと言ってる方がいたようですね。
それにもチャレンジしてみたいですね。

SecHack365の紹介(トレーニーより)

sechack365.nict.go.jp


こんにちわ。

(実は)私は2017年度からスタートしたSecHack365という年間を通したハッカソンに参加しています。

SecHack365 は高度な技術力を持つセキュリティ研究者や開発者を育成することで、我が国のセキュリティ技術力、産業競争力を高めることを目的としています。


というわけで、今回LTをする機会があり、SecHack365の紹介をしてきましたので、せっかくなのでその資料をUploadしておこうと思います。

遠くないうちに第一回からの備忘録を書きたいと思うのですが。。



おまけ

SecHack365はたくさんのスタッフさんや著名な方々がバックアップしてくれています。
そこで、スタッフとしてお手伝いしてくれる方のことをトレーナー、参加者のことをトレーニーと呼んでいます。

次回は大阪なのですが、クリスマスイブが・・・!

MacでopenSUSEのLiveUSBを作成してMacでブートできるようにしたよ

f:id:Tokina:20171024144618p:plain

 

とてつもなく久しぶりにブログを書きます

どうも、Tokinaです

 

さすがにブログは誰も見ていないとは思いますが、せっかくの残りの大学院生の生活でできるだけ多くのことを残していきたいと思います。

 

実は私は電気通信大学の学生で、本学にてopenSUSE.Asia Summit 2017が開催され、そこで学生ボランティアとしてお手伝いさせて頂きました。そちらについては別の記事として書きます!

そこでいろいろお話を聞くことができ、「openSUSEのカメレオンかわいい!」となったので、MacopenSUSEを使ってみたいと思い、久しぶりに記事をかきかきしていているのです

(えっ、カメレオンじゃなくてヤモリなんですか。。。)

 

さて、本題に入りましょう。

 

アジェンダ

 

 

 

openSUSEについて

openSUSEは誰もがご存知(たぶん)と思います。知ってます?

簡単に説明しますと、世界的オープンソースディストリビューションです。そこには多くのその思想に共感したディストリビューターたちがテクノロジーを高めあっています。詳しくは割愛しますが、ギーコ(Geeko)ちゃんが目印です。詳しくは日本のWikiを参照してください。Have a lot of fun ...

無料でインストールディスクとか配っていたので、それを今回は利用しました。

 

 

f:id:Tokina:20171024144308j:plain

 

このLEAPというのは安定バージョン(いわゆるLTS)です。

あとTumbleweedtとはどんどんアップロードされているローリング版です(不安定っちゃ不安定、開発者向け)。

今回はこのLEAP 42.3を入れることにしました。

 

※裏面には熱い気持ちが書かれています

f:id:Tokina:20171024144303j:plain

 

LiveUSB作成までの流れ

  1. ISOイメージを持ってくる
    今回はもらったDVDディスクをImageBurnでばーんしました
  2. ブータブルUSBを作る(意味は後述)
    Windowsでもなんでもいいのですが、今回はMacだけでも完結できます
  3. 何かしらのPCでブータブルUSBを起動し、LiveUSBにしたいUSBメモリに書き込む
    これもなんでもいいのですが、Macでやりました
  4. 起動確認
    どこでも起動できるLiveUSBの完成です

 

用意したUSBメモリ

8Gあれば足りるよ!と聞いていたのですが、openSUSEの標準デスクトップのKDEを入れようとするとちょっと足りないので、できれば16GBより大きいものを推奨します

 

私は8GBより大きなUSBメモリはメイン使用の32GBのものしかもったいませんでしたw

あと、もしブータブルUSBメモリ(インストールするためのUSBメモリ)を作る人がいたら、その人はUSBメモリを二つ用意してください。

ブータブルディスクとかの人はLiveUSBに書き込むところまで飛ばしてください。

 

 

 

MacでブータブルUSBを作成する

この手順は超かんたんです。間違えると死にます。

間違えるとデータが消えます。

 1.Macに接続されたUSBメモリを確認する

 $ diskutil list

ここでブータブルUSBを作成したいUSBメモリを見つけます

 2.半マウント状態にする

$ diskutil unmountDisk /disk/disk???

???はさっき見つけたUSBメモリです。普通disk2以降です。これで見えないのにマウントされた状態になります。

 3.ddコマンドを使ってISOファイルを書き込む

$ dd if='path of your ISO file's directly' of=/dev/rdisk??? bs=4k

 

これで何も出ないですが、ちょっと待ちます。終わるとなんか出ます。

ちなみにddはすごいコピーのコマンドです。bsは書き込みサイズ指定してます。

終わったらエラーと怒られ、Finderさんにもエラーと怒られましたが、普通に引っこ抜きました。

 

これでブータブルUSBがたぶんできました

WindowsでブータブルUSBを作成する

これもいくつか試しました。 最近脆弱性が発表された気がするRufusをつかうのがやはり安定でしょう。ちなみに、他のLinux Live USB Creatorとかでは上手く行きませんでした。unetbootinはつかわないようにと警告されているそうですので、やめておくのが無難でしょう。FATですよ

 

LiveUSBとブータブルUSBの違い

いろいろ調べていて思いましたが、あんまり区別されていないので私自身よくわかっていません

 

どうやら

  • LiveUSB➔PCからUSBメモリ本体をホストとして起動する
  • ブータブルUSB➔OSイメージを入れたインストールディスクとして利用する

こんな認識で調べていくと、大体うまくいくことがわかりましたよ(超いまさら)

最後LiveUSBを作成したのは6年ほどまえにBackTrackのLiveUSBを作った以来ですから。。。新しくKaliさんのLiveUSBも作りたいです

 

ブータブルUSBを起動してLiveUSBを作成する

Macで起動する際にAltを長押ししてブートメディアを選択します

Bootcampを使ってる人は分かるかと思います

 

f:id:Tokina:20171024001745p:plain

 

ここでinstallationを選択してそこそこ進みますと、パーティションの提案を行ってきます。ここで、デフォルトではMacのメインパーティション全てを上書きする設定になっているので、慎重にLiveUSBにする予定のUSBを選択する。パーティション設定の作成から選択できるはずです。

f:id:Tokina:20171024002314p:plain

※上記の例はVirtualBoxでインストールするときのものです

 

あとは少し時間がかかりますがインストールを待つのみです。

 

openSUSEの起動

USBハブから起動出来ない場合もあるので、マシンに直接LiveUSBを挿入する必要があるかも。一瞬welcome to GRUB!と表示されたりされなかったりして起動します。

f:id:Tokina:20171024003026p:plain

もしインストールの画面がでたらboot from hard diskを選択すればOKでした

 

 

可視化が面白いので皆さん試してみてください。 

f:id:Tokina:20171024144236j:plain

 

久しぶりに真面目に大した事ない記事を書きました。

書きたいことは色々在るのですが・・・

AWS関連のことやインターンについてまとめたいと思っています

 

 

 

セキュリティ・キャンプ全国大会@2016の専門講義を振り返る

f:id:Tokina:20160817222043j:plain

 

こんばんわ。

tokinaです。連日投稿するのは私のモチベがキープ出来ている証拠でしょうか。

 残念、連日投稿はできませんでした、、、(そもそも入力速度が遅い、、、

 

始めたTwitterですが、多くの人フォローしていただけてありがたいです。

今後ともよろしくお願いします。

 

はじめに

 

今回は全国大会での専門講義を振り返りたいと思います。

長くなるので、一度受講した講義を以下にまとめておきます。(詳細な時間割はこちら

 

Day2

Day3

  • 3-C 脆弱性検出実践(ファジング技術と脆弱性報告)
  • 4-C オンラインゲームアタック&ディフェンスチャレンジ
  • 5-D みんなでクールなROPガジェットを探そうぜ

Day4

 

上記を見ればわかりますが、レイヤーがばらばらですねえ、、、

 

各講義を振り返る前に、トラックについて触れておきます。

今回のトラックは以下の5つに分かれていました。(集中講義もあります)

 

・アプリケーション  →Aトラック

・IoT          →Bトラック

・検知                       →Cトラック

・解析                       →Dトラック

 

実は去年の時間割は外部に公開されていないようで、見つけられませんでしたが、今年のは事前に公開されていました。

上記のトラックをレイヤーの高い順に並べると多分こんな感じ↓

A>C>D>B

そう、私はレイヤを行ったり来たりしていたのです。

でも楽しかったですよ。大体の人はレイヤーが集中していたように感じました。

 

さて、それでは気を持ち直して各講義について振り返りたいと思います!

 

続きを読む