👖 🚋 🖊️ アーケードマシンでゲームを探索する、パート1 🔋 👨🏿‍🍳 🐏

ええと、ここで彼らは私をハブで禁止しており、私はあなたのために素晴らしい記事を持っているので、皆さんこんにちは！

はじめに

アーケードマシンには何があるのだろうか？ゲームの開発にどのOS、どのテクノロジーが使用されていますか？コピーおよび変更からどのように保護されていますか？はいの場合、このトピックへようこそ。

内部

それでは、マシンの中には何がありますか？

PIUIOおよびJAMMAボードを搭載した通常のx86コンピューター
アンプ、クロスオーバー、イコライザー
LEDパネル
ボタン「TEST」、「SERVICE」、およびイコライザーノブを備えたコントロールパネル
LCDまたはCRT画面

もちろん、私たちは主にコンピューターに興味があります。

コンピューターの最新バージョンの内部にはいくつかの改訂版があります。

マザーボード ：Gigabyte GA-945GCM-S2L / Asrock G41M-S3

グラフィックス ：Geforce 8400GS / Geforce 9300GS

メモリ ：DDR2 / DDR3 512 MB

プロセッサー ：Intel Celeron

ゲーム自体はハードドライブにあります。 SafeNet MicroDog USBドングルが含まれています。

リサーチ

どこから始めますか？当然、ハードドライブダンプを削除します。これはLinuxで1つのコマンドで実行されます。

dd if=/dev/sdX of=./dump.bin bs=1M

お茶を飲みに行きます約10〜15分かかります。ウィンチェスターは、160ギガバイトと250ギガバイトで使用されます。

実行中のハードドライブで何もしないでください！ 常に画像を使用する必要があります！

画像が撮影されます。 cfdiskを実行してみましょう。

何が見えますか？ ext2ファイルシステムを備えた2つのパーティションと、ディスクの先頭にある疑わしい未割り当て領域。ファイルシステムはすぐに、UNIXのようなものが内部にあるという考えにつながります。もちろん、Linuxである可能性が高いです。

仮想マシンで実行してみましょう。私はqemuが大好きなので、使用しています。

そしてそれ以上。次に、次のようなエラーでqemuが失敗します。

qemu: fatal: Trying to execute code outside RAM or ROM at 0xa5ff00d8

ただフリーズします。正直なところ、このゲームにはハードドライブへのバインドがあることを知っていたため、アルゴリズムは非常にシンプルであり、データの整合性チェックを使用せず、復号化されたデータ、および仮想マシンの場合はゴミに制御をすぐに転送することが明らかになりました。

さらに、私は、いくつかの発見を待つのではなく、興味のために、ext2ファイルシステムでこれらの2つのセクションにあるものを見ることにしました。そして、ここに何があります：

  1 ├── [4.0K] game │  └── [ 25G] _00000.BIN ├── [4.3M] i ├── [ 16K] lost+found ├── [ 0] n ├── [8.5M] p ├── [7.8M] u └── [ 22M] x game/_00000.BIN: data i: data n: empty p: data u: data x: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped  2: ├── [ 16K] lost+found └── [144K] PIUFESTAEX.INI

さて、セクション1の「x」ファイルを除くすべてのデータは、通常のデータであるか、暗号化されています。どういうわけか、このマスから際立っている「x」は1つだけです。これは共有ライブラリであり、おそらくゲームによって読み込まれます（実際にはそうではありません）。

次は？まあ、彼らはハードドライブ自体に登りました。

 00000000 fa 33 c0 8e d0 bc 00 7c 8b f4 50 07 50 1f fb fc |.3.....|..PP..| 00000010 bf 00 06 b9 00 01 f3 a5 ea 1d 06 00 00 b6 00 b9 |................| 00000020 02 00 bf 05 00 bb 00 07 b8 01 02 57 cd 13 5f 73 |...........W.._s| 00000030 0c 33 c0 cd 13 4f 75 ed be 8a 06 eb 3b b9 03 00 |.3...Ou.....;...| 00000040 bf 05 00 bb 00 20 53 07 bb 00 00 b8 20 02 57 cd |..... S..... .W.| 00000050 13 5f 73 0c 33 c0 cd 13 4f 75 e8 be 8a 06 eb 18 |._s.3...Ou......| 00000060 b9 ff 3f be 00 08 33 ff ad 83 e6 bf 26 33 05 ab |..?...3.....&3..| 00000070 49 75 f5 ea 00 00 00 20 ac 3c 00 74 0b 56 bb 07 |Iu..... .<.tV.| 00000080 00 b4 0e cd 10 5e eb f0 eb fe 44 69 73 6b 20 49 |.....^....Disk I| 00000090 2f 4f 20 45 72 72 6f 72 00 00 00 00 00 00 00 00 |/O Error........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000180 28 43 29 32 30 30 34 20 41 4e 44 41 4d 49 52 4f |(C)2004 XXXXXXXX| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 9b f6 31 c9 00 00 00 00 |..........1.....| 000001c0 41 8f 83 fe ff ff cf ce 61 00 b1 a1 a9 03 00 fe |A.......a.......| 000001d0 ff ff 83 fe ff ff 6f 56 36 04 80 60 1f 00 00 00 |......oV6..`....| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 50 75 6d 70 20 49 74 20 55 70 3a 20 46 69 65 73 |Xxxx Xx Xx: Xxxx| 00000210 74 61 45 78 00 00 00 00 00 00 00 00 00 00 00 00 |xxXx............| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000300 20 20 20 20 20 20 20 20 20 20 20 20 36 56 4d 51 | 6VMQ| 00000310 57 54 34 37 43 43 34 36 20 20 20 20 53 54 33 31 |WT47CC46 ST31| 00000320 36 30 33 31 38 41 53 20 20 20 20 20 20 20 20 20 |60318AS | 00000330 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | 00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 0e a8 36 bd 22 ac ea 0e a9 36 bb 22 82 66 80 70 |..6."....6.".fp| 00000410 dc 7a 36 37 c8 5d 18 36 ae fa 83 3a 74 d8 35 29 |.z67.].6...:t.5)| 00000420 11 b9 2d 25 1f c8 7d 10 07 c8 7d 21 81 34 07 ae |..-%..}...}!.4..| ...

（「X」の代わりに、製造元の名前とゲームの名前がありました。これらのデータでこのトピックがグーグルにならないように、それらを削除しました。必要に応じて、HEXデータを変更しませんでした。）

これは何ですか説明します。

0-1BEでは、MBRブートローダーが配置されます。これは、400から始まる最初のディスクからstage2ブートローダーをロードする最も単純なものです。最も興味深い行は300-32Fにあり、ハードドライブ、ファームウェアバージョン、およびモデルのシリアル番号に非常に似ています。しかし、推測できることは何ですか;）

説明	データ
シリアル番号（20バイト）	（12スペース）6VMQWT47
ファームウェアバージョン（8バイト）	CC46（4スペース）
モデル名（40バイト）	ST3160318AS（29スペース）

私は簡単な方法で進みました。stage2-loaderのアルゴリズムを分解するのではなく、環境変数DRIVE_MODEL、DRIVE_SERIAL、DRIVE_VERSIONからハードドライブデータを取得するために、qemuに小さなコードを追加しただけです。また、qemuを使用すると、ゲストマシンのメモリをダンプできます。これは便利です。

 valdikss@valaptop:~/ % DRIVE_SERIAL=" 6VMQWT47" DRIVE_VERSION="CC46 " DRIVE_MODEL="ST3160318AS" qemu-system-i386 disk.img -monitor stdio QEMU 1.4.1 monitor - type 'help' for more information (qemu) dump-guest-memory mem.bin (qemu) quit

データ復号化の正確さを純粋に視覚的に判断することができました。カーネルが正常にアンパックされて起動された場合、現時点でカーソルが画面に表示され、ファイルシステムが正しくアンパックされた場合、仮想マシンの画面が点滅し、Xが起動しようとします

Linuxoidとして、私はすぐにAlt + FNの組み合わせを使用して別のコンソールに切り替えようとしましたが、成功しました。2番目のコンソールでX出力がありました。

qemuの画像は正常に起動されましたが、すでに良好です。次は何ですか？ファイルシステムを取得する必要があります。確かに、initrdまたはinitramfsにはカーネルがロードされます。カーネルには、必要なすべてのファイルが配置されているか、rootfsを復号化して接続します。どうする？メモリダンプに戻り、すばらしいBinWalkユーティリティを使用して説明します。

 DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------------------- 0 0x0 ELF 32-bit LSB core file Intel 80386, version 1 (SYSV) 141888 0x22A40 Copyright string: " 1999-2003 XXXXXXXXxxx" 1649782 0x192C76 CramFS filesystem, little endian size 279239 CRC 0x42c70000, edition 20, 141723904 blocks, 1589959 files 3848752 0x3ABA30 CramFS filesystem, little endian size 4947968 version #2 sorted_dirs CRC 0x9c99ddde, edition 0, 2433 blocks, 235 files 17648271 0x10D4A8F mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit 17752783 0x10EE2CF mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit 17773455 0x10F338F mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit 17966760 0x11226A8 Copyright string: " (C) 1996-2009 the UPX Team. All Rights Reserved. $l Rights Reserved. $" 18179243 0x11564AB Copyright string: " (C) 2009 Free Software Foundation, Inc.ion, Inc." 18236316 0x116439C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 18261064 0x116A448 LZMA compressed data, properties: 0xBD, dictionary size: 16777216 bytes, uncompressed size: 33554432 bytes 18261104 0x116A470 LZMA compressed data, properties: 0xB8, dictionary size: 16777216 bytes, uncompressed size: 33554432 bytes 21033884 0x140F39C ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV) 21061669 0x1416025 ELF 32-bit LSB no file type, no machine, (GNU/Linux) 21088103 0x141C767 ELF 21152544 0x142C320 LZMA compressed data, properties: 0x6C, dictionary size: 16777216 bytes, uncompressed size: 838860800 bytes 21435292 0x147139C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 21525404 0x148739C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 21537692 0x148A39C ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV) 21554076 0x148E39C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 21615281 0x149D2B1 Copyright string: " (C) 2006 Free Software Foundation, Inc.ion, Inc." 21672860 0x14AB39C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 21926836 0x14E93B4 ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV) 110031566 0x68EF2CE gzip compressed data, was "cursor.pcf", from Unix, last modified: Fri Feb 13 07:15:31 2004 116417852 0x6F0653C CramFS filesystem, little endian size 4947968 version #2 CRC 0x86f06160, edition 16777216, 18 blocks, 0 files 121710143 0x741263F LZMA compressed data, properties: 0x87, dictionary size: 1048576 bytes, uncompressed size: 256 bytes 121721756 0x741539C ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV) 122005647 0x745A88F LZMA compressed data, properties: 0x87, dictionary size: 1048576 bytes, uncompressed size: 256 bytes 122594740 0x74EA5B4 LZMA compressed data, properties: 0x7E, dictionary size: 16777216 bytes, uncompressed size: 33554432 bytes 122614684 0x74EF39C CramFS filesystem, little endian size 4947968 version #2 sorted_dirs CRC 0x9c99ddde, edition 0, 2433 blocks, 235 files 129803164 0x7BCA39C CramFS filesystem, little endian size 4947968 version #2 sorted_dirs CRC 0x9c99ddde, edition 0, 2433 blocks, 235 files

ああ、たくさんあります！

実際、すべてのLZMA応答は偽です。彼は魔法の数を持っていません、ELFの半分も偽物です。ただし、235個のファイルを含むCramFSは実際のファイルと非常によく似ており、高い確率でinitrdとして使用されます。

メモリから正しいCramFSを取得するのは簡単です。 CramFSがファイル形式でハードドライブに保存されたら、アンパックを試みます。 firmware-mod-kitパッケージのcramfs-2.0を使用しました。

 valdikss@valaptop:~/ % cramfsck -x root cram1.bin cramfsck: crc error

さて、あなたは何を期待しましたか？すべてがとてもシンプルだと思いましたか？

cramfsckでチェックサムチェックにパッチを当てると、ファイルシステムを「正常に」解凍できます。

ファイルシステムツリー

 ├── [4.0K] bin │  ├── [ 7] ash -> busybox │  ├── [130K] busybox │  ├── [ 7] cat -> busybox │  ├── [ 7] chmod -> busybox │  ├── [ 7] cp -> busybox │  ├── [ 7] df -> busybox │  ├── [ 7] dnsdomainname -> busybox │  ├── [ 7] echo -> busybox │  ├── [ 7] false -> busybox │  ├── [ 7] hostname -> busybox │  ├── [ 7] kill -> busybox │  ├── [ 7] ln -> busybox │  ├── [ 7] ls -> busybox │  ├── [ 7] mkdir -> busybox │  ├── [ 7] mknod -> busybox │  ├── [ 7] mount -> busybox │  ├── [ 7] mv -> busybox │  ├── [ 7] netstat -> busybox │  ├── [ 7] ping -> busybox │  ├── [ 7] ps -> busybox │  ├── [ 7] pwd -> busybox │  ├── [ 7] rm -> busybox │  ├── [ 7] sh -> busybox │  ├── [ 7] sleep -> busybox │  ├── [ 7] sync -> busybox │  ├── [ 7] true -> busybox │  ├── [ 7] umount -> busybox │  ├── [ 7] uname -> busybox │  └── [ 7] vi -> busybox ├── [4.0K] dev │  ├── [ 0] console │  ├── [ 0] null │  ├── [ 0] tty1 │  └── [ 0] tty2 ├── [4.0K] etc │  ├── [4.0K] init.d │  │  ├── [ 90] mnttab │  │  ├── [ 754] once │  │  ├── [ 412] rcS │  │  └── [ 244] run │  ├── [ 151] inittab │  └── [4.0K] X11 │  └── [ 23] xorg.conf -> /usr/lib/xorg/xorg.conf ├── [4.0K] lib │  ├── [111K] ld-2.10.1.so │  ├── [ 12] ld-linux.so.2 -> ld-2.10.1.so ... │  ├── [ 78K] libz.so.1.2.3 │  └── [4.0K] modules │  └── [ 25K] atkbd.ko ├── [4.0K] mnt │  ├── [4.0K] 0 │  │  └── [ 0] invalid │  ├── [4.0K] 1 │  │  └── [ 0] invalid │  └── [4.0K] hd ├── [1.1M] piu ├── [4.0K] proc ├── [4.0K] sbin │  ├── [ 14] halt -> ../bin/busybox │  ├── [ 14] ifconfig -> ../bin/busybox │  ├── [ 14] init -> ../bin/busybox │  ├── [ 14] insmod -> ../bin/busybox │  ├── [ 14] lsmod -> ../bin/busybox │  ├── [ 14] mdev -> ../bin/busybox │  ├── [ 14] poweroff -> ../bin/busybox │  ├── [ 14] reboot -> ../bin/busybox │  └── [ 14] route -> ../bin/busybox ├── [4.0K] SETTINGS ├── [4.0K] sys ├── [ 4] tmp -> /var ├── [4.0K] usr │  ├── [4.0K] bin │  │  ├── [ 18K] amixer │  │  ├── [ 17] du -> ../../bin/busybox │  │  ├── [ 17] env -> ../../bin/busybox │  │  ├── [ 17] free -> ../../bin/busybox │  │  ├── [ 17] less -> ../../bin/busybox │  │  ├── [4.4K] mountrd │  │  ├── [4.6K] mount_tab │  │  ├── [ 17] telnet -> ../../bin/busybox │  │  ├── [ 25K] usbdaemon │  │  ├── [ 4] X -> Xorg │  │  ├── [ 14K] xinit │  │  └── [1.7M] Xorg │  ├── [4.0K] lib │  ├── [4.0K] sbin │  │  └── [ 17] setlogcons -> ../../bin/busybox │  ├── [4.0K] share │  │  ├── [4.0K] alsa │  │  │  ├── [8.8K] alsa.conf │  │  │  ├── [4.0K] cards │  │  │  │  ├── [ 669] AACI.conf │  │  │  │  ├── [ 687] aliases.alisp │... │  │  │  │  ├── [ 839] VXPocket.conf │  │  │  │  └── [1.3K] YMF744.conf │  │  │  ├── [4.0K] init │  │  │  │  ├── [1.8K] 00main │  │  │  │  ├── [6.9K] default │  │  │  │  ├── [1.4K] hda │  │  │  │  ├── [ 391] help │  │  │  │  ├── [ 932] info │  │  │  │  └── [ 11K] test │  │  │  └── [4.0K] pcm │  │  │  ├── [ 805] center_lfe.conf ... │  │  │  └── [ 978] surround71.conf │  │  └── [4.0K] X11 │  │  └── [4.0K] xkb │  │  ├── [4.0K] compiled │  │  │  └── [ 11K] server.xkm │  │  └── [4.0K] rules │  │  ├── [ 34K] base │  │  ├── [ 31K] evdev │  │  └── [ 4] xorg -> base │  └── [ 4] var -> /var └── [4.0K] var

それだけです。 /etc/init.d/runのようなテキストファイルは正常なようです。ただし、実行可能ファイルとライブラリは起動されません。最初は、ゲームは修正されたカーネルまたは修正されたlibcのいずれかを使用すると考えました。実行可能ファイルにパッチを適用し、hello worldとどの程度異なるかを観察しました。それらはすべて、 セグメンテーションフォールトで終了するか、さらに悪いことに、 違法なハードウェア命令で終了します。

参照「hello world」をコンパイルしました、なぜなら最初から__libc_start_mainを呼び出して、どこか間違った方向に飛んでしまいました。それから彼は再ロックで罪を犯した、なぜならいくつかはそのままでbeatられ、おそらく修正が含まれていると示唆しましたが、いいえ、再ロックを編集した後、ゲームは開始しようとしましたが、そうではありませんでした。約3日間考えました。私は、実行可能ファイルが何らかの形でCramFSを破り、テキストファイルは元の形式のままであるという結論に達しました。そして彼は正しかった！

/etc/init.d/run

 echo run export __GL_SYNC_TO_VBLANK=1 export force_s3tc_enable=true export LD_LIBRARY_PATH=/lib:/usr/lib:/mnt/hd/lib cd /mnt/hd/game xinit /piu /mnt/hd/game/ -- -br -quiet -logverbose 0 -verbose 0 -depth 24 -audit 0 -bs -tst -xinerama #/bin/sh

/etc/init.d/once

 until /usr/bin/mount_tab /etc/init.d/mnttab; do sleep 1; done /usr/bin/mountrd insmod /usr/lib/modules/nvidia.ko insmod /usr/lib/modules/drm.ko insmod /usr/lib/modules/fb.ko insmod /usr/lib/modules/font.ko insmod /usr/lib/modules/softcursor.ko insmod /usr/lib/modules/bitblit.ko insmod /usr/lib/modules/fbcon.ko insmod /usr/lib/modules/drm_kms_helper.ko insmod /usr/lib/modules/cfbcopyarea.ko insmod /usr/lib/modules/cfbimgblt.ko insmod /usr/lib/modules/cfbfillrect.ko insmod /usr/lib/modules/i915.ko mkdir /dev/dri ln -s /dev/card0 /dev/dri/card0 /usr/bin/usbdaemon amixer set Master 80% unmute amixer set PCM 75% unmute amixer set Front 90% unmute insmod /lib/modules/atkbd.ko

/etc/init.d/run

 setlogcons 2 mount -n -t tmpfs -o size=128k var /var mkdir /var/log mkdir /var/run mkdir /var/run/microdog mount -t sysfs sysfs /sys mount -t proc proc /proc mount -t usbfs none /proc/bus/usb mount -t tmpfs mdev /dev mkdir /dev/pts mount -t devpts devpts /dev/pts echo /sbin/mdev > /proc/sys/kernel/hotplug mdev -s mkdir /dev/snd cp -a /dev/controlC* /dev/snd cp -a /dev/pcmC* /dev/snd cp -a /dev/timer /dev/snd

なぜなら元のCramFSを手元に持っていて、Alt + F2を押すだけで仮想マシンのOSコンソールにアクセスできることを思い出して、元の/etc/init.d/runを置き換え、xinit呼び出しを/ bin / shに置き換えてみることにしました。しかし、変更されたCramFSを何らかの方法でイメージにプッシュする必要があります。ハードドライブのイメージで「Compressed RamFS」という行を探して、暗号化されていないことに少し驚きました。もちろん、それだけではなく、「パディング」によって、ハードドライブ上のファイル全体が32KBのデータのブロックと512バイトのvoidに分割されます。まあ、それは問題ないようです！

たまたま/etc/init.d/runだけでなく/etc/init.d/onceも変更して、mount_tab、mountrd、およびusbdaemonの呼び出しをコメントアウトし、呼び出しのループに注意を払っていませんでしたmount_tab。

そこで、/ etc / init.d / runを編集し、CramFSをアセンブルし、イメージに書き込みました。さて、元の/etc/init.d/runでFSを収集し、ファイルの違いを探し始めました。結局のところ、それらの多くがあったので、私は問題が何であるかを理解しようと長い間試みましたが、firmware-mod-kitのcramfs-2.0は少し異なる収集をすることがわかりました。さて、リポジトリから通常のcramfs-toolsをダウンロードして収集しましたが、突然、チェックサムに加えて、ファイルの最後のバイトが異なることがわかりました。元のファイルには0x80があり、もちろん収集したファイルには0x00があります。この状況に驚いて、彼は自分のファイルの最後のバイトを置き換え、ハードドライブとURAのイメージに入れました！イメージは修正されたFSから始まり、コンソールを取得しました。ファイルをコピーしても複雑さは発生せず、スタートアップファイルは実際にLinuxシステムで実行されました。このステップで、実際にCramFSが実行可能ファイルを具体的に変更することに気付きました。

IDA PROのmount_tab、mountrd、およびusbdaemonをざっと見てみると、その時点でmount_tabがファイルシステムを適切な場所（ハードドライブ上の2つのパーティション、/ mnt / gameの2つのパーティション、/ SETTINGSの2番目のパーティション）、mountrd AGPおよびPCIバスをスキャンし、復号化してメモリにロードし、最初のセクションにあるファイル「p」、「i」または「u」の1つを/ usr / libにマウントします。これにはビデオカードのドライバーが含まれ、usbdaemonはUSBでの作業を提供しますUNIXソケット経由のドングル。

偽りの喜び

私は座って、ゲームの起動ファイルを調べていますが、それをコピーして取り出したので、疑いが忍び込み始めました。どういうわけかそうではなく、私が探求しているゲームのバージョンについての言及はなく、一般的に、何らかの形で何かが正しくありません。このファイルはゲームの異なるバージョンに属していることを認識し、明らかに、USBドングルをチェックした後、彼はどこかから別のファイルを取得して復号化すると仮定しました。すべてがずっと面白くなりました。

mount_tabを呼び出すときのループを覚えていますか？最初の起動では、ファイルシステムを実際にマウントしますが、次の起動では、最初のオフセットのヘッダーに応じて、オフセット0x1F80200または0x2080200から一定量のデータをハードドライブから読み取り、このデータを復号化し、CramFSゲームの起動ファイルを直接置き換えます正しいもの。私はこの動きが本当に好きでした！私は激怒しましたが、同時に開発者の機知に誇りを持っています。

おわりに

記事はややくしゃくしゃになっており、私の考え、推測、観察から成り立っています。読むことが面白かったと思います。パート2は純粋に技術的なもので、ゲームのファイルシステムの解析とUSBドングルからのゲームの解除が含まれる可能性があります。

最後にビデオをご覧ください。

へのご挨拶

それがグーグルしないようにコメントにゲームの名前を書かないでください。 よろしくお願いします！

アーケードマシンでゲームを探索する、パート1

はじめに

内部

リサーチ

偽りの喜び

おわりに

More articles: