1719409302
2024-06-26 12:15:46
Apple Mac SE ROM イメージから生成されたダンプを詳しく調べているうちに、大量の非コード、非オーディオ データがあることに気付きました。Adam Mayer はさまざまなストライド幅をテストし、67 バイト (横 536 ピクセル) のところに、明らかに人物の写真である何らかの画像データがあることを発見しました。画像の残りの部分は歪んでおり、非圧縮ビットマップとして保存されていないことがわかりました。
調査の結果、上記の混乱した画像を解読し、「1986 年 11 月 20 日木曜日「：
この写真と ROM に保存されていた他の 3 枚の写真をどのように復元したかについてのリバース エンジニアリングの詳細と、Motorola 68000 時代の Macintosh に関する情報については、以下をお読みください。
私たちはブルックリンの道端でこの Macintosh SE を見つけ、NYC Resistor に持ち込みました。起動はしますが、メディアがないため、さらにデジタル考古学的な調査を行うことにしました。
2つのROMチップ（ボードの中央、統合WozマシンであるVLSI ASICの上にあるもの）を取り外し、 プロムデート デバイス。チップのピン配置はM27C512 PROMと同じですが、 ヴップ ピンは A17 に再利用されます。再プログラムできないマスク ROM なので、プログラミング ピンは必要ありません (Nick さん、ありがとうございます)。これにより、M27C512 プログラマブル ROM の 64 KB と比較して、アドレス空間が 128 KB (1024 キロビット) に拡張されます。
m68kは16ビット幅のバスを持っているので、128KBの8ビットROMはそれぞれ半ワードで、それを256KBのバイナリファイルにマージする必要があります。 文字列 ファイルには「シカゴ「、」パック” そして “CDEF（バイト順序が間違っている場合は「APKC」など）。
イースターエッグの報告 アドレスにジャンプすることで見つけることができると述べた 0x41D89AROMを起動することができました ミニ vMac そして、これらがすでに発見されていた秘密の画像であることを確認しました。これで終わりでもよかったのですが、それらがどのように保存され、表示されているのかを知りたかったし、ROM に保存されている他の驚きのものを探すことができたので、さらに調査が必要でした。
ROMを逆アセンブルするには、生のバイナリダンプをELFファイルに変換するのが最も簡単だとわかりました。 オブジェクトダンプ 処理します。履歴から、ROMがアドレスにマッピングされていることがわかります。 0x0040_0000 (24 MB) がメモリ内にあるため、ELF ファイルの開始アドレスをそこに設定しました。IDA Pro は、まさにこの種のリバース エンジニアリングを実行するための優れたツールですが、この分析には無料のソフトウェアを使用しています。
m68k-elf-objcopy --change-addresses=0x400000 --redefine-sym _binary_mac_se_bin_start=rom --strip-symbol _binary_mac_se_bin_size --strip-symbol _binary_mac_se_bin_end -I binary -O elf32-m68k -B m68k roms/mac-se.bin roms/mac-se.elf
イースターエッグ関数のアドレスを見ると m68k-elf-objdump -D roms/mac-se.elf、 私たちは見る：
41d89a: 4eba 0018 jsr %pc@(41d8b4) 41d89e: 5847 addqw #4,%d7 41d8a0: 0287 0000 000c andil #12,%d7 41d8a6: 6100 002e bsrw 41d8d6 41d8aa: 307c 00b5 moveaw #181,%a0 41d8ae: a03b 0120073 41d8b0: 4efa ffec jmp %pc@(41d89e )
の 0xa03b 命令が奇数です — モトローラは、で始まるすべての命令を予約しました 0xAなので、これは正当なm68k命令ではありません。代わりに、不正命令トラップがトリガーされ、トラップハンドラは次のワードを見て適切なハンドラにベクトルします。このAラインまたはAトラップは、 Macintosh ツールボックス 通常のシステム コール メソッドに比べて、コード スペースを大幅に節約できます。 このコードリスト それは _遅れ そして、 %a0 遅延時間を指定する引数として使用されます。アセンブリ コードで何が起こっているかを理解するために、このリストを再度参照します。
これに基づいて、この関数を「C」のようなものに翻訳できます。
void easter_egg(void)
{
func_41d8b4();
while (1)
{
d7 = (d7 + 4) & 0xC;
func_0x41d8d6();
_Delay(181);
}
}
これが呼び出す最初の関数は 0x41d8b4:
41d8b4: 31fc ffff 0b9e movew #-1,b9e 41d8ba: 594f subqw #4,%sp 41d8bc: 2f3c 6262 6d63 movel #1650617699,%sp@- 41d8c2: 4267 clrw %sp@- 41d8c4: a9a0 0124640 41d8c6: 201f movel %sp@+,%d0 41d8c8: 6700 0050 beqw 41d91a41d8cc: 2040 moveal %d0,%a0 41d8ce: 21d0 0a78 movel %a0@,a78 41d8d2: 7e00 moveq #0,%d7 41d8d4: 4e75 rts ... 41d91a: a9ff 0124777
これにより、Aラインコールが行われます 0xA9A0、 または _GetResource(0x62626d63) そしてセット 0xb9e、 部屋の挿入フラグ 検索関数にROMテーブルを検索するように指示します。リソースの取得に失敗した場合は、デバッガートラップにジャンプします（0xA9FF）、マシンを停止します。それ以外の場合はゼロになります %d7 そして、返されたアドレスからリソースのアドレスを読み取ります。 _リソースを取得 その値をグローバルメモリの場所に書き込みます 0xa78 （アップルスクラッチ）。
ASCIIを話す人にとっては、この定数は興味深いものになるかもしれません。これはマルチバイト文字です。bbmc‘、あなたはおそらく 文字列 オフセットでの出力 0x1af4e、ある種の構造のように見えます:
001af3e: 5041 434b 0002 006a 7463 736c 0000 008e PACK...jtcsl.... 001af4e: 6262 6d63 0000 009a 5345 5244 0000 00a6 bbmc....SERD.... 001af5e: 4452 5652 0004 00b2 4344 4546 0001 00ee DRVR....CDEF.... 001af6e: 4b43 4852 0000 0106 4b4d 4150 0000 0112 KCHR....KMAP.... 001af7e: 4d42 4446 0000 011e 4d44 4546 0000 012a MBDF....MDEF...* 001af8e: 5744 4546 0001 0136 4355 5253 0003 014e WDEF...6CURS...N 001af9e: 464f 4e54 0004 017e 0005 ffff 5801 b122 FONT...~....X.." 001afae: 0000 0000 0004 ffff 5801 c188 0000 0000 ........X....... 001afbe: 0007 ffff 5801 d348 0000 0000 0000 ffff ....X..H........ 001afce: 5801 d896 0000 0000 0000 ffff 5801 d924 X...........X..$
現時点では、構造を解読する方法も、 %a0 グローバルに参照解除されるときを指す 0xa78これについては後でまた触れますが、明らかにそれは 0x009A そして赤い部分は 0x1AFDA。
次に 関数0x41d8d6()擬似コードが散りばめられています:
41d8d6: moveal a78,%a0
41d8da: addaw %d7,%a0
41d8dc: movel %a0@,%d3 d3 = _a78[d7];
41d8de: movel a78,a7c
41d8e4: addl %d3,a7c _a7c = _a78 + d3;
41d8e8: movel 824,a80 _a80 = _824 // ScrnBase
41d8ee: movel #340,%d3 d3 = 340;
do {
41d8f4: pea a7c
41d8f8: pea a80
41d8fc: movew #72,%sp@- // 72 * 8 == 576 bits
41d900: a8d0 _UnpackBits(&_a7c, &_a80, 72)
41d902: subql #8,a80 _a80 -= 8;
41d906: dbf %d3,41d8f4 } while (d3--)
41d90a: pea a7c
41d90e: pea a80
41d912: movew #64,%sp@-
41d916: a8d0 _Unpackbits(&_a7c, &_a80, 64);
41d918: rts return;
これら 3 つの関数のコード全体を C に似た形式で書き直します。
void draw_bitmap(const uint8_t * packed)
{
uint8_t * fb = _ScrnBase;
for (int y = 0 ; y
Adam found the format expected by _UnpackBits defined in PackBits on wikipedia, and wrote a python unpackbits.py that can be given the offsets of the images in the ROM. So the last piece of the puzzle was to figure out where they are located.
And this is where I cheated… Based on a binary search of the image space using unpackbits.py, I found that the first one started at 0x1d93c. Looking slightly earlier in the ROM dump, I saw:
001d920: 0000 0064 0000 0018 0000 5618 0000 a71c ...d......V.....
001d930: 0000 f700 0001 4281 0000 0000 30aa 552a ......B.....0.U*
001d940: 52a5 294a 5294 a529 4a52 2449 1224 44a9 R.)JR..)JR$I.$D.
それ 0x0000_0018 正しいようです。 0x1D924 + 0x18 = 0x1D93Cそしてそのすぐ後には、他のビットマップの適切な間隔のように見える追加のオフセットがあります。これにより、他のビットマップは次のようになります。 0x22F3C、 0x28040、 0x2D024 そして未使用のもの 0x31BA5ROMダンプのリソース定義領域を振り返ってみると、 0x5801D924（冒頭の 0x58 (Mac SE には 24 ビットのアドレスしかなかったので、CPU によって無視されます)。
アダムのツールと私のツールを組み合わせて実行する 16進数2png 地域では4つの画像が成功しました!
for offset in 1D93C 22F3C 28040 2D024; do
off_decimal=`echo 16i $offset p | dc`
../unpackbits.py $off_decimal 5000
So here is the team that twenty five years ago found space in the ROM to include their own images as an easter egg. Can anyone identify them? Where are they now? Are they “JCSLWRLBBMABOEMTDAHJTCFJLMBKCRCLAKEHBRDCDAFSHFT“? If you do know who they are, please send them our thanks for a fun puzzle!
5 番目の領域には何があるのでしょうか? 注目すべき画像データはないようですが、ROM 内の文字列に基づくオーディオである可能性があります。これは後で取り組むプロジェクトになるかもしれません...
0031ba0: 00b9 00b9 0000 c000 08fc 0000 0068 600a .............h`. 0031bb0: 0000 5345 5244 0000 0003 487a 0074 487a ..SERD....Hz.tHz 0031bc0: 0058 487a 003c 487a 0020 76fa 3003 a53d .XHz.
もちろん、これらの画像の著作権は Apple Computer が所有しています。つまり、次のようになります。
#ROM #の幽霊 #NYC #レジスター