Phá vỡ giao diện điều khiển: một lịch sử ngắn gọn về bảo mật trò chơi điện tử

Bảo mật trong trò chơi điện tử luôn là một mục tiêu thay đổi không ngừng, khi các hệ máy chơi game phát triển thành những nền tảng điện toán hoàn chỉnh được khóa chặt bởi nhiều lớp bảo vệ — nhưng với mỗi chiếc khóa từng được tạo ra, luôn có một ai đó quyết tâm tìm cách mở nó.

Bản thân là một người hâm mộ trò chơi điện tử, tôi chưa bao giờ nghĩ nhiều về điều này cho đến khi trở thành kỹ sư và bắt đầu tìm hiểu sâu về bảo mật. Về cốt lõi, các hệ máy chơi game là các hệ thống nhúng (embedded systems), và lịch sử về cách bảo mật của chúng được xây dựng, bẻ khóa và xây dựng lại chứa đầy những bài học có thể áp dụng ngoài phạm vi phòng khách của chúng ta.

Trong bài viết này, chúng ta sẽ đi ngược dòng lịch sử bảo mật của máy chơi game, từ những ngày đầu khi hầu như không có bất kỳ sự bảo vệ nào, trải qua hàng thập kỷ với các biện pháp phòng thủ ngày càng tinh vi, cho đến các hệ thống hiện đại sử dụng nhiều kỹ thuật giống như các thiết bị nhúng nhạy cảm về bảo mật — đồng thời cho thấy cách mà các nhà nghiên cứu và những người đam mê vẫn liên tục tìm ra những lỗ hổng dù cho các lớp phòng thủ đó vững chắc đến đâu.

Tôi sẽ tập trung chủ yếu vào các máy chơi game tại gia thay vì các hệ máy cầm tay, ngoại trừ Nintendo Switch vì nó nằm ở vị trí giao thoa giữa cả hai danh mục. Để giữ cho bài viết có độ dài hợp lý, tôi sẽ không cố gắng bao phủ mọi lỗ hổng hoặc mã khai thác đã được công bố. Thay vào đó, tôi sẽ tập trung vào một số ví dụ tiêu biểu và phổ biến nhất. Vì lý do tương tự, tôi sẽ không đi sâu vào chi tiết kỹ thuật của mọi cuộc tấn công, nhưng tôi sẽ cung cấp tài liệu tham khảo và liên kết nếu có thể cho những độc giả muốn tìm hiểu sâu hơn.

Mục tiêu của tôi là cho thấy cách bảo mật đã phát triển như thế nào trong ngành công nghiệp trò chơi điện tử và những gì chúng ta có thể học được từ quá trình phát triển đó. Cuối cùng, dù chúng ta đang thiết kế một máy chơi game, một thiết bị y tế hay một hệ thống công nghiệp, mô hình đe dọa có thể khác nhau, nhưng nhiều thách thức bảo mật cơ bản lại vô cùng tương đồng.

Vậy nên hãy bắt đầu thôi!

Miền tây hoang dã: khi không có ổ khóa nào trên cửa

Những máy chơi game tại gia đời đầu, như Atari 2600 (1977), về cơ bản là không có bảo mật. Phần cứng không có cơ chế nào để xác minh xem băng trò chơi có chứa phần mềm hợp pháp hay không. Bất kỳ chip ROM nào được nối với đúng đầu kết nối đều sẽ chạy. Rào cản thực sự duy nhất là về vật lý và kinh tế: bạn cần có phần cứng để sản xuất một băng trò chơi.

Nguồn: Wikipedia

Kỷ nguyên Atari 2600 là miền tây hoang dã của trò chơi điện tử. Không có ký mã (code signing), không có xác minh bằng mật mã, và không có kế hoạch khóa vùng (region-locking) có chủ đích — mặc dù sự khác biệt về tiêu chuẩn NTSC/PAL/SECAM giữa các khu vực vẫn ảnh hưởng đến tính tương thích.

Các nhà phát hành bên thứ ba như Activision nổi tiếng là được thành lập bởi chính các kỹ sư của Atari, những người đã rời đi để tạo ra các trò chơi của riêng họ, bởi vì về mặt kỹ thuật không có gì ngăn cản họ làm điều đó. Lựa chọn duy nhất của Atari là hành động pháp lý, chứ không phải các kiểm soát kỹ thuật.

Điều này đã thay đổi với sự xuất hiện của Nintendo Entertainment System (NES) vào năm 1985, hệ máy đã đưa ra nỗ lực nghiêm túc đầu tiên trong việc kiểm soát phần mềm bằng phần cứng. Điều đó hoạt động như thế nào, và nó kéo dài bao lâu?

Chip khóa phần cứng và 10NES

Bị tổn thương bởi cuộc khủng hoảng trò chơi điện tử Bắc Mỹ năm 1983, một phần do thị trường tràn ngập các tựa game kém chất lượng, Nintendo đã xuất xưởng NES với một IC bảo mật chuyên dụng gọi là 10NES (sau này được biết đến với tên gọi CIC, hay Checking Integrated Circuit), có mặt trên cả máy chơi game và mọi băng trò chơi được cấp phép.

Nguồn: Wikipedia

Chip này là một hệ thống xác thực dạng thách thức-phản hồi (challenge-response): một chip 10NES bên trong máy chơi game sẽ liên lạc với một chip 10NES tương ứng bên trong mỗi băng trò chơi được cấp phép. Nếu quá trình bắt tay xác thực thất bại, máy chơi game sẽ liên tục khởi động lại (mỗi giây một lần), tạo ra hiện tượng màn hình nhấp nháy khét tiếng.

Nguồn: Trang web của Fabien Sanglard

Cả hai chip đều là các bộ vi điều khiển 4-bit giống hệt nhau (Sharp SM590) chạy cùng một firmware, nhưng hoạt động trong các vai trò khác nhau, được cấu hình thông qua chân CONF trong sơ đồ trên. Chip trong máy chơi game đóng vai trò là chủ (master, CONF=1), còn chip trong băng trò chơi đóng vai trò là tớ (slave, CONF=0).

Khi bật nguồn, hai chip đồng bộ hóa qua một đường xung nhịp và dữ liệu chung, sau đó bắt đầu trao đổi một chuỗi bit giả ngẫu nhiên được tạo ra bởi một thanh ghi dịch nội bộ. Chip của máy chơi game điều khiển xung nhịp và liên tục so sánh đầu ra của chip trên băng trò chơi với chuỗi bit dự kiến của riêng nó. Miễn là cả hai chip vẫn đồng bộ - nghĩa là băng trò chơi chứa một chip 10NES chính hãng chạy cùng chương trình - quá trình xác thực sẽ thành công và máy chơi game sẽ khởi động bình thường. Nếu các chuỗi bit khác biệt tại bất kỳ thời điểm nào, chip của máy chơi game sẽ kéo đường reset xuống mức thấp, gây ra hiện tượng khởi động lại (và màn hình nhấp nháy).

Quan trọng là, không có khóa bí mật nào liên quan — cả hai chip đều chạy thuật toán hoàn toàn giống nhau, và bảo mật hoàn toàn dựa vào việc thuật toán đó không được biết đến và khó trích xuất từ silicon. Đây chính là hình thức thuần túy nhất của "bảo mật thông qua sự mơ hồ" (security through obscurity)!

Đây cũng là lần sử dụng rộng rãi đầu tiên của xác thực phần mềm dựa trên phần cứng trong một thiết bị tiêu dùng. Và nó đã khóa hiệu quả các băng trò chơi không được cấp phép - ít nhất là trong một thời gian, bởi vì 10NES đã bị kỹ thuật đảo ngược khá nhanh chóng…

Tengen, công ty con phát hành trò chơi của Atari, đã nổi tiếng với việc thực hiện kỹ thuật đảo ngược chip này và sản xuất bản sao của riêng họ (Rabbit) để tạo ra các băng NES không được cấp phép. Vâng, bạn đọc đúng rồi đó, Atari đã hack Nintendo! Điều này dẫn đến vụ kiện mang tính bước ngoặt Atari Games Corp. kiện Nintendo of America (1992).

Trong khi đó, cộng đồng homebrew phát hiện ra rằng việc vô hiệu hóa vật lý chip CIC bằng cách cắt các chân cụ thể trên chip bên trong máy chơi game sẽ ngăn nó kéo đường reset xuống mức thấp, cho phép máy chơi game khởi động bất kể loại băng nào được cắm vào.

Một số nhà sản xuất không chính thức còn đi xa hơn, sử dụng một cú sốc điện áp để tắt CIC ngay trong quá trình xác thực trước khi nó kịp kéo đường reset xuống — một ví dụ thô sơ, sớm sủa về tấn công tiêm lỗi (fault injection attack), cùng loại kỹ thuật phần cứng sau này sẽ được sử dụng để đánh bại chuỗi khởi động mật mã của Xbox 360.

Nintendo đã áp dụng phương thức CIC xuyên suốt ba thế hệ máy chơi game dùng băng — NES, Super NES, và Nintendo 64 — liên tục cải tiến chip qua từng phiên bản để gây khó khăn cho việc sao chép. Tuy nhiên, điểm yếu cơ bản chưa bao giờ thay đổi, vì xác thực chỉ thuần túy dựa trên sự hiện diện vật lý của một con chip tương thích, mà không có bất kỳ xác thực mật mã nào đối với mã nguồn thực tế của trò chơi. Một khi hiểu được giao thức, bạn có thể sao chép hoặc vượt qua con chip đó. Chỉ đến khi GameCube (2001) ra đời, từ bỏ băng để chuyển sang sử dụng đĩa miniDVD độc quyền, Nintendo mới thực sự từ bỏ mô hình CIC.

Kỷ nguyên này đã thiết lập một mô hình lặp đi lặp lại trong nhiều thập kỷ: một biện pháp bảo mật dựa trên sự mù mờ hoặc tính sẵn có của phần cứng, theo sau là kỹ thuật đảo ngược, và cuối cùng là bị bẻ khóa. Vậy quá trình chuyển đổi sang phương tiện lưu trữ quang học đã thay đổi cuộc chơi như thế nào?

Đĩa quang và sự ra đời của modchip

Máy PlayStation (1994) đã chuyển từ băng sang CD-ROM, và Sony biết rằng các ổ đĩa CD-R ngày càng rẻ khiến vi phạm bản quyền trở thành một mối đe dọa nghiêm trọng. Vì vậy, họ đã tạo ra một sơ đồ bảo vệ bản quyền tập trung vào hai ý tưởng liên kết: firmware của ổ đĩa tìm kiếm tín hiệu xác thực SCEx dành riêng cho khu vực được mã hóa trong một vùng đĩa không tiêu chuẩn gần phần lõi đĩa, và các mã định danh khu vực/cấp phép của đĩa phải khớp với thị trường của máy chơi game. Về cơ bản, toàn bộ biện pháp bảo vệ dựa vào một định dạng phương tiện tùy chỉnh mà các đầu ghi CD phổ thông không thể tái tạo lại.

Điều này tạo ra một bề mặt tấn công mới và góp phần phổ biến một loại sửa đổi phần cứng mới được gọi là modchip. Một chiếc modchip PlayStation điển hình là một vi điều khiển nhỏ được hàn lên bo mạch chủ, có chức năng đánh lừa chuỗi xác thực SCEx, cho phép ổ đĩa chấp nhận các loại đĩa sao chép hoặc đĩa không đúng khu vực.

Nguồn: Blog của Kevin Chung

Hàng chục thiết kế modchip đã xuất hiện chỉ trong vòng một năm kể từ khi máy chơi game này ra mắt, nhiều thiết kế không yêu cầu gì hơn ngoài việc hàn vài sợi dây vào các điểm nhất định trên bo mạch.

Ngoài modchip, PlayStation còn dễ bị tổn thương trước trò swap trick (tráo đĩa) khét tiếng: khởi động bằng một đĩa hợp lệ, giữ cho cảm biến nắp mở, và tráo sang đĩa chép sau khi quá trình xác thực ban đầu hoàn tất.

Bài học rút ra rộng hơn là biện pháp bảo vệ chính của PlayStation nằm ở tầng xác thực đĩa, mà không có xác thực mật mã đối với mã nguồn được tải vào bộ nhớ. CPU sẽ thực thi bất cứ thứ gì đĩa chứa. Việc vượt qua bước kiểm tra đĩa là đủ để chạy bất kỳ thứ gì.

Máy PlayStation 2 (2000) đã nâng cao tiêu chuẩn đôi chút với sơ đồ xác thực ổ đĩa mạnh mẽ hơn, nhưng cuối cùng nó vẫn có thể bị đánh bại bằng modchip và chiêu tráo đĩa. Cách tiếp cận bảo mật chỉ dựa trên đĩa này không phải là duy nhất của Sony: Sega Saturn dựa vào xác thực dựa trên đĩa tương tự, và ngay cả Nintendo GameCube cũng sử dụng định dạng miniDVD độc quyền làm rào cản chính. Không thiết bị nào trong số này cố gắng xác thực bằng mật mã mã nguồn mà chúng thực thi — sự bảo vệ chỉ dừng lại ở ổ đĩa quang. Chỉ cần vượt qua bước kiểm tra đĩa, CPU sẽ không đặt thêm câu hỏi nào nữa.

Máy Sega Dreamcast xứng đáng được nhắc đến riêng biệt, vì sự bảo vệ của nó không chỉ dựa vào việc kiểm tra xác thực đĩa đơn thuần. Nó kết hợp định dạng độc quyền GD-ROM, hỗ trợ định dạng MIL-CD và một sơ đồ xáo trộn tệp thực thi. Trên thực tế, máy chơi game này đã bị xâm phạm khi những người đam mê học cách lạm dụng đường dẫn khởi động MIL-CD và tái tạo logic xáo trộn, cho phép phần mềm khởi động từ các đĩa CD-R thông thường.

Cuối cùng, việc bảo vệ phương tiện lưu trữ sẽ không bao giờ là đủ. Bước tiếp theo là bảo vệ chính mã nguồn.

Ký mã xác thực mật mã xuất hiện trên máy chơi game

Máy Xbox gốc (2001) được xây dựng dựa trên phần cứng PC quen thuộc (dòng Pentium III, GPU Intel, ổ cứng tiêu chuẩn), chạy một hệ điều hành rút gọn bắt nguồn từ Windows 2000. Đây là một trong những máy chơi game gia đình lớn đầu tiên triển khai chuỗi tin cậy mật mã bắt nguồn từ một khối khởi động ẩn bên trong MCPX. Khối khởi động đó giải mã và xác minh một bộ nạp khởi động (bootloader) bên ngoài, từ đó lại giải mã và xác minh nhân (kernel). Sau đó, nhân sẽ thực thi việc kiểm tra chữ ký trên phần mềm mà nó tải vào.

Andrew “bunnie” Huang là một trong những nhà nghiên cứu đầu tiên và có tầm ảnh hưởng nhất trong việc đảo ngược kiến trúc bảo mật của Xbox, ghi lại công trình của mình trong một bản ghi nhớ tại MIT năm 2002 và sau đó là trong Hacking the Xbox: An Introduction to Reverse Engineering — và đúng vậy, nó được tải xuống miễn phí, nên hãy tải ngay một bản nhé! 😉

Ông đã chỉ ra rằng ROM khởi động ẩn của Xbox có thể được khôi phục bằng cách kết nối vào bus HyperTransport, vì mã khởi động đi qua bus đó dưới dạng không mã hóa. Việc làm này không yêu cầu phải tháo vỏ chip, nhưng cần có phần cứng dò bus dựa trên FPGA tùy chỉnh và quyền truy cập vật lý vào bo mạch chủ.

Nguồn: Hacking the Xbox

Việc khôi phục ROM khởi động đã phá vỡ sự bí mật của gốc tin cậy phần cứng (hardware root of trust) của máy: các nhà nghiên cứu giờ đây có thể tái tạo logic giải mã bộ nạp khởi động và vật liệu khóa, cho phép phân tích sâu hơn về chuỗi khởi động và cuối cùng giúp tạo ra mã khởi động thay thế, chẳng hạn như Cromwell.

Việc ký mã nguồn đã nâng cao đáng kể tiêu chuẩn bảo mật, nhưng nó không bảo vệ được trước các lỗi an toàn bộ nhớ trong chính mã nguồn đã được ký!

Tràn bộ đệm và một chú ngựa tên Epona

Các tệp lưu game (save file) hóa ra lại là một vectơ tấn công hiệu quả đến bất ngờ. Một vài trò chơi Xbox gốc — MechAssault, Splinter Cell, và 007: Agent Under Fire — có các trình phân tích tệp lưu game không xác thực được độ dài dữ liệu đầu vào. Một tệp lưu game được tạo thủ công có thể gây tràn bộ đệm và giành quyền thực thi mã trong tiến trình của trò chơi. Và vì các trò chơi Xbox chạy ở chế độ nhân (kernel mode), một trò chơi có thể khai thác đồng nghĩa với việc kiểm soát toàn bộ hệ thống.

Những cuộc tấn công này được gọi là softmod.

Nintendo Wii (2006) đã lặp lại kịch bản tương tự. Twilight Hack đã khai thác lỗ hổng tràn bộ đệm stack trong trò chơi The Legend of Zelda: Twilight Princess, được kích hoạt bởi một tệp lưu (save file) được thiết kế đặc biệt chứa tên quá dài cho Epona, con ngựa của Link. Lỗ hổng đó cho phép Wii thực thi mã homebrew từ thẻ SD, và nó trở thành một trong những con đường đầu tiên được sử dụng rộng rãi để cài đặt Homebrew Channel. Sau này, các công cụ tiên tiến hơn như BootMii đã đẩy quyền kiểm soát đi sâu hơn nữa vào quy trình khởi động.

Bài học rút ra rất rõ ràng: việc bảo mật chuỗi khởi động trong khi vẫn để các ứng dụng đáng tin cậy tự do phân tích dữ liệu đầu vào không an toàn chỉ làm chuyển dịch bề mặt tấn công. Thế hệ console thứ bảy đã cố gắng giải quyết vấn đề này một cách hệ thống hơn — nhưng lại tự phát sinh những vấn đề mới.

Khi khởi động an toàn (secure boot) thất bại

Thế hệ console thứ bảy — PlayStation 3 (2006), Xbox 360 (2005) và Wii (2006) — đều sử dụng nhiều mật mã bất đối xứng để thực thi việc ký mã (code signing). Chỉ phần mềm được ký bằng khóa riêng (private key) của nhà sản xuất mới được chấp nhận thực thi. Lý thuyết thì rất ổn, nhưng quá trình triển khai thì không được như vậy.

“JTAG/SMC Hack” là một trong những cuộc tấn công đầu tiên và tinh vi nhất nhắm vào cơ chế khởi động an toàn của Xbox 360, kết hợp nhiều bề mặt tấn công để đạt được việc thực thi mã chưa ký. Cuộc tấn công liên quan đến việc nạp lại NAND bằng một image được chế tạo chứa firmware SMC đã sửa đổi, một bộ nạp khởi động (bootloader) cũ và một kernel cũ có lỗ hổng, sau đó sử dụng giao diện JTAG bị lộ để chuyển hướng thực thi vào kernel cũ đầy lỗ hổng đó.

Những sai lầm trong thiết kế chính của Microsoft là để hở giao diện gỡ lỗi JTAG và kích hoạt nó trong một khoảng thời gian ngắn trong quá trình khởi động, mặc định tin tưởng firmware SMC như một thành phần không được kiểm chứng nằm ngoài chuỗi khởi động an toàn, và cung cấp khả năng bảo vệ chống hạ cấp yếu kém, cho phép thực hiện các cuộc tấn công hạ cấp (downgrade attacks). Vectơ tấn công này đã được đóng lại sau đó bằng một bản cập nhật phần mềm, giới thiệu các biện pháp bảo vệ chống hạ cấp mạnh mẽ hơn và ngăn cản console khởi động kernel cũ có lỗ hổng.

Một cuộc tấn công phần cứng cơ bản hơn đã xuất hiện vào năm 2011: Reset Glitch Hack (RGH), được phát triển bởi GliGli và Tiros. RGH sử dụng một cú "glitch" reset được canh thời gian chính xác — thường kết hợp với việc làm chậm xung nhịp CPU tạm thời — để bỏ qua bước so sánh hash của bootloader, cho phép bootloader giai đoạn tiếp theo đã bị sửa đổi được chạy. Một cuộc tấn công tiêm lỗi (fault-injection) cổ điển, có thể tái lập với phần cứng giá rẻ (hình dưới), không thể khắc phục bằng phần mềm. Microsoft chỉ giải quyết được vấn đề này ở các phiên bản phần cứng sau đó của console.

Nguồn: Le blog de Chip’n Modz

Câu chuyện về PlayStation 3 thậm chí còn mang tính giáo huấn hơn về mặt mật mã học. Sony đã sử dụng ECDSA để ký các phần mềm quan trọng của PS3, và ECDSA yêu cầu một nonce mới, không thể dự đoán cho mỗi chữ ký. Nếu tái sử dụng nonce đó, khóa ký riêng có thể được khôi phục bằng đại số chỉ từ các chữ ký. Thất bại của Sony còn vượt xa việc sử dụng các giá trị ngẫu nhiên yếu — quá trình triển khai đã sử dụng một hằng số: cùng một số cố định làm nonce trong mọi chữ ký. Đó là điều mà nhóm nghiên cứu bảo mật fail0verflow đã tiết lộ tại buổi nói chuyện có tiêu đề “PS3 Epic Fail” tại sự kiện 27C3 vào tháng 12 năm 2010, giúp việc khôi phục khóa trở nên đơn giản từ bất kỳ hai chữ ký nào.

Nhà nghiên cứu George Hotz (được biết đến với biệt danh geohot) sau đó đã công khai khóa ký riêng của Sony, giúp có thể ký mã tùy ý như mã hợp lệ trên các console PS3 tin tưởng vào khóa đó. Sony đã kiện và sau đó đạt được thỏa thuận dàn xếp, nhưng vấn đề về cơ bản rất khó giải quyết vì khóa đã được nhúng vào trong quá trình triển khai root-of-trust và không thể dễ dàng thu hồi!

Sự cố này đã trở thành một trong những ví dụ nổi tiếng nhất về lỗi triển khai mật mã thảm khốc. Thuật toán thì ổn, nhưng cách triển khai thì không. Các con số ngẫu nhiên rất quan trọng trong nhiều lĩnh vực của khoa học máy tính, bao gồm (và đặc biệt là) mật mã. Để tìm hiểu thêm về nó, hãy xem bài viết giới thiệu về số ngẫu nhiên của tôi.

Cuối cùng, đây là một quá trình học hỏi cho cả những kẻ tấn công và những người thiết kế. Các cuộc tấn công liên tục đẩy xa ranh giới, và các nhà thiết kế rút ra bài học từ những sai lầm để cải thiện bảo mật. Nhưng liệu điều đó có thực sự cải thiện trên các bản phát hành console mới nhất?

Bảo mật hơn là bảo mật tốt hơn?

Máy Nintendo Switch nguyên bản (2017) được xây dựng dựa trên Tegra X1 của Nvidia, có root-of-trust cho khởi động an toàn được thực hiện trong mã BootROM, giống như thường thấy trên các SoC hiện đại. Vào năm 2018, nhà nghiên cứu bảo mật Kate Temkin và nhóm ReSwitched đã công bố fusée gelée (CVE-2018-6242), một lỗ hổng tràn bộ đệm trong trình xử lý USB Recovery Mode của bootROM.

Việc kích hoạt lỗ hổng chỉ cần một đoạn dây nhỏ để nối tắt hai chân trên đầu nối Joy-Con bên phải (để vào chế độ RCM) và kết nối USB với PC hoặc một dongle nhỏ. Bằng cách gửi một gói truyền dữ liệu USB điều khiển quá kích thước, kẻ tấn công có thể làm tràn bộ đệm, ghi đè lên địa chỉ trả về của trình xử lý RCM trên stack, và chuyển hướng thực thi đến mã tùy ý trong SRAM, trước khi bất kỳ bước xác minh chữ ký nào diễn ra.

Vì lỗ hổng nằm trong mask ROM, Nintendo không thể vá nó trên hàng triệu máy Switch đã bán ra thị trường. Bất kỳ máy Switch nào sử dụng chip Tegra X1 gốc đều bị ảnh hưởng vĩnh viễn. Nintendo buộc phải khắc phục nó trong các phiên bản phần cứng sau này như Tegra X1+ (tên mã Mariko).

Vì tò mò, có những ví dụ khác về lỗ hổng trong việc triển khai root-of-trust từ ngành công nghiệp nhúng, giống như lỗ hổng được tìm thấy trên các chip NXP iMX6.

Về phía PlayStation 4 (2013), tính đến thời điểm viết bài này, chưa có cuộc tấn công công khai nào vào root-of-trust phần cứng được ghi nhận rộng rãi, nhưng nhiều khai thác thực thi mã từ xa đã được công bố cho phép phần mềm không được phép chạy sau khi khởi động bình thường.

Một ví dụ nổi tiếng đã sử dụng lỗ hổng WebKit để thực thi mã trong tiến trình trình duyệt, sau đó sử dụng khai thác kernel để thoát khỏi sandbox và giành quyền kiểm soát ở cấp kernel. Một cuộc tấn công lớn khác, PPPwn, nhắm vào stack mạng Ethernet/PPPoE của máy chơi game và khai thác lỗ hổng trong quá trình triển khai PPPoE để thực thi mã kernel từ xa.

Vì đây là những cuộc tấn công ở lớp phần mềm thay vì phá vỡ công khai gốc tin cậy phần cứng (hardware root of trust), Sony có thể giảm thiểu chúng thông qua các bản cập nhật firmware. Theo thời gian, các phiên bản firmware mới hơn đã thu hẹp bề mặt tấn công và đóng lại nhiều con đường khai thác đã được công khai.

Giờ đây, sau ba thập kỷ của các vụ hack, khai thác, lỗi và khôi phục khóa — chúng ta có thể học được gì từ đó?

Bài học từ ba thập kỷ bảo mật máy chơi game

Nếu nhìn vào một máy chơi game hiện đại — PS5 hoặc Xbox One và Xbox Series — nó có tất cả các biện pháp giảm thiểu mà bạn mong đợi từ một thiết bị nhúng bảo mật được thiết kế tốt: khởi động an toàn (secure boot), mã hóa toàn bộ ổ đĩa, cách ly thông qua hypervisor, hệ thống cập nhật mạnh mẽ để vá lỗ hổng, và nhiều thứ khác. Tuy nhiên, nếu có đủ tài nguyên và động lực, các hệ thống đủ phức tạp cuối cùng đều sẽ bị khai thác.

Ví dụ, có những lỗ hổng và chuỗi khai thác đã được công khai cho PS5. Hai ví dụ nổi tiếng là chuỗi khai thác BD-J được báo cáo qua HackerOne, kết hợp năm lỗi để thực thi các payload tùy ý, và Byepervisor, một bản khai thác hypervisor PS5 công khai cho firmware 1.xx–2.xx.

Đối với các nền tảng Xbox hiện đại, công trình công khai năm 2024 đã phơi bày khai thác kernel SystemOS trên cả Xbox One và Xbox Series, trong khi cuộc tấn công voltage-glitch vào boot-ROM Bliss năm 2026 đã được trình bày công khai cho chiếc Xbox One nguyên bản.

Theo thời gian, các nhà sản xuất máy chơi game đã học được rằng chỉ các biện pháp giảm thiểu kỹ thuật là không đủ. Vì vậy, họ đã thêm việc khóa dịch vụ (service lock-in) như một biện pháp bổ sung. Ví dụ, nếu bạn jailbreak PS4, bạn sẽ mất quyền truy cập vào PlayStation Network. Đối với những người dùng coi trọng chơi game trực tuyến, cái giá đó vượt xa bất kỳ lợi ích nào từ việc chạy mã không chính thống (unsigned code).

Cuối cùng, bài học rất đơn giản: bảo mật không phải là một tính năng bạn thêm vào sản phẩm; nó là thuộc tính trong kiến trúc của sản phẩm đó. Những sản phẩm có tính bảo mật bền vững nhất là những sản phẩm được xây dựng dựa trên hai nguyên tắc cơ bản: phòng thủ theo chiều sâu (defense in depth) và bảo mật theo thiết kế (security by design), được áp dụng theo cách nhất quán với mô hình đe dọa của hệ thống.

Tôi hy vọng bạn thích chuyến hành trình xuyên suốt lịch sử bảo mật máy chơi game điện tử này — cá nhân tôi chắc chắn đã rất vui khi viết nó.

Vui lòng gửi nhận xét hoặc câu hỏi của bạn qua email tới địa chỉ hello tại sergioprado.blog, hoặc đăng ký bản tin để nhận cập nhật.

Xem thêm

• Số ngẫu nhiên là gì và cách quản lý chúng trên Linux?
• Giới thiệu về TPM (Trusted Platform Module)
• RPMB, một nơi bí mật bên trong eMMC
• Giới thiệu về quản lý SBOM trên Linux nhúng
• Mã hóa khóa bất đối xứng và chữ ký số trong thực tế