#44u61l5f

Anti Game hacking 프로그램의 구현.

(Dual) — Sun, 02 Dec 2007 12:58:38 +0900

Anti Game hacking 프로그램의 구현.

작성자 : Dual5651 (dual@null2root.org) in Null@Root

소개

이번 글에서는 그 시점에서 알게된 Anti GH 프로그램이 갖추어야할 기능이 무엇
이며, 그 기능의 구현에 필요한 코드와 그 기능의 존재하는 약점등에 대해서 다루어
보고자 합니다. 이 글의 구성은 다음과 같습니다.

1. Anti Game Hacking 프로그램에 필요한 기능들.
2. Anti Game Hacking Program 구현에 필요한 코드들.

1. Anti Game Hacking 프로그램에 필요한 기능들.

Anti GH 프로그램은 어떤 기능들이 필요할까요?

1. (Binary /Data File) Packing / Encrypting

2. GH Program Detecting

3. AutoPlay Blocking

4. Message Hooking Blocking

5. Unauthorized memory access Blocking

6. Debugging Blocking

7. SpeedHack Blocking

8. Integrity Checking

9. System descriptor restoring

첫번째로 필요한 기능으로써, 실행파일 및 데이터 파일의 압축 또는 암호화를
들 수 있습니다. 이 부분에 대해선 다른 의견을 가지고 있는 분들도 많은거 같습니다.
이런 분들의 주장에 근거로는 패킹 및 인크라입팅에 의존하면, 프로그램 자체의
Secure Coding이 약해지고, 대부분 이러한 패킹 및 인크라입팅은 범용적으로
사용되는 상용프로그램일 가능성이 높음으로, 풀릴(뚫릴 - 그만큼 공략하는 사람도
많기 때문에) 가능성도 높으며, 이로 인한 결과는 상상이상으로 치명적일 것이기
떄문입니다. 그럼에도 불구하고, 최근 실행파일의 패킹을 하지 않은 프로그램을
더 찾기 힘들만큼 많이 사용되어 지고 있으며, 또 어느정도 첫번째 방어선으로써
기대되어 지는 기능을 하여주고 있습니다.

그렇다면 게임의 데이터 파일들에 대한 패킹 및 인크라입팅은 왜 필요한 것일까요?
최근 Anti GH 프로그램의 도입으로 Memory Hacking이 힘들어지자, 최근 공격자들은
게임의 데이터파일을 조작하는 방식의(고전적이라면 고전적인 방법의) 해킹을 다시
시도하기 시작하였습니다. 실제 2007년도 국내의 어떤 게임에서는 해당 방식에 의한
GH이 이루어지기도 하였습니다.

두번째로 필요한 기능으로써, 게임해킹 프로그램의 감지를 들 수 있습니다.
최근 가장 많이 쓰이는 GH방식으로 Memory Hacking이 있습니다.
이러한 MH(Memory Hacking)은 공격자 입장에서 Generic Game Hacking Tool
(ex: CheatEngine,Tsearch and so on...)로 우선 대상 Game에 대한 분석을 하고
그 후 그 게임만을 대상으로 하는 게임 트레이너가 나오게 됩니다.
즉, 범용 게임 해킹툴의 완전한 차단은 특정 게임 대상 트레이너의 제작을 막는 방법
이기도 합니다. 물런 이는 반드시 그러한 것은 아니며, 거의 근접한 %의 역활을 할 수
있습니다. 감지하는 방법으로써는 첫번째로 패턴 매칭이 있습니다.
패턴 매칭이란 특정한 GH 프로그램에서 발견되는 문자열이나, 코드배열등을
Anti GH프로그램에서 모든 프로세스에서 찾아 보고, 있다면 GH 프로그램으로
간주하는 방식입니다. 두번째로 Finding Named Object기법이 있습니다.
예를들어,

hFileMap = CreateFileMapping((HANDLE)INVALID_HANDLE_VALUE,NULL,
PAGE_READWRITE,0,dwSize,"DUALMEM");

의 경우 처럼, GH 프로그램이 사용되는 시스템 전역에 공유되는 파일맵의 이름이라던지,
GH 프로그램의 창이름, 클레스 이름, 프로세스 이름, 로드되는 드라이버 이름, 뮤텍스,
레지스트리 키등등의 요소등을 검사해보는 방법입니다. 이러한 요소를 확인하는 방법은
sysinternals의 Process Explorer를 이용하여 해당 GH프로그램이 가지고 있는 핸들등
을 통해서 확인하여 볼 수 있습니다.

세번째로 필요한 기능으로써, 자동 플레이 차단을 들 수 있습니다.
최근 메모리 해킹보다 더 큰 문제로 대두되고 있는 것이, 자동플레이 문제 입니다.
과거에는 '작업장'이라는 이름으로, 빈곤한 국가에서 아동 및 청소년의 노동력을
착취하여 지속적인 게임 플레이를 통한 아이템 획득하여, 이를 판매, 이익을 얻는
방식의 범죄가 존재한 반면, 최근에는 이러한 노동력 착취가 아닌, 자동으로
게임을 플레이 해주는 프로그램 및 하드웨어를 이용하여 자동적으로 플레이 하여,
아이템을 획득, 이를 판매하여, 이익을 얻는 방식으로 변모하였습니다.

최근 단순한 메크로 방식의 자동 플레이 보다 진화된 형태의 두가지 자동 플레이
방식이 등장하였는데, 첫번쨰로 게임 클라이언트와 서버와의 통신 프로토콜등을
분석하여 게임 클라이언트와 똑같은 기능을 하는 클라이언트를 만들어(UI는 없는)
해당 클라이언트에 AI를 붙이어 자동적으로 사냥하게 하는 것입니다.
이 방식으로 접근하게 될 경우, Anti GH프로그램은 올바른 역활을 할 수 없게 되며,
서버측의 입장에서도 올바른 클라이언트와 공격자에 의해 만들어진 오토 플레이용
클라이언트를 분간하는 것도 현재로선, 명확한 방법은 존재하지 않습니다.
또 이 방식의 공격은 2차적인 피해를 낮기도 하는데, 이런 오토 플레이로써 기능을
하다가, 후에는 '프리 서버'라는 이름으로 판매되어, 실제 게임의 플레이어 수를
줄이고, 저작권을 침해하는 범죄가 2차적으로 이어집니다.
두번쨰로 하드웨어 방식의 오토 플레이 입니다. 이는 실제 사용자에 의해 이뤄지는
올바른 입력과 분간하는 것이 힘듭니다. 이를 분간하기 위한 방법으로써, 행동
패턴 기반의 감지방법이나, WMI등을 이용, 하드웨어의 ID를 확인하여 오토 플레이용
하드웨어를 감지하는 방법등이 사용되어 지고 있습니다.

네번쨰로 필요한 기능으로써, 메시지 후킹 차단을 들 수 있습니다.
공격자는 메시지 후킹을 사용자의 키입력등을 가로 챌 목적으로 사용합니다.
게임의 경우, 키 입력을 가로채어, 아이디와 패스워드등을 알아낸 후,
접속하여 아이템등을 빼가는 등의 범죄에 사용되어 집니다.
현재 존재하는 대부분의 Anti GH 프로그램등은 대부분 기본적으로 유저레벨단의
메시지 후킹을 차단하고 있으며, 이로 인해 최근에는 키로거들도 유저레벨에서
메시지 후킹을 하는 방식이 아닌, 커널레벨에서 필터 드라이버등으로써 키로거
기능을 수행하고 있습니다.

다섯번쨰로 필요한 기능으로써, 허용되지 않은 메모리 접근차단을 들 수 있습니다.
매시각각 생겨나는 GH 프로그램에 대응한다는 것은 참 힘든일이며,
Private한 GH 프로그램에 대해선 대응하기가 힘들다는 이유에서 이 방법은 Anti GH에
큰 도움이 되는 방법입니다. 게임 및 보호 프로그램의 프로세스에 허용되지 않은
접근을 차단함으로써, Private한 GH 프로그램도 견제할 수 있게 됩니다.
이를 수행하기 위해서 유저레벨에서는 각 프로세스에 Dll을 삽입하여, API를 후킹하게
하고, 커널레벨에서는 NtOpenProcess(), NtRead/WriteVirtualMemory()등의 함수를
후킹하여 프로세스로의 접근을 차단합니다. 그러나 최근 GH 프로그램도 이런 후킹에
대응하기 위하여, 기존의 API를 호출하는 것이 아닌, Pesudo 코드를 사용함으로써,
위에서 말했던 API들로는 충분치 않아, 최근에는 KeAttachProcess() 같은 프로세스
메모리 전환 계열 함수도 후킹대상에 포함되고 있습니다.

여섯번쨰로 필요한 기능으로써, 디버깅 차단을 들 수 있습니다.
게임을 디버거에게 내준다는 것은, 알몸을 보여주는 것과 같습니다.
그럼으로, 디버거는 어떻게든 차단해야 하는 존재입니다. 디버거를 감지하는
방법으로는 우선 앞에서 말했던 요소들을 혼합함으로써 이루어 질 수 있습니다.
디버거들이 사용하는 API(DebugActiveProcess)같은 프로세스들을 후킹하는
것도 중요하며, 유명한 범용 디버거가 있는지 정기적으로 확인하여, 이들의
창이름, 클레스 이름, 프로세스 이름등 Anti GH프로그램의 두번쨰 기능에서
거론한 요소들로 감지할 수 있으며, 디버거 역시 유저레벨 디버거의 경우
다섯번째 기능으로 차단되며, 커널레벨 디버거의 경우는 반드시 두번쨰 기능을
이용하여 차단되어져야 합니다. 유명한 커널레벨 디버거로써는 SoftIce와
syser가 있으며, 필수적인 차단리스트 입니다.

일곱번째로 필요한 기능으로써, 스피드 핵 차단을 들 수 있습니다.
공격자 입장에서 생각하기에는 단순히 스피드 핵을 차단하는 이유가 공정성 때문
이라고 생각할지 모르겠지만, 실제적으로 스피드 핵을 차단하는 이유는 공정성
그 이상의 이유가 있습니다. 스피드 핵을 사용할 경우 특정한 기능을 수행하는
루틴의 반복시간에 Gap이 짧아 짐으로써, (Delay시간의 감소) 서버로 유입되는
패킷량 역시 증가되게 됩니다. 만약, 스피드를 정상적인 속도에 10배로 하였다면,
서버로 보내는 패킷량도 10배에 근접하게 된다고 보시면 됩니다. 즉 반드시
차단해야 합니다. 스피드 핵은 두종류가 있는데, 첫번쨰는 GetTickCount() ,
timeGetTime(),QueryPerformanceCounter()등의 시간관련 함수를 후킹하는
방식이 있습니다. 이는 프로세스로의 메모리 접근을 차단함으로써 해결할 수
있는 문제입니다. (사실 메모리 접근을 하지 않고 후킹을 할 수도 있습니다.
-CopyOnWrite 관련) 두번쨰는 시스템의 PIT자체를 줄임으로써, 시스템 시간
전체를 빠르게 돌아가게 하는 방법이 있습니다. 이는 시스템 내부적으론 감지가
힘들게 되며, 서버와의 연동체크를 통해서 감지하는 방법이 있습니다.

여덟번째로 필요한 기능으로써, 무결성 검사를 들 수 있습니다.
무결성 검사를 하는 이유로는, 만약 게임프로세스 및 보호 프로세스가 패킹이
해제되거나, 변조된 상태에서 실행된다면, Anti GH은 정상적인 기능을 수행할 수
없게 됩니다. 무결성 검사는 보호 프로세스가 시작될떄에, 게임 파일 및 보호
프로세스 자체 파일들에 대하여 우선적으로 이루어져야 하며,
실행 중에도 코드섹션에 대하여 정기적으로 이루어져야 합니다.
이렇게 검사를 수행할 경우, 만약 다섯번쨰 기능이 우회되여, 게임의 메모리나,
게임의 데이터 파일등이 수정되었다고 하여도, 이를 감지할 수 있습니다.

아홉번째로 필요한 기능으로써, 시스템 디스크립터 복구를 들 수 있습니다.
게임이 시작하기전 시스템의 중요한 디스크립터들(ex: ssdt, idt, and so on)을
복구 하여둠으로써, 꺠끗한 환경에서 게임이 돌아가도록 해야 합니다.
이 작업이 수행되어 지지 않으면, Anti GH 프로그램은 올바른 작동을 할 수 없을
수도 있습니다.

2. Anti Game Hacking Program 구현에 필요한 코드들.

앞에서는 안티 게임 해킹 프로그램이 갖추어야할 기능들에 대해서 알아 보았습니다.
이번에는 이러한 기능들을 구현하기 위해서 알아야 할 점 및 코드에 대해서 다루어
보도록 하겠습니다.

첫번째로 실행파일 및 데이터 파일의 압축 또는 암호화의 경우 코드의 길이가
짧은편이 아님으로, 관련 링크로 대신하도록 하겠습니다.
http://dual5651.hacktizen.com/tt/entry/Make-your-owner-PE-Protector-Part-1-Your-
first-EXE-Protector
참고 적으로 최근의 게임 EXE 패킹은 더미다 패커가 인기를 끌고 있고,
드라이버의 경우 Code Virtualizer가 인기를 끌고 있습니다.

두번쨰로 게임해킹 프로그램의 감지의 코드는 다음과 같습니다.

프로세스 메모리 영역의 패턴 검사 :

BOOL PatternSearchFromAllProcesses()
{
char StringDataBase[][30] = {"CheatEngine",
"AutoPlay",
"GameHack",
"Memory Search",
"TSearch"};
char szProcess[MAX_PATH] = {0,};
DWORD ProcessesID[1024];
char WarningString[MAX_PATH] = "게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n";
MEMORY_BASIC_INFORMATION struct_mbi;
SYSTEM_INFO struct_si;
HMODULE hMod;
DWORD dbNeeded,dbNeeded2;
HANDLE hProcess;
LPVOID newbuf;
LPVOID p;
ULONG ret;
int cnt;

GetSystemInfo(&struct_si); //Getting Information to get max,min address

printf("StartAdr : 0x%x, EndAdr : 0x%x\n",
struct_si.lpMinimumApplicationAddress,
struct_si.lpMaximumApplicationAddress);

for(cnt=0; ;cnt++) //Counting Pattern
if(!StringDataBase[cnt][0])
break;

EnumProcesses(ProcessesID,sizeof(ProcessesID),&dbNeeded); //Get Processes IDs.

for(int i = 0; i < dbNeeded / sizeof(DWORD); i++)
{
if((ProcessesID[i] == GetCurrentProcessId()) || ProcessesID[i] == 4) continue; //Do not scan by self

hProcess = OpenProcess(PROCESS_VM_READ|PROCESS_QUERY_INFORMATION,FALSE,ProcessesID[i]);

if(hProcess)
{
EnumProcessModules(hProcess,&hMod,sizeof(hMod),&dbNeeded2);
GetModuleBaseName(hProcess,hMod,szProcess,sizeof(szProcess)); //Get Module Name
p = struct_si.lpMinimumApplicationAddress;

do
{
VirtualQueryEx(hProcess,p,&struct_mbi, sizeof(struct_mbi));
newbuf = malloc(struct_mbi.RegionSize);
//Sometimes regionSize makes me crazy!!!
if(newbuf)
{
   ReadProcessMemory(hProcess,p,newbuf,struct_mbi.RegionSize,&ret);
   if(ret)
   {
for(DWORD i = (DWORD)newbuf; i <= (DWORD)newbuf+(DWORD)struct_mbi.RegionSize; i++)
{
   for(int j = 0; j < cnt; j++)
   {
if(!strnicmp((char *)StringDataBase[j],(char *)i,strlen((char *)StringDataBase[j])))
{
strcat(WarningString,szProcess);
strcat(WarningString,"프로세스를 종료하신후 다시 실행하여 주세요.\n");
MessageBox(NULL,WarningString,"해킹 프로그램 발견",MB_ICONSTOP);
CloseHandle(hProcess);
ExitProcess(-1);
}
   }
}
   }
}
free(newbuf);
*((PDWORD)&p) += (DWORD)struct_mbi.RegionSize;
}while(p < struct_si.lpMaximumApplicationAddress);
}
CloseHandle(hProcess);
}
return TRUE;
}

실제로 실행해보면 알 수 있지만, ReadProcessMemory()를 수행하는 것은 꾀 시간을
많이 소요하는 작업입니다. 이렇게 하는 것보다는 Dll을 모든 프로세스에 인젝션 시키신 후,
각 프로세스에 인젝션된 Dll에서 메모리 검사를 하게되면, 같은 프로세스 영역 내임으로,
ReadProcessMemory()도 필요 없으며, 분할처리가 가능해져, 그 속도 역시 빨라 집니다.
Dll을 인젝션 하는 방식의 코드는 별도로 코드를 첨부하도록 하겠습니다.

Finding Named Object기법의 경우는 창이름 이나 클레스 이름은 EnumWindow 함수를
돌면서 GetWindowText(), GetClassName()함수를 이용하여 구하여 비교하는 방식을
쓰면 됩니다. 코드는 다음과 같습니다.

char szWindowDataBase[][30] = {"CheatEngine",
   "AutoPlay",
   "GameHack",
   "Memory Search",
   "TSearch"};

char szClassDataBase[][30] = {"CheatEngine",
   "AutoPlay",
   "GameHack",
   "Memory Search",
   "TSearch"};

int cnt,cnt2;

BOOL CALLBACK EnumWinProc(HWND hwnd,LPARAM lparam)
{
   char szWindow[255];
   char szClass[255];

   if(GetParent(hwnd)) return TRUE;
   GetWindowText(hwnd,szWindow,255);
   GetClassName(hwnd,szClass,255);

   for(int i = 0; i < cnt; i++)
   {
   if(!strnicmp(szWindowDataBase[i],szWindow,strlen(szWindowDataBase[i])))
   {
MessageBox(NULL,"게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n","해킹 프로그램 발견",MB_ICONSTOP);
ExitProcess(-1);
   }
   }

   for(i = 0; i < cnt; i++)
   {
   if(!strnicmp(szClassDataBase[i],szClass,strlen(szClassDataBase[i])))
   {
MessageBox(NULL,"게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n","해킹 프로그램 발견",MB_ICONSTOP);
ExitProcess(-1);
   }
   }
   return TRUE;
}

BOOL FindBadWindowOrClass()
{
for(cnt = 0; ;cnt++) //Counting Pattern
if(!szWindowDataBase[cnt][0])
break;

for(cnt2 = 0; ;cnt2++) //Counting Pattern
if(!szWindowDataBase[cnt2][0])
break;

EnumWindows(EnumWinProc,NULL);
return TRUE;
}

프로세스 이름의 경우 EnumWindow 콜백에서 GetThreadProcessId() 함수를 한 후,
OpenProcess() 하여주고, GetModuleBaseName()함수를 이용하여 프로세스 이름을
구하여 확인시켜 주는 방식으로 진행하여 주면 됩니다. 이 코드는 패턴 검사의 코드를
조금 수정하면 됨으로 따로 올리진 않겠습니다. 그 나머지 요소는 GH 프로그램이
사용하고 있는 요소들을 어떻게 확인하는지 Process Explorer를 이용한 예제를 보여드
리 겠습니다.

먼저 위와 같이 Lower panel view를 Handles로 해줍니다.

TSearch에서 사용중인 핸들 목록을 볼 수 있는데요.
위 그림에서 보면, TSearch는 3가지의 독특한 Event를 만드는 것을 알 수 있습니다.
즉, 다음 3가지 중 하나를 선택하여 해당 이벤트가 존재하는지를 확인한다면,
TSearch의 실행여부를 확인할 수 있습니다. 코드는 다음과 같습니다.

BOOL CheckByEventName()
{
char szEventDataBase[][30] = {
"User stopped search",
"Debugger Loaded",
"TSearch.ServerLoaded"
};
HANDLE hEvent;

for(int cnt = 0; ;cnt++) //Counting Pattern
if(!szEventDataBase[cnt][0])
break;

for(int i = 0; i < cnt; i++)
{
if(OpenEvent(EVENT_ALL_ACCESS,FALSE,szEventDataBase[i]))
{
MessageBox(NULL,"게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n","해킹 프로그램 발견",MB_ICONSTOP);
ExitProcess(-1);
}
}

return TRUE;
}

뮤텍스를 이용한 확인 방법의 코드는 다음과 같습니다.

BOOL CheckByMutexName()
{
char szMutexDataBase[][30] = {
"TSearch",
"CheatEngine",
"GameHack"
};
HANDLE hEvent;

for(int cnt = 0; ;cnt++) //Counting Pattern
if(!szMutexDataBase[cnt][0])
break;

for(int i = 0; i < cnt; i++)
{
CreateMutex(NULL,FALSE,szMutexDataBase[i]);
if(GetLastError() == ERROR_ALREADY_EXISTS)
{
MessageBox(NULL,"게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n","해킹 프로그램 발견",MB_ICONSTOP);
ExitProcess(-1);
}
}

return TRUE;
}

파일맵을 이용한 방법의 코드는 다음과 같습니다.

BOOL CheckByFileMapName()
{
char szFileMapDataBase[][30] = {"DUALMEM",
"TSearch",
"CheatEngine",
"GameHack"
};
HANDLE hFileMap;
LPVOID pMapFile;

for(int cnt = 0; ;cnt++) //Counting Pattern
if(!szFileMapDataBase[cnt][0])
break;

for(int i = 0; i < cnt; i++)
{
hFileMap = CreateFileMapping((HANDLE)INVALID_HANDLE_VALUE,NULL,
PAGE_READWRITE,0,1,szFileMapDataBase[i]);
if(GetLastError() == ERROR_ALREADY_EXISTS)
{
MessageBox(NULL,"게임 해킹 프로그램 발견 되었습니다.\n게임이 종료 됩니다.\n","해킹 프로그램 발견",MB_ICONSTOP);
ExitProcess(-1);
}
}

return TRUE;
}

레지스트리, 파일로 확인하는 방법은 어떤 레지스트리나 파일을 쓰는지는 Process
Explorer를 확인하는 것으로 동일하고, 확인은 레지스트리나 파일을 열 떄,
이미 존재하는지 여부만 확인해주면 됨으로 별도의 코드는 첨부하지 않겠습니다.
윈도우즈에 로드되어 있는 드라이버의 목록은 ntdll.dll의
ZwQuerySystemInformation() 를 이용하여 구할 수 있습니다.

참고적으로 위의 핸들목록을 출력하는 기능은 정덕영님의 저서 'Windows 구조와
원리 그리고 Codes'에 나온 코드인 ListHandles라는 코드도 똑같은 기능을 합니다.
코드는 다음과 같습니다.

#include "stdafx.h"
#include "windows.h"
#include <stdio.h>
#include "nativeAPI.h"

BOOL EnablePrivilege(PCSTR name)
{
TOKEN_PRIVILEGES priv = {1, {0, 0, SE_PRIVILEGE_ENABLED}};
LookupPrivilegeValue(0, name, &priv.Privileges[0].Luid);

HANDLE hToken;
OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hToken);

AdjustTokenPrivileges(hToken, FALSE, &priv, sizeof priv, 0, 0);
BOOL rv = GetLastError() == ERROR_SUCCESS;

CloseHandle(hToken);
return rv;
}

int main(int argc, char* argv[])
{
ULONG pid;
HANDLE hProcess, hCurrentProcess;
SYSTEM_HANDLE_INFORMATION *aHandles;
ULONG nHandles, nCount;
ULONG *pULONG;

//1. Parameter parsing
if (argc == 1)
{
printf("HELP : ListHandles PID\n");
return 0;
}
pid = strtoul(argv[1], 0, 0);

//2. Get process handle
EnablePrivilege(SE_DEBUG_NAME);
hProcess = OpenProcess(PROCESS_DUP_HANDLE, FALSE, pid);
hCurrentProcess = GetCurrentProcess();

//3. Get Handle's Information
nCount = 100;
pULONG = (PULONG)malloc(nCount * sizeof(SYSTEM_HANDLE_INFORMATION) + sizeof(ULONG));
while (ZwQuerySystemInformation(SystemHandleInformation, pULONG,
nCount * sizeof(SYSTEM_HANDLE_INFORMATION)+ sizeof(ULONG)
, 0) == STATUS_INFO_LENGTH_MISMATCH)
{
free(pULONG);
nCount += 50;
pULONG = (PULONG)malloc(nCount * sizeof(SYSTEM_HANDLE_INFORMATION) + sizeof(ULONG));
}
nHandles = *pULONG;
aHandles = (PSYSTEM_HANDLE_INFORMATION)(pULONG + 1);

//4. Print Handle's Information
printf("Process ID : %x\n", pid);
for (ULONG i = 0; i < nHandles; i++)
{
if (aHandles[i].ProcessId == pid)
{
HANDLE hObject;
OBJECT_BASIC_INFORMATION obi;
POBJECT_TYPE_INFORMATION pOti;
POBJECT_NAME_INFORMATION pOni;
ULONG nTypeName, nObjectName, n;

if(DuplicateHandle(hProcess, (HANDLE)aHandles[i].Handle,
hCurrentProcess, &hObject, 0, 0, DUPLICATE_SAME_ACCESS) == FALSE)
continue;

ZwQueryObject(hObject, ObjectBasicInformation, &obi, sizeof(obi), &n);
printf("%p %04hx %3lx %3ld %4ld ",
aHandles[i].Object, aHandles[i].Handle, obi.Attributes,
obi.HandleCount - 1, obi.PointerCount - 2);
//Object Type
nTypeName = obi.TypeInformationLength + 2;
pOti = (POBJECT_TYPE_INFORMATION)malloc(nTypeName);

ZwQueryObject(hObject, ObjectTypeInformation, pOti, nTypeName, &nTypeName);
printf("%-14.*ws ", pOti->Name.Length / 2, pOti->Name.Buffer);
//Object Name
nObjectName = obi.NameInformationLength == 0
? MAX_PATH * sizeof (WCHAR) : obi.NameInformationLength;

pOni = (POBJECT_NAME_INFORMATION)malloc(nObjectName);

if (NT_SUCCESS(ZwQueryObject(hObject, ObjectNameInformation, pOni,
nObjectName, &nObjectName)))
printf("%.*ws", pOni->Name.Length / 2, pOni->Name.Buffer);

printf("\n");

free(pOni); free(pOti); CloseHandle(hObject);
}
}
free(aHandles);
CloseHandle(hProcess);

return 0;
}

세번쨰로 자동 플레이 차단은 에플리케이션 방식의 오토플레이라면 유저레벨에서
막는방법과 커널레벨에서 막는 방법으로 나뉠 수 있습니다. 사실 후킹하는 시점이
다를 뿐, 실제적으로 차단해야할 API들은 같습니다. 유저레벨에서는 모든 프로세스에
Dll을 인젝션 한 후, 해당 Dll에서 GetPixel(), PostMessageA(), PostMessageW(),
SendInput(), SendMessageA(), SendMessageW(), SetCursorPos(), keybd_event(),
mouse_event() 등의 함수를 차단하여 주어야 합니다.
커널레벨에서는 KeServiceDescriptorTableShadow에 있는 SendInput(),
NtUserQueryWindow(), NtUserBuildHwndList(), NtUserFindWindowEx(),
NtUserGetForegroundWindow(), GetDC(), GetWindowDC() 등의 함수를 후킹해서
처리해 주어야 합니다. 그래픽 관련 함수를 후킹하는 이유는 최근 오토플레이들은
단순한 메크로가 아닌, 픽셀 정보를 읽어온 후, 그에 interact하여 작동하는 방식을
많이 취하기 떄문입니다. 위의 함수들을 모두 후킹하여 처리하여 주면, 에플리케이션
방식의 메크로는 거의 차단된다고 보시면 됩니다. (커널레벨에서의 irp 발생 및
pesudo 코드 사용등 예외는 존재합니다.)

네번쨰로 메시지 후킹 차단은 커널단에서 비교적 강력하게 구현될 수 있는데,
메시지 후킹은 SetWindowHookEx()를 이용해서 이루어 지는데, 운영체제 내에서는
다음과 같은 구조체로 관리 되어 집니다.

#define CWINHOOKS (WH_MAX - WH_MIN + 1)

typedef struct tagPROCESSINFO * PPROCESSINFO;
typedef struct tagDESKTOP * PDESKTOP;
typedef struct tagDESKTOPINFO * PDESKTOPINFO;
typedef struct tagTHREADINFO * PTHREADINFO;
typedef struct tagHOOK * PHOOK;
typedef HWND * PWND;

typedef struct _HEAD {
// KHANDLE h;
DWORD h;
DWORD cLockObj;
} HEAD, *PHEAD;

typedef struct _THROBJHEAD {
HEAD a;
PTHREADINFO pti;
} THROBJHEAD, *PTHROBJHEAD;

typedef struct _DESKHEAD {
PDESKTOP rpdesk;
// KPBYTE pSelf;
PVOID pSelf;
} DESKHEAD, *PDESKHEAD;

typedef struct _THRDESKHEAD {
THROBJHEAD a;
DESKHEAD b;
} THRDESKHEAD, *PTHRDESKHEAD;

typedef struct tagHOOK { /* hk */
THRDESKHEAD head;
PHOOK phkNext;
int iHook;    // WH_xxx hook type
PVOID offPfn;
UINT    flags;    // HF_xxx flags
int ihmod;
PTHREADINFO ptiHooked;    // Thread hooked.
PDESKTOP    rpdesk; // Global hook pdesk. Only used when
   // hook is locked and owner is destroyed
} HOOK;

typedef struct tagDESKTOPINFO {

PVOID pvDesktopBase;    // For handle validation
PVOID pvDesktopLimit; // ???
PWND    spwnd; // Desktop window
DWORD fsHooks;    // Deskop global hooks
PHOOK aphkStart[CWINHOOKS + 1]; // List of hooks
PWND    spwndShell;    // Shell window
PPROCESSINFO ppiShellProcess;    // Shell Process
PWND    spwndBkGnd;    // Shell background window
PWND    spwndTaskman;    // Task-Manager window
PWND    spwndProgman;    // Program-Manager window
PVOID pvwplShellHook; // see (De)RegisterShellHookWindow
int cntMBox;    // ???
} DESKTOPINFO;

typedef struct _CLIENT_ID
{
HANDLE UniqueProcess;
HANDLE UniqueThread;
} CLIENT_ID;

#pragma packed(1)
typedef struct tagTHREADINFO {
struct W32THREAD // dt win32k!_W32THREAD -r
{
PVOID pEThread;
unsigned long RefCount;
PVOID ptlW32;
PVOID pgdiDcattr;
PVOID pgdiBrushAttr;
PVOID pUMPDObjs;
PVOID pUMPDHeaps;
unsigned long dwEngAcquireCount;
PVOID pSemTable;
PVOID pUMPDObj;
} W32THREAD;

//***************************************** begin: USER specific fields

PVOID ptl;    // Listhead for thread lock list
// end :: 0x2c :: start
PPROCESSINFO    ppi;    // process info struct for this thread
PVOID    pq; // keyboard and mouse input queue
PVOID spklActive; // active keyboard layout for this thread
PVOID pcti; // Info that must be visible from client
PDESKTOP    rpdesk;
PDESKTOPINFO    pDeskInfo;    // Desktop info visible to client

// ....omitted....

} THREADINFO, *PTHREADINFO;

typedef struct _TEB
{
   NT_TIB Tib; // 00h
   PVOID EnvironmentPointer; // 1Ch
   CLIENT_ID Cid;    // 20h
   PVOID ActiveRpcInfo;    // 28h
   PVOID ThreadLocalStoragePointer;    // 2Ch
   PVOID Peb; // 30h
   DWORD LastErrorValue; // 34h
   DWORD CountOfOwnedCriticalSections; // 38h
   PVOID CsrClientThread;    // 3Ch
   PTHREADINFO Win32ThreadInfo;    // 40h
   DWORD Win32ClientInfo[0x1F];    // 44h
   PVOID WOW32Reserved;    // C0h
   DWORD CurrentLocale;    // C4h
   DWORD FpSoftwareStatusRegister; // C8h
   PVOID SystemReserved1[0x36];    // CCh
   PVOID Spare1; // 1A4h
   LONG ExceptionCode; // 1A8h
   DWORD SpareBytes1[0x28];    // 1ACh
   PVOID SystemReserved2[0xA]; // 1D4h
// GDI_TEB_BATCH GdiTebBatch;    // 1FCh
   DWORD gdiRgn; // 6DCh
   DWORD gdiPen; // 6E0h
   DWORD gdiBrush; // 6E4h
   CLIENT_ID RealClientId; // 6E8h
   PVOID GdiCachedProcessHandle; // 6F0h
   DWORD GdiClientPID; // 6F4h
   DWORD GdiClientTID; // 6F8h
   PVOID GdiThreadLocaleInfo;    // 6FCh
   PVOID UserReserved[5];    // 700h
   PVOID glDispatchTable[0x118]; // 714h
   DWORD glReserved1[0x1A];    // B74h
   PVOID glReserved2;    // BDCh
   PVOID glSectionInfo;    // BE0h
   PVOID glSection;    // BE4h
   PVOID glTable;    // BE8h
   PVOID glCurrentRC;    // BECh
   PVOID glContext;    // BF0h
   DWORD LastStatusValue; // BF4h
   UNICODE_STRING StaticUnicodeString; // BF8h
   WCHAR StaticUnicodeBuffer[0x105]; // C00h
   PVOID DeallocationStack;    // E0Ch
   PVOID TlsSlots[0x40]; // E10h
   LIST_ENTRY TlsLinks;    // F10h
   PVOID Vdm;    // F18h
   PVOID ReservedForNtRpc; // F1Ch
   PVOID DbgSsReserved[0x2]; // F20h
   DWORD HardErrorDisabled;    // F28h
   PVOID Instrumentation[0x10];    // F2Ch
   PVOID WinSockData;    // F6Ch
   DWORD GdiBatchCount;    // F70h
   DWORD Spare2; // F74h
   DWORD Spare3; // F78h
   DWORD Spare4; // F7Ch
   PVOID ReservedForOle; // F80h
   DWORD WaitingOnLoaderLock;    // F84h
} TEB, *PTEB;

TEB의 Win32ThreadInfo 구조체의 pDeskInfo에 aphkStart라는 배열이
훅을 관리하는데, 즉 이 배열을 주기적으로 0으로 초기화 시킴으로써 설치된 훅을
제거할수도 있으며 메시지 후킹을 차단할수도 있습니다.

다섯번쨰로 필요한 기능으로써, 허용되지 않은 메모리 접근차단은 유저레벨에서는
각 프로세스에 Dll을 인젝션 한 후, NtOpenProcess(), NtProtectVirtualMemory(),
NtReadVirtualMemory(), NtWriteVirtualMemory(), ZwOpenProcess(), ZwProtect
VirtualMemory(), ZwReadVirtualMemory(), ZwWriteVirtualMemory(),
OpenProcess(), ReadProcessMemory(), VirtualProtect(), VirtualProtectEx(),
WriteProcessMemory(), GetWindowThreadProcessId()등의 API를 후킹하여
주어야 합니다. 유저레벨에서의 후킹코드는 앞에서 다뤘던 코드에 조금의 수정을
가하면 되는 것임으로, 생략하도록 하겠습니다. 커널레벨에서의 후킹코드들은
다음과 같습니다.

ZwOpenProcess Hook :

NTSTATUS NewZwOpenProcess(
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL
)
{
NTSTATUS rc;
NTSTATUS rc2;
CHAR Caller_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];
PEPROCESS Process;
char *nameptr;

GetProcessName( Caller_Process_Name ); //Get Process Name

rc = ((ZWOPENPROCESS)(OldZwOpenProcess)) (
ProcessHandle,
DesiredAccess,
ObjectAttributes,
ClientId OPTIONAL);

if(DesiredAccess == PROCESS_ALL_ACCESS)
{

if(NT_SUCCESS(rc))
{

rc2 = ObReferenceObjectByHandle(
*ProcessHandle,
PROCESS_ALL_ACCESS,
NULL,
KernelMode,
(void *)&Process,
NULL);
if(NT_SUCCESS(rc2))
{
nameptr = (PCHAR)Process + gProcessNameOffset;
strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
if(!strncmp(Target_Process_Name,MYPROCESS,strlen(MYPROCESS)))
{
ObDereferenceObject(Process);
ZwClose(ProcessHandle);
rc = STATUS_INVALID_HANDLE;
ProcessHandle = 0;
}
}
}
}
return rc;
}

ZwOpenProcess() 함수를 후킹하고 있다가, 만약 핸들을 오픈하고자 하는 프로세스가,
보호하는 프로세스라면 핸들을 닫고 잘못된 핸들이라고 값을 리턴합니다.

ZwWriteVirtualMemory Hook :

NTSTATUS NTAPI NewZwWriteVirtualMemory(
IN HANDLE hProcess,
IN PVOID BaseAddress,
IN PVOID Buffer,
IN ULONG BytesToWrite,
OUT PULONG BytesWritten
)
{
NTSTATUS rc;
NTSTATUS rc2;
CHAR Attack_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];
PEPROCESS Process;
char *nameptr;

GetProcessName( Caller_Process_Name );

rc2 = ObReferenceObjectByHandle(
hProcess,
PROCESS_ALL_ACCESS,
NULL,
KernelMode,
(void *)&Process,
NULL);
if(NT_SUCCESS(rc2))
{
nameptr = (PCHAR)Process + gProcessNameOffset;
strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
ObDefreferenceObject(Process);
if(!strncmp(Target_Process_Name,MYPROCESS,strlen(MYPROCESS)))
{
return STATUS_UNSUCCESSFUL;
}
}

rc = ((ZWWRITEVIRTUALMEMORY)(OldZwWriteVirtualMemory)) (
hProcess,
BaseAddress,
Buffer,
BytesToWrite,
BytesWritten);
return rc;
}

ZwReadVirtualMemory Hook :

NTSTATUS NTAPI NewZwReadVirtualMemory(
IN HANDLE hProcess,
IN PVOID BaseAddress,
OUT PVOID Buffer,
IN ULONG BytesToRead,
OUT PULONG BytesRead
)
{
NTSTATUS rc;
NTSTATUS rc2;
CHAR Caller_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];
PEPROCESS Process;
char *nameptr;

GetProcessName( Caller_Process_Name );

여섯번쨰로 디버깅 차단은 코드에 안티 디버깅 루틴을 삽입과 후킹을 사용합니다.
안티 디버깅 루틴을 먼저 다루어 보면,
첫번쨰로 IsDebuggerPresent() 함수를 이용한 방법이 있는데,
IsDebuggerPresent()함수는 kernel32.dll에 의해 export되어지는 함수로써,
해당 함수를 호출한 프로세스가 디버깅 당하는 중이면 TRUE(1)을,
아닐 경우는 FALSE(0)을 반환하는 함수이다. 즉 이 함수를 주기적으로 호출하여
줌으로써 디버깅 여부를 확인할 수 있다. 코드는 다음과 같습니다.

if(IsDebuggerPresent())
{
OutputDebugString("Debugeed!!");
//디버깅 당하는 중일떄의 어떠한 처리
}

두번쨰 방법으로 PEB 구조체의 BeingDebuggged 값을 직접 조작하는 방법이 있다.
IsDebuggerPresent()함수는 내부적으로, PEB의 BeingDebugged값을 읽어서 리턴
하여 주는 함수입니다. 즉 IsDebuggerPresent()함수를 호출하지 않고, 직접
PEB의 BeingDebugged의 값을 읽어와도 결과는 같다는 소리입니다.
다음은 PEB의 BeingDebugged의 값을 읽어오는 함수 입니다.

BOOL Pesudo_IsDebuggerPresent()
{
BOOL Retval = 0;
__asm
{
push eax
mov eax,dword ptr fs:{0x18]
mov eax,dword ptr ds:[eax+0x30]
movzx eax,byte ptr ds:[eax+0x2]
mov Retval,eax
pop eax
}
return Retval;
}

세번쨰 방법으로 CheckRemoteDebuggerPresent() 함수를 이용하는 방법이 있습니다.
이 함수는 함수를 호출하는 프로세스 자신외에도, 타 프로세스에도 사용이 가능합니다.
다음과 같이 사용합니다.

BOOL CheckDebugger(HANDLE hProcess)

{
BOOL Retval = 0;

CheckRemoteDebuggerPresent(hProcess,&Retval);
return Retval;
}

* CheckRemoteDebuggerPresent()는 NTAPI의 ZwQueryInformationProcess()로
연결됩니다. ZwQueryInformationProcess()는 다음과 같은 호출 인자를 갖는 함수입니다.

NTSTATUS NTAPI ZwQueryInformationProcess(HANDLE ProcessHandle,
PROCESSINFOCLASS ProcessInformationClass,
PVOID ProcessInformation,
ULONG ProcessInformationLength,
PULONG ReturnLength);

첫번쨰는 질의 하고자 하는 대상 프로세스의 핸들.
두번쨰는 질의 하고자 하는 내용(디버깅 여부는 ProcessDebugPort)
세번쨰는 결과
네번쨰는 길이
다섯번쨰는 실반환 길이이다.
해당 함수를 직접 호출하는 것도 하나의 방법이 될 수 있을 것입니다.

네번쨰 방법으로 NtGlobalFlag의 값을 확인하는 방법이 있다.
디버거가 프로세스를 디버깅 할때는, 셋되어 지는 Flag들이 있는데, NtGlobalFlag는
그 중 하나이다. 코드는 다음과 같습니다.

BOOL CheckNtGlobalFlag()
{
BOOL Retval = 0;

__asm
{
push eax
mov eax,dword ptr fs:[0x30]
mov eax,0x68
mov eax,dword ptr ds:[eax]
cmp eax,0x70
pop eax
jne NotDebuged
mov Retval,1
NotDebugged :
nop
}
return Retval;
}

다섯번쨰 방법으로 Heap flags를 이용하는 방법이 있습니다. Heap의 상태가 디버그
되지 않고 있는 평소 상태와 다른지를 확인하는 것은 강력한 안티디버그 메소드가 될
수 있습니다. 예를들면, 힙 해더에 있는 ForceFlags(오프셋 0x10)은 디버거의 존재
여부를 확인하기 위해 쓰일 수 있습니다.대략적인 코드는 다음과 같습니다.

mov eax, fs:[30h]
mov eax, [eax+18h] ;process heap
mov eax, [eax+10h] ;heap flags
test eax, eax
jne @DebuggerDetected

여섯번쨰 방법으로 UnhandledExceptionFilter를 이용하는 방법이 있습니다.
SEH 핸들러의 주소로 디버거가 없을시 실행할 코드로 넣어주고,
고의적으로 예외를 발생시키어, 디버거가 있는지 없는지를 확인하여 주는
방법입니다. (디버거가 존재함으로, SEH 핸들러로 넘어 가지 않고, 다음 명령을
실행 시키게 되는점을 이용) 코드는 다음과 같습니다.

push @not_debugged
call SetUnhandledExceptionFilter
xor eax, eax
mov eax, dword [eax] ; trigger exception
;program terminated if debugged
;...
@not_debugged:
;process the exception
;continue the execution
;...

일곱번째로 NtSetInformationThread를 이용하는 방법이 있습니다. ThreadInformationClass 가 0x11 (ThreadHideFromDebugger 상수)로 지정되고
호출되면, 스레드는 디버거로부터 분리 될 것입니다. (ThreadHideFromDebugger는
ETHREAD의 필드중에 하나죠.) 코드는 다음과 같습니다.

Example:
push 0
push 0
push 11h ;ThreadHideFromDebugger
push -2
call NtSetInformationThread
;thread detached if debugged
;...

여덟번쨰로 kernel32!CloseHandle and NtClose 를 이용하는 방법이 있습니다.
프로세스가 디버그될 떄, ZwClose() 를 잘못된 핸들을 주고 호출하는 것은
STATUS_INVALID_HANDLE(0xC0000008) 예외를 발생 시킵니다.
디버깅 당하고 있다면, CloseHandle()를 호출하는 다음줄의 코드를 발생시킬 것이고,
디버깅 되고 있지 않다면, SEH핸들러가 호출될 것임을 이용한 방법입니다.
코드는 다음과 같습니다.

push offset @not_debugged
push dword fs:[0]
mov fs:[0], esp
push 1234h ;invalid handle
call CloseHandle
; if fall here, process is debugged
;...
@not_debugged:
;...

아홉번쨰로 OutputDebugStringA를 이용하는 간단한 방법도 있습니다.
OutputDebugString()함수가 성공적으로 수행되는지, 안되는지 (리턴값)을 확인하는
방법입니다. 코드는 다음과 같습니다.

xor eax, eax
push offset szHello
call OutputDebugStringA
cmp eax, 1
jne @DebuggerDetected
...

앞서 말한 방법들을 모두 TLS Callback으로써 등록하여 작동시킬수도 있습니다.
TLS Callback은 스텔스하게 안티 디버그 코드를 실행시킬 수 있는 방법으로 사용될
수 있는데, 단지 안티 디버그 코드를 프로그램에 넣어놓고, 헥스 에디터등을 이용하여
PE해더의 Thread Local Storage entry (PE optional header에서 10번째 디렉토리 엔트리
에 있는) 의 값을 코드의 주소로 바꾸어줌으로써, 안티 디버그 코드가 프로그램의
엔트리 포인트가 실행되기전에, 실행 되도록 만들어 줄 수 있습니다.

열번째 방법으로 커널레벨에서 확인하는 방법으로써, 보호하고자 하는 프로세스의
EPROCESS에 debug port의 값을 확인하는 방법이 있습니다. debug port의 값은
디버깅 되고 있지 않을떄는 0이며, 디버깅 될때에는 0이 아닙니다. 이 점을 이용해서
디버깅 여부를 확인하고 싶은 프로세스의 EPROCESS 스트럭쳐의 debug port값을
확인하는 것은 아주 강력한 안티 디버그 방법으로서 사용될 수 있습니다.
이 밖에도 훨씬 많은 안티 디버깅 방법들이 존재하며,
나머지 목록및 더 자세한 설명은 다음페이지를 참조하시기 바랍니다.
http://dual5651.hacktizen.com/tt/entry/Windows-Anti-Debug-Reference

이렇게 많은 안티 디버깅 루틴이 존재하지만, 안티 디버깅 루틴만으로 충분한 것은
아닙니다. 위에서 말했듯이, 후킹 역시 중요한 부분을 차지 합니다.
DebugActiveProcess() 같은 함수를 필수적으로 후킹해 주어서 디버거가 붙는
자체를 차단해 주어야 합니다. 또 게임을 바로 실행시키는 방식이 아닌,
로더를 거치는 방식을 사용하여, CreateProcess()에 DEBUG_ONLY_THIS_PROCESS
같은 옵션을 가지고 임으로 사용되는 것을 막아주어야 합니다.

여덟번쨰로 필요한 기능인 무결성 검사의 코드는 다음과 같습니다.

#include "stdafx.h"
#include <windows.h>

int main(int argc, char* argv[])
{
int a;
DWORD checksum = 0xE1E4CDE2;
__asm
{
pushad
pushfd

mov esi,offset StartAddressOfCheck
mov ecx,offset EndAddressOfCheck
sub ecx,offset StartAddressOfCheck
xor eax,eax
xor ebx,ebx

Check_Loop:
mov ebx, [esi]
add eax,ebx
rol eax,1
inc esi
loop Check_Loop

cmp eax,checksum
jne EndAddressOfCheck //코드 조작 감지
popfd
popad
}
StartAddressOfCheck:
a = 5;
if(a > 10)
{
MessageBox(NULL,"You beat this program!!","Congratulation",64);
return 0;
}
else
{
MessageBox(NULL,"a 변수의 값이 10보다 작습니다.","ashole!",MB_ICONWARNING);
return 0;
}
EndAddressOfCheck:
__asm
{
popfd
popad
}
MessageBox(NULL,"You can`t beat this program sxxker!!","Cracker!!",MB_ICONWARNING);
return 0;
}

StartAddressOfCheck 로 부터 EndAddressOfCheck 까지의 명령어들의 합산값을
미리 계산하여 두고, 프로그램을 실행할 떄에, 그값이 기존의 값과 같은지 여부를
확인하여 변조되었는지를 확인하는 방법입니다. 이 확인하는 루틴을 별도의 스레드를
만들어 와일을 돌리거나, 타이머를 이용하는 방법으로, 코드의 지속적인 감시도 가능합니다.
단, 명령코드의 합산은 현재 코드가 존재하는 주소에 의해서도 영향을 받기 떄문에,
컴파일 모드가 디버그 인지, 릴리즈 인지, StartAddressOfCheck앞에 새로운 코드나
문자열등 StartAddressOfCheck의 주소에 영향을 줄 수 있는 변수가 있으면, 새롭게
checksum 값을 계산하여 상수값으로 주어야 합니다. 다소 귀찮은 면이 있지만,
프로그램을 안전하게 보호하는데 한 역활을 할 수 있습니다. 위의 코드는 프로세스에
대한 검사이지만, 파일에 대해서도 쉽게 적용할 수 있을 것입니다. (ReadFile())
또, 조금만 생각해보면, 게임에 무결성 체크 코드를 넣지 않아도, Anti GH 프로그램에서
ReadProcessMemory()함수를 이용하여 체크할수도 있을 것입니다.

아홉번쨰로 필요한 기능인 시스템 디스크립터 복구이 의미하는 것은 Rootkit에
의해 변조되어 있을, 디스크립터들(ex: SSDT, IDT, and so on..)을 의미 합니다.
SSDT 나 IDT의 변조여부는 어떻게 확인하는가? 원리는 간단합니다.
SSDT나 IDT는 기본적으로 ntoskrnl.exe의 메모리 영역에 속함으로,
각 모듈들의 시작주소와 끝주소들을 구해놓고, 만약 백터나 디스패쳐의 주소가
ntoskrnl.exe의 시작주소와 끝주소 사이에 있지 않다면, 이는 변조된 것으로
판단하면 됩니다. 코드는 다음과 같습니다.

PMODULE_LIST GetListOfModules(PNTSTATUS pns)

{

ULONG ul_NeededSize;

ULONG *pul_ModuleListAddress = NULL;

NTSTATUS ns;

PMODULE_LIST pml = NULL;

// Call it the first time to determine the size required

// to store the information.

ZwQuerySystemInformation(SystemModuleInformation,

&ul_NeededSize,

&ul_NeededSize);

pul_ModuleListAddress = (ULONG *) ExAllocatePool(PagedPool, ul_NeededSize);

if (!pul_ModuleListAddress) // ExAllocatePool failed.

{

if (pns != NULL)

*pns = STATUS_INSUFFICIENT_RESOURCES;

return (PMODULE_LIST) pul_ModuleListAddress;

}

ns = ZwQuerySystemInformation(SystemModuleInformation,

pul_ModuleListAddress,

ul_NeededSize,

0);

if (ns != STATUS_SUCCESS)// ZwQuerySystemInformation failed.

{

// Free allocated paged kernel memory.

ExFreePool((PVOID) pul_ModuleListAddress);

if (pns != NULL)

*pns = ns;

return NULL;

}

pml = (PMODULE_LIST) pul_ModuleListAddress;

if (pns != NULL)

*pns = ns;

return pml;

}

..................

   g_pml = GetListOfModules(&ns);
   if(!g_pml)
   {
DbgPrint("Get Failed");
return;
   }
   for(count = 0; count < g_pml->d_Modules; count++)
{
if(!_stricmp("ntoskrnl.exe",g_pml->a_Modules[count].a_bPath+g_pml->a_Modules[count].w_NameOffset))
{
g_NTOSKRNL.Base = (ULONG)g_pml->a_Modules[count].pBase;
g_NTOSKRNL.End = ((ULONG)g_pml->a_Modules[count].pBase + g_pml->a_Modules[count].d_Size);
}
}

위의 코드로 ntoskrnl.exe의 시작주소와 끝주소를 알 수 있으며, SSDT와 IDT를
끝번호까지 돌면서, ntoskrnl.exe에 속하는지만 확인하여 주면 됩니다.
만약, 이런식으로 루프를 돌다가 변조된 것이 발견되면 어떻게 복구해야할까요?
그것에 대해서는
http://dual5651.hacktizen.com/tt/entry/SSDT-후킹-무력화에-대한-연구
의 SSDT Restore에 대해서 읽어보시고, 코드를 참조하시면 됩니다.

목차에는 없지만 최근 많이 사용되고 있는 프로세스 숨기기에 대해서도 간단히
다루어 보겠습니다. 첫번째로 사용할 수 있는 방법으로서 커널단에서
ZwQuerySystemInformation() 이라는 함수를 후킹하는 방법이 있습니다.
코드는 다음과 같습니다.

NTSTATUS NTAPI NewZwQuerySystemInformation(
IN ULONG SystemInformationClass,
IN PVOID SystemInformation,
IN ULONG SystemInformationLength,
OUT PULONG ReturnLength
)
{
NTSTATUS rc;
CHAR Attack_Process_Name[PROCNAMELEN];

GetProcessName( Attack_Process_Name );

rc = ((ZWQUERYSYSTEMINFORMATION)(OldZwQuerySystemInformation)) (
SystemInformationClass,
SystemInformation,
SystemInformationLength,
ReturnLength );

if( NT_SUCCESS( rc ) && strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{

if(5 == SystemInformationClass)
{
struct _SYSTEM_PROCESSES *curr = (struct _SYSTEM_PROCESSES *)SystemInformation;
struct _SYSTEM_PROCESSES *prev = NULL;

while(curr)
{
ANSI_STRING process_name;
ANSI_STRING ANSI_Enemy_Name;
UNICODE_STRING Enemy_Name;
RtlUnicodeStringToAnsiString( &process_name, &(curr->ProcessName), TRUE);
if( (255 > process_name.Length) && (0 < process_name.Length) )
{
if(0 == strncmp( process_name.Buffer, ProcessName, NT_PROCNAMELEN-1))
{

//DbgPrint("[Alarm] ProcessScan Detected\n");
//DbgPrint("Called by %s\n",Attack_Process_Name);
if(prev)
{
if(curr->NextEntryDelta)
{
prev->NextEntryDelta += curr->NextEntryDelta;
}
else
{
prev->NextEntryDelta = 0;
}
}
else
{
if(curr->NextEntryDelta)
{
(char *)SystemInformation += curr->NextEntryDelta;
}
else
{
SystemInformation = NULL;
}
}
}
}
RtlFreeAnsiString(&process_name);
prev = curr;
if(curr->NextEntryDelta) ((char *)curr += curr->NextEntryDelta);
else
{
curr = NULL;
}
}
}
}
return rc;
}

NtUserQueryWindow(), NtUserBuildHwndList(), NtUserFindWindowEx(),
NtUserGetForegroundWindow() 라는 함수들은 창의 핸들과 관련이 있는 함수들입니다.
창의 핸들을 획득하는 것을 차단하기 위해 위의 함수들을 후킹하는 코드 입니다.

UINT_PTR NewNtUserQueryWindow(IN ULONG WindowHandle,IN ULONG TypeInformation)
{
ULONG WindowHandleProcessID;
CHAR Attack_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];
PEPROCESS Process;
char *nameptr;

GetProcessName(Attack_Process_Name);
if(strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
WindowHandleProcessID = ((NTUSERQUERYWINDOW)(WINDOWSERVICEIDX(483)))(WindowHandle,0);
if(PsLookupProcessByProcessId((HANDLE)WindowHandleProcessID,&Process) == STATUS_SUCCESS)
{
ObDereferenceObject(Process);
nameptr = (PCHAR)Process + gProcessNameOffset;
strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
if(!strncmp(Target_Process_Name,ProcessName,NT_PROCNAMELEN-1) || WindowHandleProcessID == SaruenProcessID)
{
return 0;
}
}
}
return OldNtUserQueryWindow(WindowHandle,TypeInformation);
}

NTSTATUS NewNtUserBuildHwndList(IN HDESK hdesk, IN HWND hwndNext, IN ULONG fEnumChildren, IN DWORD idThread, IN UINT cHwndMax, OUT HWND *phwndFirst, OUT ULONG* pcHwndNeeded)
{
NTSTATUS result;
CHAR Attack_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];
ULONG ProcessID;
PEPROCESS Process;
char *nameptr;
ULONG i = 0,j;

GetProcessName(Attack_Process_Name);
if(strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
if(fEnumChildren == 1)
{
ProcessID = OldNtUserQueryWindow((ULONG)hwndNext,0);
if(PsLookupProcessByProcessId((HANDLE)ProcessID,&Process) == STATUS_SUCCESS)
   {
ObDereferenceObject(Process);
   nameptr = (PCHAR)Process + gProcessNameOffset;
   strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
if(!strncmp(Target_Process_Name,ProcessName,NT_PROCNAMELEN-1) || ProcessID == SaruenProcessID)
{
return STATUS_UNSUCCESSFUL;
}
}
}
result=((NTUSERBUILDHWNDLIST)(WINDOWSERVICEIDX(312)))(hdesk,hwndNext,fEnumChildren,idThread,cHwndMax,phwndFirst,pcHwndNeeded);
if (result == STATUS_SUCCESS)
{
while (i<*pcHwndNeeded)
{
ProcessID=OldNtUserQueryWindow((ULONG)phwndFirst[i],0);
if(PsLookupProcessByProcessId((HANDLE)ProcessID,&Process) == STATUS_SUCCESS)
   {
   nameptr = (PCHAR)Process + gProcessNameOffset;
   strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
ObDereferenceObject(Process);
if(!strncmp(Target_Process_Name,ProcessName,NT_PROCNAMELEN))
{
   for (j=i; j<(*pcHwndNeeded)-1; j++)
   phwndFirst[j]=phwndFirst[j+1];

   phwndFirst[*pcHwndNeeded-1]=0;
   (*pcHwndNeeded)--;
   continue;
}
}
i++;
}
}
return result;
}
return OldNtUserBuildHwndList(hdesk,hwndNext,fEnumChildren,idThread,cHwndMax,phwndFirst,pcHwndNeeded);
}

ULONG NewNtUserFindWindowEx(IN HWND hwndParent, IN HWND hwndChild, IN PUNICODE_STRING pstrClassName OPTIONAL, IN PUNICODE_STRING pstrWindowName OPTIONAL, IN DWORD dwType)
{
ULONG result;
ULONG ProcessID;
PEPROCESS Process;
char *nameptr;
CHAR Attack_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];

GetProcessName(Attack_Process_Name);
if(!strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
result=OldNtUserFindWindowEx(hwndParent,hwndChild,pstrClassName,pstrWindowName,dwType);
return result;
}
result = ((NTUSERFINDWINDOWEX)(WINDOWSERVICEIDX(378)))(hwndParent,hwndChild,pstrClassName,pstrWindowName,dwType);
if(strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
   ProcessID = OldNtUserQueryWindow(result,0);
   if(PsLookupProcessByProcessId((HANDLE)ProcessID,&Process) == STATUS_SUCCESS)
   {
   nameptr = (PCHAR)Process + gProcessNameOffset;
   strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
if(!strncmp(Target_Process_Name,ProcessName,NT_PROCNAMELEN-1) || ProcessID == SaruenProcessID)
{
result=0;
}
ObDereferenceObject(Process);
   }

}
return result;
}

ULONG NewNtUserGetForegroundWindow(VOID)
{
ULONG result;
ULONG ProcessID;
PEPROCESS Process;
char *nameptr;
CHAR Attack_Process_Name[PROCNAMELEN];
CHAR Target_Process_Name[PROCNAMELEN];

GetProcessName(Attack_Process_Name);
if(!strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
result=OldNtUserGetForegroundWindow();
return result;
}
result = ((NTUSERGETFOREGROUNDWINDOW)(WINDOWSERVICEIDX(404)))();
if(strncmp(Attack_Process_Name,ProcessName,NT_PROCNAMELEN-1))
{
   ProcessID = OldNtUserQueryWindow(result,0);
   if(PsLookupProcessByProcessId((HANDLE)ProcessID,&Process) == STATUS_SUCCESS)
   {
   nameptr = (PCHAR)Process + gProcessNameOffset;
   strncpy(Target_Process_Name, nameptr, NT_PROCNAMELEN);
Target_Process_Name[NT_PROCNAMELEN] = 0;
if(!strncmp(Target_Process_Name,ProcessName,NT_PROCNAMELEN-1) || ProcessID == SaruenProcessID)
{
result=LastForegroundWindow;
}
else
{
LastForegroundWindow=result;
}
ObDereferenceObject(Process);
   }

}
return result;
}

두번쨰로 사용할 수 있는게 DKOM입니다. DKOM은 예외경우가 많이 발생할 수 있음으로,
필드 프로그램에서 사용할 떄에는, 신중에 신중을 고려하여야 할 부분입니다.

첫번째로 가장 많이 알려진 DKOM적 방법인 EPROCESS LINK를 끊는 방법입니다.
먼저 숨기고자 하는 프로세스 이름으로 EPROCESS를 찾는 함수 입니다.

PEPROCESS
FindProcessByName(char *Name)
{
PLIST_ENTRY start_plist,plist_hTable = NULL;
ULONG *d_pid;
PEPROCESS eproc;
char *nameptr;
CHAR Process_Name[NT_PROCNAMELEN];
NTSTATUS rc;

plist_hTable = (PLIST_ENTRY)((*(ULONG*)
((ULONG)PsInitialSystemProcess + 0xC4)) + 0x1C);

start_plist = plist_hTable;

do
{
d_pid = (ULONG*)(((ULONG)plist_hTable + 0x8)
- 0x1C);
rc = PsLookupProcessByProcessId((HANDLE)*d_pid,&eproc);
if(eproc && NT_SUCCESS(rc))
{
nameptr = (PCHAR)eproc + gProcessNameOffset;
strncpy(Process_Name, nameptr, NT_PROCNAMELEN);
Process_Name[NT_PROCNAMELEN] = 0;
ObDereferenceObject(eproc);
if(!strncmp(Process_Name,Name,NT_PROCNAMELEN-1))
{
return eproc;
}
}
// DbgPrint("%s\n",Process_Name);
plist_hTable = plist_hTable->Flink;
}while(start_plist != plist_hTable);

return 0;
}

그후에는 다음과 같은 코드로 숨킬 수 있습니다.

PEPROCESS MyProcess;
PLIST_ENTRY plist_active_procs;

MyProcess = FindProcessByName(ProcessName);

if(MyProcess)
{
plist_active_procs = (LIST_ENTRY *)((DWORD)MyProcess + 0x88);
*((DWORD *)plist_active_procs->Blink) = (DWORD)plist_active_procs->Flink;
*((DWORD *)plist_active_procs->Flink+1) = (DWORD)plist_active_procs->Blink;
plist_active_procs->Flink = (LIST_ENTRY *) &(plist_active_procs->Flink);
plist_active_procs->Blink = (LIST_ENTRY *) &(plist_active_procs->Flink);
}

위의 코드에 다음과 같은 한줄을 붙여넣음으로서, 보호하고자 하는 프로세스의
PID를 0으로 만들어 접근이 불가능하게 할 수도 있습니다.

*((DWORD*)((DWORD)MyProcess+0x84)) = 0;

csrss.exe 에서 핸들을 지우는 코드 입니다.

PEPROCESS gpeproc_csrss;

gpeproc_csrss = (PEPROCESS)FindProcessByName("csrss.exe");
if(!gpeproc_csrss) gpeproc_csrss = (PEPROCESS)FindProcessByName
("CSRSS.EXE");

if(gpeproc_csrss) EraseHandle((PEPROCESS)gpeproc_csrss, (PVOID)MyProcess);

void EraseHandle(PEPROCESS eproc, PVOID tarHandle)
{
PTABLE_ENTRY orig_tableEntry, p_tableEntry, *pp_tableEntry, **ppp_tableEntry;
int a, b, c;
int i_numHandles, i_hperPage, i_numTables;
int i_handle;

//DbgPrint("Hiding %x from %s process handle table.\n", tarHandle, (DWORD)eproc+gul_ProcessNameOffset);
i_numHandles = *(int*)((*(PDWORD)((DWORD) eproc + 0xC4)) + 0x3C);
orig_tableEntry = (PTABLE_ENTRY)*(PDWORD)((*(PDWORD)((DWORD) eproc + 0xC4)));
i_numTables = ((DWORD)orig_tableEntry & 3);

i_hperPage = PAGE_SIZE/sizeof(TABLE_ENTRY);

if (i_numTables == 0)
{
//DbgPrint("Found a single level handle table.\n");
p_tableEntry = (PTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);
for (a = 0; a < i_hperPage; a++)
{
if (((p_tableEntry[a].object ^ 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle - 0x18))
{
//DbgPrint("Handle = %x Object Header %x Security %x\n", a*4, ((p_tableEntry[a].object | 0x80000000) & 0xfffffff8), p_tableEntry[a].security);
p_tableEntry[a].object = 0;
p_tableEntry[a].security = 0;
}
}
}
else if (i_numTables == 1)
{
//DbgPrint("Found a two level handle table.\n");
pp_tableEntry = (PPTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);
for (a = 0; a < i_hperPage; a++)
{
if (pp_tableEntry[a] == NULL)
break;

for (b = 0; b < i_hperPage; b++)
{
if (((pp_tableEntry[a][b].object ^ 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle - 0x18))
{
//DbgPrint("Handle = %x Object Header %x Security %x\n", ((a*512)+b)*4, ((pp_tableEntry[a][b].object | 0x80000000) & 0xfffffff8), pp_tableEntry[a][b].security);
pp_tableEntry[a][b].object = 0;
pp_tableEntry[a][b].security = 0;
}
}

}
}
else if (i_numTables == 2)
{
//DbgPrint("Found a three level handle table.\n");
ppp_tableEntry = (PPPTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);
for (a = 0; a < i_hperPage; a++)
{
if (ppp_tableEntry[a] == NULL)
break;

for (b = 0; b < i_hperPage; b++)
{
if (ppp_tableEntry[a][b] == NULL)
break;

for (c = 0; c < i_hperPage; c++)
{
if (((ppp_tableEntry[a][b][c].object ^ 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle - 0x18))
{
//DbgPrint("Handle = %x Object Header %x Security %x\n", ((a*512)+(b*256)+c)*4, ((ppp_tableEntry[a][b][c].object | 0x80000000) & 0xfffffff8), ppp_tableEntry[a][b][c].security);
ppp_tableEntry[a][b][c].object = 0;
ppp_tableEntry[a][b][c].security = 0;
}
}

}
}
}
}

PspCidTable에서 오브젝트를 지우는 함수 입니다.

먼저 다음과 같이 PspCidTable을 지우는 함수를 먼저 호출 합니다.

DWORD gcid_table;

gcid_table = GetPspCidTable();

DWORD
GetPspCidTable()
{
PVOID pPspCidTable = NULL;
ULONG i;
UNICODE_STRING usPsLookup;
PUCHAR Buff;

RtlInitUnicodeString( &usPsLookup, L"PsLookupProcessByProcessId" );
Buff = MmGetSystemRoutineAddress( &usPsLookup );

if( Buff != NULL )
{
for( i = 0; i < 0x40; i++, Buff++ )
{
if( *(PUSHORT)(Buff) == 0x35ff && *((PUCHAR)Buff+6) == 0xe8 )
{
pPspCidTable = (PVOID)(*(PULONG)(Buff+2));
break;
}
}
}

return (DWORD)pPspCidTable ? *(DWORD*)pPspCidTable : (DWORD)NULL;
}

EraseObjectFromPspCidTable(gcid_table, (PVOID)MyProcess, 0,*((DWORD*)((DWORD)MyProcess+0x84)), 0 );

void EraseObjectFromPspCidTable(DWORD handle_table, PVOID tarHandle, enum ObjectType obj_type, DWORD pid, DWORD tid)
{
PTABLE_ENTRY orig_tableEntry, p_tableEntry, *pp_tableEntry, **ppp_tableEntry;
int a, b, c;
int i_numHandles, i_hperPage, i_numTables;
int i_handle;

i_numHandles = *(int*)(handle_table + 0x3c);
orig_tableEntry = (PTABLE_ENTRY)*(PDWORD)(handle_table + 0);
i_numTables = ((DWORD)orig_tableEntry & 3);

i_hperPage = PAGE_SIZE/sizeof(TABLE_ENTRY);

if (i_numTables == 0)
{

// DbgPrint("Found a single level handle table.\n");
p_tableEntry = (PTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);
for (a = 0; a < i_hperPage; a++)
{
if (((p_tableEntry[a].object | 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle))
{
// DbgPrint("[%d]\n",a);
// DbgPrint("Handle = %x Object %x Security %x\n", a*4, ((p_tableEntry[a].object | 0x80000000) & 0xfffffff8), p_tableEntry[a].security);

// add_index(&g_PspCidTableList, SINGLE_LEVEL,obj_type,(DWORD)tarHandle,pid,tid, a,0, 0, p_tableEntry[a].object, p_tableEntry[a].security);

p_tableEntry[a].object = 0;
p_tableEntry[a].security = ((PHANDLE_TABLE)handle_table)->FirstFree;
((PHANDLE_TABLE)handle_table)->FirstFree = (ULONG)( (tid!=0) ? tid : pid );
}
}
}
else if (i_numTables == 1)
{
// DbgPrint("Found a two level handle table.\n");
pp_tableEntry = (PPTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);

for (a = 0; a < i_hperPage; a++)
{
if (pp_tableEntry[a] == NULL)
break;

for (b = 0; b < i_hperPage; b++)
{
//DbgPrint("Comparing %x to %x\n", ((pp_tableEntry[a][b].object | 0x80000000) & 0xfffffff8), tarHandle);
if (((pp_tableEntry[a][b].object | 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle))
{
// DbgPrint("[%d][%d]\n",a,b);
// DbgPrint("Handle = %x Object %x Security %x\n", ((a*512)+b)*4, ((pp_tableEntry[a][b].object | 0x80000000) & 0xfffffff8), pp_tableEntry[a][b].security);
// add_index(&g_PspCidTableList, DOUBLE_LEVEL,obj_type,(DWORD)tarHandle, pid,tid, a,b, 0, pp_tableEntry[a][b].object, pp_tableEntry[a][b].security);

pp_tableEntry[a][b].object = 0;
pp_tableEntry[a][b].security = ((PHANDLE_TABLE)handle_table)->FirstFree;
((PHANDLE_TABLE)handle_table)->FirstFree = (ULONG)( (tid!=0) ? tid : pid );
}
}

}
}
else if (i_numTables == 2)
{
// DbgPrint("Found a three level handle table.\n");
ppp_tableEntry = (PPPTABLE_ENTRY)((DWORD)orig_tableEntry & 0xfffffff8);
for (a = 0; a < i_hperPage; a++)
{
if (ppp_tableEntry[a] == NULL)
break;

for (b = 0; b < i_hperPage; b++)
{
if (ppp_tableEntry[a][b] == NULL)
break;

for (c = 0; c < i_hperPage; c++)
{
if (((ppp_tableEntry[a][b][c].object | 0x80000000) & 0xfffffff8) == ((DWORD)tarHandle))
{
// DbgPrint("Handle = %x Object %x Security %x\n", ((a*512)+(b*256)+c)*4, ((ppp_tableEntry[a][b][c].object | 0x80000000) & 0xfffffff8), ppp_tableEntry[a][b][c].security);
// add_index(&g_PspCidTableList, TRIPLE_LEVEL,obj_type, (DWORD)tarHandle, pid,tid, a,b, c, ppp_tableEntry[a][b][c].object, ppp_tableEntry[a][b][c].security);

ppp_tableEntry[a][b][c].object = 0;
ppp_tableEntry[a][b][c].security = ((PHANDLE_TABLE)handle_table)->FirstFree;
((PHANDLE_TABLE)handle_table)->FirstFree = (ULONG)( (tid!=0) ? tid : pid );
}
}

}
}
}
}

HandleListEntry 해제하는 코드 입니다.

UnHookHandleListEntry((PEPROCESS)MyProcess);

void UnHookHandleListEntry(PEPROCESS eproc)
{
PLIST_ENTRY plist_hTable = NULL;
plist_hTable = (PLIST_ENTRY)((*(PDWORD)((DWORD) eproc + 0xc4)) + 0x1c);

//DbgPrint("Unhooking the handle table of Process: %s\n", (DWORD)eproc+gul_ProcessNameOffset);
*((DWORD *)plist_hTable->Blink) = (DWORD) plist_hTable->Flink;
*((DWORD *)plist_hTable->Flink+1) = (DWORD) plist_hTable->Blink;

//plist_hTable->Flink = (LIST_ENTRY *) &(plist_hTable->Flink); // Change the current LIST_ENTRY
//plist_hTable->Blink = (LIST_ENTRY *) &(plist_hTable->Flink); // so we don't point to crap

}

프로세스에 속해 있는 스레드를 숨기는 코드 입니다.

if(gpeproc_csrss) HideThreadsInTargetProcess((PEPROCESS)MyProcess, gpeproc_csrss);

void HideThreadsInTargetProcess(PEPROCESS eproc, PEPROCESS target_eproc)
{
PETHREAD start, walk;
DWORD check1, check2;

if (eproc == NULL)
return;

check1 = *(DWORD *)((DWORD)eproc + 0x50);
check2 = ((DWORD)eproc + 0x50);
// If check1 points back to the EPROCESS, there are no threads in the process.
// It must be exiting.
if (check1 == check2)
return;

start = *(PETHREAD *)((DWORD)eproc + 0x50);
start = (PETHREAD)((DWORD)start - 0x1b0);
walk = start;
do
{
EraseHandle(target_eproc, walk);
walk = *(PETHREAD *)((DWORD)walk + 0x1b0);
walk = (PETHREAD)((DWORD)walk - 0x1b0);
}while (walk != start);
}

지금 소개한 프로세스 숨기는 코드들만 사용하여도, 충분히 강력한 효과를 내실 수 있
을 것입니다. 하지만 꼭 명심하시기 바랍니다. DKOM을 사용할떄는 충분한 필드 테스트가
선행되어져야 한다는 것을...

여담이지만, 사실 이 글의 제목은 'Anti Game hacking 프로그램이 갖추어야할 기능들과
약점들.' 이었는데요. 글을 쓰다보니 -_-;; 필요한 기능과 코드만 다루어도 글의 길이가
꾀 길더군요. 그래서 두편으로 나누기로 결정을 하였습니다. 그럼 다음편에서는
Anti GH 프로그램의 약점과 그 대안에 대해서 알아보도록 하겠습니다.
이 글에서 잘못된 부분은 dual@null2root.org 로 알려주시거나, 이 글에 리플을 달아
주셔도 감사하겠습니다. 그럼 이만 (__)...

프로세스에서 메모리 패턴 검사 :

윈도우,클레스 목록에서 검사 :

이벤트,뮤텍스,파일맵 이름 검사 :

CRC 검사 :

참고 문헌 (?)
- 추후 추가 예정.

CAIN을 이용한 SSL 스니핑 방법.

(Dual) — Sat, 01 Dec 2007 19:18:25 +0900

http://blog.naver.com/kodoi486/70024323339
좋네요 -_-!! 아이디도 필이 확오네요................ㅋㅋ(자갈치아주매........)

File CRC Check 검사기법 우회하기 - Target : GomEncoder

(Dual) — Fri, 30 Nov 2007 23:03:30 +0900

Long time no see!
Dual입니다. :0
아주 오~~랜만에 활동시작 겸 RE에 관한 글을 써보고자 합니다.
주제는? File CRC Check 검사 우회하기(?) 입니다.
대상은 GomEncoder로 잡았는데요, 별 다른 이유가 있는 것은 아닙니다.
그런데 GomEnc가 CRC 체크를 하는 이유는 모르겠습니다(바이러스에 의한 손상검사?)
아시는 분은 댓글 좀 알려주세요. ;0

먼저 한번 생각해 보죠.
저번에 간단히 프로세스의 CRC체크를 우회(?)하는 방법에 대해서 다루었었습니다.
다른 프로세스의 메모리에 CRC 체크를 하는 경우에는 메모리 관련 API들을 후킹했었죠.
이번엔 File이니, 파일관련 API에 브레이크 포인트를 걸고 접근하면 된다는 건
간단하게 파악할 수 있는 요소입니다.

파일관련 API라면? 아무래도 파일의 핸들을 얻기 위한 CreateFile() 이라던지,
파일을 읽어오기 위한 ReadFile() 등이 있겠죠..?
물런 훨씬 다양한 방법으로 파일을 읽어올수도 있겠습니다만,
많은 Win32에플리케이션 제작자들은 해당 API를 많이 사용합니다.

음.. 네 먼저 곰인코더라는 바탕화면에 있는 빠른실행은GomEnc.exe라는 실행파일로
연결 되있네요. 하지만 사실은 이것은 버젼확인과 CRC체크등을 하는 런쳐일뿐,
실제 알맹이(?)는 GomEncMain.exe입니다.

이제 PEID로 GomEnc.exe 와 GomEncMain.exe의 패킹 여부를 알아 보도록 하죠.

런쳐님께선 패킹이 안되있으시고, 알맹이(?)님께서는 y0da로 패킹이 되게시네요.
사실GomEncMain.exe의 패킹여부는 그닥 중요하지 않겠네요.
왜냐면 오늘 글에서는 GomEnc.exe를 공략하는 거니까요. ;0

GomEnc.exe는 패킹도 되어 있지 않으니 한번 올리디버거로 열어서 ReadFile과
CreateFile에 BP(브레이크 포인트)를 잡아 보겠습니다.

(클릭해서 보세요)

0013BE90 0013FB10 |FileName =
"C:\Program Files\GRETECH\GomEncoder\GomEncMain.exe"
0013BE94 80000000 |Access = GENERIC_READ
0013BE98 00000001 |ShareMode = FILE_SHARE_READ
0013BE9C 00000000 |pSecurity = NULL
0013BEA0 00000003 |Mode = OPEN_EXISTING
0013BEA4 08000000 |Attributes = SEQUENTIAL_SCAN
0013BEA8 00000000 \hTemplateFile = NULL

핸들을 열어오는 대상이 GomEncMain.exe니, 올바르게 접근해 온 모양입니다.

0013BE98 00000090 |FileHandle
0013BE9C 0013BEB8 |Buffer
0013BEA0 00001000 |nNumberOfBytes
0013BEA4 0013CEBC |lpNumberOfBytesRead
0013BEA8 00000000 |lpOverlapped

자, 여기서 CRC값을 계산해내는 코드를 찾기 위해서 중요한 값이 무엇일까요?
답은 Buffer의 주소입니다. 그곳에 읽어온 값이 저장될 것이고, 프로그램 내에서는
그 곳에 저장된 값들을 가지고 계산을 할 것임으로, 결국 그 메모리에 ReadAccess
하는 코드를 찾으면, 그곳이 바로 CRC값을 계산해네는 곳이 되겠습니다.

(클릭해서 보세요)

음 MZ가 있는 것으로 보아, 파일의 처음부터 1000바이트 씩 읽어오는군요.

가장 앞에 'M'에 하드웨어 브레이크 포인트를 걸겠습니다.

(클릭해서 보세요)

이제 디버기를 run 시키면, 다음과 같은 코드에 와있게 됩니다.

0040102B    0FB61A    MOVZX EBX,BYTE PTR DS:[EDX]
0040102E    8BF0    MOV ESI,EAX
00401030    836D 10 08    SUB DWORD PTR SS:[EBP+10],8
00401034    23F1    AND ESI,ECX
00401036    33F3    XOR ESI,EBX
00401038    8BD8    MOV EBX,EAX
0040103A    C1EB 08 SHR EBX,8
0040103D    8B04B5 90204000 MOV EAX,DWORD PTR DS:[ESI*4+402090]
00401044    33C3    XOR EAX,EBX
00401046    42    INC EDX
00401047    8BF0    MOV ESI,EAX
00401049    0FB61A    MOVZX EBX,BYTE PTR DS:[EDX]
0040104C    23F1    AND ESI,ECX
0040104E    33F3    XOR ESI,EBX
00401050    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
00401054    8B34B5 90204000 MOV ESI,DWORD PTR DS:[ESI*4+402090]
0040105B    C1E8 08 SHR EAX,8
0040105E    33F0    XOR ESI,EAX
00401060    42    INC EDX
00401061    8BC6    MOV EAX,ESI
00401063    23C1    AND EAX,ECX
00401065    33C3    XOR EAX,EBX
00401067    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
0040106B    8B0485 90204000 MOV EAX,DWORD PTR DS:[EAX*4+402090]
00401072    C1EE 08 SHR ESI,8
00401075    33C6    XOR EAX,ESI
00401077    42    INC EDX
00401078    8BF0    MOV ESI,EAX
0040107A    23F1    AND ESI,ECX
0040107C    33F3    XOR ESI,EBX
0040107E    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
00401082    8B34B5 90204000 MOV ESI,DWORD PTR DS:[ESI*4+402090]
00401089    C1E8 08 SHR EAX,8
0040108C    33F0    XOR ESI,EAX
0040108E    42    INC EDX
0040108F    8BC6    MOV EAX,ESI
00401091    23C1    AND EAX,ECX
00401093    33C3    XOR EAX,EBX
00401095    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
00401099    8B0485 90204000 MOV EAX,DWORD PTR DS:[EAX*4+402090]
004010A0    C1EE 08 SHR ESI,8
004010A3    33C6    XOR EAX,ESI
004010A5    42    INC EDX
004010A6    8BF0    MOV ESI,EAX
004010A8    23F1    AND ESI,ECX
004010AA    33F3    XOR ESI,EBX
004010AC    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
004010B0    8B34B5 90204000 MOV ESI,DWORD PTR DS:[ESI*4+402090]
004010B7    C1E8 08 SHR EAX,8
004010BA    33F0    XOR ESI,EAX
004010BC    42    INC EDX
004010BD    8BC6    MOV EAX,ESI
004010BF    23C1    AND EAX,ECX
004010C1    33C3    XOR EAX,EBX
004010C3    0FB65A 01 MOVZX EBX,BYTE PTR DS:[EDX+1]
004010C7    8B0485 90204000 MOV EAX,DWORD PTR DS:[EAX*4+402090]
004010CE    C1EE 08 SHR ESI,8
004010D1    33C6    XOR EAX,ESI
004010D3    42    INC EDX
004010D4    8BF0    MOV ESI,EAX
004010D6    23F1    AND ESI,ECX
004010D8    33F3    XOR ESI,EBX
004010DA    C1E8 08 SHR EAX,8
004010DD    8B34B5 90204000 MOV ESI,DWORD PTR DS:[ESI*4+402090]
004010E4    33C6    XOR EAX,ESI
004010E6    42    INC EDX
004010E7    4F    DEC EDI
004010E8 ^ 0F85 3DFFFFFF JNZ GomEnc.0040102B

드디어!! CRC 체크 루틴에 도달한 것이죠.

이후의 File Check를 우회하는 방법은 프로세스에서 하는 방식과 같습니다.
프로세스 내에 메모리를 할당하고 원본의 내용을 카피한 후, 그 내용으로
베이스 어드레스를 바꾸어 주면 됩니다. 이 경우에는 edx가 베이스 인데요,
edx에 할당한 메모리 주소를 줘도 됩니다.
정말 쉽죠? :)

간단하게 해당 주소에 BP를 건 후, BP가 걸리면 EDX레지스터의 값을
대상 프로세스에 메모리를 할당하고, 거기에 .bak파일을 열어서 복사해 넣은
주소로 옮겨서 CRC체크를 우회하는 코드를 만들어 봤습니다.
-_-; 소스를 보시면서 원리를 참고 하시는게 더 도움이 되는 분이 많겠죠.

간단한 테스트를 해보겠습니다.

먼저 다음과 같이 .bak 파일을 만들었습니다.

그리고 GomEncMain.exe 의 내용을 다음과 같이 바꿔봤습니다.

먼저 CRC 체크 우회기를 키기 전에, GomEnc.exe를 그냥 실행시켜 봤습니다.

이제 우회기를 키고 한번 해보겠습니다.

WoW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

소스 다운로드 :

CRC.zip

-----------------------------------------------------------
그 외의 GomEnc의 CRC 체크를 우회하기 위한 방법들로는,
CreateFile을 할때 파일명을 GomEncMain.bak 로 주고,
GomEncMain.exe를 해당 파일명으로 복사해준 후,
GomEncMain.exe는 마음껏 수정해줘도 되는 방법이 있겠고,
GomEnc.ini에 저장되있는 CRC값을 변조된 GomEncMain.exe의
CRC값으로 바꿔주는 방법도 있고 하지만,
이런건 아무래도 이 경우에만 쓸 수 있는 꼼수겠죠 -_-;
여담이지만... 곰인코더에서 GPL 를 쓴다면, 곰인코더를 상용화해서 사용하기
위해서는 소스공개를 해야되는 것 아닌지요? -_-;
그리고, 무료버젼에서의 유일한 단점인 워터마크를 사용자가 컨트롤 할 수 있도록
해놓은 점이 사실상 이해가 잘 가지를 않네요..
setting.ini
[WATERMARK]
START_TIME
END_TIME
POS_X
POS_Y
MARGIN_X
MARGIN_Y

개선되어져야 할 부분들 같습니다..

루트킷 한글판 등장

(Dual) — Tue, 27 Nov 2007 19:02:50 +0900

루트킷은 해커들이 공격하고자 하는 시스템에 지속적이면서 탐지되지 않은 채로 교묘히 접근할 수 있는 최고의 백도어라고 할 수 있다. 루트킷에 관한 최고의 전문가 두 명이 최초로 종합적인 루트킷 가이드를 집필했다. 루트킷이 무엇이고 어떻게 작동하며 제작하는지, 어떻게 루트킷을 탐지하는지 등에 대해 차례로 설명한다.

그렉 호글런드 - 소프트웨어 보안 분야의 개척자 역할을 수행해 왔다. 그는 현재 소프트웨어 보안 검증 서비스를 선도적으로 제공하는 기업인 HBGray 사의 CEO이다. 그렉은 최초의 네트워크 보안 취약점 스캐너(포춘 500대 기업의 절반 이상에 설치되었다) 중 하나를 제작한 후 최초의 윈도우NT 기반 루트킷을 작성하고 그것을 문서화했다. 또한 블랙 햇, RSA와 그 밖의 보안 컨퍼런스의 단골 발표자로도 활동하고 있고, 베스트셀러인 <Exploiting Software: How to Break Code>(Addison-Wesley, 2004)의 공동 저자이기도 하다.

제임스 버틀러 - HBGray의 기술 이사인 제임스 버틀러는 커널 프로그래밍과 루트킷 개발 분야의 최고 전문가 중 한명으로 손꼽히며, 호스트 기반 침입 탐지 시스템에 대한 폭넓은 경험을 갖췄다. 루트킷 탐지와 포렌식 시스템을 위한 VICE 프로그램의 개발자로, 과거 Enterasys의 보안 소프트웨어 선임 엔지니어 및 미국국가안전보장국의 컴퓨터 과학자로 재직한 바 있다. 또한 블랙 햇 보안 컨퍼런스의 단골 발표자이자 트레이너이며 매릴랜드 볼티모어 카운티 대학에서 컴퓨터공학 석사 학위를 취득했다. 그의 논문으로는 'IEEE Information Assurance Workshop', 'Phrack, USENIX ;login:', 'Information Management and Computer Security' 등이 있다.

윤근용 - 시스템 프로그래머로서 시스템에 대한 다양한 분야에 관심이 많으며 특히 보안 분야에 대한 관심이 높아 다년간 보안 업무에 종사하고 있다. 바이러스 보안 업체를 거쳐 현재는 NHN에서 보안 관련 프로젝트를 수행하고 있다. 역서로는 <웹 애플리케이션 해킹 대작전>(에이콘출판, 2007), <실전해킹 절대내공>(에이콘출판, 2007)이 있다.

몇 년 전부터 우리는 협력해서 'Offensive Aspects of Rootkit Technology'라는 교육을 제공해 왔다. 그 교육은 원래 하루 교육이었으나 지금은 수백 페이지의 설명과 예제 코드를 다루는 교육으로 확대되었으며, 그 교육에서 사용되는 교재를 기반으로 이 책이 저술되었다. 현재 우리는 블랙 햇(the Black Hat) 보안 컨퍼런스에서 한 해에 몇 번씩 루트킷 교육을 제공하고 있다. 물론 비공개적으로 교육을 제공하기도 한다. 우리는 교육을 어느 정도 함께 제공해 오면서 우리의 관계를 좀더 긴밀히 할 필요가 있다고 판단했으며 그에 따라 지금은 HBGray 사에서 같이 일하고 있다. HBGray에서 우리는 매우 복잡한 루트킷 문제와 매일 씨름하며, 오늘날 윈도우 사용자들에게 닥친 위협과 미래에 위협이 될 수 있는 것들을 다루기 위해 우리의 경험을 바탕으로 이 책을 저술했다.

사이버 보안 종사자가 루트킷의 위협을 이해하기 위해 꼭 읽어야 할 필독서. - 마크 루시노비치 (윈도우 IT 프로, Windows & .NET Magazine 편집자)

루트킷을 주제로 한 서적은 이 책이 유일하다. 윈도우 보안 연구자나 보안 프로그래머의 흥미를 끌기에 충분하다. 최신 기술을 매우 상세히 설명하며, 책에 실린 기술 정보도 무척 훌륭하다. 또한 콘텐츠의 기술적인 수준이 높고 많은 시간을 투자한 구체적인 구현 예도 매우 멋지다. 정말 탁월한 책이다. - 토니 보츠 (보안 컨설턴트 겸 엑스티빅스 사의 CEO)

윈도우 보안 분야 관련자라면 반드시 읽어야 할 책이다. 보안 전문가, 윈도우 시스템 관리자, 윈도우 시스템 프로그래머라면 루트킷 개발자들이 사용하는 기술에 대해 관심이 많을 것이다. IT와 보안 전문가들이 최신 이메일 바이러스나 그 달의 보안 패치 설치 여부만을 걱정하고 있을 때, 호글런드와 버틀러는 윈도우 운영체제을 위협하는 은닉성 높은 루트킷에 눈을 뜨게 해줬다. 여러분이 맡고 있는 네트워크나 시스템 공격을 제대로 방어하려면 무엇보다도 공격에 사용되는 기술을 파악해 둬야 한다. - 제니퍼 콜드 (보안 컨설턴트, 저자 겸 강사)

누군가에게 점령당한다는 것은 정말 최악의 사건이다. 루트킷에 대한 최초의 서적이자 호글런드와 버틀러가 저술한 이 책을 읽으면 점령 당한다는 것이 무엇을 의미하는지 알게 될 것이다. 루트킷은 악의적인 해킹 툴인 디컴파일러, 디스어셈블러, 오류 삽입 엔진, 커널 디버거, 페이로드 수집기, 커버리지 툴, 실행 흐름 분석 툴 등의 정점에 위치해 있다. 이 책은 공격자가 루트킷을 어떻게 감쪽같이 숨기는지를 설명한다. - 게리 맥그로 (박사, 씨지털 사의 CTO)

저자들은 윈도우 API 파괴와 루트킷 제작에 있어서 최고의 전문가다. 이 두 대가는 루트킷에 대한 베일을 벗기고 루트킷 정보를 어둠의 세상 밖으로 이끌어 내기 위해 힘을 합쳐 노력하고 있다. 윈도우 시스템 보안이나 포렌식 분석에 관심 있는 사람이라면 반드시 읽어야 할 책이다. - 할랜 카비 (<Windows Forensics and Incident Recovery

1장 흔적을 남기지 말라 ... 23
공격자의 동기 이해 ... 24
은닉의 역할 ... 24
은닉이 필요 없는 경우 ... 25
루트킷이란? ... 26
왜 루트킷이 존재하는가? ... 26
원격 명령 실행과 제어 ... 27
소프트웨어 감청 ... 27
루트킷의 합법적인 이용 ... 28
루트킷의 역사 ... 29
루트킷은 어떻게 동작하는가? ... 30
패치 ... 30
이스터 에그 ... 31
스파이웨어 ... 31
소스 코드 조작 ... 31
소프트웨어 변경의 합법성 ... 32
무엇이 루트킷이 아닌가? ... 32
루트킷은 공격툴이 아니다 ... 33
루트킷은 바이러스가 아니다 ... 34
루트킷과 소프트웨어 공격 ... 35
왜 공격 코드가 여전히 문제인가? ... 37
공격을 위한 루트킷 기술 ... 38
HIPS ... 38
NIDS ... 39
IDS/IPS 우회하기 ... 40
포렌식 툴 우회하기 ... 40
결론 ... 41

2장 커널 조작 ... 43
커널의 중요 요소 ... 44
루트킷 설계 ... 45
커널 레벨 코드 소개 ... 48
윈도우 디바이스 드라이버 개발 ... 49
Device Driver Development Kit ... 49
빌드 환경 ... 50
파일 ... 50
Build 툴 ... 52
언로드 루틴 ... 53
드라이버 로드, 언로드 ... 54
디버그 메시지 로그하기 ... 54
유저 모드와 커널 모드 요소를 모두 포함하는 루트킷 ... 55
IPR ... 56
파일 핸들 생성 ... 60
심볼릭 링크 추가 ... 61
루트킷 로딩 ... 63
드라이버 로드를 위한 비정상적인 방법 ... 63
드라이버 로드를 위한 정상적인 방법 ... 65
리소스에서 .sys 파일 추출하기 ... 67
재부팅시 자동 시작 ... 69
결론 ... 71

3장 하드웨어 레벨의 지식 ... 73
링 제로 ... 74
테이블, 테이블 그리고 또 테이블 ... 76
메모리 페이지 ... 77
메모리 접근 검사 ... 78
페이징과 주소 변환 ... 79
페이지 테이블 ... 81
페이지-디렉토리 엔트리 ... 83
페이지-테이블 엔트리 ... 83
페이지 테이블의 읽기 전용 속성 ... 84
멀티 프로세스와 멀티 페이지 디렉토리 ... 84
프로세스와 스레드 ... 85
메모리 디스크립터 테이블 ... 86
글로벌 디스크립터 테이블 ... 87
로컬 디스크립터 테이블 ... 87
코드 세그먼트 ... 87
콜 게이트 ... 87
인터럽트 디스크립터 테이블 ... 88
다른 형태의 게이트 ... 91
시스템 서비스 디스패치 테이블 ... 91
컨트롤 레지스터 ... 92
컨트롤 레지스터 0 ... 92
그 밖의 컨트롤러 레지스터들 ... 93
EFlags 레지스터 ... 93
멀티 프로세서 시스템 ... 93
결론 ... 95

4장 전통적인 후킹 기술 ... 97
애플리케이션 레벨의 후킹 ... 97
임포트 어드레스 테이블 후킹 ... 99
인라인 함수 후킹 ... 100
사용자 프로세스 영역으로 DLL 인젝션하기 ... 103
커널 후킹 ... 108
시스템 서비스 디스크립터 테이블 후킹 ... 109
인터럽트 디스크립터 테이블 후킹 ... 118
디바이스 드라이버 오브젝트의 Major Function 후킹 ... 123
하이브리드 후킹 ... 133
프로세스의 주소 공간으로 진입하기 ... 134
후킹을 위한 메모리 공간 ... 138
결론 ... 140

5장 런타임 패치 ... 141
우회 패치 ... 142
MigBot을 이용한 실행 흐름 변경 ... 143
함수의 바이트 코드 검사 ... 145
원래의 명령어 바이트 ... 146
NonPagedPool 메모리 이용 ... 149
런타임 주소 결정 ... 149
점프 템플릿 ... 153
인터럽트 후킹 예제 ... 154
기타 유사한 방법들 ... 161
결론 ... 162

6장 계층 드라이버 ... 163
키보드 스니퍼 ... 164
IRP와 스택 로케이션 ... 166
KLOG 루트킷 ... 169
파일 필터 드라이버 ... 183
결론 ... 197

7장 커널 오브젝트 직접 변경 ... 199
DKOM의 장점과 단점 ... 200
운영체제 버전 판단하기 ... 202
유저 모드에서 운영체제 버전 판단 ... 202
커널 모드에서 운영체제 버전 판단 ... 204
레지스트리를 이용한 운영체제 버전 판단 ... 204
유저 모드 프로세스에서 디바이스 드라이버로의 통신 ... 206
DKOM을 이용한 은닉 ... 210
프로세스 은닉 ... 210
디바이스 드라이버 은닉 ... 216
동기화 이슈 ... 220
DKOM을 이용한 토큰의 권한과 그룹 변경 ... 224
프로세스 토큰 변경 ... 225
윈도우 이벤트 뷰어 속이기 ... 239
결론 ... 241

8장 하드웨어 조작 ... 243
왜 하드웨어인가? ... 245
펌웨어 변경 ... 246
하드웨어 접근 ... 247
하드웨어 주소 지정 ... 247
하드웨어 접근은 RAM에 접근하는 것과 다르다 ... 248
타이밍 ... 249
I/O 버스 ... 249
BIOS에 접근 ... 251
PCI, PCMCIA 디바이스 접근 ... 252
예 : 키보드 컨트롤러 접근 ... 252
8259 키보드 컨트롤러 ... 253
키보드 LED 변경 ... 253
하드 리부팅 ... 260
키보드 모니터링 ... 260
마이크로코드 업데이트 ... 267
결론 ... 268

9장 은닉 채널 ... 269
원격 명령 및 제어 그리고 데이터 빼내기 ... 270
TCP/IP 프로토콜 위장 ... 271
트래픽 패턴의 인지 ... 272
데이터를 있는 그대로 전송하지 말라 ... 273
시간을 이용하라 ... 274
DNS 패킷 안에 숨겨라 ... 274
아스키 문자 숨기기 ... 274
다른 TCP/IP 채널 이용 ... 275
TDI를 이용한 루트킷 ... 276
어드레스 스트럭처 생성 ... 277
로컬 어드레스 오브젝트 생성 ... 279
TDI 엔드 포인트 생성 ... 283
엔드 포인트와 로컬 어드레스 연결 ... 286
리모트 서버로 연결 - TCP 핸드쉐이크 전송 ... 288
리모트 서버로 데이터 전송 ... 290
네트워크 패킷 변경 ... 293
윈도우XP에서의 로우 소켓 구현 ... 293
인터페이스에 바인딩 ... 294
로우 소켓 스니핑 ... 295
로우 소켓을 이용한 무차별적인 스니핑 ... 296
로우 소켓을 이용한 패킷 전송 ... 297
소스 포트, 주소 위조 ... 297
바운싱 패킷 ... 298
NDIS를 이용한 루트킷 ... 299
프로토콜 등록 ... 299
프로토콜 드라이버 콜백 ... 304
패킷 전체 이동 ... 309
호스트 에뮬레이션 ... 317
자체 MAC 주소 생성 ... 317
ARP 처리 ... 317
IP 게이트웨이 ... 320
패킷 전송 ... 320
결론 ... 325

10장 루트킷 탐지 ... 327
존재 탐지 ... 328
출입문 보호 ... 328
메모리 스캐닝 ... 331
후킹 탐지 ... 331
행동 탐지 ... 341
숨겨진 파일과 레지스트리 키 탐지 ... 341
숨겨진 프로세스 탐지 ... 342
결론 ... 345

-_- 웹파일 업로드 취약점에 대한 고찰에 결과.

(Dual) — Sun, 25 Nov 2007 13:07:32 +0900

다운로드 :

test.zip

웹파일 업로드 문제점, 이젠 거의(?) 찾아볼 수 없는 문제점이 되었죠.
(그래서 사실 아직 많기도 한..)
-_-;;; ㅋㅋ 재가 웹파일업로드 문제점을 테스트 할떄 쓰는 파일입니다.
누군가에겐 도움이 되겠죠 -_-; (PHP 대상)

POC 2007 사진들?ㅎㅎ

(Dual) — Mon, 19 Nov 2007 09:30:22 +0900

아 정말 오랜만에 글을 올려봅니다. ㅎㅎ
엇그제 POC에 다녀왔는데요~
간단하게 한번 후기를 작성해 보고자 합니다. ㅎㅎ
사진의 출처는 SP사이트 입니다. ㅎㅎ

오옹 스텝및 발표자분들이 열심히 준비하고 게시군요 ㅋㅋ

현장의 모습이네요. (사진으로 보니깐 넓어 보이네요)

입구의 모습입니다. 입구에서 등록 및 무선 통역기를 받을 수 있었습니다.

- - <=== ㅎㅎㅎ

ㅎㅎ 유리바다님

wow ~

왼쪽분이 일본분 발표자 인가 그러셨는데 그런데 ㅋㅋ 상태가 점차 안좋아 지시죵

진행을 맡으신 루시도 세븐님?ㅎㅎ;

SnoopSpy의 GilGil님 이십니다 ㅎㅎ

저 가운데 분의 정체는 뭐죠?ㅎㅎ; 머리가 중국무협영화의 스타일?ㅎㅎ

왼쪽은 싱가포르 syscan의 운영자 토마스, 오른쪽은 이뮤니티의 세일즈 맨 이십니다. ㅎㅎ

열심히 듣는 사람들의 모습?ㅎㅎ;'

명함 사세욤~~

번쩍~ 번쩍~ 라스트 플레이스의 아트라스(?) 라는 닉을 쓰시는 리더라고 들었습니다. ㅎㅎ
이름이 뭐냐고 물으시길래, 발음좀 굴려서 마이네미즈 샤뮤엘 쿠 라고 했지요 ㅎㅎ

마지막으로 연회때 사진 입니다. ㅎㅎ; 색깔 보정좀 했는데 -_-너무 밝아졌네요.

CRC(Cyclic Redundancy Check) bypassing?

(Dual) — Wed, 17 Oct 2007 18:43:25 +0900

CRC 체크를 우회하는 방법에 대해 질문하는 분들이 종종 있더군요.
-_-; 너무 엉터리라서 저에게 핵토파스칼 킥을 날릴분들이 많을지도 모르겠지만,
간단히 한번 말해보도록 하겠습니다.

재가 처음에 CRC 체크를 우회하는 것에 대해서 생각을 해볼 때,
첫번쨰 생각한 것은 Shadow Walker Protect 였습니다.
-_-;; 해당 프로젝트가 무엇인지에 대한 설명은 넘어가도록 하겠습니다.

그러나 Shadow Walker Project는 소요되는 시간과 코드량에 비해
위험성이 다소 있기 때문에 결국 쓰지 않았죠. (절떄 귀찮아서가 아닐껍니다.)

두번째 생각한 것은 CRC체크 루틴을 찾아서 수정한다 였는데,
-_- 음.. 얼마 안되서 인터넷에 나오더군요. (그걸 구현하다니 성실한 녀석들)

그렇다면 CRC 체크 루틴은 어떻게 찾을 수 있는 걸까요?

이 대답은 두가지로 나뉘어 집니다.
왜냐하면 CRC체크 루틴은 해당 프로그램 내에서 이루어질 수도 있고,
외부 프로그램에 의해서 이루어질수도 있기 떄문입니다.

먼저 내부 프로그램에 의한 CRC체크 루틴을 찾는 방법에 대해서 말해보자면,
프로그램 내에서 CRC체크 루틴은 대략 어떤 모습을 가지고 있을까요? -_-?
정말 간단하게 생각해보자면 다음과 같다고 볼 수 있겠죠.

for(int i = EntryPoint; i <= SizeOfImage; i++)
{
...
checksum += memory[i];
....
}

-_-;; 재밌는게 보이죠?
모든 메모리의 변조여부를 체크하기 위해서는 모든 메모리에 접근해서 읽어와야
합니다. 즉 Read가 발생하죠... (여기서 감이 오죠)

우리에겐 INTEL이 주신 축복인.. Hardware BreakPoint라는 친구가 있죠.
이 친구가 도와주면 우리는 특정한 메모리 주소에 Write or Read|Write or Excute가
발생했을때와 그 읽기 또는 읽기쓰기 또는 실행을 시도한 주소가 어딘지 알 수 있죠.
-_-; 읽기또는쓰기를 시도한 메모리 주소가 바로 CRC체크루틴이 있는 곳이겠죠..?
(Haredware BreakPoint에 대해선 다음글에서 말하고 있네요 : 링크)

체크루틴을 찾았으면 다음에 할일은 검사에 걸리지 않도록 하는 일입니다.
이것도 역시 아주 간단한데요.
-_-; 음.. 위에서 간단히 설명을 위해 사용했던 코드는 다음과 같이도 표시됩니다.

for(int i = EntryPoint; i <= SizeOfImage; i++)
{
...
checksum += *(BaseAddress + i);
....
}

결국 memory라는 BaseAddress를 기반으로 i값만큼 떨어진 오프셋에 있는 값을
한개씩 확인하는 거죠. 이걸 기반으로 CRC 체크 루틴을 우회할 수 있는 간단한
아이디어를 생각해 낼 수 있는 겁니다.

CRC체크 루틴이 원하는 Original Memory들을 덤프하여 둔 후,
해당 프로세스 내에 다시 메모리를 할당하여 대상 메모리에 덤프해둔 메모리를 복사하면,
기존의 공간과 똑같은 메모리 구조를 가지고 있게 됩니다.
그 후 찾아낸 CRC체크 루틴에서 사용하는 BaseAddress를 할당한 메모리 주소로
바꿔주게 되면 우리가 본래 내용을 변조하여도 언제나 덤프해둔 메모리의 내용만
검사할 것이기 때문에 감지를 우회할 수 있게 됩니다.
이를 간단하게 그림으로 표시해봤습니다.

위는 기존의 메모리 상태이고, 체크루틴의 BaseAddress를 바꾼 후는 :

정말 쉽죠..? (이런말 하다가 죽은 미술가가 한명 있죠..)

그렇다면 외부 프로그램에 의해 검사되는 방식은 어떨까요? 그것도 정말 쉬운데요.
외부 프로세스에서 타 프로세스의 메모리로 접근하기 위해서는 유저레벨에서는
ReadProcessMemory() 라는 API를 사용합니다.
음.. 아마도 인자값이 ReadProcessMemory(hProcess,BaseAddress,buffer,len,&ret);
식으로 썻었던거 같은데요..
커널단에서 ReadProcessMemory()라는 API는 ZwReadVirtualMemory()라는 함수로
연결이 되고, ZwReadVritualMemory함수를 후킹하는 다음과 같은 형식의 코드를
작성함으로써 앞에서 사용했던 방법과 동일하게 돌파가 가능하겠죠.

if((BaseAddress => CRCStartAddress) && (BaseAddress <= CRCEndAddress))

{

..........

BaseAddress = DumpedMemory;

..........

}
내부에서의 검사루틴 돌파법을 이해했다면 두번쨰 방법의 이해는 누워서 호떡먹기보다
쉬울겁니다. -_-/

이번년도 참가예정 국내 보안 컨퍼런스 소개.

(Dual) — Sat, 13 Oct 2007 14:44:21 +0900

1. POC (Power Of Community)

주소 : http://www.powerofcommunity.net

소개 : 2006년도 부터 열리기 시작한 국제 컨퍼런스인 POC는 SecurityProof의
운영자인 Vangelis의 주도하에 다음과 같은 모토를 기반으로 열립니다.

- Hacker Should be free.
- We hack for security.
- We should trust Power of community.

성격 : 이론이나 단순한 프로젝트의 성격에 대한 논의 보다는 실제적인 공격이
어떻게 이루어지는지의 방법론과 시현을 보다 강조하는 성격을 가지고 있습니다.

열리는 날짜 : 11월 15 ~ 16일

장소 : 양재에 위치한 서울 교육 문화 회관

일정 :
첫날 - 11월 15일

08:00~09:00	Registration - 등록
09:30~10:30	Casper, Forensics and Anti-Forensics - 포렌식과 안티 포렌식
11:00 ~ 12:00	Silverbug, How to Hack Your Cell Phones? - 핸드폰 해킹
12:00 ~ 13:00	Lunch - 점심시간 (따로 제공되지는 않습니다.)
13:00 ~ 14:10	Xpl017Elz,Updating.... (미정)
14:20 ~ 15:30	Daiki Fukumori, Attacking Web 2.0 - Web 2.0 에서의 해킹
15:40 ~ 16:50	Dave Aitel, Writing Exploits Using Immunity Debugger - 이뮤니티 디버거를 이용한 익스플로잇 작성
17:00 ~ 18:10	Grugq, Hacking Sucks: Presentation the Hash Hacking Harness

둘째날 - 11월 16일

09:10 ~ 10:10	AmesianX, How to Implement COM Monitor - 1 - COM 후킹
10:20 ~ 11:10	AmesianX, How to Implement COM Monitor - 2 - ""
11:20 ~ 12:30	Hendrik, Hacking VoIP Routers - VoIP 라우터 해킹
12:30 ~ 13:30	Lunch - 점심시간(따로 제공되지는 않습니다)
14:00 ~ 15:10	@tlas, VulnCatcher: Fun with Vtrace and Programmatic Debugging - Defcon CTF 1위팀인 1st@place팀의 리더에 발표
15:30 ~ 16:40	Linzi, Another Idosyncratic Attack
16:50 ~ 18:00	GilGil, SnoopSpy2(Advanced Network Hacking and Security Tool) Project - POC2006에서 voIP Sniffer를 발표한 GilGil님의 SSL MITM시현예상
18:00 ~ 18:30	Closing Ceremony - 폐회
19:00 ~ 21:00	Dinner Party for Speakers, Guests, Participants, and Staffs - 디너 파티 (* 등록시에 디너파티도 등록을 해야 참가 가능)

지원되는 통역언어 : 한국어, 영어, 중국어, 일본어 (번역기의 체널별 선택)

등록 :

* 조기 등록 : 9월 1 ~ 30일

* 후기 등록 : 10월 1일 ~ 11월 10일

* 현장 등록 : 11월 15 ~ 16

구분	날짜	요금
조기	9월 1 ~ 30일	\150,000 (학생 - \50,000)
후기	10월 1 ~ 11월 10일	\200,000(학생 - \100,000)
현장	11월 15 ~ 16일	\300,000(학생 - \150,000)

----------------------------------------------------------------------------------

2. AVAR (Association of anti-Virus Asia Researchers)

주소 : http://www.aavar.org/avar2007/

소개 : 98년 6월 안철수, 안철수 연구소 이사회 의장과 무라카미 세이지
JCSR회장이 아시아 지역의 안티바이러스 분야 협력 증진을 위해 창립한 비영리 조직.

성격 : 세계 보안 및 바이러스 백신 전문가, 각국 정부 관계자등 주요인사들이 많이 참가하며,
전문가들의 전문가를 위한 악성코드에 대한 논의, 대책 강구, 중국발 해킹, 실행파일
압축기반의 바이러스에 대한 대책, 온라인 게임보안등 다양한 주제로 이루어짐.
* 전문가들의 컨퍼런스이기 떄문에 등록금액이 비쌈.

열리는 날짜 : 11월 28-30일

장소 : 서울 프라자 호텔

일정 :

첫날 - 11월 28일

시간	세션

16:00 ~ 19:00	등록

19:00 ~ 21:00	Cocktail Reception - ?!

둘째날 - 11월 29일

시간	세션

08:30 ~ 09:00	등록

09:00 ~ 09:20	환영겢회사 Seiji Murakami, Chairman of AVAR/ Charles Ahn. The host of AVAR 2007/ Byung-Jo Suh, Director General of MIC

09:20 ~ 10:00	Keynote Speech; Security-From Ocean’s Eleven to Seven-Eleven Vincent Weafer - Symantec Corp.

10:00 ~ 10:20	Coffee Break

10:20 ~ 11:00	The Name of The Game Igor Muttik - McAfee

11:00 ~ 11:40	Hackers are storming:New Attack in Online Game Security Area DeokYoung Jung, Howoong Lee - AhnLab

11:40 ~ 12:20	Predicting Hurricanes: Contributing Factors in rise of “False Positives" Mario Vuksan - Bit9, Inc.

12:20 ~ 13:40	Lunch(Luncheon Speech) CDNetworks

13:30 ~ 14:10	Conventional and Advanced Generic Detections Itshak(Tsahi) Carmona - CA, Inc.

14:10 ~ 14:50	The Cybercrime: Fact, reasons, trends Eugene Kaspersky - Kaspersky Lab

14:50 ~ 15:30	Life after Signatures - Pattern analysis application for detecting server-side polymorphic malware before system penetration Amir Lev - Commtouch

15:30 ~ 15:45	Coffee Break

15:45 ~ 16:25	Testing, Testing: Anti-Malware Evaluation for the Enterprise David Harley & Andrew Lee - ESET LLC

16:25 ~ 17:05	Nature of Anti-Malware Testing and Certification Programs Life and times of testing Anti-virus Products Andrew Hayter - ICSA Labs

17:05 ~ 17:45	Testing of "Dynamic Detection" Maik Morgenstern & Andreas Marx - AV-Test. org.

19:00 ~ 22:00	Banquet

셋째날 - 11월 30일

시간	세션

08:30 ~ 08:50	등록

08:50 ~ 09:30	Design of X86 Emulator for Generic Unpacking Chandra Prakash - Sunbelt Software

09:30 ~ 10:10	Anti-unpacker Tricks in Malicious Code Tan, Xiaodong - Websense Inc.

10:10 ~ 10:50	Zero-Hour-Analysis System Shigeru Ishii - IPA, Japan

10:50 ~ 11:10	Coffee Break

11:10 ~ 11:50	Myth and Truth about Windows Vista Security Hongseok Kim - Microsoft

11:50 ~ 12:30	Understanding and Teaching Heuristics Randy Abrams - ESET LLC

12:30 ~ 13:40	Lunch(Luncheon Speech) New Technology Wave Inc.

13:40 ~ 14:20	Is Hong Kong's new Anti-Spam Law Effective? Allan Dyer - Yui Kee Computing Ltd.

14:20 ~ 15:00	Research & Defense on Password-stealing Trojans in China Ritchie Chen - Kingsoft

15:00 ~ 15:40	KrCERT Botnet Mitigation Dong-Ryun Lee - KISA, Korea

15:40 ~ 15:55	Coffee Break

15:55 ~ 16:35	Find out the “Bad guys” on the Symbian Jie Zhang - Fortinet, Inc.

16:35 ~ 17:35	Panel Discussion

17:35 ~ 17:50	Closing Ceremony

17:50 ~ 18:20	AVAR Members meeting

등록 :

조기 등록	총 요금
AVAR 회원	KRW 540,000	KRW 585,000
비회원	KRW 600,000	KRW 650,000

* 조기등록 기간 : 10월 31일 2007년

등록 요금이 포함하는 것?
- 28일의 칵테일 접대
- 컨퍼런스 세션 참가
- 컨퍼런스 내용에 대한 하드커피본과 CD-ROM 포맷.
- 목요일, 11월 29일 그리고 금요일, 11월 30일에 제공되는 점심 그리고 중간 회복(?).
- 목요일 11월 29일에 제공되는 연회
- 양말과 티셔치 그리고 기타.

* KRW가 Korea Won이라면 일반인은 65만원이네요.
-.- 확실한건 일찍일어나는 새가 되지 못하면 두개다 아주 비싸죠~

* 주의할 점이랄까요..
메인 스폰서로서 ncsc(국가사이버안전센터)가 있습니다,
많이들 아시다시피 ncsc는 nis(국가정보원)의 소속기관이죠.
나쁜 짓 많이 해서 캥기는거 있는 분들은 -,.-;;

.net Application 공략 하기

(Dual) — Fri, 12 Oct 2007 16:15:09 +0900

위와 같이 텍스트 박스 한개와 버튼 한개로 이루어진 .net 프로그램이 하나 존재합니다.
이 프로그램을 OllyDebugger로 Open 하거나 Attach 하여 함수 목록을 보면

사용하는 함수 목록이 보이지 않습니다. -_-;

PEID로 패커 및 컴파일러 타입을 알아 보았습니다.

C# 또는 Basic 으로 만들어진 .NET Application이라 그랬던 거군요 -_-;ㅋ

이런 .NET Application은 Reflector 라는 프로그램으로 공략할 수 있습니다.
-_-;; 음.. 디컴파일러(?) 정도의 기능을 제공하여 줍니다.

우선 위와같이 대상 프로그램을 로드해왔습니다.

-_-; Go to member~

클릭할떄 어떻게 되는지 궁금함으로 via_click 을 클릭했습니다.

다음과 같은 코드가 via_click의 코드군요.

private: void __gc* vla_Click(Object __gc* sender, EventArgs __gc* e)
{
    Int32 __gc* numArray __gc [] = __gc new Int32 __gc*[12];
    VariantType __gc* type = *static_cast<__box VariantType*>(Conversions::ToInteger(MyProject::Computer->Registry->GetValue(S"HKEY_CURRENT_USER\\valid", S"", 0)));
    Decimal __gc* num = ((((*static_cast<__box Double*>(type) + 1.5) * *static_cast<__box Double*>(type)) + 0.025));
    if (this->txt->Text == S"somerandomvl")
    {
        Interaction::MsgBox(RuntimeHelpers::GetObjectValue(Encrypt::ParseandDecrypt(Conversions::ToString(Encrypt::ParseandEncrypt(S"ydXX!if not txt is blah youfailed")))), MsgBoxStyle::Exclamation, S"585mfg9gf");
    }
    else
    {
        Interaction::MsgBox(RuntimeHelpers::GetObjectValue(Encrypt::ParseandDecrypt(S"ydXX!if not txt is blah youfailed")), MsgBoxStyle::Exclamation, S"585mfg9gf");
    }
    if (Convert::ToDouble(num) == (((*static_cast<__box Double*>(type) + 1.5) * *static_cast<__box Double*>(type)) + 0.025))
    {
        if ((type == VariantType::Empty) | (MyProject::Application->Info->DirectoryPath->Length->ToString()->Length == 0x1ca))
        {
            Interaction::MsgBox(S"nope", MsgBoxStyle::Information, S"sorry");
        }
        else if ((((this->txt->Text != this->txt->Text) & false) | false) | (type == VariantType::Null))
        {
            this->txt->Text = Conversions::ToString(Encrypt::ParseandDecrypt(S"fm`{f}kpwrn"));
        }
    }
}

음 -_-; 두가지 함수가 존재하는군요.
Encrypt::ParseandEncrypt 와 Encrypt::ParseandDecrypt 네요~

[StandardModule]
private __gc sealed class Encrypt
{
    // Methods
    public: static Object __gc* ParseandDecrypt(String __gc* stringd);
    public: static Object __gc* ParseandEncrypt(String __gc* stringd);
};

Expand Methods

음 -_-; 두 함수를 디스어셈블~!

public: static Object __gc* ParseandDecrypt(String __gc* stringd)
{
    Int32 __gc* numArray __gc [] = __gc new Int32 __gc*[0x80];
    Int32 __gc* index = 0;
    do
    {
        if ((index % 2) == 0)
        {
            numArray[index] = (index - 3);
        }
        if ((index % 2) == 1)
        {
            numArray[index] = (index + 4);
        }
        index++;
    }
    while ((index <= 0x7f));
    index = 0;
    String __gc* str2 = S"";
    Int32 __gc* length = stringd->Length;
    for (Int32 __gc* i = 1; (i <= length); i++)
    {
        Int32 __gc* charCode = (Strings::Asc(Strings::Mid(stringd, i, 1)) - numArray[index]);
        str2 = String::Concat(str2, Conversions::ToString(Strings::Chr(charCode)));
        index++;
        if (index > 0x7f)
        {
            index = 0;
        }
    }
    return str2;
}
 
 
public: static Object __gc* ParseandEncrypt(String __gc* stringd)
{
    Int32 __gc* numArray __gc [] = __gc new Int32 __gc*[0x80];
    Int32 __gc* index = 0;
    do
    {
        if ((index % 2) == 0)
        {
            numArray[index] = (index - 3);
        }
        if ((index % 2) == 1)
        {
            numArray[index] = (index + 4);
        }
        index++;
    }
    while ((index <= 0x7f));
    index = 0;
    String __gc* str2 = S"";
    Int32 __gc* length = stringd->Length;
    for (Int32 __gc* i = 1; (i <= length); i++)
    {
        Int32 __gc* charCode = (Strings::Asc(Strings::Mid(stringd, i, 1)) + numArray[index]);
        str2 = String::Concat(str2, Conversions::ToString(Strings::Chr(charCode)));
        index++;
        if (index > 0x7f)
        {
            index = 0;
        }
    }
    return str2;
}
-_-오옹... 다른 부분은 완전히 똑같고 딱 한글자 틀립니다.
Encrypt:
Int32 __gc* charCode = (Strings::Asc(Strings::Mid(stringd, i, 1)) + numArray[index]);

Decrypt:
Int32 __gc* charCode = (Strings::Asc(Strings::Mid(stringd, i, 1)) - numArray[index]);



위의 코드를 기반으로 VC용으로 좀 변환해 봤습니다.
 
#include "stdafx.h"
#include <string.h>
#include <stdlib.h>
void ParseandDecrypt(char *str)
{
    char numArray[0x80];
    int index = 0;
    do
    {
        if ((index % 2) == 0)
        {
            numArray[index] = (index - 3);
        }
        if ((index % 2) == 1)
        {
            numArray[index] = (index + 4);
        }
        index++;
    }
    while ((index <= 0x7f));
    index = 0;
 int length = strlen(str);
    char *str2 = (char *)malloc(length+1);
 str2[length] = 0;
    for (int i = 0; i < length; i++)
    {
        char charCode = (str[i] - numArray[index]);
        str2[i] = charCode;
  index++;
        if (index > 0x7f)
        {
            index = 0;
        }
    }
 printf("Decrypted Text : %s\n",str2);
 free(str2);
}
 
 void ParseandEncrypt(char *str)
{
    char numArray[0x80];
    int index = 0;
    do
    {
        if ((index % 2) == 0)
        {
            numArray[index] = (index - 3);
        }
        if ((index % 2) == 1)
        {
            numArray[index] = (index + 4);
        }
        index++;
    }
    while ((index <= 0x7f));
    index = 0;
 int length = strlen(str);
    char *str2 = (char *)malloc(length+1);
 str2[length] = 0;
    for (int i = 0; i < length; i++)
    {
        char charCode = (str[i] + numArray[index]);
        str2[i] = charCode;
  index++;
        if (index > 0x7f)
        {
            index = 0;
        }
    }
 printf("Encrypted Text : %s\n",str2);
 free(str2);
}

int main(int argc, char* argv[])
{
 char buffer[15] = {0,};
 printf("Encrypted Text : ");
 gets(buffer);
 ParseandDecrypt(buffer);
 return 0;
}



-_-음... 다음조건을 만족할떄 Decrypt되어 출력되는..


else if ((((this->txt->Text != this->txt->Text) & false) | false) | (type == VariantType::Null))
{
   this->txt->Text = Conversions::ToString(Encrypt::ParseandDecrypt(S"fm`{f}kpwrn"));
}

fm`{f}kpwrn 을 만든 코드에 넣어보면 -_-;


Decompiler 덕분에 입문자도 거져먹기로 풀 수 있습니다.
(-,.-;; 도구는 인간을 XXXX 만드는거 같아요)

Windows Anti-Debug Reference

(Dual) — Mon, 08 Oct 2007 13:52:36 +0900

Windows Anti-Debug Reference
Nicolas Falliere 2007-09-12

This paper classifies and presents several anti-debugging techniques used on Windows NT-based operating systems. Anti-debugging techniques are ways for a program to detect if it runs under control of a debugger. They are used by commercial executable protectors, packers and malicious software, to prevent or slow-down the process of reverse-engineering. We'll suppose the program is analyzed under a ring3 debugger, such as OllyDbg on Windows platforms. The paper is aimed towards reverse-engineers and malware analysts. Note that we will talk purely about generic anti-debugging and anti-tracing techniques. Specific debugger detection, such as window or processes enumeration, registry scanning, etc. will not be addressed here.

[1] Intro

This paper classifies and presents several anti-debugging techniques used on Windows NT-based operating systems.
Anti-debugging techniques are ways for a program to detect if it runs under control of a debugger. They are used by commercial executable protectors, packers and malicious software, to prevent or slow-down the process of reverse-engineering.

We'll suppose the program is analyzed under a ring3 debugger, such as OllyDbg on Windows platforms. The paper is aimed towards reverse-engineers and malware analysts.
Note that we will talk purely about generic anti-debugging and anti-tracing techniques. Specific debugger detection, such as window or processes enumeration, registry scanning, etc. will not be addressed here.

[2] Anti-debugging and anti-tracing techniques

- Exploiting memory discrepancies

(1) kernel32!IsDebuggerPresent
IsDebuggerPresent returns 1 if the process is being debugged, 0 otherwise. This API simply reads the PEB!BeingDebugged byte-flag (located at offset 2 in the PEB structure).
Circumventing it is as easy as setting PEB!BeingDebugged to 0.
Example:
call IsDebuggerPresent
test eax, eax
jne @DebuggerDetected
...

(2) PEB!IsDebugged

This field refers to the second byte in the Process Environment Block of the process. It is set by the system when the process is debugged.
This byte can be reset to 0 without consequences for the course of execution of the program (it is an informative flag).

Example:
mov eax, fs:[30h]
mov eax, byte [eax+2]
test eax, eax
jne @DebuggerDetected
...

(3) PEB!NtGlobalFlags

When a process is created, the system sets some flags that will define how various APIs will behave for this program. Those flags can be read in the PEB, in the DWORD located at offset 0x68 (see the reference).
By default, different flags are set depending if the process is created under a debugger or not. If the process is debugged, some flags controlling the heap manipulation routines in ntdll will be set: FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK and FLG_HEAP_VALIDATE_PARAMETERS.
This anti-debug can be bypassed by resetting the NtGlobalFlags field.

Example:
mov eax, fs:[30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne @DebuggerDetected
...

(4) Heap flags

As explained previously, NtGlobalFlags informs how the heap routines will behave (among other things). Though it is easy to modify the PEB field, if the heap does not behave the same way as it should when the process is not debugged, this could be problematic. It is a powerful anti-debug, as process heaps are numerous, and their chunks can be individually affected by the FLG_HEAP_* flags (such as chunk tails). Heap headers would be affected as well. For instance, checking the field ForceFlags in a heap header (offset 0x10) can be used to detect the presence of a debugger.

There are two easy ways to circumvent it:

- Create a non-debugged process, and attach the debugger once the process has been created (an easy solution is to create the process suspended, run until the entry-point is reached, patch it to an infinite loop, resume the process, attach the debugger, and restore the original entry-point).

- Force the NtGlobalFlags for the process that we want to debug, via the registry key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options": Create a subkey (not value) named as your process name, and under this subkey, a String value "GlobalFlags" set to nothing.

Example:
mov eax, fs:[30h]
mov eax, [eax+18h] ;process heap
mov eax, [eax+10h] ;heap flags
test eax, eax
jne @DebuggerDetected
...

(5) Vista anti-debug (no name)

Here's an anti-debug specific to Windows Vista that I found by comparing memory dumps of a program running with and without control of a debugger. I'm not sure of its realiability, but it's worth mentionning (tested on Windows Vista 32 bits, SP0, English version).

When a process is debugged, its main thread TEB, at offset 0xBFC, contains a pointer to a unicode string referencing a system dll. Moreover, the string follows this pointer (therefore, located at offset 0xC00 in the TEB). If the process is not debugged, the pointer is set to NULL and the string is not present.

Example:
call GetVersion
cmp al, 6
jne @NotVista
push offset _seh
push dword fs:[0]
mov fs:[0], esp
mov eax, fs:[18h] ; teb
add eax, 0BFCh
mov ebx, [eax] ; pointer to a unicode string
test ebx, ebx ; (ntdll.dll, gdi32.dll,...)
je @DebuggerNotFound
sub ebx, eax ; the unicode string follows the
sub ebx, 4 ; pointer
jne @DebuggerNotFound
;debugger detected if it reaches this point
;...

- Exploiting system discrepancies

(1) NtQueryInformationProcess
ntdll!NtQueryInformationProcess is a wrapper around the ZwQueryInformationProcess syscall. Its prototype is the following:

NTSYSAPI NTSTATUS NTAPI NtQueryInformationProcess(
IN HANDLE ProcessHandle,
IN PROCESS_INFORMATION_CLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,
OUT PULONG ReturnLength
);

When called with ProcessInformationClass set to 7 (ProcessDebugPort constant), the system will set ProcessInformation to -1 if the process is debugged.
It is a powerful anti-debug, and there is no easy way to circumvent it. However, if the program is traced, ProcessInformation can be modified when the syscall returns.

Another solution is to use a system driver that would hook the ZwNtQueryInformationProcess syscall.
Circumventing NtQueryInformationProcess will bypass many anti-debug techniques (such as CheckRemoteDebuggerPresent or UnhandledExceptionFilter).

Example:
push 0
push 4
push offset isdebugged
push 7 ;ProcessDebugPort
push -1
call NtQueryInformationProcess
test eax, eax
jne @ExitError
cmp isdebugged, 0
jne @DebuggerDetected
...

(2) kernel32!CheckRemoteDebuggerPresent

This API takes two parameters: a process handle, and a pointer to a DWORD. If the call is successful, the DWORD value will be set to 1 if the process is being debugged.
Internally, this API calls ntdll!NtQueryInformationProcess with ProcessInformationClass set to ProcessDebugPort (7).

Example:
push offset isdebugged
push -1
call CheckRemoteDebuggerPresent
test eax, eax
jne @DebuggerDetected
...

(3) UnhandledExceptionFilter

When an exception occurs, with Windows XP SP>=2, Windows 2003, and Windows Vista, the usual way the OS processes the exception is:

- If any, pass control to the per-process Vectored Exception Handlers.
- If the exception is not processed, pass the control to the per-thread top SEH handler, pointed by FS:[0] in the thread that generated the exception. SEH are chained and called in turn if the exception is not processed by the previous in the chain.
- If the exception has not been processed by any of the previous handlers, the final SEH handler (set by the system), will call kernel32!UnhandledExceptionFilter. This function will decide what it should do depending if the process is debugged or not.
- If it is not debugged, it will call the user-defined filter function (set via kernel32!SetUnhandledExceptionFilter).
- If it debugged, the program will be terminated.

The debugger detection in UnhandledExceptionFilter is made with ntdll!NtQueryInformationProcess.

Example:
push @not_debugged
call SetUnhandledExceptionFilter
xor eax, eax
mov eax, dword [eax] ; trigger exception
;program terminated if debugged
;...
@not_debugged:
;process the exception
;continue the execution
;...

(4) NtSetInformationThread
ntdll!NtSetInformationThread is a wrapper around the ZwSetInformationThread syscall. Its prototype is the following:
NTSYSAPI NTSTATUS NTAPI NtSetInformationThread(
IN HANDLE ThreadHandle,
IN THREAD_INFORMATION_CLASS ThreadInformationClass,
IN PVOID ThreadInformation,
IN ULONG ThreadInformationLength
);

When called with ThreadInformationClass set to 0x11 (ThreadHideFromDebugger constant), the thread will be detached from the debugger.

Similarly to ZwQueryInformationProcess, circumventing this anti-debug requires either modifying ZwSetInformationThread parameters before it's called, or hooking the syscall directly with the use of a kernel driver.

Example:
push 0
push 0
push 11h ;ThreadHideFromDebugger
push -2
call NtSetInformationThread
;thread detached if debugged
;...

(5) kernel32!CloseHandle and NtClose

APIs making user of the ZwClose syscall (such as CloseHandle, indirectly) can be used to detect a debugger. When a process is debugged, calling ZwClose with an invalid handle will generate a STATUS_INVALID_HANDLE (0xC0000008) exception.

As with all anti-debugs that rely on information made directly available from the kernel (therefore involving a syscall), the only proper way to bypass the "CloseHandle" anti-debug is to either modify the syscall data from ring3, before it is called, or set up a kernel hook.

This anti-debug, though extremely powerful, does not seem to be widely used by malicious programs.

Example:
push offset @not_debugged
push dword fs:[0]
mov fs:[0], esp
push 1234h ;invalid handle
call CloseHandle
; if fall here, process is debugged
;...
@not_debugged:
;...

(6) Self-debugging

A process can detect it is being debugged by trying to debug itself, for instance by creating a new process, and calling kernel32!DebugActiveProcess(pid) on the parent process.

In turn, this API calls ntdll!DbgUiDebugActiveProcess which will call the syscall ZwDebugActiveProcess. If the process is already debugged, the syscall fails. Note that retrieving the parent process PID can be done with the toolhelp32 APIs (field th32ParentProcessID in the PROCESSENTRY32 structure.

(7) Kernel-mode timers

kernel32!QueryPerformanceCounter is an efficent anti-debug. This API calls ntdll!NtQueryPerformanceCounter which wraps the ZwQueryPerformanceCounter syscall.

Again, there is no easy way to circumvent this anti-tracing trick.

(8) User-mode timers

An API such as kernel32!GetTickCount returns the number of milliseconds ellapsed since the system started. The interesting thing is that it does not make use of kernel-related service to perform its duties. A user-mode process has this counter mapped in its address space. For 8Gb user-mode spaces, the value returned would be:

d[0x7FFE0000] * d[0x7FFE0004] / (2^24)

(9) kernel32!OutputDebugStringA

This anti-debug is quite original, I have encountered it only once, in files packed with ReCrypt v0.80. The trick consists of calling OutputDebugStringA, with a valid ASCII string. If the program is run under control of a debugger, the return value will be the address of the string passed as a parameter. In normal conditions, the return value should be 1.

Example:
xor eax, eax
push offset szHello
call OutputDebugStringA
cmp eax, 1
jne @DebuggerDetected
...

(10) Ctrl-C

When a console program is debugged, a Ctrl-C signal will throw a EXCEPTION_CTL_C exception, whereas the signal handler would be called directly is the program is not debugged.

Example:
push offset exhandler
push 1
call RtlAddVectoredExceptionHandler
push 1
push sighandler
call SetConsoleCtrlHandler
push 0
push CTRL_C_EVENT
call GenerateConsoleCtrlEvent
push 10000
call Sleep
push 0
call ExitProcess
exhandler:
;check if EXCEPTION_CTL_C, if it is,
;debugger detected, should exit process
;...
sighandler:
;continue
;...

- CPU anti-debug

(1) Rogue Int3

This is a classic anti-debug to fool weak debuggers. It consists of inserting an INT3 opcode in the middle of a valid sequence of instructions. When the INT3 is executed, if the program is not debugged, control will be given to the exception handler of the protection and execution will continue.

As INT3 instructions are used by debuggers to set software breakpoints, inserting INT3 opcodes can be used to trick the debugger into believing that it is one his breakpoints. Therefore, the control would not be given to the exception handler, and the course of the program would be modified. Debuggers should track where they set software breakpoints to avoid falling for this one.

Similarly, note that INT3 may be encoded as 0xCD, 0x03.

Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 0CCh
;if fall here, debugged
;...
@handler:
;continue execution
;...

(2) "Ice" Breakpoint

The so-called "Ice breakpoint" is one of Intel's undocumented instruction, opcode 0xF1. It is used to detect tracing programs.

Executing this instruction will generate a SINGLE_STEP exception. Therefore, if the program is already traced, the debugger will think it is the normal exception generated by executing the instruction with the SingleStep bit set in the Flags registers. The associated exception handler won't be executed, and execution will not continue as expected.
Bypassing this trick is easy: one can run over the instruction, instead and single-stepping on it. The exception will be generated, but since the program is not traced, the debugger should understand that it has to pass control to the exception handler.

Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 0F1h
;if fall here, traced
;...
@handler:
;continue execution
;...

(3) Interrupt 2Dh

Executing this interrupt if the program is not debugged will raise a breakpoint exception. If the program is debugged, and the instruction is not executed with the trace flag, no exception will be generated, and execution will carry on normally. If the program is debugged and the instruction traced, the following byte will be skipped, and execution will continue. Therefore, using INT 2Dh can be used as a powerful anti-debug and anti-tracer mechanism.
Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 02Dh
mov eax, 1 ;anti-tracing
;...
@handler:
;continue execution
;...

(4) Timestamp counters
High precision counters, storing the current number of CPU cycles executed since the machine started, can be queried with the RDTSC instruction. Classic anti-debugs consist of measuring time deltas at key points in the program, usually around exception handlers. If the delta is too large, that would mean the program runs under control of a debugger (processing the exception in the debugger, and giving control back to the debuggee is a lengthy task).

Example:
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
rdtsc
push eax
xor eax, eax
div eax ;trigger exception
rdtsc
sub eax, [esp] ;ticks delta
add esp, 4
pop fs:[0]
add esp, 4
cmp eax, 10000h ;threshold
jb @not_debugged
@debugged:
...
@not_debugged:
...
handler:
mov ecx, [esp+0Ch]
add dword ptr [ecx+0B8h], 2 ;skip div
xor eax, eax
ret

(5) Popf and the trap flag

The trap flag, located in the Flags register, controls the tracing of a program. If this flag is set, executing an instruction will also raise a SINGLE_STEP exception. The trap flag can be manipulated in order to thwart tracers. For instance, this sequence of instructions will set the trap flag:

pushf
mov dword [esp], 0x100
popf

If the program is being traced, this will have no real effect on the flags register, and the debugger will process the exception, believing it comes from regular tracing. The exception handler won't be executed. Circumventing this anti-tracer trick simply require to run over the pushf instruction.

(6) Stack Segment register

Here's a very original anti-tracer. I encountered it in a packer called MarCrypt. I believe it is not widely known, not to mention, used.
It consists of tracing over this sequence of instructions:

push ss
pop ss
pushf
nop

When tracing over pop ss, the next instruction will be executed but the debugger will not break on it, therefore stopping on the following instruction (NOP in this case).
Marcrypt uses this anti-debug the following way:

push ss
; junk
pop ss
pushf
; junk
pop eax
and eax, 0x100
or eax, eax
jnz @debugged
; carry on normal execution

The trick here is that, if the debugger is tracing over that sequence of instructions, popf will be excuted implicitly, and the debugger will not be able to unset the trapflag in the pushed value on the stack. The protection checks for the trap flag and terminates the program if it's found.
One simple way to circumvent this anti-tracing is to breakpoint on popf and run the program (to avoid using the TF flag).

(7) Debug registers manipulation

Debug registers (DR0 through DR7) are used to set hardware breakpoints. A protection can manipulate them to either detect that hardware breakpoints have been set (and therefore, that it is being debugged), reset them or set them to particular values used to perform code checks later. A packer such as tElock makes use of the debug registers to prevent reverse-engineers from using them.
From a user-mode perspective, debug registers cannot be set using the privileged 'mov drx, ...' instruction. Other ways exist:

- An exception can be generated, the thread context modified (it contains the CPU registers at the time the exception was thrown), and then resumed to normal execution with the new context.

- The other way is to use the NtGetContextThread and NtSetContextThread syscalls (available in kernel32 with GetThreadContext and SetThreadContext).

Most protectors use the first, "unofficial" way.

Example:
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
xor eax, eax
div eax ;generate exception
pop fs:[0]
add esp, 4
;continue execution
;...
handler:
mov ecx, [esp+0Ch] ;skip div
add dword ptr [ecx+0B8h], 2 ;skip div
mov dword ptr [ecx+04h], 0 ;clean dr0
mov dword ptr [ecx+08h], 0 ;clean dr1
mov dword ptr [ecx+0Ch], 0 ;clean dr2
mov dword ptr [ecx+10h], 0 ;clean dr3
mov dword ptr [ecx+14h], 0 ;clean dr6
mov dword ptr [ecx+18h], 0 ;clean dr7
xor eax, eax
ret

(8) Context modification

As with debug registers manipulation, the context can also be used to modify in an unconventionnal way the execution stream of a program. Debuggers can get easily confused!
Note that another syscall, NtContinue, can be used to load a new context in the current thread (for instance, this syscall is used by the exception handler manager).

- Uncategorized anti-debug

(1) TLS-callback

This anti-debug was not so well-known a few years ago. It consists to instruct the PE loader that the first entry point of the program is referenced in a Thread Local Storage entry (10th directory entry number in the PE optional header). By doing so, the program entry-point won't be executed first. The TLS entry can then perform anti-debug checks in a stealthy way.
Note that in practice, this technique is not widely used.
Though older debuggers (including OllyDbg) are not TLS-aware, counter-measures are quite easy to take, by the means of plugins of custom patcher tools.

(2) CC scanning

A common protection feature used by packers is the CC-scanning loop, aimed at detecting software breakpoints set by a debugger. If you want to avoid that kind of troubles, you may want to use either hardware breakpoints or a custom type of software breakpoint. CLI (0xFA) is a good candidate to replace the classic INT3 opcode. This instruction does have the requirements for the job: it raises a privileged instruction exception if executed by a ring3 program, and occupies only 1 byte of space.

(3) EntryPoint RVA set to 0

Some packed files have their entry point RVA set to 0, which means they will start executing 'MZ...' which corresponds to 'dec ebx / pop edx ...'.

This is not an anti-debug trick in itself, but can be annoying if you want to break on the entry-point by using a software breakpoint.

If you create a suspended process, then set an INT3 at RVA 0, you will erase part of the magic MZ value ('M'). The magic was checked when the process was created, but it will get checked again by ntdll when the process is resumed (in the hope of reaching the entry-point). In that case, an INVALID_IMAGE_FORMAT exception will be raised.

If you create your own tracing or debugging tool, you will want to use hardware breakpoint to avoid this problem.

[3] Conclusion

Knowing anti-debugging and anti-tracing techniques (un)commonly used by malware or protectors is useful knowledge for a reverse-engineer. A program will always have ways to find it is run in a debugger - the same applies for virtual or emulated environments, but since ring3 debuggers are some of the most common analysis tools used, knowing common tricks, and how to bypass them, will always prove useful.

[4] Links

MSDN
Portable Executable Tutorial, Matt Pietrek
Syscall Reference, The Metasploit Project
Undocumented Functions for MS Windows NT/2K
Intel Manuals
- Common exception codes - Microsoft Windows SDK, ntdll.h
- Status codes list (including common exception codes) - Microsoft Windows DDK, ntstatus.h
- Context Structures documentation - Microsoft Windows SDK, ntdll.h

[5] Data reference

- CONTEXT structure for IA32 processors
struct CONTEXT_IA32
{
// ContextFlags must be set to the appropriate CONTEXT_* flag
// before calling (Set|Get)ThreadContext
DWORD ContextFlags;

// CONTEXT_DEBUG_REGISTERS (not included in CONTEXT_FULL)
DWORD Dr0; // 04h
DWORD Dr1; // 08h
DWORD Dr2; // 0Ch
DWORD Dr3; // 10h
DWORD Dr6; // 14h
DWORD Dr7; // 18h

// CONTEXT_FLOATING_POINT
FLOATING_SAVE_AREA FloatSave;

// CONTEXT_SEGMENTS
DWORD SegGs; // 88h
DWORD SegFs; // 90h
DWORD SegEs; // 94h
DWORD SegDs; // 98h

// CONTEXT_INTEGER
DWORD Edi; // 9Ch
DWORD Esi; // A0h
DWORD Ebx; // A4h
DWORD Edx; // A8h
DWORD Ecx; // ACh
DWORD Eax; // B0h

// CONTEXT_CONTROL
DWORD Ebp; // B4h
DWORD Eip; // B8h
DWORD SegCs; // BCh (must be sanitized)
DWORD EFlags; // C0h
DWORD Esp; // C4h
DWORD SegSs; // C8h

// CONTEXT_EXTENDED_REGISTERS (processor-specific)
BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
};

- Process Environment Block structure (from The Wine Project)
struct PEB
{
BOOLEAN InheritedAddressSpace; // 00
BOOLEAN ReadImageFileExecOptions; // 01
BOOLEAN BeingDebugged; // 02
BOOLEAN SpareBool; // 03
HANDLE Mutant; // 04
HMODULE ImageBaseAddress; // 08
PPEB_LDR_DATA LdrData; // 0c
RTL_UPROCESS_PARAMETERS *ProcessParameters; // 10
PVOID SubSystemData; // 14
HANDLE ProcessHeap; // 18
PRTL_CRITICAL_SECTION FastPebLock; // 1c
PVOID /*PPEBLOCKROUTI*/ FastPebLockRoutine; // 20
PVOID /*PPEBLOCKROUTI*/ FastPebUnlockRoutine; // 24
ULONG EnvironmentUpdateCount; // 28
PVOID KernelCallbackTable; // 2c
PVOID EventLogSection; // 30
PVOID EventLog; // 34
PVOID /*PPEB_FREE_BLO*/ FreeList; // 38
ULONG TlsExpansionCounter; // 3c
PRTL_BITMAP TlsBitmap; // 40
ULONG TlsBitmapBits[2]; // 44
PVOID ReadOnlySharedMemoryBase; // 4c
PVOID ReadOnlySharedMemoryHeap; // 50
PVOID *ReadOnlyStaticServerData; // 54
PVOID AnsiCodePageData; // 58
PVOID OemCodePageData; // 5c
PVOID UnicodeCaseTableData; // 60
ULONG NumberOfProcessors; // 64
ULONG NtGlobalFlag; // 68
BYTE Spare2[4]; // 6c
LARGE_INTEGER CriticalSectionTimeout; // 70
ULONG HeapSegmentReserve; // 78
ULONG HeapSegmentCommit; // 7c
ULONG HeapDeCommitTotalFreeTh; // 80
ULONG HeapDeCommitFreeBlockTh; // 84
ULONG NumberOfHeaps; // 88
ULONG MaximumNumberOfHeaps; // 8c
PVOID *ProcessHeaps; // 90
PVOID GdiSharedHandleTable; // 94
PVOID ProcessStarterHelper; // 98
PVOID GdiDCAttributeList; // 9c
PVOID LoaderLock; // a0
ULONG OSMajorVersion; // a4
ULONG OSMinorVersion; // a8
ULONG OSBuildNumber; // ac
ULONG OSPlatformId; // b0
ULONG ImageSubSystem; // b4
ULONG ImageSubSystemMajorVersion; // b8
ULONG ImageSubSystemMinorVersion; // bc
ULONG ImageProcessAffinityMask; // c0
ULONG GdiHandleBuffer[34]; // c4
ULONG PostProcessInitRoutine; // 14c
PRTL_BITMAP TlsExpansionBitmap; // 150
ULONG TlsExpansionBitmapBits[32]; // 154
ULONG SessionId; // 1d4
};

- Thread Environment Block structure (from The Wine Project)
struct TEB
{
NT_TIB Tib; // 000 Info block
PVOID EnvironmentPointer; // 01c
CLIENT_ID ClientId; // 020 PID,TID
PVOID ActiveRpcHandle; // 028
PVOID ThreadLocalStoragePointer; // 02c
PEB *Peb; // 030
DWORD LastErrorValue; // 034
ULONG CountOfOwnedCriticalSections; // 038
PVOID CsrClientThread; // 03c
PVOID Win32ThreadInfo; // 040
ULONG Win32ClientInfo[0x1f]; // 044
PVOID WOW32Reserved; // 0c0
ULONG CurrentLocale; // 0c4
ULONG FpSoftwareStatusRegister; // 0c8
PVOID SystemReserved1[54]; // 0cc
PVOID Spare1; // 1a4
LONG ExceptionCode; // 1a8
BYTE SpareBytes1[40]; // 1ac
PVOID SystemReserved2[10]; // 1d4
DWORD num_async_io; // 1fc
ULONG_PTR dpmi_vif; // 200
DWORD vm86_pending; // 204
DWORD pad6[309]; // 208
ULONG gdiRgn; // 6dc
ULONG gdiPen; // 6e0
ULONG gdiBrush; // 6e4
CLIENT_ID RealClientId; // 6e8
HANDLE GdiCachedProcessHandle; // 6f0
ULONG GdiClientPID; // 6f4
ULONG GdiClientTID; // 6f8
PVOID GdiThreadLocaleInfo; // 6fc
PVOID UserReserved[5]; // 700
PVOID glDispachTable[280]; // 714
ULONG glReserved1[26]; // b74
PVOID glReserved2; // bdc
PVOID glSectionInfo; // be0
PVOID glSection; // be4
PVOID glTable; // be8
PVOID glCurrentRC; // bec
PVOID glContext; // bf0
ULONG LastStatusValue; // bf4
UNICODE_STRING StaticUnicodeString; // bf8
WCHAR StaticUnicodeBuffer[261]; // c00
PVOID DeallocationStack; // e0c
PVOID TlsSlots[64]; // e10
LIST_ENTRY TlsLinks; // f10
PVOID Vdm; // f18
PVOID ReservedForNtRpc; // f1c
PVOID DbgSsReserved[2]; // f20
ULONG HardErrorDisabled; // f28
PVOID Instrumentation[16]; // f2c
PVOID WinSockData; // f6c
ULONG GdiBatchCount; // f70
ULONG Spare2; // f74
ULONG Spare3; // f78
ULONG Spare4; // f7c
PVOID ReservedForOle; // f80
ULONG WaitingOnLoaderLock; // f84
PVOID Reserved5[3]; // f88
PVOID *TlsExpansionSlots; // f94
};

- NtGlobalFlags
FLG_STOP_ON_EXCEPTION 0x00000001
FLG_SHOW_LDR_SNAPS 0x00000002
FLG_DEBUG_INITIAL_COMMAND 0x00000004
FLG_STOP_ON_HUNG_GUI 0x00000008
FLG_HEAP_ENABLE_TAIL_CHECK 0x00000010
FLG_HEAP_ENABLE_FREE_CHECK 0x00000020
FLG_HEAP_VALIDATE_PARAMETERS 0x00000040
FLG_HEAP_VALIDATE_ALL 0x00000080
FLG_POOL_ENABLE_TAIL_CHECK 0x00000100
FLG_POOL_ENABLE_FREE_CHECK 0x00000200
FLG_POOL_ENABLE_TAGGING 0x00000400
FLG_HEAP_ENABLE_TAGGING 0x00000800
FLG_USER_STACK_TRACE_DB 0x00001000
FLG_KERNEL_STACK_TRACE_DB 0x00002000
FLG_MAINTAIN_OBJECT_TYPELIST 0x00004000
FLG_HEAP_ENABLE_TAG_BY_DLL 0x00008000
FLG_IGNORE_DEBUG_PRIV 0x00010000
FLG_ENABLE_CSRDEBUG 0x00020000
FLG_ENABLE_KDEBUG_SYMBOL_LOAD 0x00040000
FLG_DISABLE_PAGE_KERNEL_STACKS 0x00080000
FLG_HEAP_ENABLE_CALL_TRACING 0x00100000
FLG_HEAP_DISABLE_COALESCING 0x00200000
FLG_VALID_BITS 0x003FFFFF
FLG_ENABLE_CLOSE_EXCEPTION 0x00400000
FLG_ENABLE_EXCEPTION_LOGGING 0x00800000
FLG_ENABLE_HANDLE_TYPE_TAGGING 0x01000000
FLG_HEAP_PAGE_ALLOCS 0x02000000
FLG_DEBUG_WINLOGON 0x04000000
FLG_ENABLE_DBGPRINT_BUFFERING 0x08000000
FLG_EARLY_CRITICAL_SECTION_EVT 0x10000000
FLG_DISABLE_DLL_VERIFICATION 0x80000000