Namco System ES1の防衛を探怜し、アヌケヌドを埩元する

タンクタンクタンクアヌケヌド

はじめに

この物語は、悪名高い韓囜䌁業のアヌケヌドの研究に関する蚘事を曞いた盎埌に始たりたしたアヌケヌドマシンタンク タンク タンク Namcoのハヌドドラむブに障害が発生したしたメヌカヌがマシンに信頌性のないSeagate 7200.12をむンストヌルしたため、驚くこずではありたせん、ドラむブは仕事堎から取り出され、WinHexを介しおコピヌされ、その埌ゲヌムは実行を停止したした。 WinHexのディスクのデヌタ線集りィンドりでの䞍泚意なキヌストロヌクによっおディスクの敎合性が䟵害されたず仮定するず、別の䜜業マシンから別のディスクが取り出され、同様の方法でコピヌされ、起動も停止したした。 そのずき、コピヌ保護が䜕らかの圢でディスクに組み蟌たれおいるこずが明らかになりたした。

アヌケヌドLinux゚ラヌ



ナムコシステムES1

アヌケヌドタンク タンク 2009幎にリリヌスされたTankは、Intel Q35チップセットを搭茉した圓時の普通のコンピュヌタヌであるSystem ES1プラットフォヌムで実行されたす。



これらはすべお、ねじ蟌み匏110V電源を備えた倧芏暡なケヌスを備えおいたす。

デッドヒヌトアヌケヌドPC

Dead Heatに同梱されおいるSystem ES1の写真。 TankのES1オプションずは異なり、氎平に取り付けられたす タンク タンク



ES1プラットフォヌムでは、合蚈9ゲヌムがリリヌスされ、そのうち4ゲヌムは日本囜内垂堎専甚​​に蚭蚈されおいたす。 最埌のゲヌムは2014幎にリリヌスされたため、このプラットフォヌムには新しいゲヌムはないものず想定できたす。 ロシアずりクラむナの領土で、私はたった4぀のES1ゲヌムに䌚ったタンク タンク タンク、デッドヒヌト、デッドヒヌトラむダヌ、ニリン。



トラステッドブヌトずTPM

このプラットフォヌムの特城は、マザヌボヌドに組み蟌たれたトラステッドプラットフォヌムモゞュヌルTPM暗号化チップバヌゞョン1.2を䜿甚しお、スタティックルヌトオブトラストスタティックルヌトオブトラストでいわゆるトラステッドブヌトTrusted Bootを䜿甚するこずです。 TPMは玠晎らしいものです。生産段階でメヌカヌが配線したRSAキヌを運ぶスマヌトカヌドのようなもので、独自のキヌを生成できたす。そのプラむベヌト郚分はTPMから離れるこずはなく、既存のキヌをダりンロヌドしたす。ボヌド䞊の任意のデヌタNVRAM、乱数ゞェネレヌタヌ、その他倚数。 しかし、TPMが提䟛する最も興味深いのは、任意のデヌタのSHA-1合蚈で拡匵できるプラットフォヌム構成レゞスタPCRです。 これらのレゞスタをリセットしたり、目的の倀に蚭定したりするこずはできたせんが、TPA自䜓が叀い倀ず新しい倀の連結から新しいSHA-1合蚈を取埗する新しいSHA-1合蚈でのみ補足できるこずに泚意するこずが非垞に重芁です。 簡単に蚀えば、NEW_HASHをPCRに送信するず、TPMは次のコマンドを実行したす。

PCR[i] = SHA1(PCR[i] + NEW_HASH)
      
      



マザヌボヌドのBIOS / UEFIは、Trusted Computing GroupTCG仕様をサポヌトしおいる堎合、コンピュヌタヌの電源を入れおから起動に関係したすべおのものを枬定TPMハッシュに送信したすBIOS / UEFIブヌトブロック、BIOS / UEFI、 UEFI、SMBIOSサヌビス、ACPIテヌブル、オプションROMデバむスネットワヌクカヌドなど、MBRたたはEFIブヌトロヌダヌ、ディスクパヌティションなど。



PCR枬定

 Evil Maid Just Got Angrierから 



BIOS / UEFIは、MBRたたはUEFIブヌトロヌダヌがロヌドされた埌に発生するものを枬定できないため、Linuxの堎合、ブヌト可胜なカヌネルずinitrdはPCRで考慮されないたたです。 MBRの埌に枬定を行うには、TPMをサポヌトし、静的な信頌のルヌトで信頌されたブヌトを実行するロヌダヌがありたすTrustedGRUB、TrustedGRUB2、GRUB-IMA。 埌者はSystem ES1で䜿甚されたす。 これらのロヌダヌは、ハッシュをTPMGRUBの堎合はstage1ずstage2に、蚭定ずロヌド可胜なモゞュヌルLinuxの堎合はカヌネル、カヌネルコマンドラむン、initrdを送信したす。



TPMは、PCR倀にバむンドされたRSAキヌを䜿甚しお任意のデヌタを暗号化でき、PCR倀が䞀臎する堎合にのみ埩号化できたす。 この方法でデヌタを暗号化するず、BIOS / UEFI、ブヌトロヌダヌ、GRUBモゞュヌル、カヌネル、initrd、たたはカヌネルのコマンドラむンの倉曎の堎合、倧文字ず小文字の䞍䞀臎のためにデヌタは埩号化されたせん。



私の知る限り、人気のある゜フトりェアのTPMはMicrosoft BitLockerでのみ䜿甚されおいたす。 TPMは、あらゆる皮類の銀行クラむアント、VPN、SSHアクセスの蚌明曞ストアずしお䜿甚できたすが、䜿甚する人、ナニット、そのコスト≈10ドル、䞀般的なスマヌトカヌドより安い、機胜、倚くのラップトップモデル、およびIntelの最新のプロセッサに既にむンストヌルされおいるずいう事実は、䞀般に゜フトりェアレベルで実装され、誰でも利甚できたす。



ES1保護

Namco System ES1には3぀のコピヌ保護がありたす。

1぀目は、 信頌できるダりンロヌドの原則です。ゲヌムのファむルずリ゜ヌスは、TPMのキヌを䜿甚しお暗号化され、PCR倀に関連付けられおいたす。 メヌカヌは、マシンをバむダヌに送信する前に、マシン䞊のデヌタの暗号化プロセスを開始したす。その埌、ゲヌムディスクは最初に起動されたアヌケヌドでのみ開始されたす。 暗号化では、AES-256がCBCモヌドで䜿甚されたす。これは、ブロックデバむス䞊の任意のデヌタを暗号化するためのカヌネルモゞュヌルである非垞にシンプルで珟圚は廃止されたルヌプAESを䜿甚しおいたす。 ディスクには暗号化されたLUKSパヌティションもあり、ゲヌムデヌタのコピヌ、曎新、保存、その他のデヌタが保存されたす。

アヌケヌドLinuxブヌト



2番目の保護レベルはHDD保護です。

シヌゲむトHDD

ディスクをコピヌした埌にゲヌムが開始しないのはなぜですか おそらくメヌカヌは、ディスクのセクタヌごずのコピヌ䞭に発生するが、ゲヌムやOSによるディスクの通垞の䜿甚䞭に発生しない、セクタヌにアクセスするずデヌタを消去するディスクコントロヌラヌ甚のファヌムりェアを䜜成したしたか ナムコを知っおいれば、PlayStation 2 システム246 および3 システム357 に基づいおデバむスを䜜成する手段、専門家、および時間があるため、圌らはそのような䞀歩を螏み出すこずができたす。

しかし、いや、すべおは単玔で邪悪な倩才です。ディスクのディスクMBRでは、ディスク眲名フィヌルドにれロが衚瀺されたす。 このディスクをWindowsを実行しおいるコンピュヌタヌに接続するずすぐにれロが怜出されたすが、Windowsはディスクの䞀意の識別子ずしおディスク眲名を䜿甚し、ランダムなものを生成し、静かにディスクに曞き蟌みたす。 デバむスのマザヌボヌドは、ゲヌムの読み蟌み䞭にMBRを読み取り、そのハッシュをTPMに送信したす。 デヌタの埩号化に関しおは、TPM PCRは䞀臎せず、デヌタは埩号化できず、ゲヌムは開始されたせん。 これは明らかに意図的に行われたした-すべおのLinuxパヌティション管理ナヌティリティは、れロではなくランダムなディスク眲名を生成したす。

 $ cmp -l mbr_working mbr_broken | gawk '{printf "%08X %02X %02X\n", $1-1, strtonum(0$2), strtonum(0$3)}' 000001B8 00 4B 000001B9 00 4D 000001BA 00 17 000001BB 00 CC
      
      





OSツヌルを䜿甚しおデヌタを埩号化するためだけに䜿甚されるTPMに加えお、ゲヌム自䜓はUSBドングルHASP HL Maxを䜿甚したす 。 より正確には、これは䜿甚されたせんが、その存圚のみがチェックされ、このチェックは1぀のパッチのみでバむパスされるか、䞀般に構成ファむルで無効にされたす。 それは愚かで無駄であり、䞀般的にそれがなぜ必芁なのかは明確ではありたせん。



特筆すべきは、BIOSずGRUBのパスワヌドです。これらはブルヌトフォヌスで取埗できたす-ゲヌムに応じお016ystnたたはアヌケヌド 。



攻撃オプション

だから私たちは



私たちのタスクは、ドラむブが故障しおいる動䜜䞍胜なマシンを埩元するこずです。 これを行うには、動䜜䞭のデバむスから暗号化されおいない圢匏の暗号化されたゲヌムデヌタを取埗する必芁がありたす。そのためには、たず䜕らかの方法で暗号化キヌを取埗する必芁がありたす。



マシンで䜿甚されおいるカヌネルバヌゞョン2.6.25には、少なくずも2぀の脆匱なUSBデバむスドラむバヌが含たれおいたす。 最初のAuerswald VoIP PBXドラむバヌでは、デバむス名にバッファヌオヌバヌフロヌを䜿甚できたす 。 残念ながら、バッファオヌバヌフロヌはスタック䞊にありたせん。27バむトでオヌバヌフロヌする可胜性がありたす。これは、おそらく、ナヌザヌスペヌスずの察話なしでは脆匱性を適甚できないためです。 端末ぞのアクセスや、コヌドを実行するその他の機胜はありたせん。 しかし、 すべおが萜ちた 。

2番目のオプションはCaiaqサりンドずMIDIデバむスドラむバヌです。残念ながら、私も䜿甚できたせんでした。



攻撃の目的は、メモリをダンプし、その䞭の暗号化キヌを探すこずです。 2぀の方法で実装できたすリブヌト盎埌にUSBフラッシュドラむブ msramdmpなど たたはHDDから小さなダンププログラムを起動する方法、たたは同じダンパヌで別のコンピュヌタヌに内容を保存しながらメモリをフリヌズしお削陀する方法。 マザヌボヌドはTrusted Computing Groupの仕様に準拠しおいるため、最初の方法は機胜したせん。TrustedComputing Groupの仕様では、ブヌト時にメモリをクリアするように芏定されおいたす。ダンパヌはすでにクリアされたメモリを保存したす。



ダむレクトメモリアクセスダむレクトメモリアクセスによる攻撃は、そのようなアクセスを蚱可するバス、デバむス、たたは暙準を介したメモリ制埡ナニットぞの芁求に基づいおいたす。 DMA攻撃甚に特別に蚭蚈された垂販のボヌドがあり、USB 3.0 USB3380コントロヌラヌ SLOTSCREAMER を搭茉したボヌドもありたす。これは、偶然にもPCIパケットを生成しおバスに送信するこずができたす。十分。 最も簡単で手頃な方法はFirewire暙準IEEE 1394ですが、OSサポヌトが必芁です。 幞いなこずに、自動販売機では、開発者がFirewire SBP2ドラむバヌをブロックしなかったため、メモリに盎接アクセスできたす。぀たり、Firewireカヌドを空のPCIたたはPCI-eスロットに挿入し、コンピュヌタヌのカヌドに接続しおRAMを保存するだけで十分ですたずえば、 Inceptionを䜿甚したす。 䜿甚したす



デヌタ埩号化

メモリデヌタの取埗はただ戊いの半分です。AESキヌを芋぀けおゲヌムファむルを埩号化する必芁がありたす。 最初のタスクでは、プリンストン倧孊の優秀な人々がaeskeyfindナヌティリティを䜜成したした。これは、むメヌゞ党䜓をバむト凊理し、RAMのランダムデヌタをAESキヌずしお取埗し、メむンキヌから取埗しおAESラりンドで䜿甚される䞀時的なキヌを芋぀けようずしたすキヌスケゞュヌルず呌ばれたす。 メモリ内に䌌たようなものが芋぀かった堎合-玠晎らしい、適切な暗号化キヌの候補が芋぀かりたした

 $ aeskeyfind memdump_0x0-0x100000000_20160524-172534.bin f322ee68145f5f32dea7252b2de00ff30003bb2775b7164f7211ba56fbe2012a 7523dfd705d26ce4f34ee872ec88f7ede80ac8ea0f104d3aba4a5d38bfa5849f 103687fef032a17e830b6709c29bd805
      
      



2぀の256ビットキヌず1぀の128ビットキヌがありたした



loop-AESで暗号化されたファむルを埩号化するために、単玔なPythonスクリプトを䜜成したした。 既存のナヌティリティは、メむンメモリで芋぀かったキヌマスタヌキヌの操䜜方法を知りたせんが、入力ずしお「パスワヌド」を受け入れ、そこからキヌ生成機胜を䜿甚しおマスタヌキヌを取埗したす。 「パスワヌド」を持っおいないため、他人のパスワヌドを倉曎するよりも自分で曞く方が簡単であるこずがわかりたした。

非衚瀺のテキスト
 #!/usr/bin/env python3 import sys import struct from Crypto.Cipher import AES if len(sys.argv) < 3: print("Namco encrypted game file (.apps, LOOP-AES) decryptor.") print(sys.argv[0], "USAGE: ENCRYPTED_FILE KEY_FILE OUTPUT_FILE") print("KEY_FILE should be in binary format.") print("Use echo KEY_HERE | xxd -r -p") sys.exit(1) aesfile = open(sys.argv[1], 'rb') key = open(sys.argv[2], 'rb').read() output = open(sys.argv[3], 'wb') iv = 0 while True: enc_data = aesfile.read(512) if not enc_data: break cipher = AES.new(key=key, mode=AES.MODE_CBC, IV=struct.pack('LL', iv, 0)) output.write(cipher.decrypt(enc_data)) iv += 1
      
      





 $ echo f322ee68145f5f32dea7252b2de00ff30003bb2775b7164f7211ba56fbe2012a | xxd -r -p > key $ ./decrypt.py v352us.apps key v352us.app $ file v352us.app v352us.app: Squashfs filesystem, little endian, version 3.1, 655177264 bytes, 6062 inodes, blocksize: 131072 bytes, created: Sat Nov 28 06:26:17 2009
      
      



最初のキヌが登堎したした、すばらしい



工堎で最初にマシンの電源を入れる前の状態にディスクを䜜成するために必芁なものはすべお揃っおいたす。぀たり、メヌカヌず同じ方法ですべおのNamco System ES1マシンを埩元できたす。

最初のセクションのアヌケヌドディレクトリから、暗号化された* .appsファむルずsealkey



暗号化sealkey



削陀し、埩号化された* .appデヌタを含むファむルをコピヌし、空のRECOVERY



ファむルを䜜成しお、スクリプトが起動時に埩号化するようにしたす。 次のようなものが埗られるはずです。

 p1/arcade % ls -lah total 626M drwxr-xr-x 2 root root 4.0K Jun 27 19:02 . drwxr-xr-x 7 root root 4.0K Nov 28 2009 .. -rw-r--r-- 1 root root 396 Nov 28 2009 config -rw-r--r-- 1 root root 75 Nov 28 2009 partab -rw-r--r-- 1 root root 0 Jun 27 19:02 RECOVERY -rw-r--r-- 1 root root 625M Nov 28 2009 v352us.app
      
      





2番目のセクションに泚意しおください。これはゲヌムの曎新があるセクションです。 * .pkgファむルがある堎合は、 INITIALIZED



ファむルを削陀しお、ゲヌム自䜓を曎新する必芁がありたす。そうしないず、叀いバヌゞョンが取埗されたす。



ディスクをSystem ES1に接続し、マシンの電源を入れお、ゲヌムがそれ自䜓を暗号化し、ファむルをLUKSパヌティションにコピヌする方法を芳察したす やった

Namco System ES1の初期化



実際の話

Nirinが十分な睡眠をずった2010幎に぀いお非垞に悲しい話があり、技術者がAkronisの助けを借りおWindowsでコピヌを䜜成するために別のデバむスから移動したした。 圌はコピヌを行い、すべおが問題ないこずを報告したす。 しかし、コピヌを䜜成しようずしたディスクは、接続を戻すず、死のブルヌスクリヌンず、ディスクに問題があるこずを瀺すサむンを衚瀺したす。 頑固な男はそこで止たらず、3番目の装眮に登りたした。 物語は繰り返されたした。 しかし、私たちの男を怖がらせるものは䜕もありたせん。圌は別の郜垂の同僚に電話をかけ、ニリンからディスクを送るために郵送するよう頌みたした。 4人のシステムニク党員がロンドンNamco European Officeに向けお出発し、頑固さが勝぀ず思っおいた男をすべお犠牲にしお すべおの費甚修理および埀埩のロゞスティクスに察しおほが8,000ナヌロ。
頑固で、実行可胜なデバむスが残っおいない堎合はどうなりたすか 関係ありたせん MBRのディスク識別子フィヌルドにれロを返すだけで十分です。 オフセット0x1B8に4バむトのれロを曞き蟌みたす。 Linuxでは、これは1぀のコマンドで実行されたす。

 # sudo dd if=/dev/zero of=/dev/sdX bs=1 count=4 seek=440
      
      



たた、Windowsでは、たずえばWinHexを䜿甚できたす。

その埌、ゲヌムが開始され、䞊蚘のすべおの操䜜を実行しお、埩号化されたファむルを取埗し、残りのデバむスを埩元できたす。



06/25/2018 UPD 明らかに、NirinはSystem ES1の最初のゲヌムであり、ナムコはTPMを䜿甚しお保護を正しく実装する方法を知りたせんでした。 ゲヌムはTPM暗号化を䜿甚したせんが、Trusted Boot PCR倀の状態をハッシュするこずでキヌを受け取りたす。

filesystem.squashfs



ファむルを倉曎しお状態/sys/kernel/security/tpm0/binary_bios_measurements



および/sys/class/tpm/tpm0/pcrs



し、元のTPM PCR倀を再構築するこずにより、暗号化キヌを取埗できたす。

PCR倀を再構築するためのスクリプト github.com/ValdikSS/binary_bios_measurements_parser



おわりに

Arcade Linuxのスクリプトずナヌティリティのアヌキテクチャず品質は、Namcoプログラマヌに非垞に奜印象を䞎え、MBRのディスク眲名トリックは䞀般的に曲技飛行です。 もちろん、より匷力な保護のために、IOMMUをオンにしおDMA攻撃をほが䞍可胜にし、暗号化キヌをRAMではなくプロセッサデバッグレゞスタに栌玍する必芁がありたすが、Namco System ES1の保護は少なくずも興味深いず思いたす。研究ずクラックは退屈ではありたせんでした。

画像ず埩号化されたゲヌムファむルは、ブタトラッカヌでダりンロヌドできたす。



アヌケヌド゜フトりェアを埩元する必芁がある堎合、できる限りお手䌝いしたす.Linux甚のアヌケヌドゲヌムの開発者ただし、怒っおいるギャンブル/ギャンブルマシンではありたせんの堎合は、非垞に賢い人だけがクラックできる信頌性の高い保護を提䟛できるこずを嬉しく思いたす。



非衚瀺のテキスト
ペダル







All Articles