ทำไมวงการ Security จีนจึงมี ARK Tool มากมาย • un4ckn0wl3z

บทนำ

ถ้าเราเคยค้นหาเครื่องมือสำหรับตรวจสอบ Windows Kernel, ค้นหา hidden process, ตรวจสอบ kernel hook หรือจัดการ driver ที่ไม่สามารถลบออกด้วยเครื่องมือทั่วไปได้ เรามักพบชื่อของเครื่องมือจากประเทศจีนอยู่เสมอ เช่น

IceSword หรือ 冰刃
Wsyscheck
XueTr
PowerTool
ATool
PCHunter
火绒剑 หรือ Huorong Sword

เครื่องมือเหล่านี้มักถูกเรียกรวมกันว่า ARK Tool ซึ่งย่อมาจาก Anti-Rootkit Tool

คำถามที่น่าสนใจคือ

ทำไมวงการ Security ของจีนจึงสร้าง ARK Tool ออกมามากกว่าหลายประเทศ?

คำตอบไม่ได้อยู่ที่ว่าคนจีนมีความชื่นชอบ rootkit เป็นพิเศษ และไม่ควรถูกอธิบายเป็นลักษณะนิสัยของคนทั้งประเทศ แต่เกิดจากการรวมกันของหลายปัจจัย ทั้งยุคทองของ Windows XP, การแพร่ระบาดของมัลแวร์และซอฟต์แวร์ที่ถอนออกยาก, วัฒนธรรมการกำจัดมัลแวร์ด้วยมือ รวมถึงชุมชนนักพัฒนาที่ใช้การสร้าง ARK เป็นเวทีแสดงความเข้าใจด้าน Windows Internals

สำหรับผมแล้ว ARK ไม่ได้เป็นเพียงเครื่องมือสำหรับตรวจจับ rootkit เท่านั้น

การสร้าง ARK Tool คือการสร้างผลงานที่ใช้แสดงว่านักพัฒนาคนนั้นเข้าใจ Windows Kernel ลึกเพียงใด

บทความนี้จะพาย้อนกลับไปดูที่มาของวัฒนธรรม ARK ในจีน ตั้งแต่ IceSword จนถึงเครื่องมือรุ่นใหม่ ก่อนเชื่อมโยงมาถึง DIOPROCESS ซึ่งเป็น Windows research framework ที่ผมพัฒนาขึ้น โดยขยายแนวคิดของ ARK จาก Ring 3 และ Ring 0 ลงไปถึง Hypervisor, UEFI และ System Management Mode

1. ARK Tool คืออะไร

ARK ย่อมาจาก Anti-Rootkit

ตามความหมายดั้งเดิม มันคือเครื่องมือสำหรับตรวจจับสิ่งที่ rootkit พยายามซ่อนจากระบบปฏิบัติการ เช่น

Process
Thread
Driver
File
Registry key
Network connection
Service
Kernel hook

อย่างไรก็ตาม คำว่า ARK ในวงการ Security จีนมีความหมายกว้างกว่าโปรแกรมตรวจจับ rootkit ทั่วไป

ARK ของจีนมักเป็นเครื่องมือแบบ all-in-one ที่สามารถ

แสดง process และ driver ที่ถูกซ่อน
ตรวจสอบ kernel module
ตรวจจับ SSDT และ inline hook
แสดง kernel callbacks
ตรวจสอบ filter driver
แสดงข้อมูล file system และ registry
Terminate process ที่ Task Manager จัดการไม่ได้
Unload driver หรือ module
ลบไฟล์ที่ถูกป้องกัน
Restore โครงสร้างหรือ pointer ที่ถูกแก้ไข

บทความจีนในปี 2011 เคยรวบรวม ARK ยอดนิยมเจ็ดตัว ได้แก่ IceSword, Wsyscheck, Snipesword, SysReveal, XueTr, Superkill และ ATool พร้อมอธิบายความสามารถตั้งแต่ค้นหา hidden process ไปจนถึงจัดการ SSDT, inline hook, kernel modules และ network ports

ดังนั้น ARK Tool จึงไม่ใช่เพียง antivirus ขนาดเล็ก แต่มีลักษณะคล้ายกับการนำเครื่องมือหลายประเภทมารวมกัน

Task Manager
    +
Process Explorer
    +
Autoruns
    +
Kernel Debugger
    +
Rootkit Detector
    +
Driver Inspector
    +
Memory Viewer
    +
Manual Removal Tool
    =
ARK Tool

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

2. เมื่อระบบปฏิบัติการอาจไม่ได้บอกความจริง

โปรแกรมทั่วไปบน Windows มักขอข้อมูลจากระบบปฏิบัติการผ่าน API

ตัวอย่างเช่น โปรแกรมจัดการ process อาจเรียก API เพื่อขอรายการ process ที่กำลังทำงานอยู่

Application
    │
    │ Request process list
    ▼
Windows API
    │
    ▼
Kernel
    │
    ▼
Process information

ปัญหาเกิดขึ้นเมื่อ rootkit เข้าไปแทรกแซงเส้นทางดังกล่าว

Application
    │
    ▼
Windows API
    │
    ▼
Rootkit Hook
    │
    ├── Process A
    ├── Process B
    ├── Process C
    └── Process X ถูกซ่อน

ในกรณีนี้ Task Manager ไม่ได้ทำงานผิดพลาด มันเพียงแสดงข้อมูลที่ระบบปฏิบัติการส่งกลับมาให้เท่านั้น

Rootkit อาจซ่อนตัวเองด้วยวิธีต่าง ๆ เช่น

Hook system call
แก้ไข SSDT
Inline hook kernel function
ใช้ filter driver
แก้ไข linked list ของ kernel object
ปลอมผลลัพธ์จาก API
Intercept file หรือ registry operation

แนวคิดพื้นฐานของ ARK จึงเป็นการถามว่า

ถ้าเส้นทางข้อมูลปกติถูกแก้ไข เราจะตรวจสอบข้อมูลจริงจากเส้นทางอื่นได้หรือไม่?

ตัวอย่างเช่น ARK อาจเปรียบเทียบรายการ process จากหลายแหล่ง

ActiveProcessLinks ─────┐
PspCidTable ────────────┼──> Cross-view comparison
Handle Table ───────────┤
Thread ownership ───────┘

เมื่อ process ปรากฏอยู่ในแหล่งข้อมูลหนึ่ง แต่หายไปจากอีกแหล่งหนึ่ง ก็อาจเป็นสัญญาณว่ามีการแก้ไขโครงสร้างภายใน kernel

เทคนิคนี้มักถูกเรียกว่า Cross-view Detection

3. ยุคทองของ Rootkit บน Windows XP

เหตุผลสำคัญที่ทำให้ ARK Tool เติบโตในจีนคือช่วงเวลาที่มันถือกำเนิดขึ้น

ในยุค Windows XP นักพัฒนา driver สามารถแก้ไขหลายส่วนของ kernel ได้อย่างอิสระกว่าระบบ Windows สมัยใหม่ เทคนิคที่ได้รับความนิยมประกอบด้วย

SSDT Hook
Shadow SSDT Hook
IDT Hook
Inline Hook
DKOM
IRP Hook
Filter Driver
Kernel Object Modification

เทคนิค hook บน Windows XP เขียนได้ไม่ยาก แต่ให้ความสามารถสูงมาก และในเวลานั้นระบบยังไม่มีข้อจำกัดเข้มงวดเหมือน Windows x64 รุ่นใหม่ เมื่อ rootkit เพิ่มจำนวนขึ้น เครื่องมือ ARK จึงเติบโตตามไปด้วย โดย IceSword เป็นหนึ่งในตัวแทนสำคัญของยุคนั้น

สภาพแวดล้อมดังกล่าวสร้างการแข่งขันระหว่างสองฝ่าย

Rootkit ซ่อน Process
        │
        ▼
ARK เพิ่มวิธี Enumerate ใหม่
        │
        ▼
Rootkit วิเคราะห์และหลบ ARK
        │
        ▼
ARK ลงไปอ่าน Kernel Structure โดยตรง
        │
        ▼
Rootkit โจมตี Driver หรือ Communication ของ ARK

มันคือเกมแมวไล่จับหนูที่ไม่มีฝ่ายใดชนะอย่างถาวร

4. 手工杀毒 — วัฒนธรรมการกำจัดมัลแวร์ด้วยมือ

หนึ่งในคำสำคัญของวงการ Security จีนยุคนั้นคือ

手工杀毒 — Shǒugōng shādú

แปลตรงตัวได้ว่า การกำจัดไวรัสด้วยมือ

แทนที่จะติดตั้ง antivirus แล้วกด Scan ผู้ใช้ระดับสูงจะเปิด ARK และตรวจสอบระบบทีละส่วนด้วยตัวเอง

ตรวจ Process
      ↓
ตรวจ Module
      ↓
ตรวจ Driver
      ↓
ตรวจ Startup Entry
      ↓
ตรวจ File และ Registry
      ↓
ตรวจ Hook และ Callback
      ↓
Terminate / Unload / Delete / Restore

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

คำว่า 操控感 สามารถอธิบายได้ว่าเป็นความรู้สึกที่ผู้ใช้สามารถควบคุมระบบได้โดยตรง ARK จีนจำนวนมากจึงไม่ได้เน้นเพียงการตรวจจับ แต่ยังให้ผู้ใช้ terminate, unload, restore หรือลบสิ่งผิดปกติด้วยตัวเอง

นี่ไม่ได้หมายความว่าต่างประเทศไม่มีเครื่องมือที่ดี เพราะยังมีเครื่องมืออย่าง RootkitRevealer, BlackLight, GMER และ Kernel Detective

ความแตกต่างอยู่ที่แนวทางการออกแบบ

Automated Security Product
    └── โปรแกรมเป็นผู้ตัดสินใจ

ARK Tool
    └── นักวิเคราะห์เป็นผู้ตัดสินใจ

5. 软件流氓 — เมื่อปัญหาไม่ได้มีเพียงไวรัส

อีกหนึ่งบริบทสำคัญคือการแพร่ระบาดของ 软件流氓 หรือซอฟต์แวร์อันธพาล

โปรแกรมประเภทนี้อาจไม่ได้ทำตัวเหมือนไวรัสแบบดั้งเดิมเสมอไป แต่มักมีพฤติกรรมเช่น

ติดตั้งพ่วงมากับโปรแกรมอื่น
แทรก browser
เปลี่ยน homepage
สร้าง startup entries
ป้องกัน process ของตัวเอง
ใช้ driver ป้องกันไฟล์และ registry
ถอนการติดตั้งได้ยาก
สร้าง process กลับขึ้นมาใหม่หลังถูกปิด

เมื่อซอฟต์แวร์ใช้ kernel driver ป้องกันตัวเอง เครื่องมือจัดการไฟล์หรือ Task Manager ธรรมดาจึงอาจไม่สามารถลบมันได้

IceSword ถูกนำมาใช้จัดการปัญหาประเภทนี้ เพราะสามารถมองเห็น hidden process, driver และข้อมูลที่ไม่ปรากฏผ่านเครื่องมือปกติ รวมถึงจัดการไฟล์หรือ registry ที่ถูก driver ป้องกันไว้ได้

ดังนั้น ARK ในจีนไม่ได้เป็นเพียงเครื่องมือในห้องแล็บของนักวิจัยมัลแวร์ แต่ยังเป็นเครื่องมือซ่อมระบบสำหรับผู้ใช้ระดับสูงด้วย

6. IceSword — จุดเริ่มต้นของตำนาน ARK จีน

เมื่อพูดถึง ARK จีน ชื่อแรกที่มักถูกกล่าวถึงคือ IceSword หรือ 冰刃

IceSword ถูกพัฒนาโดยโปรแกรมเมอร์จีนที่ใช้ชื่อว่า pjf_ และได้รับชื่อเสียงอย่างมากในช่วงประมาณปี 2005

หน้าตาของมันมีลักษณะคล้าย Windows Explorer แต่สามารถแสดงสิ่งที่ Windows Explorer หรือ Task Manager ไม่สามารถมองเห็นได้ เช่น

Hidden process
Hidden file
Hidden service
Hidden registry entry
Kernel module
Protected object

สิ่งที่ทำให้ IceSword กลายเป็นตำนานไม่ใช่เพียงจำนวนฟังก์ชัน แต่เป็นความสามารถในการต่อสู้กับ rootkit ที่มีอยู่จริง

ในปี 2005 ผู้พัฒนา Hacker Defender ซึ่งเป็น rootkit ที่มีชื่อเสียงในยุคนั้น ระบุว่า IceSword เป็นเครื่องมือ Anti-Rootkit ที่สามารถตรวจจับ Hacker Defender ได้ และมองว่ามันเป็นความท้าทายที่เขาต้องการเอาชนะ

เหตุการณ์นี้แสดงให้เห็นว่า IceSword ไม่ได้เป็นเพียงโปรแกรมดูข้อมูลระบบ แต่ได้รับการยอมรับจากฝั่งผู้พัฒนา rootkit ว่าเป็นคู่ต่อสู้ทางเทคนิค

นี่คือธรรมชาติของ ARK

ARK ไม่ได้ยืนอยู่นอกสนามรบ แต่มันเป็นส่วนหนึ่งของสนามรบ

7. จาก IceSword สู่ XueTr และ PCHunter

หลังจาก IceSword ประสบความสำเร็จ เครื่องมือ ARK รุ่นใหม่ก็เริ่มปรากฏขึ้น

7.1 Wsyscheck

Wsyscheck เน้นความสะดวกในการใช้งาน สามารถตรวจสอบ process, service, module และ file system พร้อมใช้สีช่วยแยกรายการที่น่าสงสัย

มันแสดงให้เห็นว่า ARK ไม่จำเป็นต้องเป็นเครื่องมือที่มีแต่หน้าต่าง hexadecimal หรือข้อมูลดิบเสมอไป การออกแบบ interface ที่ช่วยให้นักวิเคราะห์มองเห็นความผิดปกติได้รวดเร็วก็เป็นส่วนสำคัญเช่นกัน

7.2 XueTr

XueTr ขยายขอบเขตของ ARK อย่างมาก โดยรวมความสามารถหลายประเภทไว้ในโปรแกรมเดียว เช่น

Process, thread และ module inspection
SSDT และ Shadow SSDT inspection
IDT inspection
Kernel callback enumeration
Filter driver inspection
Object type hook detection
Kernel patch detection
File system และ registry management
Inline hook detection และ restoration

รายการความสามารถของ XueTr แสดงให้เห็นว่า ARK เริ่มเปลี่ยนจากเครื่องมือกำจัด rootkit ไปเป็น Windows Kernel Inspection Platform

7.3 PCHunter

เมื่อ Windows เปลี่ยนเข้าสู่ยุค x64 เครื่องมือจำนวนมากหยุดพัฒนาเพราะต้องรับมือกับ

Driver Signature Enforcement
Kernel Patch Protection
ความแตกต่างของโครงสร้างใน Windows แต่ละรุ่น
การเปลี่ยนแปลงของ internal symbols และ offsets
กลไกป้องกัน kernel ที่ซับซ้อนขึ้น

PCHunter กลายเป็นหนึ่งในชื่อที่ยังถูกพูดถึงในฐานะผู้สืบทอดแนวคิด ARK บน Windows รุ่นใหม่กว่า

เมื่อ Windows 10 และระบบ x64 แพร่หลาย จำนวน ARK ที่ยังใช้งานได้จริงลดลงอย่างมาก เพราะการพัฒนาเครื่องมือประเภทนี้ต้องรับมือกับข้อจำกัดด้าน driver signing และการป้องกันข้อมูลสำคัญของ kernel

8. ทำไมการสร้าง ARK จึงเป็นการโชว์ความรู้ด้าน Kernel

ผู้ใช้ทั่วไปอาจมองเห็นเพียง GUI ที่มีรายการ process, driver และ callback

แต่สิ่งที่อยู่เบื้องหลัง ARK หนึ่งตัวมีความซับซ้อนกว่านั้นมาก

ความสามารถของ ARK	ความรู้ที่นักพัฒนาต้องมี
แสดง Process และ Thread	Windows Process Manager, EPROCESS, ETHREAD
ค้นหา Hidden Process	DKOM, Cross-view Detection, Handle Table
แสดง Driver และ Kernel Module	PsLoadedModuleList, PE Format, Loader Internals
ตรวจ SSDT และ Inline Hook	Assembly, Disassembly, Calling Convention
แสดง Kernel Callback	Callback Internals, Symbols, Reverse Engineering
ตรวจ Filter Driver	I/O Manager, Device Stack, IRP
ตรวจ File และ Registry	File System Driver, Configuration Manager
อ่าน Process Memory	Virtual Memory Manager, VAD, Page Table
ตรวจ User-mode Hook	PE Import/Export, IAT, EAT, Code Integrity
สื่อสารระหว่าง GUI กับ Driver	IOCTL, Shared Memory, Synchronization
รองรับ Windows หลายรุ่น	Symbols, Signatures, Dynamic Offset Resolution
ป้องกัน BSOD	IRQL, Locking, Reference Counting, Race Condition

การเขียน ARK จึงไม่ใช่เพียงการเขียน driver ที่สามารถอ่าน memory ได้

นักพัฒนาต้องเข้าใจว่า

Object ถูกสร้างและทำลายเมื่อใด
Pointer ใดมีอายุการใช้งานนานเพียงใด
ต้องเพิ่มและลด reference count ตรงไหน
Code สามารถทำงานที่ IRQL ระดับใด
โครงสร้างใดได้รับการป้องกัน
ข้อมูลใดเปลี่ยนไปตาม Windows build
การอ่านข้อมูลพร้อมกับ kernel ที่กำลังแก้ไขข้อมูลนั้นจะเกิด race condition หรือไม่

Driver ที่สามารถแสดง process ได้หนึ่งครั้งไม่ใช่เรื่องยากที่สุด

สิ่งที่ยากกว่าคือทำให้มัน

ทำงานได้อย่างเสถียร
ไม่ทำให้เครื่อง BSOD
รองรับหลาย Windows builds
แสดงข้อมูลที่เชื่อถือได้
ทำงานในระบบที่อาจพยายามหลอกหรือโจมตีตัวเครื่องมือ

GUI ของ ARK เป็นเพียงยอดภูเขาน้ำแข็ง ส่วนที่อยู่ใต้น้ำคือ Windows Internals, Reverse Engineering และ Kernel Engineering

ด้วยเหตุนี้ นักพัฒนา ARK จำนวนมากจึงไม่ได้สร้างเครื่องมือเหล่านี้เพื่อแข่งขันกับบริษัท Antivirus โดยตรง

พวกเขาสร้างมันเพื่อพิสูจน์ว่า

“ผมเข้าใจ Windows ลึกพอที่จะมองเห็นสิ่งที่ระบบปฏิบัติการปกติไม่แสดงออกมา”

9. ARK คือ Portfolio ของนักพัฒนา Kernel

ในสาย Web Development เราสามารถแสดงความสามารถผ่านเว็บไซต์หรือระบบที่สร้างขึ้น

ในสาย Game Development เราอาจสร้าง game engine หรือเกมหนึ่งตัว

ในสาย Compiler เราอาจสร้างภาษาโปรแกรมหรือ virtual machine

สำหรับสาย Windows Kernel การสร้าง ARK Tool เป็นหนึ่งในผลงานที่สามารถรวมความรู้แทบทุกส่วนไว้ในโปรเจกต์เดียว

Windows Internals
        +
Kernel Driver Development
        +
Reverse Engineering
        +
Assembly
        +
Memory Management
        +
Operating System Design
        +
Security Research
        +
GUI Development
        =
ARK Tool

ผู้สร้าง ARK ไม่จำเป็นต้องอธิบายเป็นร้อยหน้าว่าเขาเข้าใจ kernel มากเพียงใด

เพียงเปิดโปรแกรม แล้วแสดงให้เห็นว่าเครื่องมือสามารถ enumerate, compare, inspect และอธิบายโครงสร้างภายในระบบได้อย่างถูกต้อง ผลงานก็พูดแทนตัวผู้สร้างแล้ว

ARK จึงมีสถานะคล้ายกับงานประเภทต่อไปนี้

การสร้าง Debugger
การสร้าง Disassembler
การสร้าง Hypervisor
การสร้าง Operating System
การสร้าง Antivirus Engine
การสร้าง Memory Forensics Framework

แต่ ARK มีลักษณะพิเศษ เพราะมันต้องทำงานอยู่ภายในระบบที่อาจถูกแก้ไขโดยคู่ต่อสู้

10. ความเป็น Dual-use ของ ARK

เทคนิคจำนวนมากใน ARK สามารถใช้ได้ทั้งฝ่ายป้องกันและฝ่ายโจมตี

เทคนิค	ฝ่ายป้องกัน	ฝ่ายโจมตี
Enumerate Callback	ตรวจสอบตำแหน่งของ Security Software	ค้นหา Callback เพื่อหลบการตรวจสอบ
อ่าน Physical Memory	ตรวจสอบความสอดคล้องของ Kernel	หลีกเลี่ยง API Monitoring
ตรวจ Hook	ค้นหา Rootkit	ค้นหา Hook ของ EDR
แก้ Process Structure	Restore ความเสียหาย	ซ่อนหรือเปลี่ยนสถานะ Process
EPT Hook	สร้าง Stealth Monitor	เปลี่ยน Execution View
UEFI Inspection	ตรวจสอบ Boot Integrity	แทรกแซงระบบก่อน OS ทำงาน

นี่เป็นเหตุผลว่าทำไม ARK บางตัวจึงถูก Antivirus ระบุเป็น HackTool แม้ว่าตัวเครื่องมือจะถูกสร้างขึ้นเพื่อวิเคราะห์ระบบก็ตาม

สิ่งที่แยก ARK, rootkit และ offensive tool ออกจากกันจึงไม่ใช่ API หรือเทคนิคที่ใช้เพียงอย่างเดียว แต่ประกอบด้วย

วัตถุประสงค์
วิธีแจกจ่าย
ผู้ควบคุมเครื่องมือ
การได้รับอนุญาต
สภาพแวดล้อมที่นำไปใช้งาน

คนที่จะตรวจจับการบิดเบือนระบบได้ ต้องเข้าใจวิธีบิดเบือนระบบเสียก่อน

11. เมื่อ ARK แบบดั้งเดิมเริ่มไม่เพียงพอ

Windows รุ่นใหม่เพิ่มกลไกป้องกัน kernel หลายชั้น

11.1 Driver Signature Enforcement

Windows x64 กำหนดให้ kernel-mode driver ต้องมีลายเซ็นที่เหมาะสมก่อนจึงจะสามารถโหลดได้

11.2 Kernel Patch Protection

Kernel Patch Protection หรือ PatchGuard ทำให้การแก้ไขโครงสร้างสำคัญของ kernel โดยตรงมีความเสี่ยงที่จะทำให้ระบบหยุดทำงาน

11.3 Virtualization-based Security

Windows เริ่มใช้ virtualization เพื่อแยกข้อมูลและ security component สำคัญออกจาก kernel ปกติ

11.4 ความแตกต่างระหว่าง Windows Builds

Internal structures และ implementation details เปลี่ยนแปลงได้ในแต่ละ build ทำให้เครื่องมือที่อาศัย hardcoded offset มีอายุการใช้งานสั้น

ผลคือ ARK รุ่นใหม่ต้องเปลี่ยนแนวทาง

ยุค Windows XP
    │
    ├── SSDT Hook Detection
    ├── Inline Hook Detection
    └── Hidden Process Detection
            │
            ▼
ยุค Windows x64
    │
    ├── Callback Inspection
    ├── Filter Driver Inspection
    ├── ETW และ Telemetry
    ├── Cross-view Enumeration
    ├── Hypervisor-based Inspection
    └── Firmware Integrity

ARK ไม่ได้หายไป แต่มันเปลี่ยนจากเครื่องมือกำจัด rootkit ให้กลายเป็น framework สำหรับสำรวจ trust boundary ของระบบ

12. DIOPROCESS — จาก Process Monitor สู่ Post-ARK Framework

DIOPROCESS คือโปรเจกต์ที่ผมพัฒนาขึ้นเพื่อศึกษา Windows Internals และการทำงานของระบบในหลาย privilege levels

จุดเริ่มต้นของมันคือ Windows process monitor ที่สามารถตรวจสอบ process, thread, handle, module, memory region, network connection และ system events ได้

ในภายหลังโปรเจกต์ถูกขยายให้มี kernel driver สำหรับงานวิจัย เช่น kernel callback enumeration, PspCidTable enumeration, process protection inspection และการวิเคราะห์ hook

อย่างไรก็ตาม เป้าหมายของ DIOPROCESS ไม่ได้หยุดอยู่ที่การเป็น Task Manager ที่มีฟังก์ชันมากขึ้น

มันถูกพัฒนาให้เป็น research framework ที่ครอบคลุมหลายระดับของระบบ

┌─────────────────────────────────────────────────────┐
│ Ring 3   │ DIOPROCESS User Interface                │
│          │ Process, Thread, Module, Memory, Network │
├──────────┼──────────────────────────────────────────┤
│ Ring 0   │ Windows Kernel Driver                    │
│          │ Kernel Object and Callback Research      │
├──────────┼──────────────────────────────────────────┤
│ Ring -1  │ Intel VT-x Hypervisor                    │
│          │ EPT, Hypercall, Memory Inspection        │
├──────────┼──────────────────────────────────────────┤
│ Pre-OS   │ UEFI Application / DXE Runtime Driver   │
│          │ Boot Process and Runtime Communication   │
├──────────┼──────────────────────────────────────────┤
│ Ring -2* │ System Management Mode                  │
│          │ Firmware-level Memory Research           │
└──────────┴──────────────────────────────────────────┘

* Ring -2 เป็นคำเรียกแบบไม่เป็นทางการเพื่ออธิบายตำแหน่งของ SMM

สถาปัตยกรรมส่วน firmware ประกอบด้วย module สำคัญ ได้แก่

DioProcessEfi
DioProcessDxe
DioProcessSmm

DioProcessEfi ใช้ศึกษาเส้นทางการ boot และช่วงเปลี่ยนผ่านระหว่าง UEFI กับระบบปฏิบัติการ

DioProcessDxe ทำหน้าที่เป็น runtime component และสะพานเชื่อมระหว่างโลกของ firmware กับระบบปฏิบัติการ

DioProcessSmm ใช้ศึกษาการสื่อสารและ memory operation ภายใน System Management Mode ซึ่งแยกออกจาก address space ปกติของระบบปฏิบัติการ

13. DNA ของ ARK ภายใน DIOPROCESS

แม้ว่า DIOPROCESS จะมีขอบเขตกว้างกว่า Anti-Rootkit Tool แบบดั้งเดิม แต่แนวคิดพื้นฐานยังคงเหมือนกัน

อย่าเชื่อข้อมูลจากเส้นทางเดียว และอย่าถือว่าระดับที่เรากำลังทำงานอยู่คือแหล่งความจริงสูงสุดเสมอไป

13.1 เมื่อ Ring 3 อาจถูกหลอก

เราตรวจสอบข้อมูลจาก kernel และเปรียบเทียบข้อมูลจากหลายแหล่ง

13.2 เมื่อ Ring 0 อาจถูกแก้ไข

เราสามารถใช้ Hypervisor เป็นอีกมุมมองหนึ่งในการตรวจสอบ execution และ memory

13.3 เมื่อระบบถูกแทรกแซงก่อน Kernel

เราต้องศึกษากระบวนการ boot, UEFI และ firmware components

13.4 เมื่อ Hypervisor ยังไม่ใช่ระดับล่างสุด

เราต้องทำความเข้าใจ SMM, SMRAM และกลไกของ platform firmware

เส้นทางวิวัฒนาการของ DIOPROCESS จึงสามารถเขียนได้ดังนี้

Process Monitor
      │
      ▼
Windows Internals Tool
      │
      ▼
Kernel Research Tool
      │
      ▼
Anti-Rootkit / Rootkit Research
      │
      ▼
Hypervisor Research
      │
      ▼
UEFI and SMM Research
      │
      ▼
DIOPROCESS

14. ARK แบบดั้งเดิมกับ DIOPROCESS

หัวข้อ	ARK แบบดั้งเดิม	DIOPROCESS
เป้าหมายเริ่มต้น	ตรวจจับและกำจัด Rootkit	Windows Internals และ Security Research
User mode	Process, File, Registry, Network	Process, Thread, Handle, Module, Memory, Events
Kernel mode	Driver, Hook, Callback, Hidden Object	Kernel Objects, Callbacks, Memory และ Process Research
Cross-view	เปรียบเทียบข้อมูลหลายแหล่งใน Kernel	เปรียบเทียบข้อมูลข้าม User, Kernel และ Hypervisor
Hypervisor	โดยทั่วไปไม่มี	Intel VT-x และ EPT Research
UEFI	โดยทั่วไปไม่มี	UEFI Application และ DXE Runtime Components
SMM	ไม่มี	SMM Communication และ Memory Research
ลักษณะเครื่องมือ	Manual Rootkit Removal Tool	Multi-layer Windows Research Framework
คุณค่าด้าน Portfolio	แสดงความรู้ Windows Kernel	แสดงความรู้ตั้งแต่ Ring 3 ถึง Firmware

ผมจึงมอง DIOPROCESS ว่าเป็นเครื่องมือในกลุ่ม

Modern Post-ARK Windows Research Framework

มันไม่ได้แทนที่ IceSword หรือ PCHunter และไม่ได้พยายามทำหน้าที่เหมือน antivirus

แต่มันนำคำถามพื้นฐานของ ARK มาขยายต่อ

จากเดิมที่ถามว่า

มี process หรือ driver อะไรถูกซ่อนจาก Windows หรือไม่?

กลายเป็นคำถามว่า

ข้อมูลที่เราเห็นมาจาก privilege level ใด และระดับนั้นสามารถถูกหลอกได้อย่างไร?

15. การสร้าง DIOPROCESS ในฐานะ Portfolio

การเพิ่มจำนวนฟีเจอร์ไม่ใช่เป้าหมายเดียวของ DIOPROCESS

แต่ละส่วนของโปรเจกต์เป็นแบบฝึกหัดสำหรับทำความเข้าใจระบบคนละด้าน

Component	สิ่งที่ต้องศึกษา
User Interface	Desktop Architecture, State Management, FFI
User-mode Inspector	Win32, Native API, PE, Process Internals
Kernel Driver	WDK, Object Manager, Memory Manager, Synchronization
Hypervisor	VMX, VMCS, EPT, DPC, Multi-core Virtualization
UEFI Application	Boot Services, Runtime Services, PE/COFF
DXE Driver	UEFI Protocols, Events, Virtual Address Conversion
SMM Driver	SMI, SMRAM, MM Communication, Page Table
Communication Layer	IOCTL, Shared Buffer, ABI, Validation
Multi-version Support	Symbols, Signatures, Offsets, Compatibility

การทำให้แต่ละ component ทำงานแยกจากกันเป็นเรื่องหนึ่ง

แต่การทำให้ทุก component สื่อสารและทำงานร่วมกันเป็นระบบเดียวคือความท้าทายอีกระดับหนึ่ง

GUI
 │
 ▼
User-mode Controller
 │
 ▼
Kernel Driver
 │
 ├────────> Hypervisor
 │
 └────────> UEFI Runtime Component
                  │
                  ▼
                 SMM

นี่คือเหตุผลที่ผมมองว่าโปรเจกต์ประเภท ARK เป็นงานโชว์ความสามารถที่ดีสำหรับนักพัฒนา kernel

มันไม่ได้แสดงเพียงว่าเราสามารถเขียน driver ได้ แต่แสดงว่าเราเข้าใจความสัมพันธ์ระหว่าง component ต่าง ๆ ของระบบ

16. ARK ไม่ได้ตาย แต่มันเปลี่ยนรูปร่าง

ในปัจจุบัน ผู้ใช้ทั่วไปอาจไม่จำเป็นต้องเปิด ARK เพื่อกำจัดมัลแวร์ด้วยมือเหมือนในยุค Windows XP แล้ว

Antivirus และ EDR มีระบบตรวจจับอัตโนมัติที่ดีขึ้น ขณะที่ Windows เพิ่มกลไกป้องกัน kernel และ firmware มากขึ้น

แต่แนวคิดของ ARK ยังคงอยู่ในเครื่องมือหลายประเภท

EDR diagnostic tools
Memory forensic frameworks
Kernel debuggers
Anti-cheat diagnostic tools
Hypervisor-based monitors
Firmware integrity tools
Incident response tools
Threat research frameworks

ทุกเครื่องมือยังคงพยายามตอบคำถามเดียวกัน

เราจะสร้างมุมมองที่ผู้โจมตีแก้ไขหรือหลอกได้ยากกว่าเดิมได้อย่างไร?

ในยุคหนึ่ง คำตอบคือ kernel driver

ในอีกยุคหนึ่ง คำตอบอาจเป็น hypervisor

สำหรับภัยคุกคามบางประเภท คำตอบอาจต้องลงไปถึง UEFI, SMM หรือ external hardware

แต่ไม่มีระดับใดเป็นแหล่งความจริงที่สมบูรณ์ตลอดไป

ทุกระดับมี trust assumption ของตัวเอง

17. สรุปท้ายบท

สาเหตุที่วงการ Security จีนมี ARK Tool จำนวนมากไม่ได้เกิดจากเหตุผลเดียว แต่เป็นผลจากองค์ประกอบหลายด้าน

Windows XP เปิดโอกาสให้ rootkit และ kernel hook เติบโตอย่างรวดเร็ว
มัลแวร์และ软件流氓จำนวนมากใช้ driver ป้องกัน process, file และ registry ของตัวเอง
วัฒนธรรม手工杀毒ให้ความสำคัญกับการวิเคราะห์และกำจัดภัยคุกคามด้วยมือ
ผู้ใช้ต้องการ操控感 หรือความรู้สึกว่าสามารถควบคุมระบบได้โดยตรง
ชุมชนนักพัฒนาใช้ ARK เป็นพื้นที่ทดลอง Windows Internals และ Reverse Engineering
การสร้าง ARK เป็นวิธีแสดงความรู้ด้าน kernel ที่มองเห็นได้ผ่านผลงานจริง

IceSword แสดงให้เห็นว่าโปรแกรมเมอร์คนหนึ่งสามารถสร้างเครื่องมือที่กลายเป็นคู่ต่อสู้ของ rootkit ระดับนานาชาติได้

XueTr และเครื่องมือรุ่นต่อมาแสดงให้เห็นว่า ARK สามารถวิวัฒนาการเป็นแพลตฟอร์มสำหรับสำรวจ Windows Kernel ได้

DIOPROCESS คือการนำแนวคิดนั้นมาพัฒนาต่อในบริบทของระบบสมัยใหม่

จาก Process Monitor ไปยัง Kernel Driver

จาก Kernel Driver ไปยัง Hypervisor

จาก Hypervisor ไปยัง UEFI และ SMM

ท้ายที่สุดแล้ว แก่นของ ARK ไม่ได้อยู่ที่จำนวน process ที่มันสามารถ terminate ได้ หรือจำนวน hook ที่มันสามารถตรวจจับได้

แก่นของมันคือความพยายามค้นหาความจริงในระบบที่ข้อมูลทุกชั้นสามารถถูกแก้ไขได้

เมื่อระบบปฏิบัติการสามารถโกหกเราได้ เราจะลงไปตรวจสอบความจริงจากชั้นไหน?

และนั่นคือคำถามเดียวกับที่ผลักดันทั้งผู้สร้าง IceSword ในอดีต และผลักดันให้ผมสร้าง DIOPROCESS ในปัจจุบัน

Happy Hacking :)

References

Antiy, 反Rootkit工具的发展演进, 2016
https://wtc.antiy.cn/download/2016010710.pdf
Brian Livingston, IceSword Author Speaks Out on Rootkits, Datamation, 2005
https://www.datamation.com/trends/icesword-author-speaks-out-on-rootkits/
手工杀毒利器，反Rootkit工具（ARK）中的七种武器, 2011
https://www.cnblogs.com/fslnet/articles/2041542.html
Microsoft Learn, Kernel-Mode Code Signing Requirements for Windows Drivers
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-requirements—windows-vista-and-later-
DIOPROCESS
https://github.com/un4ckn0wl3z/dioprocess-private