← 2026-10-11 の一覧へ戻るホーム
古い Macromedia Director ゲームを現代のハードウェアで動作させる方法

2026/10/09 23:18

古い Macromedia Director ゲームを現代のハードウェアで動作させる方法

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

元のHacker News記事へ ↗
要約▶

Japanese Translation:

このプロジェクトは、Macromedia Director の実行ファイルをリバースエンジニアリングすることで、1990 年代の古典的な Windows ゲーム（具体的には「Findus bei den Mucklas」シリーズ、例：「Findus4」など）のコピー保護を成功裏に回避しました。プロセスには、アーカイブからディスクイメージを取得し、実際のファイルと欺瞞用のエントリを選択するための複雑なファイル構造を解決する作業が含まれました。ImHex および Ghidra を使用した分析により、以下の 2 つの特定の保護メカニズムが明らかになりました：第一に、

.dxr
セクションにある Lingo スクリプトが 
p3media
で CD の存在を確認し、欠落していた場合は 
quit()
を実行するもので、これを回避するにはアセンブリコードのジャンプオフセットを修正しました。第二に、
optgraph.dll
の 
initdisplay()
関数内部で行われるチェックで、物理ディスクの存在を検証するために特定の「マジック値」（26079537）を返すもので、これを回避するには Ghidra で戻り値をハードコーディングしました。これらバイト単位の修正を適用するための新しい Python オートメーションスクリプトが作成され、ユーザーが元のメディアなしでこれらのレガシータイトルをプレイし、データ破損のリスクを抑えることを可能にしました。この画期的な進展は、古いソフトウェアの歴史を保存する上で大きな一歩となり、macOS バージョンではしばしばこうした保護がない一方、Windows PC バージョンでは低レベルのドライブ検査に大きく依存していたことが示されています。

本文

ヴィンディ（Findus）の CD 認証回避：20 年越しのリバイバルとリバースエンジニアリング

はじめに

2000 年代初頭、地域図書館で借りて遊んだドイツ製のパズルアドベンチャーゲーム（特に『ヴィンディ』シリーズ）への憧れ。当時流行っていた Windows 95 コンピュータ上の動作条件から、CD を再燃焼させる試みを繰り返してきました。

数日前、以前失敗した試みである「Findus bei den Mucklas」のディスクイメージが公開されたのを機に、ついに成功させようと考えました。

1. ディスクイメージの取得

当時の CD ブランナーではコピー保護を突破できず、かつ過去 10 年間 PC を持たなかったため、独自で焼くことは不可能でした。

  • 幸運な出来事: 
    archive.org
    にシリーズの全タイトルを含む完全なディスクイメージがアップロードされていました。
  • ファイル構成: ゲームは 
    .ccd
    , 
    .cue
    , 
    .img
    の 3 ファイルセットとして提供。古い 
    CloneCD
    で生成されたもので、ゲームデータに加えオーディオトラックも含まれています。 
    • MODE1
      テーブル：ゲームファイル（トラック 1）
    • AUDIO
      テーブル：4 つの音源トラック（サウンドトラック用）
FILE "CD01.img" BINARY   TRACK 1 MODE1/2352   INDEX 1 00:00:00
TRACK 2 AUDIO            INDEX 1 45:08:37
TRACK 3 AUDIO            INDEX 1 46:38:44
TRACK 4 AUDIO            INDEX 1 47:08:50
TRACK 5 AUDIO            INDEX 1 47:11:58

2. イメージの展開とコピー保護 №1

古い 

ccd2iso
ツールを使用しましたが、最初の AUDIOTRACK で失敗しました。しかし、ファイル先頭部分をISO ファイルとして変換しマウントすることに成功しました。

ディレクトリ構造の改ざん対策

ファイルをマウントした際、重複ファイルが表示される奇妙な挙動が発生しました。

  • 現象: 一部のファイルがディスクイメージ内で複数回存在します。
    • 本物: 正しいサイズを持つファイル。
    • 偽物（デコイ）: 0 バイトまたは 256 バイトのみで、ランダムなゴミデータが含まれる。
  • 意図: ツールが偽のデコイのみを表示するように、意図的に不適切なディレクトリエントリを作成したと思われます。
    • Windows のネイティブ機能は正しいファイルを読み取りますが、他のツールでは異なる結果を返すことがあります。

解決策

複数のアーカイブソフト（PeaZip, Ark, Dolphin, 7z）の組み合わせで、手作業で正しいサイズのファイルを抽出することに成功しました。その後、以下のコマンドで Wine プレフィックス内にインストールし、データをコピーできるようにしました。

WINEPREFIX=$(pwd)/prefix wine "Installiere Findus4.exe"

3. コピー保護 №2：エレクトリック・ブーガルルー（Electric Boogaloo）

Findus4.exe
を実行すると、CD が欠けているというエラーポップアップが表示されました。

バグの発見

  • エラーメッセージには 
    rg -a "Lege die CD"
    という検索文字列が含まれていました。
  • 調査結果：このテキストは単に 
    Pettson3.ini
    から読み取られており、開発者が前のゲーム（Findus1/2/3）からのファイル名変更を考慮していなかったことが判明。
[CDROM]CDROM=?
[GAME1]Vind=0
[ALERT1]MESSG=Lege die CD Findus4 ein und versuche es noch einmal.
[SCREEN]FULLSCREEN=1

ディレクトリの実装（Macromedia Director）

  • 実態: これらのゲームはすべて 
    Macromedia Director Projector
    形式の実行ファイルです。
    • 末尾に 
      .dxr
      ファイルが連結されており、これが実際の実行コードとなります。
    • CD チェックはランタイム環境の一部として埋め込まれています（設定ファイルからの読み取りを回避するため）。

プロジェクトライズ（ProjectorRays）による解析

.dxr
ファイルを解析するための専用ツール 
ProjectorRays
を使用しました。この形式は以下のシグネチャを持ちます。

enum RifxType : u32 {
    MV93 = le u32("MV93"), // Director アプリラッパー
    MV95 = le u32("MV95"),
    FGDM = le u32("FGDM"),
    FGDC = le u32("FGDC"),
    APPL = le u32("APPL")  // Director アプリケーションラッパー（今回はこれ）
};
  • 発見: アドレス 
    0x00222151
    にある 
    APPL
    と、アドレス 
    0x002222F0
    にある 
    MV93
    が有効なチャンクでした。
  • パッチの適用: オフセット情報を考慮し、
    --offset
    オプションを追加してデコンパイルを実行しました。
./projectorrays decompile Findus4.exe -o output --dump-scripts --offset 0x002222F0

4. スクリプトの分析とロジック

デコンパイルされた Lingo スクリプト（約 150 行）は、ゲーム初期化ロジックを含んでいました。

CD 検出処理

.ini
ファイルを素朴に読み取り、CD ドライブを探します。見つからなければエラーメッセージを表示して終了します。

on checkpccdrompath
    seperator = the last char in the applicationPath
    drivelista = ["d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z"]
    Retvar = VOID
    
    repeat with Drive in drivelista
        iscdrom = baDiskInfo(Drive, "type")
        if iscdrom = "CD-ROM" then
            Path = Drive & ":" & seperator & "p3media"
            if checkoncd(Path) then
                Retvar = Drive
                exit repeat
            end if
        end if
    end repeat
    
    return Retvarend-- ...
  • ロジック: 全 Windows ドライブをループし、
    p3media
    フォルダを含む CD-ROM を検索。
  • 結果: 見つかった場合のみパスを設定し、ゲームを実行可能にします。

5. スクリプトのパッチング

CD パスをチェックする関数 

setSearchPaths
の 
if
ステートメントを変更しました。

  • 変更内容: CD がない場合のエラー分岐（
    else
    ）ではなく、次の指示へ直接ジャンプさせる処理に修正。
  • 推測: ゲームには「完全インストール」機能があり、データを HDD にコピーすれば動作する可能性があるため。

バイトレベルパッチ

オフセット元のバイト (
jmpifz
)		パッチ後のバイト (
nop/jmp
)
[246]
95 00 60
(JMP offset +60)
95 00 03
(JMP offset +3)
  • 手法: 
    ProjectorRays
    はアセンブルの再エクスポートをサポートしていないため、ImHex で手動パッチを行いました。
  • 処理: 元のバイト列 
    95 00 60
    を 
    95 00 03
    に上書きし、ゲームをスキップするようにしました。

これでイントロビデオが再生されるまで成功！🎉

6. コピー保護 №3：DLL による認証（Machine ID）

さらに深いコピー保護が存在しました。再度文字列検索を行いましたが、今度は 

intro.dxr
以外に以下の結果が見つかりました。

➜  rg -a 'Disc Error !'
P3media/intro.dxr...
P3media/huset.dxr...

BehaviorScript による認証

スクリプト解析により、実行ファイル（

Findus4.exe
）の隣にある 
optgraph.dll
 を読み込み、
initdisplay()
関数を呼び出していることが分かりました。

  • 処理: DLL から戻り値を確認し、特定のリターン値（マジックナンバー 
    26079537
    ）と一致しない場合、ゲームが強制終了します。
    • Mac 版も考慮されていないため、PC 版のみの認証であることが判明。
on exitFrame me
    if the platform contains "Mac" then
        nothing()
    else
        if Ok = 0 then
            alert("Disc Error !")
            avslutaSpelet()
        else
            if getReturnVal(me) <> 26079537 then
                alert("Disc Error !")
                avslutaSpelet()
            end if
        end if
    end if
end

DLL パッチングの決定

  • 選択肢:
    1. プラットフォームを Mac に見せかける。
    2. マジック値比較をバイパスする。
    3. DLL をパッチして常に成功値を返す。
  • 選択: ランタイムのリバースエンジニアリングは避け、
    optgraph.dll
    をパッチ    することにしました。

Ghidra による簡易化

Ghidra で 

optgraph.dll
を解析し、
initdisplay()
関数を以下の通り簡略化しました。

FUNCTION initdisplay(void)
0x1060: MOV EAX, 26079537    ; 成功値を直接セット
       RET                  ; 即座に返す

これにより、CD ドライブの低レベルコマンドを実行する処理をすべて削除し、常に認証を通過するようにしました。

7. オートパッチャの作成

作業完了後、適用したパッチを自動化するための Python スクリプトを作成しました。 ※このスクリプトはドイツ語版（

Findus4.exe
）に最適化されていますが、他言語版への適応も比較的容易です（ハッシュ値とオフセットの変更のみ）。

#!/usr/bin/env python3
import hashlib
import sys
from pathlib import Path

game_dir = Path(sys.argv[1]) if len(sys.argv) > 1 else Path.cwd()

patches = [
    # Findus4.exe のパッチ
    (
        game_dir / "Findus4.exe",
        "b33312ff9086c1cbc09d9cde6baa0eff4220a1ed354c9a3211ff6787fff46e39", # SHA256
        0x2252E8,
        bytes.fromhex("95 00 60"),
        bytes.fromhex("95 00 03"),
    ),
    # optgraph.dll のパッチ
    (
        game_dir / "optgraph.dll",
        "9897563fd6447976e2780ba0711f6e4e0a5a98a5c5cbecc4cb9bd608d856bd50", # SHA256
        0x1060,
        bytes.fromhex("55 8B EC 81 EC F4"), # NOP 置換前 (簡易化前のコード片)
        bytes.fromhex("B8 31 F1 8D 01 C3"), # MOV EAX=SuccessValue, RET 後
    ),
]

verified = []
for path, expected_hash, offset, original, replacement in patches:
    data = bytearray(path.read_bytes())
    actual_hash = hashlib.sha256(data).hexdigest()
    
    if actual_hash != expected_hash:
        raise SystemExit(f"Unexpected SHA-256 for {path}: {actual_hash}")
    if data[offset : offset + len(original)] != original:
        raise SystemExit(f"Unexpected bytes at 0x{offset:X} in {path}")
        
    data[offset : offset + len(replacement)] = replacement
    verified.append((path, data))

# ファイル書き込みと権限設定
for path, data in verified:
    path.chmod(path.stat().st_mode | 0o200) # Readable by all
    path.write_bytes(data)
    print(f"Patched {path}")

まとめ

  • 成果: ゲームは CD を検出せず、HDD インストールデータを正常に読み込み、イントロビデオまで到達することができました。
  • 類似タイトルの共通性: 多くの古いゲームが Macromedia Director を使用し、同様のコピー保護メカニズムを持っていたことが判明しました。
  • 今後の展望: このプロセスは他のタイトルにも適用可能ですが、各ゲームごとのオフセット調整が必要です。

20 年以上経ってから再び愛したゲームをプレイでき、子供達も楽しめるかもしれないと考え、非常に嬉しく思います。同じ喜びを感じてくれる方がいれば幸いです！

同じ日のほかのニュース

一覧に戻る →

2026/10/11 7:50

独自の意思決定モデルを構築する

## Japanese Translation: 本研究の核心となる洞察は、言語モデルは単一パスの意思決定システムを模倣することは可能であるが、特定のカリブレーションが行われる限りでは、しばしば危険な過剰な自信を示すという点にある。標準的なモデルが複数のパスを通じて順次テキストを生成するのに対し、システムワンアプローチは制約付きデコーディング（例えば、選択肢 A〜E の語彙をマスキングする）を用いて、AI に固定されたオプションを 1 パスで選択させる。この手法は推論速度を向上させるが、信頼スコアの膨張というリスクをもたらす；具体的には、ネイティブ出力トークンの確率は次のトークンに対する自信を反映しており、正しい答えの真なる確率を反映していない。CommonsenseQA の保持サンプルでの評価では、ファインチューニングの後であっても未カリーブレーテッドなモデルは、明確な単一の答えが存在しない困難な Commonsense 問題に対して高い不確かさ（例：99.78%）を割り当てることができ、マクロ F1 精度は約 58％に留まり、高自信ビンに至っては単なる 70％に過ぎなかった。本研究では、LLM 模倣（Qwen/Qwen3-1.7B）における温度スケイリングを用いてこの問題を成功裏に解決し、モデルの報告された自信を実際の性能と数学的に整合させ、結果として適合温度が約 3.8 となった。したがって、制約付きデコーディングは標準化テストのような多選択タスクに対して効率的を提供するものの、その後のカリブレーションなしで展開することは、過剰な自信による誤りを招き、ユーザーを欺くことになる。今後、事前に定義された答えへの厳格な遵守が求められる適用においては、信頼性指標が真に信頼性を反映するように、事後処理ステップ（例えば温度スケイリング）の優先を確保する必要がある。

2026/10/07 21:30

2D 車両

## Japanese Translation: 「Motion Lab」は、1996 年に GFA BASIC で書かれた先駆的な物理エンジンが GTA の車体システムを動力源としていたのを記念し、同エンジンの 30 周年を祝うためのモダンな Web ベースの再現作品です。当時の一般的なシンプルな「ポインタ・フィジックス」と異なり、この JavaScript インプリメンテーションは、リアルなトルクおよび力の相互作用を含む高度な古典的な 2 次元剛体動力学を正確にシミュレートします。本プロジェクトは、教育的目的のためにレガシースタイルを維持しつつ、オリジナルのソフトウェアが後に摩擦に関する推測に基づいた近似的かつ技術的に不正確な車体シミュレーション層を追加したことを認める一方で、「リマスター」された、より美しいバージョンの元のワイヤフレーム美学を提供しています。ユーザーは「Car（カー）」「Spaceship（スペースシップ／通称：Ship）」「Brick（ブリック）」という 3 つの異なるモードを体験でき、これらのモードは歴史的に「Brick モデル」から始まり、「Ship 要素」を含むよう進化し、最終的に「Car 要素」を取り入れた経緯を持っています。体験には、重力やバリアーの有効/無効化に加え、キーボードまたはタッチ入力により制御される GTA スタイルのカメラズームが含まれています。重要なのは、この非公式なプロジェクトが Rockstar Games および Take-Two から独立しており、オフィシャル製品ではなくトリビュートであることです。2026 年の発表を予定している本再現作品は、ユーザーが外部プラグインに依存せず、数十年にわたる技術開発を直接体験することを呼びかけています。

2026/10/11 5:31

あなたは存在したくても、街自体がそれを好まない街建設ゲーム

## Japanese Translation: サンフランシスコ当局は、特定の住宅シミュレーターに関する自由裁量審査を正式に開始し、都市の規制環境におけるその影響を検討するための重要な手続き的段階を示しています。この措置は、政府機関が該ツールを積極的に調査していることを示しており、同時に具体的な欠陥や直ちに懸念すべき事項がまだ特定されていないことも指摘しています。当面の次の段階では、審査プロセスを継続してシミュレーターの法的地位および運用可能性を決定することとなり、これが将来的にサンフランシスコにおける同様の住宅シミュレーターの開発と規制方法に影響を与える可能性があります。