테마

DMA / L0 안전 깊이 ​

DMA 보드는 호스트 밖에서 메모리를 읽으므로 프로세스·파일 흔적이 거의 없다. 장치 열거, 환경 상태, 제보를 합산해 가능성을 평가한다. 호스트 증거만으로 DMA를 Confirmed하는 절차는 없으며, 기본 출발점은 Insufficient다.

왜 DMA가 마지막인가 ​

DMA(Direct Memory Access) 장치는 호스트 안티치트와 물리적으로 분리되어 있다.

버스 마스터링은 장치가 CPU·OS를 거치지 않고 물리 메모리에 직접 접근하는 방식이다. PCILeech 계열의 공개 설명도 "타깃에 드라이버가 없어도 된다"는 점을 전제로 한다. 호스트 PC에서 프로세스·파일·드라이버 흔적이 나오지 않을 수 있는 이유이고, Ring3·Ring0에서 찾을 수 있는 증거가 가장 적은 레이어이므로 마지막에 체크한다.

흔적이 없다고 치트가 없다는 증명이 되지 않고, 환경 설정이 열려 있다고 치트가 있다는 증명도 되지 않는다. DMA 체크는 확정하는 절차가 아니라 가능성을 평가하고 증거를 수집하는 절차다.

진입 조건 ​

에스컬레이션 판단에서 DMA 트리거가 있을 때만 진행한다.

조건예시
원격 접속 프로세스 + 비정상 타임라인TeamViewer가 게임 세션 중 활성(검사 세션 자신의 연결은 제외)
제보에 "2PC"·"퓨저"·"외부 장치" 언급"컴 두 대로 돌린다"는 취지의 제보
Ring3가 설명 못 함 + 강한 행동 제보"상대 위치를 다 안다"는 제보인데 호스트 흔적이 없음
알 수 없는 PCIe·USB 장치 발견장치 관리자에 설명되지 않는 장치
외부 입력 장치 정황 + 행동 제보설명되지 않는 추가 마우스·키보드나 USB 시리얼 장치, 반복 연결 이력에 "조준·반응이 비정상"이라는 제보가 겹침
IOMMU·DMA Protection 꺼짐 + 행동 제보환경 가중

모든 SS에 기본 포함이 아니다. 진입 조건이 맞지 않으면 건너뛴다.

원격 연결 단서를 해석할 때는 지금 진행 중인 검사 세션 자체의 AnyDesk·TeamViewer 연결을 제외한다. 검사가 원격 세션 위에서 이뤄지므로, 그 흔적을 치트 단서로 오인하지 않는다.

PCIe·버스 장치 열거 ​

시스템에 연결된 장치를 확인하고, 설명할 수 없는 장치를 찾는다. DMA 장치는 PCIe 슬롯·M.2·Thunderbolt 등 버스 마스터가 가능한 인터페이스 어디에든 올 수 있다.

  1. 장치 관리자 → 보기 → 숨겨진 장치 표시. 과거에 연결됐다가 빠진 장치까지 보인다.
  2. 네트워크 어댑터, 시스템 장치, 기타 장치, 저장소 컨트롤러, USB 컨트롤러·허브를 살핀다.
  3. 드라이버가 없거나 문제 코드가 붙은 장치를 기록한다.
  4. 속성 → 세부 정보 → Hardware Ids / Compatible Ids를 복사한다.
  5. VEN_XXXX&DEV_XXXX를 PCI ID 데이터베이스로 대조한다.
  6. USBDeview 또는 USB 기록에서 FTDI FT601 계열 브릿지·반복 연결 장치를 확인한다.
  7. pnputil /enum-devices(Windows 10 1903 이상)로 전체 장치 목록을 텍스트로 확보해 둔다. /class 필터로 클래스별 열거도 가능하다.
  8. setupapi.dev.log나 Kernel-PnP 이벤트에서 연결·해제 타임라인을 본다.

숨겨진 장치 표시가 중요한 이유: DMA 장치는 세션 전후로 꽂았다 뺐다 하기 쉽고, 지금 연결돼 있지 않은 장치의 등록 흔적이 남는다. "장치 이력 청소"라는 우회 시도가 알려져 있다는 사실 자체가 이 축이 탐지 포인트임을 보여준다.

문제 코드 해석 ​

문제 코드는 "장치가 정상 동작하지 않는다"는 Windows의 일반 진단이지, 악성 장치 전용 표시가 아니다. 맥락으로 읽고 단독 증거로 쓰지 않는다.

코드Microsoft 표현DMA 맥락에서의 의미
Code 10"This device cannot start."장치가 시작되지 못함. 위장 클래스(예: Wi-Fi 카드로 보이려는 FPGA)의 드라이버 미스매치로도 생길 수 있으나, 실제 고장 장치가 훨씬 흔하다
Code 28드라이버 미설치드라이버 없는 장치. 커스텀 장치 가능성도 있으나 새 하드웨어·미설치 주변기기가 흔하다
Code 43장치가 오류를 보고해 중지됨하드웨어 또는 드라이버 실패 보고. 비특이적

Code 10·28·43은 "설명해야 할 장치" 목록을 만드는 용도다. 노란 느낌표 + 알 수 없는 VEN/DEV + 세션 전후의 장치 삭제 흔적이 겹칠 때 비로소 의미가 생긴다.

Kernel-PnP · setupapi 타임라인 ​

장치의 설치·시작·제거는 이벤트로 남는다. Microsoft-Windows-Kernel-PnP 계열 이벤트와 %SystemRoot%\INF\setupapi.dev.log를 세션 전후로 정렬한다.

이벤트의미(비공식 정리)
Kernel-PnP 400장치 구성됨
Kernel-PnP 401장치 구성 실패
Kernel-PnP 410장치 시작됨
Kernel-PnP 411장치 시작 문제
Kernel-PnP 420장치 삭제됨
Kernel-PnP 430추가 설치 필요

관심 패턴은 "세션 직전 설치 → 세션 중 또는 직후 삭제"다. 도킹 스테이션(독) 연결이 잦은 사용자는 매일 비슷한 패턴이 나오므로 장치 종류와 반복성을 함께 본다.

이상 신호 ​

신호의미
드라이버 없는 장치(Code 28/43)커스텀 장치 또는 스푸핑. 단독으로는 실패 맥락일 뿐
알 수 없는 PCI VEN/DEV IDDMA 카드 또는 FPGA 보드 가능성
위장 클래스 + 시작 실패Wi-Fi·NIC 등으로 보이려는 장치가 Code 10으로 멈춤(스푸핑 실패 시 나타나는 전형적 패턴)
네트워크 어댑터 수가 설명 불가가상 NIC 또는 추가 장치
재부팅 후 사라지는 장치세션 중에만 연결됐던 장치

장치 열거의 한계 ​

장치 목록이 깨끗해도 DMA는 배제되지 않는다. 장치 관리자에서 정상 장치처럼 보이도록 만든 변종이 알려져 있다.

  • Intel VMD 악용. Intel VMD(Volume Management Device)로 NVMe·PCIe 토폴로지를 바꿔 DMA 카드의 PCIe 존재를 OS에서 숨기는 방식이다. VMD 자체는 정상 구성이다. Dell은 Intel 11~14세대 CPU 기기가 VMD를 쓰며 Windows를 설치할 때 Intel RST VMD 드라이버가 필요하다고 안내하고, 이런 기기의 장치 관리자에는 "Intel RST VMD Controller"가 있다. 노트북·OEM 데스크톱의 VMD 컨트롤러는 단독 신호로 쓰지 않는다.
  • 저장 장치 에뮬레이션. DMA 하드웨어가 저장 장치로 행세해 장치 관리자에 정상 하드 드라이브로 나타나고 저장 드라이버의 질의에도 제대로 답한다.
  • 중간자 구성. 정상 NVMe SSD나 네트워크 카드를 치트 하드웨어 뒤에 연결해, 장치 관리자에는 정상 동작 장치로 보이게 한다.

Intorqa는 FACEIT 환경을 감사하면서 저장 장치 에뮬레이션과 중간자 구성이 IOMMU로 막힌다고 평가했다. 장치 목록 확인과 별도로 IOMMU 상태를 기록해야 하는 이유다.

IOMMU / Kernel DMA Protection 상태 ​

Kernel DMA Protection이 활성화되어 있으면 권한 없는 핫플러그 장치가 메모리에 직접 접근하는 것이 제한된다.

확인 항목방법
Kernel DMA Protectionmsinfo32 → "Kernel DMA Protection" On/Off
VT-d(Intel) / AMD-Vi(AMD) · IOMMUUEFI/BIOS 설정
Secure Bootmsinfo32 → "Secure Boot State"
VBSmsinfo32 → "Virtualization-based security"
메모리 무결성(HVCI)Windows 보안 → 코어 격리
상태의미
DMA Protection On권한 없는 핫플러그 장치의 메모리 직접 접근 제한
DMA Protection Off + 알 수 없는 PCIe 장치신호 강화
Secure Boot 꺼짐 + DMA Protection 꺼짐환경 점수 하락

두 가지 주의가 있다. 첫째, DMA Protection이 꺼져 있다고 DMA 치트가 있다는 뜻이 아니다. 구형 마더보드는 이 기능 자체를 지원하지 않는다. 둘째, 켜져 있다고 Clean도 아니다. Kernel DMA Protection은 핫플러그 Thunderbolt 계열 장치를 중심으로 동작하며, 내부 PCIe 슬롯의 장치는 별도 문제다. 상태는 "접근 가능성"의 기록이지 사용의 증거가 아니다.

메인보드 펌웨어 결함. 일부 UEFI 메인보드 펌웨어는 사전 부팅 DMA 보호가 켜져 있다고 OS에 알리면서 부팅 초기에 IOMMU를 제대로 초기화하지 못한다. 수정 전 BIOS에서는 설정과 OS 표시가 켜짐인데도, OS 방어가 올라오기 전 구간에 물리적으로 꽂힌 DMA 장치가 메모리를 읽거나 쓸 수 있다. CERT/CC가 VU#382314(2025-12-17)로 공개했고 제조사별 CVE는 ASUS CVE-2025-11901, Gigabyte CVE-2025-14302, MSI CVE-2025-14303, ASRock CVE-2025-14304다. 제조사들이 BIOS 업데이트를 내고 있고, Vanguard는 해당 기기에 VAN:Restriction으로 펌웨어 업데이트를 요구한다. 환경 기록에 메인보드 제조사·모델과 BIOS 버전·날짜(msinfo32 시스템 요약)를 남기고, 켜짐 표시만으로 사전 부팅 보호가 동작했다고 적지 않는다.

2PC 환경 단서 ​

DMA 치트의 일반적인 사용 형태는 "2PC + 퓨저"다. 퓨저는 두 PC의 화면을 하나로 합성하는 장치다(용어집). 퓨저가 없으면 원격 접속과 창 복제를 조합한 형태도 있다. Ring3에서 이미 확인한 항목을 DMA 맥락에서 다시 본다.

단서확인
원격 접속 프로세스(mstsc, TeamViewer, AnyDesk)타임라인, 게임 세션 중 활성 여부(검사 세션 자신의 연결은 제외)
창 복제·합성 소프트웨어OBS 비공식 플러그인, 가상 모니터 드라이버, 캡처 카드 소프트웨어
두 번째 PC 연결 흔적이더넷·USB-C 직결, KVM 스위치 드라이버
FTDI FT601 계열 USB 브릿지PCILeech 계열 링크로 쓰이는 장치. 정상 FTDI 장비와 구분 필요
외부 입력 장치(KmBox·Makcu·Arduino 계열)게임 PC에는 USB HID(마우스·키보드)로 연결된다. 2PC DMA에서는 두 번째 PC가 계산한 조준 보정이 이 장치로 들어온다. 1PC 구성이면 USB 시리얼 장치도 같이 적는다(HID 장치 확인)

HID 장치 확인 ​

외부 입력 장치는 게임 PC에서 평범한 마우스·키보드로 보인다. 그래서 "있는가"보다 "몇 개이고, 무엇이고, 언제 꽂혔는가"를 본다. 확인 대상 클래스는 마우스(Mouse), 키보드(Keyboard), 휴먼 인터페이스 장치(HIDClass), 포트(COM & LPT, Ports)다.

  1. 장치 관리자에서 숨겨진 장치 표시를 켠 상태로 위 네 클래스를 펼친다. 지금 연결되지 않은 과거 장치도 보인다.
  2. pnputil /enum-devices /class Mouse처럼 클래스별 목록을 텍스트로 받는다. /disconnected를 붙이면 지금 연결되지 않은 장치만 나온다. 두 스위치 모두 Windows 10 1903 이상이다.
  3. 인스턴스 ID의 VID_xxxx&PID_xxxx를 USB ID 저장소로 조회해 제조사를 확인하고, 사용자가 말한 제품과 맞춰 본다.
  4. 장치 속성 → 자세히 탭에서 설치 날짜·첫 설치 날짜(Windows 7 이상), 마지막 도착 날짜·마지막 제거 날짜(Windows 8 이상)를 적는다. 같은 값이 레지스트리 Enum\USB\VID_…&PID_…\…\Properties 아래에 UTC로 저장되므로, 표시 시각을 적을 때 기준 시간대를 함께 적는다.
  5. %SystemRoot%\INF\setupapi.dev.log에서 그 장치의 설치 기록을 찾는다. PnP 관리자가 장치·드라이버 설치를 이 로그에 순서대로 남긴다.
  6. Kernel-PnP 이벤트(위 표)와 맞춰 게임 세션 전후의 연결·해제를 본다. 이벤트 채널 중에는 기본으로 꺼져 있거나 보존량이 적은 것이 있으므로, 비어 있는 채널은 부재의 근거로 쓰지 않는다.

읽는 법:

  • 실제로 쓰는 것보다 입력 장치가 많으면 설명을 받는다. 다만 게이밍 마우스·키보드는 한 장치가 여러 HID 항목으로 잡히는 것이 정상이다. HID 클래스 드라이버가 장치의 최상위 컬렉션마다 장치 객체를 따로 만들기 때문이다.
  • VID/PID가 사용자가 말한 제품의 제조사와 다르거나 개발 보드·USB 시리얼 변환 칩 제조사로 조회되면 리드다. 정상 개발 보드도 같은 모양이므로 용도를 확인한다.
  • 설명되지 않는 USB 시리얼 장치(포트)는 목록에 남긴다.
  • 첫 설치·마지막 도착 시각이 제보된 게임 세션 직전에 몰려 있으면 교차 재료다.

장치 이력은 "연결됐다"만 말한다. 그 장치로 입력을 넣었는지는 말하지 않으므로, 장치 이상과 행동 제보가 겹쳐도 Suspicious가 상한이다.

호스트 헬퍼 ​

DMA가 본체여도 게임 PC에서 돌린 보조 프로그램이 있으면 그 실행 흔적은 Ring3 축(PF·BAM·USN)에 남는다. DMA 의심 사건에서는 Ring3 실행 목록의 설명되지 않는 단발성 도구를 이 맥락에서 다시 읽는다.

환경 점수 ​

DMA 체크에서 수집한 환경 상태를 표로 기록한다. 이 점수는 판정에 직접 쓰지 않고 증거 패키지에 포함한다.

항목정상의심
Secure Boot활성비활성
Kernel DMA ProtectionOnOff
HVCI·메모리 무결성활성비활성
알 수 없는 PCIe 장치없음있음
메인보드 모델·BIOS 버전IOMMU 결함 수정 BIOS 또는 해당 없음결함 대상 모델 + 수정 전 BIOS
원격 접속 프로세스없음 또는 설명 가능설명 불가 + 게임 세션 중

환경 점수 단독으로는 Suspicious 상향을 금지한다.

정상 vs 이상 ​

구분정상이상
PCIe 장치GPU, NVMe, 사운드, LAN알 수 없는 VEN/DEV, Code 28/43
Thunderbolt 장치독, eGPU, 외장 저장소설명 불가 장치 + 세션 타임라인
DMA ProtectionOn 또는 보드 미지원Off + 의심 장치 + 행동 제보
원격 접속없음, 가족 지원, 재택게임 세션 중 활성 + 제보
USB 장치마우스, 키보드, 헤드셋설명되지 않는 추가 입력 장치·USB 시리얼 장치, FTDI FT601, 반복 연결·해제

오탐 ​

항목정상 이유확인
캡처카드(Elgato, AVerMedia)방송·녹화OBS 설치 + 방송 채널
eGPU(Thunderbolt)외장 GPUThunderbolt 포트 + eGPU 제품
Thunderbolt 독노트북 확장제조사·사용 이력
TeamViewer / AnyDesk원격 지원, 재택업무 맥락·가족 지원 이력
Parsec / Sunshine홈 게임 스트리밍수신 기기 존재
VM 가상 NICVMware / VirtualBoxVM 소프트웨어 설치
FTDI 일반 장치개발·시리얼 통신연결된 용도 확인
게이밍 마우스·키보드의 여러 HID 항목한 장치가 최상위 컬렉션마다 따로 잡힘제품과 항목 수 대조
개발 보드(Arduino 등)개발·취미용도와 연결 시각
Intel RST VMD ControllerIntel 11~14세대 기기의 정상 저장 장치 구성CPU 세대·제조사 구성
IOMMU 꺼짐구형 보드 또는 BIOS 미지원보드 모델

판정 기준 ​

DMA 체크 단독으로 나오는 Confirmed는 없다.

패턴판정 방향
알 수 없는 PCIe + DMA Protection 꺼짐 + 원격 프로세스 + "2PC" 제보Suspicious 또는 보류 후 추가 제보 요청
환경 이상(HVCI·DMA 모두 꺼짐) + Ring3 설명 없음Insufficient. 환경 메모 기록
설명되지 않는 입력 장치 이력 + 행동 제보, 게임 PC의 실행 흔적 없음Insufficient 기본, 최대 Suspicious
입력 장치 이력 + 장치를 제어한 프로그램의 Ring3 실행 흔적그 프로그램을 Ring3 축으로 판정
정상 캡처카드 + 설명 가능한 원격 접속FP → Clean(조건부)
DMA 신호 없음DMA 결론 없음. Ring3·Ring0 판정으로 돌아감

"DMA 카드가 있다"거나 "DMA Protection이 꺼져 있다"는 것은 단독으로 치트 증거가 아니다. 제보 패턴, 환경, Ring3 흔적이 함께 있을 때 증거력이 생긴다. DMA 관련 단서만 남은 상태의 기본 라벨은 Insufficient다.

증거 캡처 ​

장치·로그 산출물은 evidence/<case-id>/08-escalation/에, 환경 상태 캡처는 09-platform-env/에 저장한다.

  1. 장치 목록(pnputil /enum-devices 전체 + 알 수 없는 장치만). Win10 1903 미만이면 이 명령이 없으므로 장치 관리자로 대체하고 그 사실을 기록한다.
  2. 문제 코드 장치의 Hardware Ids / Compatible Ids 복사본.
  3. Kernel-PnP 이벤트·setupapi.dev.log에서 세션 전후 설치·제거 구간.
  4. 입력 장치 목록(마우스·키보드·HID·포트)과 장치별 설치·첫 설치·마지막 도착·마지막 제거 시각.
  5. DMA Protection·HVCI·VBS·Secure Boot 상태 캡처(09-platform-env).
  6. UEFI 설정(Secure Boot, TPM), 메인보드 제조사·모델과 BIOS 버전·날짜.
  7. Ring3에서 발견한 원격 접속 프로세스.
  8. 환경 점수 표와 DMA 체크 발견물 요약.

흔한 실수 ​

  • 환경 설정 단독으로 Confirmed를 내린다. IOMMU off, HVCI off, Secure Boot off는 모두 단독 확정 근거가 아니다.
  • 호스트 증거만으로 DMA를 Confirmed한다. 기본 출발점은 Insufficient다.
  • HWID·보드 단서만으로 확정한다. 교차 증거가 필요하다.
  • "DMA라서 로컬에 없다"를 Clean의 근거로 쓴다. Insufficient로 처리하고 제보·환경을 별도로 기록한다.
  • Code 10·28·43 하나를 "스푸핑 증거"로 읽는다. 비특이적 실패 맥락이다.
  • DMA 장치의 구매 경로·펌웨어·설정 절차를 서술하거나 검증한다. 이 문서의 목적 밖이다.

Community. 커뮤니티에서는 "퓨저 없으면 당연히 잡힌다"는 말이 돌지만, 퓨저 유무와 탐지는 별개다. DMA 보드의 장치 ID를 스푸핑하는 방법도 논의되지만, 불완전한 스푸핑은 Code 10이나 드라이버 실패로 흔적을 남긴다. 환경 평가는 정해진 항목 체크가 기준이다.

Community. 흔한 DMA 보드의 기본 장치 ID와 대조하면 걸린다는 주장이 있다. 검증된 대조 목록이 없고 장치 ID는 바뀔 수 있으므로, 이 문서는 대조 목록을 두지 않고 일치 여부를 판정 근거로 쓰지 않는다.

Community. DMA 사용자가 게임 업데이트 뒤 오프셋을 맞추는 맵·오프셋 도구나 보드 펌웨어 도구를 게임 PC에서 돌린다는 설명이 있다. 그런 도구가 있었다면 PF·BAM에 남으므로 호스트 헬퍼로 읽는다. 펌웨어 도구는 정상 보드 관리·개발 용도와 겹치므로 게시자·경로·실행 빈도를 본다.

Community. 외부 입력 장치 설정 안내에서는 같은 PC에서 장치를 제어하는 1PC 구성이면 장치가 게임 PC에 USB 시리얼(COM) 포트로도 잡히고, 2PC 구성이면 두 번째 PC가 명령을 보내 게임 PC에는 입력 장치만 보인다고 설명한다.

Sources ​

Next ​