[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文

Semzhu-Project
手で作る
組込み向けハイパーバイザと攻撃検知手法の新しい世界
at CODE BLUE 2019
朱義文

自己紹介
朱義文 (シュヨシフミ)
● 高校3年生
○ 世田谷学園高等学校
● 興味
○ 組込みシステム
● セキュリティ・キャンプ全国大会2017修了生
● SecHack365 2018 優秀修了生
● Twitter : @envzhu
2

SecHack365 - Semzhu-Projectの始まり
➢ 日本の一年間に及ぶU-25セキュリティハッカソン
○ 若手セキュリティイノベーター育成を目的にNICTにより実施
○ 計7回の集合回を含む。
○ 学生の場合は、NICTが参加に伴う費用を全額負担
➢ 活動期間： 2018/5 ~ 2019/3

4
「高校生１人で、ハイパーバイザとセキュリティ機能を作っ
たら、一体、どんなものができあがったのか」
本講演のトピック

5
● ① 組込み向けハイパーバイザの開発
○ 背景: 趣味目的で、容易に独自改造を加え、その有効性を検証できる組込み向け
ハイパーバイザがほとんど存在しない
○ 成果: CPUエミュレータ上で動作し、AArch64向けのシンプルな組込み向けハイパ
ーバイザSemzhu-Visor の開発
概要 (1/2)

6
● ② 組込み向けセキュリティ機能の研究・開発
○ 背景: 組込みシステムに適用できる攻撃検知手法は少ない。
■ 組込み向けセキュリティの制約
● プロプライエタリなソフトウェアに対して適用可能であること
● リアルタイム性を保証すること
○ 成果: ハイパーバイザを用いた組込み向けの攻撃検知手法の開発
■ AsROP
■ AsCOP
概要 (2/2)

本日のおおまかな流れ
➢ 中心理念
➢ シンプルな組込み向けハイパーバイザ「Semzhu-Visor」の開発
➢ 先行研究における問題提起
➢ 解決手法として「AsROP」と「AsCOP」の提案
➢ まとめ
7

組込みシステムとは
9
➢ 特定の機能の実現に特化したコンピューターシステム
➢ 例）カメラ、車、人工衛星、MRI
➢ しばしば、次のことが要求される
➢ 小型
➢ 省電力
➢ リアルタイム性が保証されている

ハイパーバイザとは
10
➢ CPUやOSを高速に仮想化するための基盤や技術のことを言う
ハイパーバイザ
OSOS OS
ユーザ空間ユーザ空間ユーザ空間
物理 CPU

組込み向けハイパーバイザとは
➢ 組込みシステム向けに特化したハイパーバイザ
11
ハイパーバイザ)
汎用OS組込みOS ① 組込み OS②
ユーザ空間ユーザ空間ユーザ空間
物理 CPU

背景
➢ 組込み向けハイパーバイザの研究と活用が盛んになっている
○ 例）ACRN, Xvisor, TOPPERS SafeG
12

背景
➢ 趣味目的で容易に独自の改造を加え、検証できるほど、十分に小さくシンプ
ルな組込み向けハイパーバイザが少ない
13

背景
➢ 趣味目的で容易に独自の改造を加え、検証できるほど、十分に小さくシンプ
ルな組込み向けハイパーバイザが少ない
➢ 研究の開始からまだ日が浅い。
○ ハイパーバイザの新しい活用方法を提案し、コンピュータにおける諸問題を解決
することはできないのだろうか
○ ハイパーバイザを用いることで、新しいセキュリティ機能を開発できないのだろ
うか
14

Semzhu-Project 名前の由来
➢ 千手観音(せんじゅかんのん)
○ 千本の手を持つ菩薩
○ 陰から、千本の手で人々を支える
○ 気づかれずに、しかし強力に何かを支えるイメージ
Semzhu = Senju
15

Semzhu-Project 最終目標
容易に改造を加えることができる組込み向けハイパーバイザ
の開発
ハイパーバイザのユニークな活用方法の提案
＋
16

Semzhu-Project 現状の成果
シンプルな組込み向けハイパーバイザSemzhu-Visorの開発
ハイパーバイザを用いたセキュリティ機能
AsROP及びAsCOPの開発
＋
17

組込み向けハイパーバイザSemzhu-Visorの開発

Semzhu-Visor の特徴
➢ 開発方針
○ フルスクラッチ開発 (printf関数から自作)
○ コンパイラに非依存の実装であること
○ コードが1万行以内であること (現在 7000行)
○ CPUエミュレータ上で動作すること
19

● 仕様
○ ベアメタル型ハイパーバイザ
○ ゲストOSとしてLinux, KOZOS(組込みOS)が動作可能
○ リアルタイム性を確保
○ 改造Qemu上で動作する
➢想定ターゲット：Raspberry Pi 3 (64bit/AArch64) (ただし、実機動作は未確認)
➢開発環境 : Clang/LLVM
20

● 仕様
○ ベアメタル型ハイパーバイザ
○ ゲストOSとしてLinux, KOZOS(組込みOS)が動作可能
○ リアルタイム性を確保
○ 改造Qemu上で動作する
➢想定ターゲット：Raspberry Pi 3 (64bit/AArch64) (ただし、実機動作は未確認)
➢開発環境 : Clang/LLVM
21

22
ハイパーバイザが動作するように、Qemu(※)に以下のように機能を追加・バグの修正
● ハイパーバイザがゲストVMに対して割込み・例外を仮想的に発生させる機能を追加
● アボート例外をトラップできるように修正
● 割込み・例外トラップ機能の有効時に、ゲストVMの割込み許可状態に関わらず、割込みが発生し
てしまうバグを修正
● ハイパーバイザ用MMUにおいて、ページテーブルを一部、正しく解釈できないバグを修正
改造Qemuについて
※Qemu ･･･広く使われているオープンなCPUエミュレータ

Semzhu-Visor ハイパーバイザ本体の機能
組込み向けハイパーバイザとして最低限必要な機能のみを実装
➢ゲストVM をスケジューリングするためのスケジューラ
➢ゲストVMの仮想化
○ 周辺機器の仮想化
○ 割込み・例外の仮想化
○ タイマの仮想化
23
これらの機能をたったの7000行で実装

Semzhu-Visor 全体図
Semzhu-Visor (Hypervisor)
汎用OS組込みOS① 組込みOS②
User space User space User space
CPU (AArch64)
24
改造Qemu (CPU エミュレータ)
ホスト PC

ハイパーバイザを用いて、
組込みシステム向けのセキュリティ機能を開発
する
25

26
脅威モデル
保護対象の組込みシステムは…
DEPもしくは、それに相当する機能を持つことを想定。
● 書き込み可能かつ実行可能なメモリは存在しない。
○ → 大抵の組込みシステムに当てはまる
● →コードを注入することによって、攻撃することは不可能。
● → 手始めに、攻撃者はcodo-reuse攻撃(ROPやCOPなど)を用いて、コントロールを掌
握することを試みる

27
脅威モデル
保護対象の組込みシステムは…
DEPもしくは、それに相当する機能を持つことを想定。
● 書き込み可能かつ実行可能なメモリは存在しない。
○ → 大抵の組込みシステムに当てはまる
● →コードを注入することによって、攻撃することは不可能。
● → 手始めに、攻撃者はcodo-reuse攻撃(ROPやCOPなど)を用いて、コントロールを掌
握することを試みる
→ ROPとCOPを検知する必要がある

28
検知対象: ROP
➢ ROP(Return-oriented programming)
○ リターンアドレスを任意のアドレスに書き換え、ret命令で終わる命令列(「ROP
gadget」と呼ぶ)を実行することによって攻撃。複数のgadgetの組み合わせにより、
複雑な攻撃が可能
function1:
...
ldr x0, [x29, #28]
ldp x29, x30, [sp], #32
ret
nop
example of AArch64

29
検知対象 : COP
➢ COP(Call-oriented programming)
○ ROPでは、ret命令を用いるが、COPでは、間接関数呼び出し(indirect call)命令を
用いる
○ ROP Gadgetほど、出現頻度は多くない
○ COP Gadgetには、引数の操作など、操作性の高い命令が配置される
function:
...
ldr x0, [sp, #8]
ldr x8, [sp, #16]
blr x8
…
AArch64の例

広く使われている、ROP及びCOPに対するセキュリティ機能
● ASLR(Address space layout randomization)
○ スタックやコードの位置をランダム化することによって、攻撃を困難にする。
○ しかしBrute Force Attack や Information Leakageによってバイパス可能.
■ ASLRは根本的な解決策となっていない。
30

ROPやCOP攻撃検知の
先行研究について

32
ROPやCOPの検知手法の先行研究は、大きく次の2つに分類可能
① CFI (Control-flow integrity)
② Behavior-based Heuristics
攻撃検知の先行研究

① CFI(Control-Flow Integrity) について
➢ 2005年に発表 [1]
➢ 中心理論: 本来のプログラムでは意図されていない分岐等を排除する
➢ 間接分岐、間接関数呼び出し、関数からのリターン実行時に分岐先アドレスの正
当性を検証
➢ 実装 :コンパイル時に、対象の実行バイナリに検証コードを挿入
33
[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-flow integrity. In Proceedings of the
12th ACM conference on Computer and communications security, pages 340–353. ACM, 2005.
https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf

① CFIの実用的な問題点
➢ 検知対象のプログラムのソースコードが必要
➢ プロプライエタリなソフトウェアに対して適用できない
➢ オーバーヘッドが高い。(25% ~ 50%)
➢ → 2005年のオリジナルのCFIの提案以来、多くの研究者が欠点を克服するた
め様々な亜種(実践的なCFI)の発明に取り組む
34

② Behavior-based Heuristics
➢ プログラムの振る舞いの経験則に基づく検知理論を利用
○ 例）リターン時の分岐の距離の長さにより、ROP攻撃かどうかを判定
➢ ほとんどの場合…
➢ カーネルドライバなどカーネル空間で実装される
➢ 実行時に作用
35

② Behavior-based Heuristicsの特徴
➢ プロプライエタリなソフトウェアに対して、適用可能
➢ オーバーヘッドが小さい
➢ ほとんどの場合、カーネルドライバでの実装のため、特定のタイミングでま
とめて検知処理を行う
○ リアルタイム性が失われる
36

先行研究における問題提起
37

38
● プロプライエタリなソフトウェアに対して、機能を適用可能であること
● 組込み開発の現場においてソースコードが入手不可能なソフトウェアを用いるこ
とが多々あるため
● リアルタイム性が保持されていること
[考察] 組込み向けセキュリティ機能の制約

先行研究と制約との比較
➢ CFI
➢ コンパイラレベルで実装される。
➢ コンパイル時と実行時に作用
➢ プロプライエイタリなソフトウェアに対して適用できない
➢ Behavior-based Heuristics
➢ 殆どの場合…
■ カーネルドライバなどカーネル空間で実装される
■ 実行時に作用
■ リアルタイム性がない
39

➢ CFI
➢ プロプライエイタリなソフトウェアに対して適用できない
■ リアルタイム性がない
どちらの手法もすべての制約を満たさない。
40

問題提起
全ての組込み向けセキュリティ機能の制約をクリアできる先行研究は、
ほとんど無い
そもそも組込み向けセキュリティ機能の研究が進んでいない
41

42
組込みシステムに適用できるセキュリティ機能を開発するこ
とはできないのだろうか？
[背景] セキュリティ機能開発のモチベーション

では、どうすれば、全ての制約をクリアする
ことができるのか

➢ CFI
○ プロプライエイタリなソフトウェアに対して適用できない
どちらの手法もすべての制約を満たさない。
44

➢ CFI
○ プロプライエイタリなソフトウェアに対して適用できない
45
実装手法と、検知手法の性質には強い相関関係が存在。
全ての制約をクリアすることを可能にする、新しい実装手法を考える必
要がある

[提案] セキュリティ機能の実装手法
CPU命令を疑似拡張する
46

[原理] どのようにして、CPU命令を擬似拡張するのか
➢ 現在、普及しているCPUには、命令を拡張する機能は無い
47

➢ 複数レイヤー間の協調動作により実現
○ [開発時] : 疑似拡張対象の命令に対して、未使用の機械語を割り当てる
○ [CPU]: 意図的にCPUの例外を起こす
○ [ハイパーバイザ] : その例外をトラップし、疑似命令をエミュレーション
48
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
変換
ゲストVM
開発時

49
変換
ゲストVM
[CPU]疑似命令実行時function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop

function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
50
変換
ゲストVM
例外が
発生
例外が
発生
[CPU]疑似命令実行時

function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
51
変換
例外が
発生
ゲストVM
例外が
発生
トラップ

function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
52
変換
例外が
発生
ゲストVM
例外が
発生
トラップ

function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
ret
nop
function:
sub sp, sp, #32
stp x29, x30, [sp, #16]
(省略)
ldp x29, x30, [sp, #16]
add sp, sp, #32
sec_ret
nop
○ 今回は、未使用の機械語の代わりにハイパーバイザコールを割当
53
変換
例外が
発生
ゲストVM
例外が
発生
トラップ

54
● プロプライエタリなソフトウェアに対しても、機能を適用できる
● ハイパーバイザレイヤーを備えるその他のCPUでも実装可能
● [重要] 実CPUレイヤーでは難しい複数レイヤー間の協調動作が可能
○ 静的解析ツールとの連携など (後述のAsROPにおけるオーバーヘッド削減テ
クニック等で利用)
[考察] CPU命令疑似拡張によるセキュリティ機能の利点

55
[考察] ハイパーバイザ上にセキュリティ機能を実装する利点
実装によっては…
● カーネル空間に対しても、機能を適用できる
● リアルタイム性を保つことが可能
● ゲストOSを修正する必要がない
● ハイパーバイザがセキュリティ機能を肩代わりし、ゲストの組込みOSの機能を減
らすことで、運用が楽になる

56
どのような疑似命令が
セキュリティ機能として動作するのか

57
このCPU命令疑似拡張を用いて、開発したセキュリティ機能を次スライドより示
す
● AsROP
● AsCOP
CPU命令疑似拡張によるセキュリティ機能

ROPに対する攻撃検知手法 AsROP
58

59
● 中心理論
○ ROPGuard(※)に基づく。通常、リターン先はその関数を呼び出したbl命令の次の命令となる
(“call-preceded”と呼ぶ)。この call-precededをチェックすることでROPを検知する(ここでは
“call-precedence check”と呼ぶ).
● 実装
○ ret命令にcall-precedence checkの処理を疑似拡張
■ 「sec_ret命令」と呼ぶ
AsROP 仕組み
※ 参考文献[2] ROPGuard I. Fratric. “ROPGuard: Runtime prevention of return-oriented programming
attacks.” 2012
function1:
...
3. bl function2
4. stur x0, [x29, #-16]
5. ...
6. ret
function2:
...
9. ret
ここにCPUはfuntion2か
らリターンするはず

60
通常のソフトウェアでは、ret命令は頻繁に実行されるので、オーバーヘッドが
大きい。そこで以下の工夫により高速化
① ROP検知処理をAArch64アセンブリで実装
② ROP検知処理を適用するret命令個数を削減
ROP攻撃検知手法におけるオーバーヘッド削減テクニック

61
② ROP検知処理を適用するret命令回数を削減
■ ROP攻撃に悪用される可能性がないret命令が存在（「無害なret命令」)
■ 今回は、「無害なret命令」をポインタ・バッファを一切用いない関数のret命令と定義
■ 事前の静的解析との連携により、無害なret命令は「sec_ret」命令に変換せずに
そのまま実行するように細工

62
② ROP検知処理を適用するret命令回数を削減
■ ROP攻撃に悪用される可能性がないret命令が存在（「無害なret命令」)
■ 今回は、「無害なret命令」をポインタ・バッファを一切用いない関数のret命令と定義
■ 事前の静的解析との連携により、無害なret命令は「sec_ret」命令に変換せずに
そのまま実行するように細工
ret命令の場所ごとに命令の振る舞いを変える
カーネルドライバやコンパイラレイヤでの実装では、難しい
→CPU命令疑似拡張による実装では容易に実現可能!

「ROP is Still Dangerous: Breking Modern Defenses」[4]
● 「call命令先行性」のチェックによる攻撃検知手法等のバイパスについて言及
○ 実行バイナリが70KB以上の場合、 Call-Preceded ROPのみで攻撃を成立させることができる
Gadgetがだいたい存在する。
■ 可変長命令の為に、ROP攻撃が行われやすいx86の特有の話である
● 比較的、ROP攻撃が行いにくい他のCPUアーキテクチャの場合は当てはまらない
■ ASLRが無効になっていることが条件
○ ASLRが有効かつ、Call-Preceded ROPのみx86以外のCPUを攻撃するのは非常に難しい
○ AsROPでは、 Call-Preceded ROPによってバイパスされる可能性は無いのではないのだろう
か。
更なる研究、実アプリケーションでの検証が必要！
[補足考察] AsROP バイパスされる可能性について
63

64
● ゲストLinux上のmrubyでHello worldを表示するスクリプトを実行
○ 中間言語へのコンパイル + 中間言語の実行
AsROP 性能評価
Linux(カーネル空間)
mruby VM(ユーザー空間)
物理CPU

65
AsROP 性能評価
機能総CPU実行サイクル
数
増加分 sec_ret命令
実行数
sec_ret命令1回の平
均実行サイクル数
検知機能をOFF
(標準時)
45,026,014 0 0 0
C言語で実装 80,580,786 35,554,772
(+79%)
113602 313サイクル
アセンブリで実装 59,887,536 14,861,522
(+33%)
113602 130サイクル
アセンブリで実装
&オーバヘッド削減テク
ニックを適用
56,433,742 11,407,728
(+25%)
83643 136サイクル

66
● １回の検知処理では、200サイクル以内に終えることを保証
○ リアルタイム性の保持に成功
● ゲストOSの修正なしで、検知機能を適用可能
● オーバーヘッドは25%
● まだ実用的だとは言えない
● →検知処理を適用するret命令の数をさらに減らす必要がある(今後の課題)
[考察] AsROPの特徴

COPに対する攻撃検知手法 AsCOP
67

68
● 中心理論
○ 通常、間接関数呼び出し命令（blr命令）では、関数の先頭アドレスに分岐する。しかし、
COP gadgetが実行される時、関数の途中のアドレスに分岐する。
○ blr命令実行時に、分岐先が関数の先頭であるかを確認することで、COPを検出する
● どのようにして関数の先頭であるかを判定するのか
○ 事前に静的解析ツールにより、実行バイナリから関数の先頭アドレスをリスト化
■ 以後、このリストを「関数リスト」と呼ぶ
○ blr命令実行時に、分岐先アドレスと関数リストを照合することで、分岐先が関数かどうかを
チェックする機能を疑似拡張 (「sec_blr命令」)
[実装] AsCOP 原理

69
● オーバーヘッドが大きい
● リアルタイム性が確保されていない
● ユーザー空間に機能を適用のために、ゲストOSの修正が必要な場合がある
○ ユーザー・アプリごとにメモリ空間が隔離されている場合、OS側で、関数リスト
とユーザーアプリを紐付ける必要がある。
[考察] AsCOP 関数リスト照合の問題点

70
関数リスト照合における問題点の解決策
① リターンアドレス保存処理のチェック
○ コンパイラを用いて、生成された実行バイナリでは…
■ 関数中の特定の位置にリターンアドレスの保存命令が配置される
○ これが検知された場合、関数の先頭だと分かる
② ret命令先行性のチェック
○ 例外を除いて、関数の先頭より1つ前には、ret命令が配置される
※関数の途中のret命令は、関数末尾のret命令への分岐に書き換えればよい
○ 直前の命令がret命令の時、そのアドレスは、関数の先頭である
例外となる関数のみをリスト化すればよい
○ アセンブリで実装かつ、直前がret命令ではない関数
○ → 関数リスト(1953個→17個) ＆照合回数(10791回→0回) の大幅削減に成功!
…
1: add sp, sp, #32
2: ret
function:
3: sub sp, sp, #32
4: stp x29, x30, [sp, #16]
…

71
● ゲストLinux上のmrubyでHello worldを表示するスクリプトを実行
○ 中間言語へのコンパイル + 中間言語の実行
AsCOP 性能評価
Linux(カーネル空間)
mruby VM(ユーザー空間)
物理CPU

72
[評価] AsCOP 性能評価
総CPU実行サイク
ル数
オーバーヘッド sec_blr命令の
実行回数
sec_blr命令の平均
実行サイクル数
46,698,998 1,672,984(+3.7%) 10791 155サイクル

73
● オーバーヘッドが3.7%と実用性が高い
● リアルタイム性が確保されている
● ゲストOSの修正の必要なし
[評価] AsCOP 特徴

74
● 動画:https://drive.google.com/open?id=1w2NKRa2cPYaSPgCjSM33F6U0jEh58oSo
● 該当ユーザアプリを実行すると、ROP gadgetが実行される
○ /demo/rop.elf : 無保護 /demo/anti_rop.elf : AsROP による保護
○ 左側 : ゲストOS(Linux)のログ右側 : Semzhu-Visorのログ
AsROPのデモ

76
ハイパーバイザがROPを検知
ゲストVMに対して仮想的にエラー例外を起こす
ハイパーバイザのログゲストOSのログ

77
ハイパーバイザがROPを検知
ゲストVMに対して仮想的にエラー例外を起こすエラー例外により、
該当アプリをOSが異常終了
ハイパーバイザのログゲストOSのログ

79
● Semzhu-Visorをより洗練し、使いやすさを向上させる。
● プロジェクトを通じて、新たなアイディアを得た。
○ 例）
○ ある命令が攻撃に悪用される可能性は、配置されている場所により段階的に
異なる。場所ごとに疑似命令の振る舞いを最適化すれば、CPUのオーバーヘ
ッドは削減可能か。
○ 疑似命令の振る舞いをランダムに変更することで、攻撃をより困難にする。
○ セキュリティ分野以外でも、ハイパーバイザの新たな可能性を模索していきたい。
今後の課題

80
● エミュレーター上で動作するシンプルな組込み向けハイパーバイザ Semzhu-Visor を開発した
● CPU命令疑似拡張による実装手法を提案した。
● CPU命令疑似拡張の特長を生かしたオーバーヘッド削減テクニックの考案により、組込みシステム
に適用できる攻撃検知手法AsROP及びAsCOPを開発した。
● 以下の特徴を持つ
■ プロプライエタリなソフトウェアに対して機能を適用可能
■ カーネル空間に対しても、適用可能
■ OSの修正必要なし
■ リアルタイム性の保持
○ AsCOPについては、性能実験により実用可能な段階であることが示されている
まとめ

81
本プロジェクトは、国立研究開発法人情報通信研究機構(NICT)が実施す
る、U25若手セキュリティイノベーター育成事業SecHack365 2018にお
ける研究開発の成果である。
謝辞

82
そこには、
組込み向けハイパーバイザの新しい世界がある。

83
無知な高校生1人でさえも
ハイパーバイザと新しいセキュリティ機能が作れる。

84
みなさんも、
自分だけのハイパーバイザの新しい世界
作ってみませんか？

[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文

Recommended

Recommended

More Related Content

Similar to [CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文

Similar to [CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文 (20)

More from CODE BLUE

More from CODE BLUE (20)