เคอร์เนลแอนติชีตทำงานอย่างไร

• ระบบแอนติชีตที่ทำงานบนเคอร์เนล สมัยใหม่เป็นหนึ่งในซอฟต์แวร์ความปลอดภัยที่ซับซ้อนที่สุดบน Windows โดยเฝ้าตรวจหน่วยความจำและเหตุการณ์ของระบบในระดับเคอร์เนลแม้ระหว่างที่เกมกำลังรันอยู่
• ใช้เคอร์เนลไดรเวอร์เพื่อก้าวข้าม ข้อจำกัดของการป้องกันในโหมดผู้ใช้ และเฝ้าตรวจการสร้างโปรเซส·เธรด การโหลดอิมเมจ และการเปลี่ยนแปลงรีจิสทรีแบบเรียลไทม์
• ระบบหลักอย่าง BattlEye, EasyAntiCheat, Vanguard, FACEIT AC ทำงานด้วยสถาปัตยกรรม 3 ชั้นคือเคอร์เนลไดรเวอร์·บริการ·DLL ของเกม โดย Vanguard ซึ่งโหลดตั้งแต่บูตจะมีอำนาจควบคุมสูงที่สุด
• ผสานการป้องกันหลายชั้น เช่น การสแกนหน่วยความจำ การตรวจจับการฮุก การตรวจสอบความสมบูรณ์ของไดรเวอร์ การรับมือการโจมตี DMA และการตรวจจับตามพฤติกรรม เพื่อสกัดการโกง
• ท้ายที่สุด การยืนยันตัวตนระยะไกลด้วย TPM และการตรวจสอบความเชื่อถือได้ของฮาร์ดแวร์ กำลังก้าวขึ้นมาเป็นฐานสำคัญของความปลอดภัยในเกม

---

1. ข้อจำกัดของการป้องกันในโหมดผู้ใช้และการย้ายสู่เคอร์เนล

• โปรเซสในโหมดผู้ใช้มีสิทธิ์ต่ำกว่าเคอร์เนล จึงถูกบายพาสได้ง่ายด้วย ชีตระดับเคอร์เนลไดรเวอร์หรือไฮเปอร์ไวเซอร์
  • ตัวอย่าง: การเรียก ReadProcessMemory สามารถถูกปลอมแปลงได้ด้วยการฮุกในเคอร์เนล
• ชีตในโหมดเคอร์เนลสามารถแก้ไขหน่วยความจำของเกมได้โดยตรง และหลบเลี่ยงการตรวจจับจากโหมดผู้ใช้ได้
• เพื่อตอบโต้เรื่องนี้ แอนติชีตจึงย้ายลงมาทำงานในระดับเคอร์เนล เพื่อเฝ้าตรวจที่ระดับสิทธิ์เดียวกัน

2. ‘การแข่งขันทางอาวุธ’ ระหว่างชีตกับแอนติชีต

• การแข่งขันด้านการยกระดับสิทธิ์ยังดำเนินต่อเนื่องจากโหมดผู้ใช้ → เคอร์เนล → ไฮเปอร์ไวเซอร์ → DMA
• แอนติชีตรับมือด้วย การบล็อกไดรเวอร์ การตรวจจับไฮเปอร์ไวเซอร์ และการป้องกัน DMA บนพื้นฐาน IOMMU
• กระบวนการนี้เพิ่มต้นทุนและความยากในการสร้างชีต จน ช่วยกันผู้ใช้ทั่วไปออกจากการเข้าถึงได้

3. ระบบเคอร์เนลแอนติชีตหลัก

• BattlEye: มีเคอร์เนลไดรเวอร์ BEDaisy.sys เป็นแกนหลัก พร้อมลงทะเบียนคอลแบ็กสำหรับโปรเซส·เธรด·การโหลดอิมเมจ
• EasyAntiCheat(EAC): อยู่ภายใต้ Epic Games และใช้โครงสร้าง 3 ชั้นคล้ายกัน
• Vanguard: โหลด vgk.sys ตั้งแต่บูต และใช้ โมเดลไวต์ลิสต์ไดรเวอร์ เพื่อควบคุมอย่างเข้มข้น
• FACEIT AC: สร้างความน่าเชื่อถือสูงด้วยการเฝ้าตรวจระดับเคอร์เนล
• งานวิจัย ARES 2024 ระบุว่าระบบเหล่านี้มี โครงสร้างทางเทคนิคคล้ายรูทคิท แต่มีจุดประสงค์เพื่อการป้องกัน

4. โครงสร้าง 3 ชั้นของเคอร์เนลแอนติชีต

• เคอร์เนลไดรเวอร์: ทำ system call hooking, สแกนหน่วยความจำ และควบคุมการเข้าถึง
• บริการในโหมดผู้ใช้: ดูแลการสื่อสารเครือข่าย การจัดการแบน และการส่งเทเลเมทรี
• DLL ของเกม: ตรวจสอบภายในโปรเซสของเกม และทำ IPC กับบริการ
• สื่อสารกันผ่าน IOCTL, Named Pipe, Shared Memory

5. ความต่างระหว่างการโหลดตอนบูตกับการโหลดตอนรันไทม์

• BattlEye/EAC: โหลดไดรเวอร์เมื่อเปิดเกม และถอดโหลดเมื่อปิด
• Vanguard: โหลดตั้งแต่บูตและเฝ้าตรวจไดรเวอร์ทุกตัวที่โหลดหลังจากนั้น
  • ด้วยเหตุนี้จึง ต้องรีบูตระบบ และสามารถป้องกันได้ตั้งแต่ขั้นตอนบูต

6. การเฝ้าตรวจด้วยคอลแบ็กของเคอร์เนล

• ObRegisterCallbacks: ควบคุมการเข้าถึงแฮนเดิลของโปรเซส และบล็อกการเข้าถึงหน่วยความจำของโปรเซสจากภายนอก
• PsSetCreateProcessNotifyRoutineEx: บล็อกการสร้างโปรเซสของชีต
• PsSetCreateThreadNotifyRoutine: ตรวจจับเธรดผิดปกติภายในโปรเซสของเกม
• PsSetLoadImageNotifyRoutine: ตรวจจับการโหลด DLL ที่ไม่ได้รับอนุญาต
• CmRegisterCallbackEx: เฝ้าตรวจการเปลี่ยนแปลงรีจิสทรี
• มินิฟิลเตอร์ไดรเวอร์: บล็อกการเข้าถึงไฟล์ชีตในระดับระบบไฟล์

7. การป้องกันและสแกนหน่วยความจำ

• บล็อกการอ่าน/เขียนหน่วยความจำจากภายนอกด้วย การจำกัดการเข้าถึงแฮนเดิล
• ตรวจจับการแพตช์โค้ดด้วย การตรวจสอบแฮชของโค้ดเซกชัน
• ตรวจจับหน่วยความจำแบบ execute ที่ถูกแมปด้วยมือผ่าน การไล่ดู VAD tree
• ใช้ฮิวริสติกเพื่อระบุ หน่วยความจำ execute แบบไม่ระบุตัวตน, DLL ที่แมปด้วยมือ, และเชลล์โค้ด

8. การตรวจจับการฉีดโค้ด

• ตรวจจับเทคนิคการฉีดหลายแบบ เช่น CreateRemoteThread, APC, NtMapViewOfSection, Reflective DLL
• ตรวจสอบการรันโค้ดผิดปกติด้วย การวิเคราะห์สแต็กเฟรม (RtlWalkFrameChain)

9. การตรวจจับการฮุก

• IAT hooking: ตรวจจับการดัดแปลง import address table
• Inline hooking: ตรวจสอบว่ามีการแพตช์หรือไม่ด้วยการเปรียบเทียบคำสั่ง JMP ต้นฟังก์ชัน
• ป้องกันการฮุกระดับเคอร์เนลด้วย การตรวจสอบความสมบูรณ์ของ SSDT, IDT, GDT
• บล็อกความพยายามหลบ ntdll ด้วย การตรวจจับการใช้ syscall โดยตรง

10. การป้องกันระดับไดรเวอร์

• ตรวจจับ ไดรเวอร์ที่ไม่ได้ลงลายเซ็นและโหมด test signing
• ใช้บล็อกลิสต์เพื่อสกัดการโจมตีแบบ BYOVD(การนำไดรเวอร์เปราะบางมาใช้โจมตี)
• เฝ้าตรวจโครงสร้างภายในเคอร์เนลอย่าง PiDDBCacheTable, MmUnloadedDrivers, BigPool เพื่อตรวจจับไดรเวอร์ที่แมปด้วยมือ

11. การต้านดีบักและป้องกันการวิเคราะห์

• ตรวจสอบการมีอยู่ของดีบักเกอร์ด้วย NtQueryInformationProcess
• ตรวจจับเคอร์เนลดีบักเกอร์ด้วย ตัวแปร KdDebuggerEnabled
• ตรวจจับเธรดที่ถูกซ่อนด้วย แฟล็ก ThreadHideFromDebugger
• สกัดสภาพแวดล้อมการวิเคราะห์ด้วย การตรวจเวลาแบบอิง RDTSC, ฮาร์ดแวร์เบรกพอยต์ และ การมีอยู่ของไฮเปอร์ไวเซอร์

12. ชีตแบบ DMA และการรับมือ

• อุปกรณ์ PCIe DMA สามารถอ่านหน่วยความจำได้โดยไม่ต้องให้ CPU เข้ามาเกี่ยวข้อง
• IOMMU จำกัดการเข้าถึงของ DMA ได้ แต่ถ้าปิดใช้งานหรือตั้งค่าผิดก็อาจถูกทำให้ไร้ผล
• การที่ อุปกรณ์ FPGA ปลอมตัวเป็นอุปกรณ์ที่ถูกต้องตามกฎหมาย ทำให้ตรวจจับได้ยาก
• บรรเทาได้บางส่วนด้วย Secure Boot และ TPM 2.0 เพื่อยืนยันความสมบูรณ์ของการบูต

13. การตรวจจับตามพฤติกรรมและแมชชีนเลิร์นนิง

• แยกการเคลื่อนไหวของมนุษย์กับระบบเล็งอัตโนมัติด้วย การวิเคราะห์อินพุตเมาส์
• ตรวจจับ triggerbot และ aimbot ด้วย โมเดล CNN·Transformer
• ตรวจจับการโกงเป็นทีม เช่น วอลแฮ็กหรือการสมรู้ร่วมคิด ด้วย กราฟนิวรัลเน็ตเวิร์ก
• เทเลเมทรีไปป์ไลน์: จับอินพุตจากเคอร์เนล → ส่งแบบเข้ารหัส → วิเคราะห์ ML ที่เซิร์ฟเวอร์ → ตัดสินใจแบน

14. การหลบหลีกในสภาพแวดล้อมเสมือนและการวิเคราะห์

• ตรวจจับ VM ด้วย CPUID hypervisor bit และ vendor string
• ตรวจหาร่องรอยจากรีจิสทรีและอุปกรณ์ของ VMware, VirtualBox, Hyper-V
• สภาพแวดล้อม virtualized ซ้อนกันสองชั้น สามารถระบุได้จากความหน่วงในการรันคำสั่ง

15. การระบุฮาร์ดแวร์และการบังคับใช้การแบน

• สร้าง HWID จาก SMBIOS, ดิสก์, GPU, MAC, MachineGuid เป็นต้น
• แม้จะพยายาม ปลอม HWID ผ่านรีจิสทรี ไดรเวอร์ หรือการดัดแปลงทางกายภาพ
  แต่ก็ยังตรวจจับได้จากความไม่สอดคล้องของตัวระบุหรือรูปแบบที่ผิดปกติ

16. แนวโน้มในอนาคตและการเปลี่ยนผ่านทางเทคนิค

• หลังจาก DMA ขั้นต่อไปคือ ชีตที่อิงเฟิร์มแวร์ ซึ่งทำให้ตรวจจับได้ยากอย่างยิ่ง
• บอตเล็งที่ขับเคลื่อนด้วย AI บนฮาร์ดแวร์ แยกจากอินพุตมนุษย์ได้ยาก
• การยืนยันตัวตนระยะไกลด้วย TPM และคลาวด์เกมมิง กำลังกลายเป็นทางเลือกระยะยาว
• เคอร์เนลแอนติชีตยังคงเป็นแนวหน้าที่ใช้งานได้จริง แต่
  การตรวจสอบความเชื่อถือได้ของฮาร์ดแวร์และการตรวจสอบฝั่งเซิร์ฟเวอร์ ถูกเสนอให้เป็นทิศทางปลายทาง

[GN⁺]

ความคิดเห็นจาก Hacker News

• สรุปคือ โปรแกรมโกงสมัยใหม่ ใช้วิธีอย่างไฮเปอร์ไวเซอร์ การแพตช์ BIOS หรืออุปกรณ์ DMA เพื่อหลบเลี่ยงแอนตีชีต
  ยิ่งเพิ่มการป้องกันในระดับฮาร์ดแวร์มากเท่าไร ผู้สร้างโปรแกรมโกงก็ยิ่งพัฒนาไปตามนั้น
  แต่เมื่อมี การวิเคราะห์การเล่นด้วย AI วิธีตรวจจับตัวผู้โกงโดยตรงก็เริ่มได้ผล
  สุดท้ายแล้วอนาคตน่าจะอยู่ที่ แอนตีชีตในโหมดผู้ใช้ ไม่ใช่โหมดเคอร์เนล และการวิเคราะห์เกมเพลย์

  • การบอกว่าการแพตช์ BIOS “นิยมมาก” ฟังดูเกินจริง
    กลับกันมันดูเป็นหลักฐานว่าแอนตีชีตทำงานได้ดี
    เมื่อก่อนแค่ดาวน์โหลดโปรแกรมตัวเดียวก็โกงได้ทันที แต่ตอนนี้กำแพงในการเริ่มต้นสูงขึ้นจนหลายคนไม่คิดจะลองเลย
    แต่ต้นบทความก็พูดว่ามาตรการป้องกันแบบนี้อาจถูกทำให้ใช้ไม่ได้ แบบนั้นก็น่าตั้งคำถามว่าเชื่อถือได้จริงหรือไม่
  • ฉันเล่น WoW และมีเสียงบ่นเยอะว่า Blizzard แบนผู้ใช้ที่ไม่ได้ทำผิด
    ฉันเองก็เคยโดนแบนสองบัญชี แต่ติดต่อฝ่ายบริการลูกค้าแล้วปลดแบนได้
    แต่ดูเหมือนว่า AI จะถูกนำมาใช้กับงานซัพพอร์ต เลยคิดว่าน่าจะมีการแบนผิดพลาดเยอะ
    ระบบแบนตามพฤติกรรม แบบนี้เสี่ยงลงโทษแม้แต่ผู้เล่นที่ทุ่มเทจริง ๆ เลยยากจะเชื่อใจ
  • เทคโนโลยีที่คุณพูดถึงมีผลในการเพิ่มต้นทุนของการโจมตี
    กล่าวคือทำให้ไม่ใช่ใครก็ได้ที่จะสร้างโปรแกรมโกงได้ ดังนั้นแอนตีชีตก็ถือว่าประสบความสำเร็จในระดับหนึ่ง
    แต่ การวิเคราะห์เกมเพลย์ อาจจับได้แค่พวกโกงแบบโจ่งแจ้ง และมีโอกาสพลาดพวก ESP ธรรมดาได้มาก
  • การวิเคราะห์พฤติกรรมจับ ‘ผู้โกงแบบแนบเนียน’ ไม่ได้
    ผู้โกงแบบนี้อันตรายกว่า เพราะค่อย ๆ ทำลายคอมมูนิตี้อย่างช้า ๆ
  • ActiBlizz เป็นแทบจะบริษัทเดียวที่ดำเนินคดีกับผู้พัฒนาโปรแกรมโกงแบบเสียเงินอย่าง Bossland หรือ EngineOwning เป็นประจำ

• การไปแตะเคอร์เนลคือการ มองข้ามโมเดลความปลอดภัยทั้งระบบของ OS
  ในความเป็นจริงก็เคยมีกรณีที่แอนตีชีตที่มีบั๊กถูกยกระดับสิทธิ์ root ไปแล้ว
  ควรใช้ความสามารถ sandbox ของ OS และห่วงโซ่ความน่าเชื่อถือในขั้นตอนบูตให้ถูกต้อง

  • ระบบนิเวศ PC ไม่ได้จริงจังกับความปลอดภัยของ boot chain เท่ากับโทรศัพท์มือถือ
    เลยยากที่จะพึ่งพาความสามารถของ OS อย่างเดียว และ attestation เองก็มีขอบเขตการใช้งานที่จำกัดในทางปฏิบัติ
    ต่อให้ไม่สมบูรณ์แบบ แต่ถ้าลดจำนวนผู้โกงได้ในเชิงสถิติก็ยังมีความหมาย
  • ความปลอดภัยที่แท้จริงไม่ใช่การล็อกฝั่งไคลเอนต์ แต่คือ ตรวจสอบจากเซิร์ฟเวอร์ว่าอนุญาตเฉพาะพฤติกรรมที่ถูกต้องเท่านั้น
  • เลยอดสงสัยไม่ได้ว่า “นี่หมายถึงจะขาย PC แบบล็อกที่ติดตั้งได้เฉพาะซอฟต์แวร์ที่ผ่านการรับรองเท่านั้นหรือ”
  • ข้ออ้างว่า “พอผู้โจมตีเข้ามาได้แล้ว การลดความเสียหายก็ไม่มีความหมาย” นั้นไม่จริงใน โลกความมั่นคงปลอดภัยไซเบอร์โดยรวม
  • การจะหยุดโปรแกรมโกงถึงขั้นให้ทุกคนต้องเสียอิสระในการรันซอฟต์แวร์ที่ต้องการนั้นเกินไป

• อยากเห็นเกมที่มี ระบบจับคู่แบบเลือกใช้แอนตีชีตได้
  คนที่เปิดแอนตีชีตก็จับคู่กันเอง ส่วนคนที่ปิดก็ใช้โครงสร้างที่คอมมูนิตี้ดูแลกันเอง
  การทดลองแบบนี้น่าจะมีแค่บริษัทระดับ Valve ที่พอทำได้

  • CS2 ของ Valve ใช้วิธีคล้ายกัน แต่ได้ยินมาว่าอัตราการโกงสูงกว่า Valorant
  • จริง ๆ แล้ว FACEIT ก็ทำหน้าที่แบบนั้นอยู่แล้ว
    แต่การกำกับดูแลกันเองของคอมมูนิตี้ไม่มีทางมีประสิทธิภาพในสเกลใหญ่
  • ก็มีคนตอบว่า “นั่นมัน PlaySafe ID ไม่ใช่เหรอ”
  • ฉันก็เห็นด้วยกับไอเดียนี้
    ส่วนตัวคิดว่าถ้ามีคนโกงก็แค่ปิดเกมแล้ว ออกไปสูดอากาศข้างนอกยังดีกว่า
    แทนที่จะติดตั้งแอนตีชีตระดับเคอร์เนลที่ ‘เหมือนมัลแวร์’ ฉันว่ากลับไปเล่นคอนโซลดีกว่า

• โดยธรรมชาติแล้วผู้โกงจะมี รูปแบบพฤติกรรมที่ผิดปกติ ดังนั้นถ้าบันทึกอินพุตทั้งหมดบนเซิร์ฟเวอร์แล้วใช้ การตรวจจับความผิดปกติด้วยแมชชีนเลิร์นนิง ก็อาจจับได้
  อีกวิธีก็คือสร้างออบเจ็กต์แบบ ‘honeypot’ เพื่อหลอกให้เฉพาะผู้โกงตอบสนอง

  • แต่จะสรุปว่าเป็นผู้โกงจากความผิดปกติทางสถิติอย่างเดียวไม่ได้
    เหมือน p-hacking ที่อาจตีความความผันผวนโดยบังเอิญว่าเป็นสัญญาณที่มีความหมาย
  • ฉันเองก็สนับสนุน โมเดล honeypot เชิงสถิติ มานานแล้ว
    จริง ๆ Dota 2 ก็เคยแบนทุกบัญชีที่อ่านพื้นที่ข้อมูลผิดปกติภายในไคลเอนต์
    ประกาศแพตช์ที่เกี่ยวข้อง
  • แต่แม้แต่ Valve ก็ใช้โมเดล ML มานานแล้ว และใน Counter-Strike ก็ยังมีผู้โกงเยอะอยู่
    มันไม่ใช่ปัญหาที่แค่โยน ML เข้าไปแล้วจะจบ
  • Honeypot มีประโยชน์ แต่ไม่เพียงพอ
    การวิเคราะห์พฤติกรรม ตามการเปลี่ยนแปลงของคอมมูนิตี้ไม่ทันได้ยาก
  • ใน CS2 แค่สถิติ ‘time-to-damage’ ก็ใช้แยกผู้โกงได้จำนวนมากแล้ว
    ผู้โกงมักตอบสนองเร็วกว่าโปรประมาณ 100ms

• ฉันไม่ใช่เกมเมอร์ แต่คิดว่าปัญหา การป้องกันการโกง ในเกมออนไลน์เป็นโจทย์ยากที่น่าสนใจในเชิงเทคนิค
  คำแนะนำแบบง่าย ๆ ว่า “ให้ประมวลผลทุกอย่างบนเซิร์ฟเวอร์” ไม่สมจริง

  • การป้องกันการโกงแทบเป็นไปไม่ได้
    เกมไม่ใช่ โอลิมปิกแต่เหมือนลีกแถวบ้าน ความสนุกสำคัญกว่าความยุติธรรมที่สมบูรณ์แบบ
    ถ้าจับคู่ผู้โกงด้วยกันเอง ผลกระทบต่อผู้ใช้ทั่วไปก็จะลดลง
  • วิธีที่ได้ผลที่สุดคือให้ แอดมินเซิร์ฟเวอร์ที่ทำงานเชิงรุก คอยสังเกตและแบนเอง
    แต่บริษัทเกมขนาดใหญ่ไม่ค่อยมีคนทำงานแบบนี้
  • ในทางเทคนิค ผู้โกงได้เปรียบเสมอเพราะควบคุม เครื่อง ที่เกมกำลังรันอยู่
    แอนตีชีตทำได้แค่เพิ่มกำแพงในการเริ่มต้น
  • อาจเป็นไปได้ที่จะใช้โครงสร้างกระจายเซิร์ฟเวอร์ใกล้ ISP แบบ Netflix
  • ทางแก้ระดับรากคือ การเปลี่ยนมุมมองทางวัฒนธรรม
    ควรมีบรรยากาศที่มองคนโกงออนไลน์ว่าเป็น ‘พวกขี้แพ้’

• แอนตีชีตระดับเคอร์เนล เป็นแนวทางที่พยายามล็อกไคลเอนต์ให้มากที่สุด แต่ก็ยังมีผู้โกงอยู่
  สุดท้ายจึงแปลว่าเซิร์ฟเวอร์ไม่อาจเชื่อใจไคลเอนต์ได้อย่างสมบูรณ์

  • นี่ไม่ใช่แค่เรื่องต้นทุน แต่เป็นปัญหาเรื่อง latency และความต่างของมุมมองเวลา
    แม้แต่ network code ก็แก้ได้ไม่หมด
  • ถ้าผู้โกงมีความพยายามมากพอ ก็อาจใช้ กล้องกับคอมพิวเตอร์อีกเครื่อง เพื่อทำอินพุตอัตโนมัติได้

• วัฒนธรรมเกมแข่งขันทุกวันนี้คือโครงสร้างที่บริษัททำให้ผู้ใช้ต้องไปแข่งกับ คนแปลกหน้า แทนเพื่อน
  แต่ก็อดคิดไม่ได้ว่าจำเป็นต้องทำถึงขนาดนั้นไหม

  • ถึงอย่างนั้นคนจำนวนมากก็ สนุกกับการแข่งขันเอง
    การวัดฝีมือกันแบบกีฬาหรือหมากรุกเป็นความต้องการตามธรรมชาติของมนุษย์

• คำพูดที่ว่าเคอร์เนลแอนตีชีตคือ “ซอฟต์แวร์ที่ซับซ้อนที่สุด” ฟังดูเกินจริง
  การดัก system call ไม่ใช่เทคนิคพิเศษอะไร

  • ประโยคที่ว่า “สแกนโครงสร้างหน่วยความจำที่โปรแกรมเมอร์ส่วนใหญ่ทั้งชีวิตไม่เคยได้แตะ” ฟังดูขำ ๆ

• ดูเหมือนจะมีหลายคนที่ไม่เคยเล่นเกมแข่งขัน
  Kernel-level anti-cheat(KLAC) ใช้งานได้ผลจริง
  เมื่อเทียบกับระบบแบบ VAC/VACNet แล้ว แบบเคอร์เนลอย่าง FACEIT หรือ Vanguard มีอัตราการโกงต่ำกว่ามาก
  แน่นอนว่ามันไม่สมบูรณ์แบบ แต่ช่วยเพิ่ม กำแพงในการเริ่มต้น ได้มาก
  แค่อุปกรณ์ DMA ก็ราคาหลายร้อยดอลลาร์แล้ว และโปรแกรมโกงขั้นสูงก็มักเป็นแบบสมัครสมาชิกที่แพง
  เกมเป็นทางเลือก ดังนั้นถ้าไม่ชอบ KLAC ก็ไม่ต้องเล่น
  แต่ถ้าปฏิเสธมัน ก็ต้องยอมรับ สภาพแวดล้อมที่ผู้โกงระบาด

• ได้ยินมาว่า การวัดการบูตด้วย TPM และ UEFI Secure Boot ช่วยทำการยืนยันระยะไกลได้ แต่ก็น่าตกใจที่ผู้โจมตีอาจบิดเบือนมันได้

  • ตัวอย่างเช่น tee.fail อธิบายวิธีทำให้การยืนยันระยะไกลใช้การไม่ได้
    เราควรมีทั้ง อิสระที่จะเป็นเจ้าของอุปกรณ์ของตนอย่างแท้จริง และเสรีภาพที่จะไม่ถูกเลือกปฏิบัติ
  • การสื่อสารระหว่างเมนบอร์ดกับชิป TPM ไม่ได้เข้ารหัส จึงสามารถเปลี่ยนค่าได้ด้วย การโจมตีแบบ MITM