← 2026-09-08 の一覧へ戻るホーム
NEC V20 マイクロコードの解読

2026/09/04 14:53

NEC V20 マイクロコードの解読

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

本プロジェクトの最も重要な成果は、高解像度のダイ写真撮影と高度な AI を用いて、NEC V20 CPU の隠蔽されたマイクロコードに成功裏にリバースエンジニアリングを行った点です。56 億ピクセルの画像を用いて主 ROM アレイを捉えた際、研究者らは標準的なビット検出ツールの適用時にコントラストの問題に直面し、その対策としてカスタム Python スクリプトを開発してビット位置を JSON 形式でエクスポートし、手動で分類された 1,000 ビット以上を用いて PyTorch を介して Convolutional Neural Network（CNN）を訓練しました。曖昧な結果に対する再訓練の後、CNN は精度が 99% 以上となり、未分類のビットは四つのみとなりました。

分析により、V20 は予想よりも多い 1,032 のマイクロコードワードを含んでいることが判明し、その理由としては ROM の上の PLA が特定のマイクロコード列を活性化させ、オペコードマッチングのためのマスク可能なブール論理を実装するために 26 入力ライン（13 の論理的入力和非対）を使用するためであることです。このアーキテクチャは、マイクロコードの約三分の二が Intel 80186 ISA を実装していることを確認しており、残りの部分は NEC の拡張命令セットまたは 8080 エミュレーションモードを処理します。以前のビット数に関する不一致は、V20 と完全に 16 ビットの V30 を区別する単純な金属層スイッチによって共有されたマイクロコードベースを特定することで解決されました。また、協力を通じて不完全な裁判書類の図も訂正され、「F」フィールドのようなフィールド定義が明確化されました（例：マイクロコードワード内の「F」フィールドを「Update Flags」としてではなく「Fetch」として再定義）。

Reenigne が Intel 8088 との以前の仕事に基づく本取り組みは、V20 と V30 の関係を明らかにするとともに、デコードされたリソース（デコーディング用スプレッドシート、ソースコードなど）を GitHub で公開し、MartyPC などのエミュレータの向上に寄与しています。その結果、標準 NEC 命令セットおよび拡張 NEC 命令セットの両方に対して極めて正確なソフトウェアエミュレーションが可能となり、オリジナルハードウェアを必要とせずにこれらのレガシープロセッサに対する深いアーキテクチャ的洞察を得ることができます。

本文

NEC V20 マイクロコードの解読と高精度エミュレーションの実現：ダイショット画像解析から CNN によるビット認識へ

背景と課題

  • reenigne 氏（Ken Shirriff）が 2020 年に Intel 8088 プロセッサのマイクロコードを解読し、極めて高精度なエミュレーションが可能になりました。
  • 既存のエミュレータ「MartyPC」に NEC V20 のサポートを追加する際、以下の課題がありました：
    • 既存コアは V20 の実際のタイミングと一致しない（サイクル非正確）。
    • これは単に 8088 コアのコピー＆ペーストに V20 用命令を付加しただけの「V20 の服を着た 8088」でした。
    • マイクロコードを使用せずに V20 をサイクル正確にするのは、試行錯誤が必要なため非常に時間がかかる（スロウ）と予想されました。

マイクロコード ROM の視覚的解析

InfoSecDJ 氏に依頼し、NEC V20 CPU のダイショット（半導体チップ表面の撮影）を取得しました。

  • 画像品質:
    • 驚異的な解像度（56 億ピクセル / $70,478 \times 80,672$）。
    • JPEG 形式では保存が困難な程度に高精細です。
  • 対象領域:
    • ダイの中心部直下の長方形領域がメインのマイクロコード ROM です。
    • ROM アレイサイズ：$258 \times 116$。
    • 総ビット数：29,928 ビット（V20 のマイクロコード単語長 29 で割り切れる）。
  • 構造的発見:
    • 得られたデータは 1,032 個のマイクロコード単語。
    • 想定していた 1,024 個との不一致がありましたが、後に NEC V20/V30 の設計事情で説明がつきました。
  • ビット検出原理:
    • メタル層下のポリシリコンギャップがトランジスタ（「1」）を形成し、存在しない場合は「0」と判定されます。

CNN を活用したビット認識の自動化

手作業での 29,928 ビットの抽出は困難なため、**畳み込みニューラルネットワーク（CNN）**による自動識別を試みました。

プロセス

  1. ツール準備: Travis Goodspeed 氏の 
    MaskRomTool
    でビット位置を抽出し、JSON 形式で出力しました。
  2. 画像生成: Python スクリプトを使って、各ビット位置の中心部分を $42 \times 42$ ピクセルの PNG として保存しました（総容量約 105 MB）。
  3. モデル訓練:
    • タスクは単純な「0 か 1 か」を分類する二値分類問題です。
    • PyTorch を用いて、数時間以内にモデルを構築・訓練しました。
    • 「ソーセージだかそうでないか（Hotdog or Not Hot Dog）」に例えられるほどシンプルなタスクでした。

訓練結果と最適化

  • 学習データセット:

    • Python/tkinter スクリプトで、キーボード入力で手動で分類可能なデータを構築し、予備として用意しました。

  • 訓練の進捗 (PyTorch ログ):

    [Epoch 01] train: loss=0.6945 acc=0.7273 f1=0.0164 | val: loss=0.6924 acc=0.7876 f1=0.0000
[Epoch 02] train: loss=0.6860 acc=0.7151 f1=0.3826 | val: loss=0.6257 acc=0.7965 f1=0.0729
[Epoch 03] train: loss=0.3751 acc=0.8914 f1=0.7213 | val: loss=0.3900 acc=0.7655 f1=0.6327
[Epoch 04] train: loss=0.1159 acc=0.9523 f1=0.9139 | val: loss=0.0495 acc=0.9912 f1=0.9773
[Epoch 05] train: loss=0.0251 acc=0.9945 f1=0.9888 | val: loss=0.0460 acc=0.9867 f1=0.9744
...
[Epoch 10] train: loss=0.0110 acc=0.9967 f1=0.9907 | val: loss=0.0437 acc=0.9912 f1=0.9773
Best val F1: 0.9891

  • 推論と微調整:

    • モデルは GPU を用いることで数分で訓練完了しました。
    • 低信頼度（閾値 < 99%）のビットを特定し、手動で再トレーニングを繰り返しました。
    • 最終的に約 4 ビットのみが不確定となっており、残りは手動確認により解決されました。

マイクロコードのデコーディングと構造解析

認識されたビットマップを「29 ビットのマイクロコード単語リスト」に変換する際、以下の回路ブロックを解析しました。

1. デコード（アクティベーション）PLA

  • 役割: メイン ROM の特定の列を選択してアクティベートします。
  • 動作原理:
    • 左側の 13 個の論理的入力（反転信号付きで合計 26 線）を受け取ります。
    • AND ゲート構造により、入力パターンとの「一致」を検出し、対応する ROM コラムを選択します。
    • 一部のビットには「don't care」（どちらでも可）の設定があり、オペコードの範囲をマッチングに含めることで効率的な実装を実現しています。

2. NEC V20/V30 の設計戦略（マイクロコード共有化）

  • 問題点: 当初 ROM から抽出された単語数（1,032 個）と想定数（1,024 個）が一致しませんでした。
  • 解決策: NEC は V20 と V30 を同一のマイクロコードマスクで設計し、製造後のメタル層切断により CPU タイプを区別しました。
    • V20: メタル構造の一部（左側トレース）を切断。8 ビットバス向け。
    • V30: 反対側を切断。16 ビットバス対応（Intel 8086 に相当）。
  • この工夫により、両 CPU が共有するマイクロコードマスクが可能になりました。

3. エミュレーションへの適用

  • 解読されたフィールド:
    • ソースレジスタ：ES, CS, SS, DS, AX, CX, DX, BX, SP, BP, SI, DI など。
    • 命令のオペコードパターン（00h-1Bh 等）が Intel 8088 ISA と一致することを確認。
  • グループデコード ROM (GDR):
    • メインマイクロコードだけでは不足する「欠落した文脈」（フラグ更新、フェッチなど）を提供します。
    • V20 でも GDR 回路が存在し、8088 の信号と互換性があることが確認されました。

結論と次のステップ

  • 達成: マイクロコードの大部分（約 1,032 単語×4 コラム×マルチプレクサ制御）が解読され、サイクル正確な V20 コアの実装が可能になりました。
  • 残課題:
    • ソースフィールドの一部の値が完全に同定されていません。
    • これらの謎は、ハードウェアテストスイートへの対応を通じてさらに明らかになる可能性があります。
  • リソース公開:
    • 解読に使用したすべてのデータと Excel シートは GitHub で入手可能です。

注記: 本プロジェクトにおける AI（CNN）は、画像認識のための単純な分類タスクであり、現代の「大規模言語モデル（LLM）」とは異なる用途です。

同じ日のほかのニュース

一覧に戻る →

2026/09/08 3:52

ロサンゼルスが一つ一つのビル建設を通じて発展していく姿を見てください（1880 年～2026 年）

## Japanese Translation: 本テキストは、ロサンゼルス独自の視覚マップを説明している。既存の構造物それぞれが建設年によって配置された一つの箱として表現されており、現在も存続している建物のみが含まれ、取り壊されたものは除外されている。その結果、この可視化は都市の歴史的景観や完全なタイムラインではなく、現在の建築環境を示している。これは生存する建築への明確な年代的概要を提供する一方で、過去の構造物や将来の開発については洞察を与えず、ロサンゼルの進化を現在にのみ焦点を当てており不完全な画像として提示する。 ## Text to translate : This text describes a unique visual map of Los Angeles where each existing structure is shown as one box arranged by its construction year. Only buildings still standing today are included; those that have been demolished are excluded. As a result, the visualization shows the current built environment rather than the city's historical appearance or full timeline. While it provides a clear chronological overview of surviving architecture, it offers no insight into former structures or future developments, presenting an incomplete picture of Los Angeles's evolution by focusing solely on the present.

2026/09/05 20:25

Linux ディストリビューション全体に対する信頼を誤用した攻撃 (Trust-Trust Attack)

## Japanese Translation: Ken Thompson の「信頼の連鎖」攻撃は、以前はコンパイラレベルでの改ざんが必要とされていたものが、GNU strip 内でも実行可能であることを実証した。本研究では、GNU strip が完成済みの ELF ファイルを改変することで、ソースコードを確認せず・改変せずにも、Linux 全体のビルド環境に永続的なバックドアを埋め込むことを示している。NixOS のブートストラッププロセスにおいて、バイナリシードに含まれる GNU strip の単一のパッチ済みバージョンによってペイロードが挿入され、それが次のビルド世代へと伝播し、シードが依存関係の閉じ外に出た後の最終的な標準環境においても存続する。実際の nixpkgs リビジョンにおいて、この攻撃は障害なく完全なグラフィカルインストールメディアを構築でき、任意の悪意のある挙動を行う汚染されたバイナリを生み出した。この発見は、NixOS のような不変系ディストリビューションに依存するユーザーや組織に対し、一見安全なツールが大規模な侵害の主要なベクトルとなるリスクを提起している。この研究成果は Aman Sharma（メール：[メールを表示]）によって提出され、UTC 2026 年 7 月 27 日 12:59:15 に投稿された（バージョン 1）。

2026/09/04 1:06

WeatherNext 3

## 日本語翻訳： ## サマリー：Google は、年間毎日ごとに正確な時間ごとの予報を生成する、これまで最も高度な全球気象 AI モデル「WeatherNext 3」をローンチしました。以前のモデルとは異なり、本モデルは生きた衛星画像を直接分析することで、降雨や降雪といった急速な変化を追跡し、トレーニングが施されたことのない場所であっても精密なローカルデータを提供します。この機能は、ジャマイカでのハリケーンメリサの上陸地点を特定して予測することを支援するなど、最近のイベントにおいて極めて重要であることを実証しました。Google Search、Maps、Gemini などの日常的な消費者向け利用に加え、WeatherNext 3 は風力発電所や太陽光発電所向けの放射線量および雲量予測という重要な産業用途に最適化されています。これにより、運営者は運用コストを削減しながら再生可能エネルギー源をより効率的に管理できるようになります。また、温度などの地表変数を 5km〜10km の高精度で予測することで、インフラがより信頼性高く動作するよう確保するとともに、ユーザーには日々の意思決定を賢く行うための精密なローカルデータを提供します。

NEC V20 マイクロコードの解読 | そっか～ニュース