ソースコードが手元にないソフトウェアを評価する場面は、実務では珍しくありません。組み込み機器、ファームウェア、サードパーティ製バイナリ、古いライブラリ、UEFI モジュール。こうした対象では、ソースコードレビューだけでは足りません。 そこで必要になるのが、バイナリからリスクを探す視点です。 VulHunt Community Edition は、Binarly が公開したバイナリ脆弱性検出フレームワークです。単純に危険な文字列を探すだけではなく、バイナリ解析、デコンパイル結果、データフロー、ルールベースの検出を組み合わせて、脆弱性候補を探すためのツールです。 この記事では、VulHunt CE を Ubuntu 上に構築し、小さな C プログラムを使って、バイナリ検査の流れを試します。 今回やること この記事では、次の流れで進めます。 1. VulHunt CE をビルドする 2. サンプルの脆弱な C プログラムを作る 3. バイナリをコンパイルする 4. VulHunt CE でスキャンする 5. 結果を読む 6. 安全版のコードと比較する

前回は、Quartusのプロジェクトを作成し、DIPスイッチの状態をLEDへそのまま出しました。書いた回路はほとんど配線だけでしたが、プロジェクト作成からピン割り当て、コンパイル、SOF書き込み、実機確認までを一通り通せたので、今回からようやく入力値を加工する回路へ進みます。 最初に作るのはAND、OR、NOTです。 論理ゲートの説明だけを見ると、真理値表を覚えて終わりにしたくなります。自分も以前は「これは知っているから飛ばしていいだろう」と思っていました。ただ、Verilogで書いた式がどのような回路になるか、複数の出力が同時に存在する感覚を実機で確認しておかないと、後で加算器やALUを読んだときに結局ここへ戻ってくることになります。今回はその手戻りを先に潰しておく回、というくらいの位置づけです。 今回はDIPスイッチのうち2個を入力A、Bとして使い、AND、OR、NOTの結果をLEDへ表示します。クロックは今回も使いません。 今回作るもの 入力はsw[0]とsw[1]です。 led[0]:A AND B led[1]:A OR B led[2

vm2 3.11.6以下では、共有Bufferプールを介してサンドボックス境界を越える情報開示・改変の可能性があります。CVE-2026-92947の最低修正版は3.11.7ですが、運用では保守版を評価し、信頼できないコードと秘密情報を同一プロセスに置く設計も見直すことが重要です。

Linux のメモリフォレンジックは、面白い一方で、最初の一歩が重い分野です。特に面倒なのが、対象カーネルに合ったデバッグシンボルやプロファイルの準備です。 インシデント対応では、解析したいマシンが都合よく標準構成とは限りません。独自カーネル、古いカーネル、更新済みの環境、すでに消えているパッケージ。そうした現実にぶつかると、メモリダンプは手元にあるのに、解析環境の準備で止まってしまうことがあります。 そこで試したいのが「mquire」 です。 mquire は、Linux メモリダンプの中に残っている BTF や Kallsyms を使い、外部のデバッグシンボルにできるだけ頼らずに解析するツールです。さらに面白いのは、プロセス、オープンファイル、ネットワーク接続、カーネルモジュール、dmesg などを SQL で横断的に調べられる ことです。 つまり、mquire は「メモリダンプを読むツール」というより、Linux の実行状態をメモリから再構成して、SQL で調査するためのツールとして見ると分かりやすいです。 今回やること この記事では、Ub

自作CPUをFPGA上で動かす、という目標を立てたまま数年放置していたのですが、重い腰を上げてDE0-Nanoを引っ張り出してきました。この連載では、Quartusのプロジェクト作成からSOF書き込みまでの一連の流れを、自分の手を動かしながら記録していきます。 最終的なゴールは簡易CPUです。ただし最初から大きなものを作ろうとすると必ず迷子になるので、今回はDIPスイッチの状態をLEDにそのまま出すだけの、拍子抜けするくらい地味な回路から始めます。 今回作るもの DE0-Nanoに乗っている4個のDIPスイッチを、そのまま8個のLEDの下位4bitに出力します。それだけです。クロックは配線だけ用意しておいて、今回はまだ使いません。 なぜこんな最小構成から始めるかというと、以前FPGAを触り始めたころ、いきなりUARTとメモリコントローラを同時に書こうとして訳が分からなくなった経験があるからです。LED、スイッチ、クロック、レジスタ、メモリ、UARTと部品を一つずつ確認していくほうが、結局は近道だと感じています。 DE0-Nanoのスペックは今更で

Hi, there. 今回は、医療機関に対するサイバー攻撃について私見を述べます。 「情報漏洩」だけの対処では、もう足りない 病院へのサイバー攻撃というと、多くの人はまず「個人情報が漏れたか」を思い浮かべます。たしかにそれは重大な問題です。しかしながら、今の医療現場で本当に深刻なのはそれだけではありません。 最近の病院被害では、「電子カルテが見られない」、「予約や検査が止まる」、「救急の受け入れが制限される」、「手術が延期される」、といった医療機関の機能そのものに対する影響が広がっています。つまり、サイバー被害は「情報の問題」だけではなく、「医療が止まる問題」になっているのです。医療分野の災害対応や継続計画を扱う米国HHSのASPR TRACIEも、近年の医療機関へのサイバー攻撃は患者ケアと業務継続のあらゆる側面に大きな影響を与えていると整理しています。 「Recent cyberattacks on healthcare facilities have had significant effects on every aspect of pat