การวิเคราะห์วิศวกรรมย้อนกลับของระบบแอนตีชีต Call of Duty

 (ssno.cc)
1 คะแนน โดย GN⁺ 2025-01-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • TAC (Treyarch Anti-Cheat) ของ Black Ops Cold War เป็นแอนตีชีตแบบผู้ใช้โหมดที่ไม่มีไดรเวอร์เคอร์เนลของ Ricochet แต่มีโครงสร้างโค้ดที่คล้ายกับ Call of Duty รุ่นใหม่อยู่มาก
  • ชั้นการป้องกันใช้ทั้งการเข้ารหัสไฟล์รัน, checksum, การทำให้ jmp อ่านยาก, การทำให้ entry point อ่านยากของ Arxan ร่วมกับการเข้ารหัสพอยน์เตอร์แบบสาย Treyarch/IW
  • TAC ทำการ ตรวจจับในผู้ใช้โหมด หลายแบบ เช่น การค้นหา API hash ตอนรันไทม์, ตรวจรูปแบบ API hook, ตรวจ debug register, ตรวจ Windows test signing, ตรวจการสร้างคอนโซล, ตรวจ DirectX/overlay
  • สำหรับ overlay ภายนอก ระบบจะเก็บสไตล์หน้าต่าง, ตำแหน่ง, display affinity, รายการโมดูลของโปรเซส แล้วอัปโหลดไปยังเซิร์ฟเวอร์ ส่วนตัวสแกนหน่วยความจำอย่าง Cheat Engine สามารถถูกตรวจจับได้ด้วย virtual memory honeypot
  • เทคนิคที่โดดเด่นที่สุดคือ syscall stub แบบกำหนดเองที่เข้ารหัสไว้ ซึ่งใช้หลบ ntdll hook และทำให้ต้นทางของ syscall ดูเหมือนมาจากฟังก์ชันอื่นใน ntdll เพื่อให้ติดตามได้ยาก

ขอบเขตและเป้าหมายของการวิเคราะห์

  • สิ่งที่นำมาวิเคราะห์คือแอนตีชีตแบบผู้ใช้โหมดภายใน Black Ops Cold War ซึ่งใช้ชื่อว่า TAC (Treyarch Anti-Cheat)
  • Black Ops Cold War ไม่มี องค์ประกอบแบบเคอร์เนลโหมด ของ Ricochet ที่มีอยู่ใน Modern Warfare 2019 และภาคหลังจากนั้น
  • ความต่างหลักกับ Call of Duty รุ่นใหม่คือไดรเวอร์เคอร์เนลโหมด โดยโค้ดแอนตีชีตส่วนใหญ่ยังอยู่ในผู้ใช้โหมดและคล้ายกับ TAC มาก
  • pseudocode ของฟังก์ชันต่าง ๆ เป็นรูปแบบที่ผู้เขียนเรียบเรียงใหม่ เพราะผล decompile จริงซับซ้อนจากโค้ด obfuscation และตัวแก้ไขที่เกี่ยวข้อง
  • เนื้อหาบางส่วนถูกตัดออกเพื่อหลีกเลี่ยงการส่งเสริมการโกงหรือการหลบเลี่ยง

Arxan และการป้องกันไฟล์รัน

  • Arxan เป็นเครื่องมือ obfuscation/ป้องกันที่ถูกใช้ในเกม Call of Duty หลายภาคตั้งแต่ Black Ops 3 เป็นต้นมา
  • การถอดรหัสไฟล์รันขณะรันไทม์
    • ไฟล์รันของเกมถูก pack และเข้ารหัสไว้
    • Arxan แทรกโค้ดเข้าไปในกระบวนการเริ่มต้นเพื่อ unpack/ถอดรหัสไฟล์รันจริงของเกม
  • checksum ของไฟล์รัน
    • Arxan เฝ้าตรวจการแพตช์ไฟล์รันของเกมอย่างต่อเนื่อง
    • หากตรวจพบ debugger หรือ checksum ไม่ตรงกัน ก็จะยุติโปรเซส
  • การทำให้ jmp อ่านยาก
    • มีการแทรก jmp จำนวนมากระหว่างคำสั่งของฟังก์ชันเพื่อทำให้การวิเคราะห์แบบสถิตยากขึ้น
    • เมื่อมีการแทรก jump หลายร้อยจุดในฟังก์ชันใหญ่ ๆ การวิเคราะห์ของ IDA อาจพังและต้องใช้เครื่องมือภายนอกช่วย
  • การทำให้ entry point อ่านยาก
    • โค้ด Arxan ที่ถูกป้องกันไว้จะ unpack และรัน entry point จริง
    • ช่วงนี้ก็อาจมีการทำให้ jmp อ่านยากเช่นกัน ทำให้ติดตาม flow ได้ยาก

การเข้ารหัสพอยน์เตอร์

  • พอยน์เตอร์สำคัญจะถูกเข้ารหัส/ถอดรหัสก่อนใช้งานทันที
    • global object ปัจจุบันของเกม
    • อาร์เรย์ของ entity
    • object pointer เป็นต้น
  • วิธีเข้ารหัสเดียวกันนี้มี 16 แบบย่อย และที่อยู่ PEB ปัจจุบันเป็นตัวกำหนดว่าจะใช้แบบไหน
  • วิธีนี้รบกวนการทำ pointer scan ของ Cheat Engine
    • ในค่า global จะเก็บเฉพาะค่าที่เข้ารหัสแล้ว
    • ค่าที่ถอดรหัสแล้วจะมีอยู่เพียงบน stack
  • หากต้องการได้พอยน์เตอร์ที่ถอดรหัสแล้ว จำเป็นต้องใช้เครื่องมือติดตามคำสั่งถอดรหัส หรือวาง hook ที่จุดซึ่งเกมถอดรหัสไว้แล้ว

การค้นหา API ตอนรันไทม์และการตรวจจับ hook

  • TAC ใช้ฟังก์ชัน ค้นหา API ตอนรันไทม์ ที่ถูก inline มา
    • รับ module hash และ API name hash
    • วนผ่านรายการโมดูลที่โหลดอยู่แล้ว hash ชื่อของมัน
    • วนผ่าน export function ของโมดูลและเทียบกับ compile-time hash
  • การระบุว่า hash ใดคืออะไรทำได้โดยอาศัยรายการโมดูลที่โหลดในโปรเซสเกมและฟังก์ชัน hash ของเกม
    • คำนวณ hash ของชื่อโมดูลและชื่อ export
    • ดึง base hash และ function hash จากผล decompile ด้วยมือเพื่อจับคู่ว่าเรียก API ตัวไหน
  • ค่า hash ไม่จำเป็นต้องเหมือนกันในแต่ละเวอร์ชันของเกม
  • เนื่องจาก function pointer ถูกเก็บในตัวแปร global จึงสามารถระบุได้อีกแบบด้วยการเทียบ virtual address กับ export function ของ DLL ที่โหลดอยู่
  • การตรวจจับ API hook ของ TAC ปัจจุบันตรวจเพียง 7 รูปแบบ
    • stub แบบ push/movabs/xchg/ret
    • push imm ตามด้วย ret
    • call
    • jmp [rip+x]
  • ระบบไม่ได้ตรวจทุก API สำคัญ แต่จะตรวจ hook ของ API ที่ตัวเองใช้งาน

การตรวจ debug register และ driver test signing

  • debug register สามารถถูกใช้เป็นวิธี hook แบบไม่แก้โค้ดเพื่อหลบการตรวจแพตช์ .text ของ Arxan ได้
  • TAC ตรวจค่า DR0~DR3 จาก thread context
    • หากพบค่า จะเรียก callback ด้วยข้อความต่างกันตามว่ามาจากภายในโปรเซสปัจจุบันหรือไม่
    • จากนั้น flow จะไปยังฟังก์ชันยุติการทำงาน
  • DR0~DR3 เป็น privileged register จึงไม่สามารถอ่านตรง ๆ ด้วย assembly ทั่วไป ต้องอาศัย Windows kernel หรือการส่งต่อ exception
  • Windows test mode อนุญาตให้รันไดรเวอร์เคอร์เนลโหมดที่ไม่ได้เซ็นอย่างถูกต้อง
  • TAC ใช้ NtQuerySystemInformation เพื่อตรวจว่ามีการเปิด test signing หรือไม่
    • การตรวจจับนี้เพียงอย่างเดียวไม่ได้ทำให้โดนแบนทันที แต่บัญชีจะถูกติดธงไว้

วิธีการยุติโปรเซส

  • TAC มีสองวิธีในการยุติโปรเซส
  • วิธีแรกคือเคลียร์รีจิสเตอร์แล้วเรียก NtTerminateProcess
    • ตั้ง RCX เป็น -1
    • หากตรวจพบว่า NtTerminateProcess ถูก hook อยู่ จะไม่ใช้วิธีนี้
  • วิธีที่สองคือเคลียร์รีจิสเตอร์แล้วกระโดดไปที่ 0x0 เพื่อทำให้โปรเซสแครช
  • ทั้งสองวิธีลบรีจิสเตอร์สำคัญ ทำให้กู้สถานะกลับได้ยาก

การตรวจจับคอนโซล ภาพแสดงผล และ overlay

  • ชีตแบบภายในอาจใช้ AllocConsole เพื่อพิมพ์ log หรือทำเมนู
  • TAC ตรวจหน้าต่างคอนโซลหรือ ConsoleHandle ใน PEB เพื่อตรวจการสร้างคอนโซล
  • การแสดงผลภายในมักวาดบนหน้าจอผ่านการ hook กราฟิก API
    • Call of Duty รุ่นใหม่ใช้ DirectX 12
    • จุด hook ที่พบบ่อยคือ IDXGISwapChain::Present
    • ใน DirectX 12 ต้องใช้ command queue และจุดที่มักใช้เก็บได้คือ ID3D12CommandQueue::ExecuteCommandLists
  • OBS Studio, Streamlabs OBS, Discord game overlay และ Steam game overlay ก็อาจทำงานในจุดคล้ายกัน
    • Steam และ Discord มีการวาดภาพ
    • กลุ่ม OBS จะจับภาพเรนเดอร์เมื่อใช้ game capture
  • ปัจจุบัน TAC ไม่ได้สแกนฟังก์ชัน present ของ DXGI โดยตรง แต่ตรวจพอยน์เตอร์ present ใน vtable

ชีตภายนอกและการตรวจจับจากหน้าต่าง

  • ชีตภายนอกมีแนวโน้มจะสร้าง overlapped window ทับบนหน้าต่างเกม
  • TAC วนตรวจทุกหน้าต่างและใช้ GetWindowLongA เพื่อตรวจสไตล์ WS_EX_LAYERED
  • จากนั้นใช้ GetWindowRect เปรียบเทียบว่าทับกับหน้าต่างเกมหรือไม่
    • หากอัตราการทับซ้อนตั้งแต่ 0.5 ขึ้นไป และจำนวน cache น้อยกว่า 8 จะเก็บ hwnd นั้นไว้
    • มีค่าตัวอย่างที่สอดคล้องกับความละเอียดหน้าจอ 1920x1080
  • หน้าต่างที่ cache ไว้จะถูกตรวจเพิ่มเติมในอีกฟังก์ชันหนึ่ง
    • ตรวจข้อความหน้าต่างด้วย GetWindowTextW
    • ตรวจชื่อคลาสด้วย GetClassNameA
    • ตรวจ display affinity ด้วย GetWindowDisplayAffinity
  • TAC ยังตรวจกรณีที่ใช้ SetWindowDisplayAffinity และ WDA_EXCLUDEFROMCAPTURE เพื่อซ่อนจากเครื่องมือบันทึกวิดีโอหรือจับภาพหน้าจอ
  • ข้อมูลเกี่ยวกับหน้าต่างจะถูกเก็บในบัฟเฟอร์ที่เข้ารหัสแล้วอัปโหลดไปยังเซิร์ฟเวอร์
    • ข้อความหน้าต่าง
    • ชื่อคลาส
    • ตำแหน่งและสไตล์ของหน้าต่าง
    • display affinity
    • รายการโมดูลและชื่อ exe ของโปรเซสที่เป็นเจ้าของหน้าต่างที่ทับอยู่
  • โปรเซสของหน้าต่างที่ทับอยู่จะถูกเปิดด้วย OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) แล้วเก็บชื่อโมดูลด้วย K32EnumProcessModules และ K32GetModuleFileNameExW

การตรวจจับตัวสแกนหน่วยความจำแบบ Cheat Engine

  • Cheat Engine ถูกตรวจจับได้ง่ายจากพฤติกรรมของหน่วยความจำเสมือนใน Windows
  • แม้โปรแกรมจะจองหน่วยความจำเสมือนด้วย VirtualAlloc แต่ก่อนมีการเข้าถึงจริงก็ยังไม่ถูก backing ด้วยหน่วยความจำกายภาพ
  • เกมสามารถจองหน่วยความจำไว้แล้วไม่ใช้งานได้
  • หาก Cheat Engine หรือแท็บหน่วยความจำของ Process Hacker สแกนบริเวณนั้น จะเกิดการเข้าถึงและทำให้หน่วยความจำนั้นกลายเป็น valid
  • honeypot แบบ TAC ใช้ K32QueryWorkingSetEx เพื่อตรวจว่าที่อยู่เสมือนนั้นถูกเข้าถึงจริงหรือยัง และใช้ตรวจจับตัวสแกนหน่วยความจำ

การรบกวน signature scanning

  • แฮ็กเกอร์เกมมักใช้ signature scanning เพื่อให้ชีตทำงานอัตโนมัติได้แม้เกมอัปเดตแล้ว
  • แนวคิดของ Treyarch คือป้องกันบริเวณรอบ return address ในฟังก์ชันที่จะไม่ถูกเรียกอีกด้วย PAGE_NOACCESS
  • signature scanner จะอ่านไบต์ของไฟล์รันจากต้นจนจบเพื่อหารูปแบบ
  • หากตรวจทุกไบต์ว่าเข้าถึงได้หรือไม่จะช้ามาก ดังนั้นเมื่อไปชนบริเวณ PAGE_NOACCESS โปรเซสอาจแครชได้
  • วิธีนี้ไม่ใช่มาตรการปิดกั้นที่สมบูรณ์ แต่ทำให้นักวิเคราะห์จำนวนมากทำงานลำบากขึ้น

การต้านดีบัก

  • การตรวจ anti-debug ของ TAC เองค่อนข้างง่าย แต่ Arxan ก็มีเทคนิค anti-debug แยกต่างหากด้วย
  • TAC วนตรวจทุก thread ของโปรเซสปัจจุบัน
    • ใช้ CreateToolhelp32Snapshot และ thread snapshot
    • ตรวจ DbgSsReserved ใน TEB ของแต่ละ thread เพื่อหา DebugObject
  • ยังมีเทคนิคเขียนลงหน่วยความจำผิดปกติเพื่อทำให้เกิด access violation
    • หากโค้ดยังไปถึงจุดหลัง exception ได้ ก็จะถือว่า debugger จัดการ exception หรือมีการหลบเลี่ยงอยู่
  • มีการใช้ CheckRemoteDebuggerPresent ด้วย
  • ThreadHideFromDebugger ทำให้ exception ถูกส่งไปยังโปรเซสแทนที่จะส่งให้ debugger
    • เมื่อ debugger พยายามหยุดโปรเซส อาจเกิด exception STATUS_BREAKPOINT และทำให้โปรเซสยุติลง
    • ในผู้ใช้โหมดไม่สามารถ unset flag นี้ได้
    • กลยุทธ์นี้ถูกเรียกใช้จาก TLS callback ก่อนถึง entry point ของไฟล์รัน

การมอนิเตอร์ทราฟฟิกเครือข่าย

  • TAC ไม่ได้เก็บทุกการเชื่อมต่อที่กำลังใช้งาน แต่จะมองหาเฉพาะเงื่อนไขบางอย่าง
  • เป้าหมายของการตรวจจับคือกรณีที่มีการสร้าง local network server ภายในโปรเซสเกม
    • ผู้โกงเขียน shellcode เข้าไปในโปรเซสเกม
    • เริ่ม network server ภายในโปรเซสเกม
    • แอปภายนอกสื่อสารแลกเปลี่ยนข้อมูลกับ local server นี้
  • TAC ใช้ GetTcpTable2 เพื่อดึงตาราง TCP แล้วเปรียบเทียบความสัมพันธ์ของการเชื่อมต่อที่โปรเซสปัจจุบันสร้างขึ้นกับพอร์ตของโปรเซสอื่น เพื่อหาตามเงื่อนไขดังกล่าว

syscall stub แบบกำหนดเองที่เข้ารหัส

  • export API จำนวนมากใน ntdll จะทำ syscall ภายใน
  • หากใช้ syscall stub แบบกำหนดเอง ก็สามารถหลบได้แม้ชีตในผู้ใช้โหมดจะ hook ฟังก์ชันของ ntdll ไว้
  • syscall อาจถูกเห็นได้ผ่าน instrumentation callback
    • instrumentation callback จะถูกเรียกหลัง syscall
    • return address จะกลายเป็นตำแหน่งถัดจากคำสั่ง syscall ทันที
  • TAC ใช้ syscall stub ที่เข้ารหัสไว้เพื่อทำให้การวิเคราะห์แบบสถิตยากขึ้น
  • stub ถูกประกอบขึ้นในพื้นที่ขนาดใหญ่ที่จัดสรรอยู่ในเซกชัน .text หลังตั้งสิทธิ์เป็น write/execute
  • ระบบจะค้นหาคำสั่ง syscall จาก NtReadFile แล้วเปลี่ยนตำแหน่งโดยใช่ค่าเวลา CPU เป็นส่วนหนึ่งของความสุ่ม
  • ฝั่งที่มอนิเตอร์อาจเห็นเหมือน syscall เกิดจากฟังก์ชันสุ่มตัวหนึ่งใน ntdll
    • syscall จริงอาจไม่ใช่ NtReadFile
    • หากไม่ตรวจ syscall index ใน eax ก็จะระบุได้ยากว่าเป็น syscall อะไร
  • มีตัวอย่างที่ตำแหน่งของคำสั่ง syscall เปลี่ยนไปทุกครั้งที่รันใหม่

การตรวจจับการหลบ ThreadHideFromDebugger

  • การตั้งค่า ThreadHideFromDebugger ต้องเรียก NtSetInformationThread
  • ผู้โกงสามารถ hook API นี้และทำให้คืนค่าว่าสำเร็จได้
    • แบบนั้นแอนตีชีตจะเชื่อว่าการซ่อนสำเร็จ ทั้งที่จริงอาจไม่มีอะไรเกิดขึ้น
  • TAC ตรวจจับ hook ที่ทำไม่ดีด้วยการเรียกพร้อม อาร์กิวเมนต์ที่ไม่ถูกต้อง แล้วดูผลลัพธ์
    • การเรียกที่ควรล้มเหลวเพราะค่า length ไม่ตรง หากกลับสำเร็จจะถือว่าถูกตรวจพบ
    • มีตัวอย่างที่คืนค่าต่างกันระหว่าง debugger กับสภาพแวดล้อม ScyllaHide
    • ยังพบ hook ที่คืนค่าสำเร็จให้คำขอ ThreadHideFromDebugger ทุกครั้งแม้จะใส่ handle ปลอม

การป้องกันการสร้าง remote thread

  • TAC ติดตั้ง exception handler ที่เรียก TerminateThread กับ thread ปัจจุบันเมื่อเกิด exception STATUS_PRIVILEGED_INSTRUCTION
  • DLL แบบ manual mapping ต้องมีวิธีรัน shellcode ในโปรเซสเป้าหมาย และวิธีที่พบบ่อยคือ CreateRemoteThread
  • TLS callback ของ Windows PE อาจถูกเรียกก่อน thread entry point เมื่อตอนสร้าง thread
  • TAC ตรวจ start address ใน context ของ thread ใหม่
    • ใช้ NtQueryInformationThread เพื่อดึง Win32 start address
    • วนรายการโมดูลที่โหลดแล้วเพื่อตรวจว่า start address อยู่ในช่วงของโมดูลปกติหรือไม่
  • หาก start address ไม่อยู่ในช่วงของโมดูลที่โหลดใดเลย ระบบจะบันทึกการตรวจพบ แล้วจงใจทำให้เกิด privileged instruction exception เพื่อยุติ thread นั้น

การตรวจอื่น ๆ และบทสรุป

  • มีโค้ดตรวจที่ยังไม่ทราบจุดประสงค์ซึ่งเช็กว่า AllocationGranularity ของ NtQuerySystemInformation เท่ากับ 0x10000 หรือไม่
    • ดูเหมือนใช้ติดธง virtual machine หรือ Windows เวอร์ชันปรับแต่ง
  • TAC พึ่งพารายการโมดูลที่เชื่อมโยงอยู่มาก จึงมีการตรวจว่า InMemoryOrderModuleList ใน PEB ว่างเปล่าหรือไม่
    • หากทำให้รายการนี้ว่าง โปรเซสเองก็อาจพังได้
  • โดยสรุป TAC เป็นแอนตีชีตแบบผู้ใช้โหมดที่มีความสามารถดังนี้
    • ค้นหา API ตอนรันไทม์
    • ตรวจจับ hook ที่ทำไม่ถูกต้อง
    • ตรวจจับ overlay ภายนอก
    • ตรวจจับ DirectX hook ภายใน
    • ตรวจ hook ของ API ที่ใช้งาน
    • ตรวจ debugger และร่องรอยการดีบัก
    • ตรวจ AllocConsole
    • ตรวจ CreateRemoteThread
    • ใช้ syscall stub แบบ spoofed และเข้ารหัส
  • Arxan ช่วยเสริม TAC ด้วย obfuscation ที่หนัก, เทคนิคขัดขวางการวิเคราะห์แบบสถิต, วิธีทำให้ IDA Pro พัง, การเฝ้าตรวจการแก้ไข .text และความสามารถ anti-debug ของตัวเอง
  • โค้ดที่คล้าย TAC ยังถูกใช้อยู่ในเกม Call of Duty ยุคใหม่ด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-21
ความคิดเห็นจาก Hacker News

  • ในปี 2021 บัญชี Linux ของ CS:GO เจอปัญหาเรื่อง ค่าความน่าเชื่อถือ จนตกเป็นสีเหลือง แล้วต่อมากลายเป็นสีแดง แม้จะไม่ใช่การแบนอย่างเป็นทางการ แต่ในทางปฏิบัติก็แทบไม่ต่างจากการลงโทษ
    ผลก็คือถูกจับคู่กับพวกโกงอยู่เรื่อย ๆ และหาคนร่วมทีมได้ยาก
    ต่อมาจึงพบว่าผู้ใช้ Linux คนอื่นที่ใช้ GPU Radeon และ VRAM ตั้งแต่ 16GB ขึ้นไปก็เจอปัญหาคล้ายกัน และได้เปิด GitHub issue เพื่อติดตามปัญหา: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
    เมื่อตรวจสอบดูก็เหมือนว่า Valve กำลังลงโทษผู้ใช้ Linux ที่มีฮาร์ดแวร์บางแบบ โดยเฉพาะ การ์ด Radeon ที่มี VRAM 16GB ขึ้นไป ซึ่งในตอนนั้นยังถือว่าค่อนข้างใหม่
    สุดท้ายหลังจากมีผู้ใช้คนหนึ่งติดต่อ gaben โดยตรง ปัญหาก็ถูกแก้ไข: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
    มีการคาดเดาว่านี่อาจเป็นผลจากการที่ Valve ใส่ใจประสบการณ์ผู้ใช้ Linux เพราะกำลังเตรียมเปิดตัว Steam Deck

    • หรือ Gabe Newell อาจจะเป็นคนดีเฉย ๆ ก็ได้?
    • ยังไม่ค่อยเข้าใจว่าการลงโทษผู้ใช้ Linux จะช่วยให้ประสบการณ์ผู้ใช้ Linux ดีขึ้นได้อย่างไร
      ถึงอย่างนั้นก็น่าสนใจอยู่
    • สงสัยว่ารู้ได้อย่างไรว่าค่าความน่าเชื่อถือตกไปเป็นสีเหลืองหรือสีแดง
      เดาว่าจากคุณภาพเกมที่แย่ลง หรือมีวิธีตรวจสอบอย่างอื่นก็ไม่แน่ใจ
      เท่าที่เข้าใจ ค่าความน่าเชื่อถือถูกซ่อนไว้เพื่อป้องกันการนำไปใช้ในทางที่ผิด

  • การโกงท้ายที่สุดแล้วเป็น ปัญหาของคน
    มาตรการป้องกันและ heuristic ที่อธิบายในบทความอาจช่วยกรองพวกโกงแบบโจ่งแจ้งได้ 90% และ anti-cheat แบบนั้นโดยพื้นฐานถือว่าเป็นทิศทางที่ดี
    แต่ anti-cheat ควรทำงานอย่างระมัดระวัง และท้ายที่สุดต้องให้ผู้เล่นกับแอดมินเป็นคนจัดการ
    เกมออนไลน์แบบหลายผู้เล่นควรรันบนเซิร์ฟเวอร์ที่มีคนดูแลเสมอ และควรมีแอดมินอยู่ในช่วงเวลาส่วนใหญ่ที่ผู้เล่นกำลังเล่น
    ถ้าเป็นแอดมินที่ผู้เล่นรู้จักยิ่งดี และตอนที่ไม่มีแอดมินก็ควรมีการกลั่นกรองที่เบากว่า เช่น vote kick หรือ vote ban
    การไล่คนโกงออกกับการไล่คนที่ใช้แชตในทางที่ผิดออกนั้นโดยแก่นแท้แล้วไม่ต่างกัน
    ท้ายที่สุด รูปแบบเซิร์ฟเวอร์ที่ใช้งานได้จริงสำหรับเกมออนไลน์แบบหลายผู้เล่นก็คือ เซิร์ฟเวอร์ส่วนตัวหรือเซิร์ฟเวอร์ชุมชน เท่านั้น
    กระบวนการควบคุมคนโกงและผู้ใช้ในทางที่ผิดไม่ควรเป็นแบบรับผ่านระบบรายงานแล้วค่อยประมวลผลทีหลัง แต่ควรให้ผู้ดูแลเกมคิกหรือแบนได้อย่างรวดเร็ว
    ถ้าเกมหนึ่งเล่นออนไลน์ได้ผ่านเซิร์ฟเวอร์จับคู่ของผู้จัดจำหน่ายเท่านั้น และการจัดการคนโกงหรือคนที่ใช้แชตในทางที่ผิดทำได้แค่กรอกแบบฟอร์มบนเว็บ ก็ไม่ควรซื้อหรือเล่น และควรใช้กระเป๋าสตางค์ของตัวเองลงคะแนน

    • เงื่อนไขที่ว่าเกมออนไลน์แบบหลายผู้เล่นต้องรันบนเซิร์ฟเวอร์ที่มีคนดูแลเสมอนั้น ฟังดูค่อนข้างเหลือเชื่อเมื่อคิดถึงขนาดของระบบ
    • ฟังดูเหมือนกำลังบอกว่าแต่ละเกมควรมี กรรมการ ที่ทุกคนมองเห็นได้ และทุกครั้งที่มีการละเมิดก็ค่อยเรียกดูภาพย้อนหลัง
      จะตั้งองค์กรแยกมาคอยตรวจกรรมการอีกชั้นก็ยังได้ แต่เอาเข้าจริงก็แค่เล่นเกมกันไปเถอะ
    • ไม่เข้าใจว่าทำไมถึงมองว่าการให้คนดูแลเป็นทางออกเดียวที่เป็นไปได้
      Apex Legends ก็ไปได้ดีด้วยระบบรายงานและ anti-cheat ที่แข็งแรง และ Rocket League ก็ใช้การกลั่นกรองอัตโนมัติเป็นหลักได้อย่างมีประสิทธิภาพ
    • โดยรวมเห็นด้วย แต่ก็ยังมีวิธีอื่น
      เช่น การยืนยันตัวตนด้วยเบอร์โทรศัพท์ การตรวจสอบด้วยรูปถ่ายแบบแมนนวล การบังคับให้เล่น 10 ชั่วโมงก่อนเข้าโหมดจัดอันดับ การรับรองจากผู้เล่นคนอื่น หรือแม้แต่ game pass แบบจ่ายครั้งเดียว 5 ดอลลาร์บนเงื่อนไขเหล่านี้ก็ได้
      ถ้ายังไม่เคยดู แนะนำให้ดู งานนำเสนอ AI anti-cheat ของ Valve
      งานค่อนข้างน่าสนใจ และอ้างว่าจับคนโกงได้ 99%
      แน่นอนว่ายังมีวิธีโกงที่ละเอียดแนบเนียนมาก ๆ อยู่เสมอ

  • มีคนสู้คดีในศาล นาน 2 ปี เพื่อพลิกคำแบนถาวรแบบผิดพลาดของ Activision และ Activision ก็แพ้คดีเพราะไม่สามารถแสดงหลักฐานการโกงได้แม้แต่นิดเดียว: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

    • ฉันก็เคยเจอเรื่องเดียวกันใน League of Legends
      ไม่เคยโกงเลยสักครั้ง แต่กลับโดนแบนโดยไม่มีคำอธิบาย และฉันเล่นอยู่ประจำสามบัญชี โดยอีกสองบัญชีก็ไม่โดนแบน
      ฝ่ายบริการลูกค้าก็พูดซ้ำแต่เพียงว่า “จากการตรวจสอบแล้ว การแบนนี้ถูกต้อง” และไม่ให้ข้อมูลอะไรเลยที่จะช่วยให้รู้ว่าทำอะไรผิดเพื่อจะแก้ไขได้
      ฉันมีสกินหายากที่สุดของเกมอยู่หลายชิ้น เล่นมาตั้งแต่ปี 2009 รวมหลายพันชั่วโมง และเล่นแต่ ARAM การจะเอาบัญชีที่มีคุณค่าทางใจมากขนาดนั้นไปเสี่ยงโกงในโหมดที่ casual ที่สุดมันไม่สมเหตุสมผลเลย
      นี่เป็นเรื่องที่ทำให้เครียดที่สุดเท่าที่เคยเจอเกี่ยวกับเกม และสุดท้ายก็ได้คนรู้จักในวงการช่วยตรวจสอบภายในให้ จึงปลดแบนโดยไม่มีเหตุผลอธิบาย
      ทุกวันนี้ก็ยังเล่นอยู่ แต่แทบทุกครั้งที่เล่นจะนึกถึงการแบนผิดพลาดครั้งนั้น และ League น่าจะเป็นเกมแข่งขันหลายผู้เล่นเกมสุดท้ายที่ฉันยอมทุ่มเวลาให้
      อีกใจก็ไม่อยากเล่นแล้ว เพราะกลัวว่าจะเกิดแบบเดิมอีก
    • ฉันก็เคยโดน แบนถาวรแบบผิดพลาด เหมือนกัน
      บนคอนโซลแทบเป็นไปไม่ได้ที่จะโกง ฉันใช้เวลานานมากกว่าจะไต่แรงก์ไปถึงแค่ Gold 1 แบบธรรมดา ๆ และไม่เคยได้รับคำเตือนหรือโดนรายงานจากพฤติกรรมใด ๆ เลย แต่กลับโดนแบนถาวรโดยไม่มีคำอธิบาย
      แทนที่จะสู้เหมือนผู้เขียน ฉันเลือกว่าจะไม่จ่ายเงินให้ผลิตภัณฑ์ของ Activision อีกเลย และคิดว่าทุกคนก็ควรทำแบบนั้น
    • ตรงที่บอกว่าถ้าเล่นเก่งในเกม ก็อาจมีคนเปิดโปรไฟล์ดูเวลาเล่นแล้วเห็นป้ายสีแดงว่า “ฉันเป็นคนโกง” ทันทีนั้น ทำให้น่าสงสัยว่าป้ายนี้อาจเข้าข่าย หมิ่นประมาท หรือไม่
      ในสหรัฐฯ คงยากกว่า แต่เท่าที่เข้าใจ ในสหราชอาณาจักรหรืออังกฤษ จำเลยต้องพิสูจน์ให้ได้ว่าสิ่งนั้นเป็นความจริง
    • แค่คิดว่าต้องไปสู้เรื่องแบบนั้นก็น่ากลัวแล้ว
      โชคดีที่แทบไม่เล่นเกมยิงหลายผู้เล่น และคงแย่มากถ้าต้องเสียคลัง Steam ขนาดใหญ่ไป
    • ตัวบทความนี้เองก็ดีพอจะส่งเป็นโพสต์แยกได้เลย และเป็นบทความที่น่าสนใจมาก

  • การทำให้งงด้วย jump น่าสนใจมาก
    ถ้ามีคนที่เคยทำ reverse engineering ลึกกว่านี้มาตอบได้ก็คงดี
    สงสัยว่า unconditional jump พบได้บ่อยมากจนกรองออกด้วยเงื่อนไขเบื้องต้นบางอย่างได้ยากจริงไหม และเพราะปลายฟังก์ชันมีการคืนค่าจึงดูเหมือนหาง่าย เลยสงสัยว่าจะวิเคราะห์สแตกเพื่อรู้ว่าฟังก์ชันจะ return ไปที่ไหน แล้วค่อยหาคำสั่งเรียกที่อยู่หน้าที่อยู่คืนค่าทันทีได้ไหม
    ผมอาจเข้าใจวิธีทำงานผิดไปก็ได้ เพราะไม่ได้เขียนแอสเซมบลี x86 เยอะนัก

    • มีเทคนิคเจ๋ง ๆ ที่ใช้ symbolic execution ผ่านอีมูเลเตอร์อย่าง angr หรือ https://github.com/cea-sec/miasm เพื่อคลายการทำให้กราฟการไหลของการควบคุมแบนราบ
      เฟรมเวิร์ก PIN ของ Intel ก็ใช้ทำการวิเคราะห์ที่น่าสนใจได้
      บทความที่อาจช่วยได้อยู่ที่นี่: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
    • unconditional jump พบบ่อยมาก และแอสเซมบลี x86 หลังผ่านการ optimize โดยรวมก็รกมาก
      หลายฟังก์ชันไม่ได้จบด้วย ret
    • วิดีโอที่ reverse engineering บางส่วนของ Guitar Hero 3 นี้อาจน่าสนใจ เพราะพูดถึงเทคนิคคล้ายกันที่ใช้ในการทำให้งงโค้ดเกมอย่างหนัก: https://www.youtube.com/watch?v=A9U5wK_boYM
    • มีปัญหาที่พบบ่อยอยู่หลายอย่าง
      jump บางอันเป็นของปลอม และ jump บางอันกระโดดเข้าไปกลางคำสั่ง
      decompiler รับมือกับสถานการณ์ที่มีสองคำสั่งอยู่ตำแหน่งเดียวกันไม่ได้
      เช่น ใน jmp 0x1234 มันอาจข้าม opcode ของ jmp แล้วถือว่า 0x1234 เป็นคำสั่งที่ถูกต้อง
      ในบางแขนงสแตกอาจพังอยู่ แต่ก็อาจเป็นความตั้งใจเพื่อทำให้เกิด exception โดยเจตนา
      ดังนั้นแม้จะซ่อมการ decompile ได้ด้วยการแทนคำสั่งอย่าง lea RAX, [rsp + 0x99999999999] ด้วย nop ก็อาจพลาด exception ที่ตั้งใจไว้
      IDA จัดการเรื่องพวกนี้ได้ไม่ค่อยดี ผมเลยใช้ไลเซนส์ Binary Ninja และสามารถเขียนสคริปต์ให้อินไลน์ฟังก์ชันสำหรับ decompiler ได้ง่าย
      ผมมองว่า IDA จัดการสถานการณ์ที่ jump ต่าง ๆ นำโค้ดก้อนเดียวกันกลับมาใช้ร่วมกันได้ไม่ดีนัก เพราะโค้ดระหว่าง jump ถูกบังคับให้สังกัดได้แค่ฟังก์ชันเดียว
      ดูเหมือนคนจะใช้ Binary Ninja น้อยกว่าเพราะเคยมีบั๊กกับเกมของ Blizzard แต่เมื่อราว 1 ปีก่อนมันถูกแก้แล้วจาก bug report
    • jump เฉพาะกลุ่มนี้ดูเหมือนจะกรองออกได้ง่ายพอสมควร
      เป็นการทำให้งงเพื่อกวนผู้ใช้เครื่องมือสำเร็จรูปทั่วไป โดยเฉพาะ IDA Pro
      การทำให้งงส่วนใหญ่มีจุดประสงค์แค่ทำให้มันน่ารำคาญพอที่คนจะย้ายไปทำโปรเจ็กต์อื่น

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

    • โกงก็ไม่ได้ทำให้ถูกแบนจาก Steam
      อย่างแย่ที่สุดก็แค่มีเครื่องหมายประจานสาธารณะติดบัญชีในเกมที่ใช้ VAC
      คนเล่นเกมมัลติเพลเยอร์เพื่อความสนุกและเพื่อปฏิสัมพันธ์กับคนอื่น ดังนั้นถ้าการโกงหรือพฤติกรรมแย่อื่น ๆ ส่งผลต่อผู้อื่น ก็ควรถูกแบนจาก การใช้บริการมัลติเพลเยอร์
    • ผมไม่เห็นว่ามันต่างจากการขับรถเกินความเร็วอย่างไร
      ถ้าสร้างความเดือดร้อนต่อสังคมก็ต้องรับผล เป็นหลักการที่พบได้ทั่วไปพอสมควร
    • ผมว่าเป็นเรื่องโอเคถ้าพวกคนโกงโดนเล่นงานสมควร
      คิดว่าเสียเงินจริงก็ได้
      แต่การถูกแบนเพราะความผิดพลาดเป็นอีกเรื่อง
      แล้วสิ่งที่ถูกแบนไม่ใช่ทั้งบัญชี Steam แต่เป็นแค่เกมนั้นที่เล่นต่อไม่ได้ไม่ใช่หรือ?
    • ติดป้ายว่าเป็นคนโกง แล้วให้ไปเล่นกับคนโกงด้วยกันน่าจะดีกว่า
    • ถ้าโกงหรือทำให้เกมของผู้เล่นคนอื่นพัง ก็สมควรเสียสิทธิ์การเข้าถึง
      ผู้เล่นคนอื่นก็จ่ายเงินมาเหมือนกัน

  • ใน COD แทบไม่จำเป็นต้องโกงเลย
    บั๊กเยอะจนเกมทำให้แทนอยู่แล้ว
    มันถึงขั้นโหลดปืนแทนมีดในแรงก์ได้ และเหมือนว่าการตรวจอุปกรณ์ปืนในแรงก์มี case หรือ if-else ที่ผิดชัดเจน เลยทำแบบนั้นได้ และถ้าปืนที่เห็นในตัวเลือกอุปกรณ์ไม่ได้รับอนุญาต ก็ดูเหมือนจะ fallback เป็น XM4 โดยอัตโนมัติ
    เป็นแทบเกมเดียวที่ผมรู้จักซึ่งเวอร์ชันแรงก์พังกว่าเวอร์ชันแคชชวล

  • สงสัยว่าไปเรียนเรื่องพวกนี้มาจากไหน
    อยากเรียนเพิ่มให้พอเข้าใจบทความนี้ได้สักครึ่งหนึ่ง แต่ไม่รู้จะเริ่มจากตรงไหน

    • เมื่อราว ๆ 15 ปีก่อน ฉันได้เรียนรู้อะไรมากมายจากการอ่านหนังสือของ Eldad Eilam ชื่อ Reversing: Secrets of Reverse Engineering
      แม้จะเป็นหนังสือเก่า แต่ยอดเยี่ยมมาก และพาให้ลองทำตามเทคนิคกับแบบฝึกหัดหลายอย่าง
      เครื่องมือสมัยใหม่อาจต่างจากตอนนั้นไปบ้าง แต่ชุดคำสั่ง x86 และภาพรวมของแอสเซมบลียังไม่ได้เปลี่ยนไปมากนัก
      หนึ่งในสิ่งที่ได้ประโยชน์มากที่สุดคือการได้รู้จัก crackme
      มันคือไบนารีท้าทายขนาดเล็กที่สร้างมาเพื่อใช้เรียนรู้การทำ reverse engineering คล้ายกับกุญแจฝึกสำหรับชุมชนสะเดาะกุญแจ
      ถ้าจำไม่ผิด ในหนังสือมีมาให้หลายตัวใน CD-ROM และถ้าหาดูออนไลน์ก็มีอีกเยอะ
      การได้ลองทำแบบฝึกหัดพวกนี้ด้วยตัวเองนี่แหละคือวิธีเรียนรู้
      ไม่ควรเริ่มจากพยายาม reverse engineering COD ตั้งแต่แรก แต่ควรค่อย ๆ สะสมพื้นฐานไปทีละขั้น
    • สมัยก่อนฉันเริ่มจาก Lena151 tutorial: https://github.com/kosmokato/Lena151
    • ถ้าเป็นเมื่อก่อนก็คงจะแนะนำให้ไปคลุกคลีกับคนใน Gamedeception แต่ดูเหมือนมันจะหายไปเมื่อไม่กี่ปีก่อน
      ขอทักทายคนที่เคยตามอ่าน UnknownCheats, cs.rin.ru และที่อื่น ๆ
    • UnknownCheats เป็นหนึ่งในที่ที่ดีที่สุดสำหรับข้อมูลแนวนี้
      ฉันก็ยังใช้งานที่นั่นอยู่ และสนใจ anti-cheat ฝั่ง user space บน Linux เป็นพิเศษ โดยเฉพาะว่า VAC ทำงานอย่างไร
    • https://pwn.college เป็นสื่อการสอนที่ยอดเยี่ยม

  • ฉันเคยลอง reverse engineering MMO ยอดนิยมที่มี Horde/Alliance เป็นแกนหลัก อยู่บ้าง และมันก็ดูเหมือนทำตามขั้นตอนแทบจะเหมือนกัน รวมถึงมี FNV32 export hash ด้วย
    เห็นว่าใช้ลูกเล่นคล้ายกันมาก เลยดูเหมือนเป็นแนวทางเดียวกันแทบทั้งหมด
    เลยสงสัยว่ามันถูกแพ็กด้วยเทคโนโลยีป้องกันตัวเดียวกันหรือเปล่า

    • Source 2 engine ก็ใช้ fnv กับ schema หรือก็คือการแฮชคุณสมบัติของเอนทิตี
    • ถ้าหลังการควบรวมมีการนำ Warden มาใช้ซ้ำกับทรัพย์สินทางปัญญาของ Activision ก็ฟังดูสมเหตุสมผล

  • Signature scanning ทรงพลังมากจริง ๆ
    สำหรับฉันนี่ก็เป็นส่วนที่น่าติดหนึบที่สุดของ reverse engineering ด้วย
    กระบวนการสร้างรายการซิกเนเจอร์ แล้วเขียน script language bindings เพื่อให้เรียกใช้ function pointers เหล่านั้นได้ เป็นอะไรที่สนุกมาก
    มันยังเป็นรากฐานของแพลตฟอร์มม็อดจากฝั่ง third-party หลายตัวด้วย เพราะต้องเปิดให้ modder เข้าถึง API ที่มีความหมายซึ่งผู้พัฒนาเจ้าของเกมไม่ได้เปิดเผยไว้

    • ฉันไม่รู้ว่า signature scanning คืออะไร แต่ไปหาข้อมูลไว้ให้คนที่สนใจแล้ว: https://www.unknowncheats.me/forum/general-programming-and-r...
    • ใช่เลย
      เท่าที่รู้ ปลั๊กอินของ Source engine บางตัวก็ใช้วิธีนี้เวลา必要
      แต่ดูเหมือนว่าส่วนใหญ่จะใช้ออฟเซ็ตของ virtual function table pointer มากกว่า

  • แอบคิดว่ามันจะเป็นไปได้หรือมีความหมายไหม ถ้าจะป้องกันการโกงด้วยการลงลายเซ็นดิจิทัลให้สถานะของเกมเป็นระยะ ๆ หรือใส่ proof of work บางอย่างเข้าไป
    เริ่มรู้สึกว่าการโกงเป็นปัญหาที่แก้ได้ยากเกินไปจริง ๆ
    ฉันกำลังทำเกม FPS ออนไลน์ขนาดเล็กที่ต้นทุนไม่สูง และแทนที่จะใส่ anti-cheat software ก็คิดว่าจะพึ่งความไว้วางใจกันเองในหมู่ผู้ใช้ ให้ผู้เล่นช่วยกันหาคนโกงเอง หรือใช้ AI แบบที่ Valve ทำ
    น่าจะปล่อยให้ผู้เล่นดูแลและรันเซิร์ฟเวอร์กันเอง
    อาจบังคับผูกเบอร์โทร คะแนนความน่าเชื่อถือจากผู้เล่นคนอื่น การยืนยันตัวตนด้วยบัตรหรือวิธีที่เข้มกว่านั้น การตรวจสอบรูปด้วยคนแบบแอปหาคู่ หรือเงื่อนไขอย่างต้องเล่นให้ครบ 10 ชั่วโมงก่อนลงแข่งจัดอันดับ
    ฉันคิดว่าผู้เล่นสายฮาร์ดคอร์น่าจะยอมทำขั้นตอนพวกนี้เพื่อให้มีคนโกงน้อยลง

    • ถ้าคุณเล่นเกมออนไลน์มาบ้าง คุณก็น่าจะรู้ว่าผู้เล่นมักจะ กล่าวหาว่าโกงกันไม่หยุด แม้มีหลักฐานเพียงน้อยนิด
      ยังมีการนำระบบแบบนี้ไปใช้ในทางสังคมเพื่อกลั่นแกล้ง เช่น รายงานผู้เล่นที่ตัวเองไม่ชอบเพื่อให้โดนแบน
      ในระบบแบบนั้น false positive จะเยอะกว่า anti-cheat แบบไหน ๆ เสียอีก
    • ถ้ามองในระดับสูง ก็แค่จำลองเกมแบบไม่มีชีตแล้วเซ็นรับรองมันไว้ ส่วนชีตก็จัดการแยกออกไปต่างหาก