Shawn's Laboratory (+Popeyed World)

Windows에 있어서는 NtQuerySystemInformation() 하고 NtSetSystemInformation()  함수가
Undocumented Native API 인데  하는 일이 진짜 많다. ...

어떤 어떤 인자를 주고 어떻게 쓰면 프로세스,화일,메모리 ... 정보를 가져올수 있다.. 등등

아래 링크에 들어가보면 자세한 정보를 얻을 수 있다. 근데 어셈블리 분석은 아직 없음, 하지만  찾아보면 어떤 짱구가 해 놨을 거 같음... -_-b

참고는

Inside Windows NT System Data, Dr. Dobb's Journal November 1999
Exploring a mysterious function , By Sven B. Schreiber

http://www.ddj.com/documents/s=897/ddj9911c/9911c.htm

Windows 2003 DDK 인스톨
http://www.microsoft.com/whdc/devtools/ddk/default.mspx

Debuging Tools for Windows 32-bit Version  인스톨
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Windows Symbol Package 인스톨
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

( 위의 스타트 페이지,  http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx )

각각 설치 한다음에
시스템 환경 설정에 _NT_SYMBOL_PATH 추가하고 "C:WINNT" 값을 적어준다.
( 심볼화일이 C:WINNTSymbols 에 설치된다는 가정하에 )

한편, 위에서 symbols 받기가 귀찮으면 c:winntonline_symbols 디렉토리를 만들고
WinDbg 에서 symbols file 설정하는 곳에
SRV*c:winntonline_symbols*http://msdl.microsoft.com/download/symbols
이런식으로 온라인 symbols을 사용할 수 있다.

만일 :
post modern 방식 크래쉬 한담에 덤프를 분석하는 방법을 사용할 것이라면,
시스템 환경설정 -> 고급 -> 성능 -> 가상메모리를 물리 메모리의 약 2배정도로 늘려 잡는다.
시스템 환경설정 -> 고급 -> 시작및 복구 -> 시스템 오류 "전체메모리 복"구 로 설정
크래쉬 덤프는 크래쉬가 난 시점에 메모리 페이지에 값을 기록하고 다음 부팅시에 이를 화일로 덤프한다.
C:WINNTMEMORY.DMP 를 WinDBG 에서 로드하면 됨


참고는 Undocumented Windows 2000 Secrets, "Setting up a debugging environment" 에서

 
System Service Dispatcher

ntdll.dll -->
        eax, 인덱스
        edx, 리턴값
        int 2Eh
                  --> ntoskrnl.exe

ntdll.dll Zw* Nt* 함수가 있으면
ntoskrnl.exe Zw* Nt* 함수가 존재한다.

ntdll.dll 은 단순히 인터페이스이고, ntdll.Zw* ntdll.Nt* 함수가 같은 주소를 사용하는 동일함수이다.
ntoskrnl.exe 에 ntoskrnl.Nt* 함수가 진짜 함수 ...

Service Descriptor Tables (SST)

ntoskrnl , win32k 두개의 시스템 서비스 테이블을 가지고 있고
이는 각각 KiServiceTable, KiArgumentTable
W32pServiceTable , W32pArgumentTable 이라는 테이블을 가지고 있다.

이 테이블들은 각각 함수의 주소와 인자의 갯수를 가진 배열구조체 이다.

int 2Eh 는 바로 위 테이블을 참조해서 KiSystemService() 로 진입하고 쓰레드는
global SDT를 사용하지 않고 KeServiceDescriptorTable 을 사용하지 않고 자체의 포인터로
KiServiceTable 와 KiArgumentTable을 참조한다.

ntdll.dll 과 ntoskrnl.exe 가 가진 함수는

C runtime library ( memcpy , sprintf .. )
Extended runtime library ( Rtl* ...)
Floating-point emulator ( _eFLD .. )

그리고 기타 프리픽스에 따라
Ki : 커널 인터럽트 핸들러
Ke : 커널 루틴
Ldr : 이미지 로더
Ps : 프로세스 서포트
Nt : Native NT API
Hal : 하드웨어 추상레이어 함수  ...

자주사용되는 데이터 타입은

문자열의 경우 UNICODE_STRING 이고
Length, MaximumLength, Buffer ... 세가지로 이루어진 구조체인데
이를 다룰려면 RtlCreateUnicodeString , RtlInitUnicodeString , RtlCopyUnicodeString 등 함수를 사용해야됨...

Native API 에 접근하기 위해서는 ntdll.lib 을 사용하고
커스터마이징 헤더를 사용하면 됨...

참고는 Undocumented Windows 2000 Secrets, "The Windows 2000 Runtime Library" 편에서...

Windows에서 커널디버깅을 통해 프로세스와 쓰레드를 손으로 찾아가며 확인하는 방법입니다. 
사용된 PC는 Windows 2003 서버버젼 입니다.

kd> dt -b nt!_EPROCESS
+0x000 Pcb              : _KPROCESS
+0x000 Header           : _DISPATCHER_HEADER
+0x010 ProfileListHead  : _LIST_ENTRY
   +0x000 Flink            : Ptr32
   +0x004 Blink            : Ptr32
     +0x018 DirectoryTableBase : Uint4B // CR3 레지스터가 저장되어 있다
+0x020 LdtDescriptor    : _KGDTENTRY
....
+0x048 SwapListEntry    : _SINGLE_LIST_ENTRY
   +0x000 Next             : Ptr32
+0x04c VdmTrapcHandler  : Ptr32
     +0x050 ThreadListHead   : _LIST_ENTRY // 쓰레드 리스트의 헤드
  +0x000 Flink            : Ptr32
  +0x004 Blink            : Ptr32
      +0x058 ProcessLock      : Uint4B
+0x05c Affinity         : Uint4B
+0x060 AutoAlignment    : Pos 0, 1 Bit
+0x060 DisableBoost     : Pos 1, 1 Bit
...
+0x090 RundownProtect   : _EX_RUNDOWN_REF
+0x000 Count            : Uint4B
+0x000 Ptr              : Ptr32
   +0x094 UniqueProcessId  : Ptr32 // 프로세스 아이디
+0x098 ActiveProcessLinks : _LIST_ENTRY // 모든 프로세스 목록 관리 리스트
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
   +0x0a0 QuotaUsage       : Uint4B
...
+0x0cc DebugPort        : Ptr32
+0x0d0 ExceptionPort    : Ptr32
   +0x0d4 ObjectTable      : Ptr32  // 문제의 오브젝트 핸들테이블
   +0x0d8 Token            : _EX_FAST_REF
...
+0x14c Spare0           : Ptr32
+0x158 PageDirectoryPte : _HARDWARE_PTE
+0x158 Filler           : Uint8B
+0x160 Session          : Ptr32
   +0x164 ImageFileName    : UChar // 프로세스의 이름
   +0x174 JobLinks         : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
+0x17c LockedPagesList  : Ptr32
+0x180 ThreadListHead   : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
...
 +0x1e8 Vm               : _MMSUPPORT
      +0x000 WorkingSetExpansionLinks : _LIST_ENTRY
    +0x000 Flink            : Ptr32
    +0x004 Blink            : Ptr32
+0x008 LastTrimTime     : _LARGE_INTEGER
    +0x000 LowPart          : Uint4B
    +0x004 HighPart         : Int4B
    +0x000 u                : __unnamed
       +0x000 LowPart          : Uint4B
       +0x004 HighPart         : Int4B
    +0x000 QuadPart         : Int8B
+0x010 Flags            : _MMSUPPORT_FLAGS
+0x014 PageFaultCount   : Uint4B
...
+0x030 NextEstimationSlot : Uint4B
+0x034 NextAgingSlot    : Uint4B
+0x038 EstimatedAvailable : Uint4B
    +0x03c WorkingSetSize   : Uint4B // 프로세스 워킹셋 사이즈
      +0x040 WorkingSetMutex  : _EX_PUSH_LOCK
   +0x000 Locked           : Pos 0, 1 Bit
   +0x000 Waiting          : Pos 1, 1 Bit
   +0x000 Waking           : Pos 2, 1 Bit
   +0x000 MultipleShared   : Pos 3, 1 Bit
   +0x000 Shared           : Pos 4, 28 Bits
   +0x000 Value            : Uint4B
   +0x000 Ptr              : Ptr32
+0x230 MmProcessLinks   : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
+0x238 ModifiedPageCount : Uint4B
+0x23c JobStatus        : Uint4B
+0x240 Flags            : Uint4B
+0x240 CreateReported   : Pos 0, 1 Bit
...
+0x24a SubSystemMinorVersion : UChar
+0x24b SubSystemMajorVersion : UChar
+0x24a SubSystemVersion : Uint2B
+0x24c PriorityClass    : UChar
   +0x250 VadRoot          : _MM_AVL_TABLE // 유저영역의 모든 메모리 설명
   +0x270 Cookie           : Uint4B

커널 레이어에서 EPROCESS 얻기

PEPROCESS PsGetCurrentProcess()
현재 프로세스의 EPROCESS을 얻어올수 있음

NTSTATUS PsLookupProcessByProcessId(IN ULONG ProcessID, OUT PVOID *EProcess )
다른 프로세스의 EPROCESS를 얻어올수 있음

프로세스를 구성하는 요소

각 프로세스의 독립적 메모리 공간의 사용은 Intel x86의 페이징 시스템을 그대로 사용함
위의 CR3 저장공간에 따라 실제 물리공간 결정 어드레스 오프셋은 물리매핑을 위한 각
페이지 디렉토리, 페이지 테이블 등의 오프셋

유저 메모리 영역 관리

kd> !process 85e3b8a8
PROCESS 85e3b8a8  SessionId: 0  Cid: 0aa8    Peb: 7ffdf000  ParentCid: 01b4
DirBase: 1e7f5000  ObjectTable: e217d008  HandleCount:  55.
Image: uedit32.exe
VadRoot 85331468 Vads 85 Clone 0 Private 740. Modified 2. Locked 0.
DeviceMap e206f720
Token                             e260f938
ElapsedTime                       00:07:44.406
UserTime                          00:00:00.000
KernelTime                        00:00:00.000
QuotaPoolUsage[PagedPool]         39256
QuotaPoolUsage[NonPagedPool]      3592
Working Set Sizes (now,min,max)  (2064, 50, 345) (8256KB, 200KB, 1380KB)
PeakWorkingSetSize                2064
VirtualSize                       41 Mb
PeakVirtualSize                   42 Mb
PageFaultCount                    2983
MemoryPriority                    BACKGROUND
BasePriority                      8
CommitCharge                      1035
  THREAD 85e3b638  Cid 0aa8.05f0  Teb: 7ffde000 Win32Thread: e126a4e0 WAIT: (Unknown) UserMode Non-Alertable
      85334ff0  SynchronizationEvent
  Not impersonating
  DeviceMap                 e206f720
  Owning Process            85e3b8a8       Image:         uedit32.exe
  Wait Start TickCount      227979         Ticks: 6558 (0:00:01:42.468)
  Context Switch Count      1298                 LargeStack
  UserTime                  00:00:00.0406
  KernelTime                00:00:00.0281
  Start Address kernel32!BaseProcessStartThunk (0x77e6b5c7)
  Win32 Start Address 0x0050cec5
  Stack Init f5664000 Current f5663bc4 Base f5664000 Limit f5661000 Call 0
  Priority 10 BasePriority 8 PriorityDecrement 0
  Kernel stack not resident.
  ChildEBP RetAddr 
  f5663bdc 80820128 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
...
  f5663d4c 7c82ed54 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f5663d64)
  0012fed4 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
  THREAD 853cf020  Cid 0aa8.0af4  Teb: 7ffdd000 Win32Thread: e290a8b8 WAIT: (Unknown) UserMode Non-Alertable
      8533a2a0  Semaphore Limit 0x7fffffff
  Not impersonating
  DeviceMap                 e206f720
  Owning Process            85e3b8a8       Image:         uedit32.exe
  Wait Start TickCount      264026      
  Context Switch Count      15                 LargeStack
  UserTime                  00:00:00.0000
  KernelTime                00:00:00.0000
  Start Address kernel32!BaseThreadStartThunk (0x77e6b5bb)
  LPC Server thread working on message Id 442d
  Stack Init f53f4000 Current f53f3c24 Base f53f4000 Limit f53f1000 Call 0
  Priority 9 BasePriority 8 PriorityDecrement 0
  Kernel stack not resident.
  ChildEBP RetAddr 
  f53f3c3c 80820128 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
...
  0158fe18 0003f1bb ntdll!KiFastSystemCallRet (FPO: [0,0,0])
WARNING: Frame IP not in any known module. Following frames may be wrong.
  0158ff84 00015360 0x3f1bb
  00000000 00000000 0x15360

kd> !vad 85331468
VAD     level      start      end    commit
857ac690 ( 6)         10       10         1 Private      READWRITE
853b6280 ( 5)         20       20         1 Private      READWRITE
...
853a51d8 ( 6)       1410     1420         0 Mapped       READONLY
85e47320 ( 7)       1430     1477        72 Private      READWRITE
85e42c20 ( 3)       1480     1481         0 Mapped       READONLY
85333b98 ( 5)       1690     16d7        72 Private      READWRITE
Total VADs:    46  average level:    5  maximum depth: 7

핸들테이블

Windows 객체 관리자는 핸들 숫자값을 핸들 테이블의 색인 정보로 활용해서 참조하고자 하는 커널 객체에 접근

kd> !handle 07fc
processor number 0, process 85e36020
PROCESS 85e36020  SessionId: 0  Cid: 05c0    Peb: 7ffdc000  ParentCid: 0ad8
DirBase: 183e5000  ObjectTable: e2879988  HandleCount: 249.
Image: windbg.exe
New version of handle table at e2e92000 with 249 Entries in use
07fc: Object: e1006d08  GrantedAccess: 00000003
Object: e1006d08  Type: (85f92900) KeyedEvent
ObjectHeader: e1006cf0
  HandleCount: 30  PointerCount: 31
  Directory Object: e1001668  Name: CritSecOutOfMemoryEvent

e1006d08 은 핸들 테이블에 존재하며 이는 3단계로 분해되서 색인처리 됨
위를 분해하면 커널 객체 포인터를 찾을 수 있음

[31..26][25..18][17..10][9..2][1..0]
         i 256     j 256     k 256

x 를 핸들이라고 하면

x 가 가르키는 테이블 의 i 인덱스
x2 = *x[i]

x2 이 가르키는 테이블의 j 인덱스
x3 = *x2[j]

x3 가 가르키는 테이블의 k 인덱스
p_kobj = *x3[k]

p_kobj 는 커널 객체의 Object 포인터 이다...

한편, 위의 [31..26] 은 Audit on Close , Protect from close, Inheritable 플래그로 사용,
[1..0] 은 Lock Flag 으로 사용한다는 전설이 내려온다구 한다...

이렇게 쓰는 이유는 에너지절약 차원...
프로세스가 가지는 핸들의 테이블 메모리를 최대한 줄일 수 있음

정리하면서 무엇보다 이거 보면서 솔루션 만드느라
조낸 고생하신 올드드래곤 옹 생각이 난다...
-_-;;;

참고는 Windows 구조와 원리 그리고 Codes , 정덕영, "프로세스와 쓰레드"편

Sysinternals 의 LiveKD라는 실시간 커널 디버깅 어시스턴트를 사용해서 실서버의 커널을 디버깅하는 방법입니다.



WinDbg 를 언제 어디서나 빠르고 편하게 사용할 수 있도록
sysinternals 에서 livekd 라는 유틸리티를 제공해 준다.

이를 사용하면 별도로 커널을 크래쉬하거나
리모트 디버깅환경을 만들지 않아도 현제 PC 에서 커널 디버깅을 수행할 수 있다. 

likvekd.sys 가 무슨 파일 드라이버 역할을 하는 것 같다.
실제 windbg는 c:windowssystem32livekd.dmp 를 읽고 있다.

사용법도 간단하다.. Debugging Tools for Windows 를 깔아 놓고 , livekd 를 설치한다음
livekd -w 하면 됨

심볼도 알아서 설치해 준다.
ㅠㅠ... 넘 편하다.



다운로드는
LiveKD, http://www.sysinternals.com/utilities/livekd.html

Remote Debugging using VMWare  http://www.catch22.net/tuts/vmware.asp 의 내용을 정리한 것입니다.

vmware 에 있는 커널 디버깅 하는 방법 설명한거...

windbg 헬프 보기 싫어서 걍 이거 참조함

1. 타켓에 Serial 포트하나 만들어 놓고 "This end is the Server" , "The other end is an application" 선택하고 Yeild on CPU poll" 선택

2. boot.ini 에 마지막 라인의 옵션에 /debugport=com1 /baudrate=11520 추가하고

2. 사용자 디버거에서
windbg -b -k com:pipe,port=\.pipecom_1,resets=0 

로 접속하면 됨

소스 디버깅을 하려면,
WinDbg 의 Symbol File Path ... 에 해당 드라이버의 pdb 가 있는 디렉토리를,
Source File Path .. 에 해당 소스 디렉토리를 정해주면 된다.

타겟 머신에서 드라이버를 설치하고,

x driver!*

심볼들을 찾아내서

bp driver!MyOpen

이런식으로 걸고 외부에서 Windbg 를 실행하면 됩니다.

Inside Microsoft Windows 2000 에서 정리한 내용입니다. 



 
부팅 (booting)

Bios 가 boot sector 를 읽음
ntldr 가 부트 섹터에 위치함

Ntldr :

16 리얼 모드 -> 32 보호모드로 전환
메모리 페이징을 시작
boot.ini 를 읽어와서 부트옵션을 적용 ( SCSI 나 특별한 장치를 위해 ntbootdd.sys 를 로드)
Ntdetect.com을 실행 시스템 정보를 모음 ( HKLMHARDWAREDESCRIPTION 에 정보가 취합됨 )
Ntoskrnl.exe 를 메모리에 로드, Bootvid.dll , Hal.dll 을 로드하고, boot-start 디바이스 드라이버를 초기화함

 ( HKLMSYSTEMCurrentControlSetServices안에 드라이버가 있음 )
CPU를 Ntoskrnl.exe 를 위해 준비하고 Ntoskrnl.exe 시작점으로 제어를 넘김

Ntoskrnl.exe :

 각종 서브시스템을 초기화, 실행하고
system-start 디바이스 드라이버를 초기화
native app 인 smss.exe ( 세션 서브시스템) 을 실행

 자세히 :

 스텝 0 : 인터럽트를 중단시키고
KiSystemStartup -> HalInitializeprocessor , Ki1InitializeKernel  ; 초기의 커널 자료구조를 생성함  Ki1InitializeKernel 은 ExpInitializeExecutive() 호출하고 이는 각각
메모리관리자, 개체관리자, 보안참조 모니터, 프로세스관리자, 플러그엔 플러그 0 단계 초기화를 한다.

 스텝 1 :

  인터럽트 준비, 전원관리자, 시스템 시간 초기화 , 개체관리자가 링크됨, 커널 스케쥴러 초기화, ntdll.dll 매핑,
구성관리자가 Registry 복원, I/O 관리자 초기화
보안참조 모니터 호출 후
Native app 인 Smss.exe 를 실행시킨다.

Smss.exe:

 Windows 서브 시스템 win32k.sys 를 로드하고,
Csrss ( client/server runtime 서브시스템) 실행, winlogon 을 로드

자세히 :

LPC 포트 개체 생성
알려진 dll 을 열고
추가적 페이징 생성

레지스트리 초기화
시스템 환경변수 생성
Win32k .sys 로드
csrss 시작
Winloon 시작

Winlogon:

 SCM(서비스 컨트롤 매니져), LSASS(로칼 보안 인증 서브시스템) 를 로드하고 사용자 로긴 다이얼로그를 띄움

SCM:

 SCM 에 있는 자동시작 드라이버들을 로드

"Inside microsoft windows 2000" ,
David A.Solomon & Mark E. Russinovich

게임에 대한 해킹으로부터 고객회사를 지켜준다는 솔루션인, 게임 가드의 문제점은 태생이 외부 솔루션이라서 게임상의 메모리 보호를 못 하거나, 패턴대응이 늦어서 신종 툴이 나올때는 패턴 업데이트가 늦어 게임들이 버젓히 뚫리는 경우가 많았습니다. 
그래서 게임자체에서 메모리나 코드보호를 해야할 필요가 있습니다. 바로 메모리셔플링이라고 하는 거인데요, 예전에 각 게임사에서 게임보안 솔루션을 자체로 만들려고 했던 이유이기도 합니다.

아래 동영상은 MoonLite Engine 이라는 툴이 나와서 한창 돌아다닐때의 일인데요, 요즘은 게임가드 제작사인 잉카에서 새버젼이 나오면 열심히 업데이트한다고 합니다. 그렇다고 해도, 근본적인 문제가 해결되는 것은 아니고 다만, 관리적인 문제로 답을 구한다?는 느낌입니다.

(아래 계속...)

JAVA 코딩 보안 가이드를 검증하다가 어떻게 JAVA 게임 해킹까지 하게 되었네요. 주요 골자는 JAVA 의 클래스 코드를 공격하는 것인데요. 이번의 저의 희생양은 Jake 2 라는 퀘이크 2의 JAVA 버젼입니다.

필요한 준비물은 아래와 같습니다.

• DJ Java Decompiler (혹은 그에 상응하는 자바 디컴파일러 )
• Java SDK 1.6 이상 (javac, jar … )
• Ant library (게임이 사용하고 있기 때문에 )
• 자바게임 ( 쓸만한 녀석, Jake 2라고 Quake II의 자바판) http://bytonic.de/html/download.html
 

DJ Java Decompiler는 java 의 묶음 화일인 jar나 class 화일을 리스팅하거나 디컴파일하는 기능을 가졌기 때문에 JAVA해킹에 유용합니다.

공격했던 지점은 Jake2.jar 화일이고 시나리오는 아래와 같습니다.

Step.1 Jake2 다운로드

Step.2 Jake2.jar 분석 Blaster gun 함수코드

Step.3 PlayerWeapon.java 추출

Step.3-1 PlayerWeapon.class 생성

Step.4 Jake2.jar 에 위 클래스 업데이트

Step.5 게임실행 - 테스트

 위에서 Wepon_Blaster_Fire 함수 의 damage를 10 에서 1000 으로 고쳤습니다.

Blaster 는 퀘이크 처음 시작하면 주어지는 권총형 무기인데, 100배정도 강하게 만든 셈이지요.

게임에서 흔희 말하는 한방핵이죠... 출몰하는 모든 적들이 한방에 죽게되었습니다.

해보신 분들은 알겠지만, 여기 나오는 "돼지녀석"은 원래 3-4방 맞아야 죽일 수 있는 몹입니다.

지금은 한방핵 中

그럼 즐핵 하세요 ~

일반적인 온라인 게임의 다이어그램은 게임 사용자가 웹으로 로그인을 하고, 웹에서 액티브엑스인 게임런쳐가 실행되 사용자 정보를 읽어들인 후, 그 정보를 게임클라이언트에 넘겨주는 것이 일반적입니다.

여기서 주로 게임런쳐가 하는 일은 아래와 같습니다.

1.사용자 PC를 체크한다 (게임이 실행될지 안될지)
2.게임이 설치되어 있지 않다면, 다운로드 받는다
3.설치되어 있다면 체크섬을 계산하여 업데이트를 다운로드 받고 이를 해당화일에 덥어 씌운다.
4.웹서버로부터 사용자 정보를 게임클라이언트에 넘겨준다. (이과정에 암호화를 사용하기도 함)
5.게임클라이언트는 위에서 넘겨받은 정보를 가지고 로긴한다.
 

보통 게임 리버스 엔지니어링시에 hex editor로 게임 클라이언트나 데이터에 수정을 가했을 경우는 게임런쳐가 그 화일들에 대한 체크섬을 계산해서 업데이트하기 때문에 애써 수정해 놓은 클라이언트 화일들이 원래 화일로 돌아오는 경우가 있는데요. 이를 우회하기 위해 게임런쳐 자체를 패치해 버리는 방법을 사용할 수 있습니다.혹은, 체크섬 엔트리들을 가지고 있는 화일을 조작해서 체크섬을 바꾸는 방법도 생각해 볼 수 있겠내요.

도식도는 아래와 같습니다.

현재 이런 취약점을 가진 게임들이 상당수 있습니다. 따라서 게임 클라이언트 스스로 방어를 할 수 있게 해줘야 합니다. 게임 클라이언트 화일 자체를 패킹을 한다던지, 컨설팅을 받아 변조가 어려운 새로운 화일 시스템을 만든다던지 하는 일이 필요한데요. 그런일들은 일반 개발자들이 하기는 힘들고, 전문적인 지식을 가진 보안인력들의 노력이 필요하게 됩니다.