:: 'Study' 카테고리의 글 목록 (10 Page)

Search Results for 'Study'

98 POSTS

2007.06.19 DLL 관련 MSDN 문서
2007.06.19 Calling Conventions in Win32 System
2007.06.19 DLL Injection - 참고
2007.06.19 DLL injction
2007.06.18 구글의 웹서버

DLL 관련 MSDN 문서

Posted 2007. 6. 19. 14:46, Filed under: Study/Computer Science

http://msdn2.microsoft.com/en-us/library/ms682592.aspx

Dynamic-Link Library Creation

To create a Dynamic-Link Library (DLL), you must create one or more source code files, and possibly a linker file for exporting the functions. If you plan to allow applications that use your DLL to use load-time dynamic linking, you must also create an import library.

Creating Source Files

The source files for a DLL contain exported functions and data, internal functions and data, and an optional entry-point function for the DLL. You may use any development tools that support the creation of Windows-based DLLs.

If your DLL may be used by a multithreaded application, you should make your DLL "thread-safe". You must synchronize access to all of the DLL's global data to avoid data corruption. You must also ensure that you link only with libraries that are thread-safe as well. For example, Microsoft Visual C++ contains multiple versions of the C Run-time Library, one that is not thread-safe and two that are.

Exporting Functions

How you specify which functions in a DLL should be exported depends on the tools that you are using for development. Some compilers allow you to export a function directly in the source code by using a modifier in the function declaration. Other times, you must specify exports in a file that you pass to the linker.

For example, using Visual C++, there are two possible ways to export DLL functions: with _declspec modifier or with a .def file. If you use the _declspec modifier, it is not necessary to use a .def file. For more information, see Exporting from a DLL.

Creating an Import Library

An import library (.lib) file contains information the linker needs to resolve external references to exported DLL functions, so the system can locate the specified DLL and exported DLL functions at run time.

For example, to call the CreateWindow function, you must link your code with the import library User32.lib. The reason is that CreateWindow resides in a system DLL named User32.dll, and User32.lib is the import library used to resolve the calls to exported functions in User32.lib in your code. The linker creates a table that contains the address of each function call. Calls to functions in a DLL will be fixed up when the DLL is loaded. While the system is initializing the process, it loads User32.dll because the process depends on exported functions in that DLL, and it updates the entries in the function address table. All calls to CreateWindow invoke the function exported from User32.dll.

For information, see Linking Implicitly with a DLL.

Warning Calling the ExitProcess function in a DLL can lead to unexpected application or system errors. Be sure to call ExitProcess from a DLL only if you know which applications or system components will load the DLL and that it is safe to call ExitProcess in this context.

Calling Conventions in Win32 System

Posted 2007. 6. 19. 14:25, Filed under: Study/Computer Science

================================================================================
Title : Calling Conventions in Win32 System

Author : proXima
Contact : proxima ]at[ postech.ac.kr
Date : 2006/10/27
================================================================================

calling convention에 대해 잘 알아두면,
프로그래밍할 때 도움이 될 수 있다.

그래서 간단하게 정리해 보았다.
읽다가 잘 이해가 안 되는 부분이 있으면, 끝까지 다 읽은 다음에 다시 한 번 보면 좋다.
왜냐면 이게 내용 비교가 서로 얽히는 부분이 있기 때문인데,
처음 읽고 개략적으로 어떤 것인지에 대해 알고 나면 한결 이해하기가 쉬울 것이라고 생각한다.
아래에는 __cdecl, __stdcall, __fastcall, __thiscall, naked 의 다섯 가지를 설명해 두었다.

1. __cdecl


 int __cdecl functionA(int a, int b);

와 같은 형식으로 선언한다.
뭐라고 읽어야 할 지는 잘 모르겠지만, C declare 인 것 같다.
VC에서는 함수를 선언할 때, calling convention을 따로 지정해 주지 않으면 기본적으로 __cdecl로 선언된다. 물론 컴파일 설정에서 바꿀 수도 있다. (VS.NET이라면 구성 속성->C/C++->고급 에서 '호출 규칙'을 변경하면 된다.)

만약 main 함수에서 functionA를 호출할 경우, main 함수에서 functionA를 호출하는 부분은 다음과 같다.


 push 2
 push 1
 call functionA
 add esp, 8

그리고 functionA 함수가 끝나는 부분은 다음과 같다.


 :
 retn

functionA 함수를 호출한 주체(여기서는 main)가 스택을 정리해 준다.
(add esp, 8이 스택을 정리한다.)
때문에 함수 호출이 많은 경우 스택을 정리하는 코드가 여러 번 들어가야 하기 때문에 코드의 용량이 커질 수 있다. 하지만 그렇다고 무조건 쓰지 말라는 건 아니다. 이것도 필요할 때가 있다. 아래의 __stdcall에서 설명하도록 하겠다.

2. __stdcall


 int __stdcall functionB(int a, int b);

와 같은 형식으로 선언한다.
standard call 이라는 뜻이며, __cdecl과는 스택을 정리하는 주체가 다르다는 차이점이 있다.

만약 위에서와 같이 main 함수에서 functionB를 호출한다고 하면, main은 __cdecl과 같다. 그러니 이번에는 functionB의 끝나는 부분만 보자.


 :
 retn 8

__stdcall 의 경우에는 functionB가 실행을 완료한 뒤, 자신이 필요로 했던 parameter들의 크기만큼 스택을 정리하며 종료한다. retn 8 에서 숫자 8이 의미하는 것은 8바이트를 정리하고 돌아가겠다는 의미이다.
이런 경우는 코드의 용량은 적게 할 수 있을지 모르지만, 제약이 있다. 함수가 받아들이는 parameter의 크기가 항상 static해야 한다는 점이다.
위의 __cdecl의 설명 중에, __cdecl이 필요할 때가 있다고 했는데, 바로 ... 이라는 parameter를 가지는 함수들을 만들 때이다. 예를 들면 printf가 있는데, printf의 경우는 그 안에 들어오는 format이 어떻게 되느냐에 따라 스택을 얼마나 탐색할 것인가를 런타임에 결정한다. 이렇게 함수에 넘기는 parameter의 크기가 정해지지 않는 경우는 함수의 내부에서 사용하는 스택의 크기가 static하지 않기 때문에 이런 함수들은 __stdcall 로 만들 수 없다.

Windows에서 제공하는 API들은 대부분 __stdcall로 선언되어 있다.
API의 선언부에 WINAPI나 CALLBACK 같은 것들이 실제로는 __stdcall을 define한 것이다.

3. __fastcall


 int __fastcall functionC(int a, int b, int c, int d);

와 같은 형식으로 선언한다.
말 그대로 fast call 이며, __stdcall과 거의 비슷하지만, 함수의 실행이 조금 빠르다.
왜 조금 빠를 수 있냐면, parameter를 레지스터로 넘기기 때문이다. 하지만 모든 parameter를 레지스터로 넘기는 것은 아니다. 첫번째 parameter와 두번째 parameter를 각각 ecx, edx를 통해 넘기게 되고, 세번째 parameter부터는 스택에 쌓도록 되어 있다.

main 함수에서 functionC를 호출한다고 하면, main 함수는 다음과 같이 된다.


 push 4
 push 3
 mov edx, 2
 mov ecx, 1
 call functionC

그리고 functionC의 마지막 부분은 다음과 같이 된다.


 :
 retn 8

이번에는 parameter를 네 개나 넘겼는데도 실제로 functionC가 정리하고 나오는 스택의 크기는 8바이트밖에 되지 않는다. 그 이유는 앞에서도 설명했듯이 parameter 두 개는 레지스터를 통해 전달되어 스택에는 두 개의 parameter밖에 들어가지 않았기 때문이다.

사족(蛇足) : 사실 __fastcall을 사용해 보지 않았기 때문에 어떤 문제가 생길 수 있는지에 대해서는 잘 모르겠지만, 아마 연산에 사용할 수 있는 레지스터가 두 개 줄어들기 때문에, 복잡한 연산을 해야 하는 경우는 오히려 속도의 저하가 있을 가능성도 있지 않을까 하는 생각이 든다.

4. __thiscall
__thiscall은 따로 선언하는 방법이 없다. 단, class의 method의 경우 자동으로 __thiscall로 선언이 된다. __thiscall의 특징은, C++에서 사용하는 this 포인터가 ecx에 들어간다는 것이다. ecx에 있는 주소값을 이용하여 그 클래스의 member variable이나 method 들을 사용할 수 있게 된다.
그 외 parameter를 넘기는 방식이나 스택을 정리하는 주체는 __stdcall과 같다.

5. naked


 int __cdecl functionD(int a, int b, int c, int d);
 :
 :
 int __declspec(naked) __cdecl functionD(int a, int b, int c, int d)
 {
    // contents
 }

와 같은 형태로 선언한다.
위에 선언하는 형태가 조금 이상하다고 느꼈을지도 모르겠다. 그렇다. 실제로 naked는 __cdecl, __stdcall, __fastcall 등과 조금 스타일이 다르다. 실제로 다른 calling convention들과 함께 선언할 수도 있다. 단, 각각의 calling convention에 따라 retn이나 스택 및 레지스터의 상태를 고려하여 내부를 작성해야 한다. 뭐 그래도 다행스럽게 넘어오는 parameter들은 그 변수명을 그대로 사용할 수 있다. 실제로 함수 내부에서 a, b가 필요하다면, 굳이 스택에서 어느 정도 거리에 있는지를 계산할 필요까지는 없다는 것이다. 그냥 a, b라고 쓰면 된다.

그리고 naked는 함수 prototype으로는 선언할 수 없도록 되어 있다. 무슨 말이냐 하면, 함수 prototype을 선언할 때에는 __declspec(naked)를 붙일 수 없다는 것이다. 함수를 작성하는 부분에서만 사용할 수 있다. 만약 prototype에 선언하게 되면 에러를 만나게 될 것이다.

naked는 사전적으로 벌거벗었다는 뜻이다. 그러면 대체 왜 함수가 벌거벗었는가... 다음과 같다.
naked로 함수를 선언하게 되면, 함수를 작성할 때 기본적으로 작성되는 다음의 코드들이 전혀 존재하지 않는다.

함수 시작시


 push ebp
 mov ebp, esp

함수 종료시


 retn

필요하게 되면, 이것들을 직접 inline assembly로 입력해 주어야 한다.
그리고 중요한 점 하나는, 반드시 함수를 종료하는 부분은 선언한 다른 convention에 맞춰주어야 한다는 것이다.
__cdecl로 선언하고서 retn 8 과 같이 스스로 스택을 정리하고 나오면 안 된다.
왜냐하면 naked로 선언하면 이것은 __cdecl에서와 같이, 호출하는 쪽에서 스택을 정리해 주는 형태로 컴파일이 되기 때문에, 만약 함수 내부에서 스택을 정리하고 나오도록 작성했다면, 호출이 종료된 뒤에 스택에서 local variable이나 return address 등이 날아가는 상황을 볼 수 있다.

이런 것들이 프로그래밍을 할 때 무슨 도움이 될 수 있겠냐고 질문할 수도 있겠지만, 뭐 그래도 알아두면 언제 써먹을 기회가 생길 지도 모르지 않을까 하고 생각하고 있다. 가끔 reverse engineering을 할 때, 어셈 코드에서 리턴부분을 보면서 '아 이건 __cdecl로 선언한 거로군' 뭐 이러고 혼자 생각할 때가 있다. 하지만 바람직하진 않은 것 같다.

-----------
웹에서 이것저것 찾아보다가 발견한 글.
내가 지난 번에 올렸던 파스칼 방식, C 방식의 함수 호출 방식 이외에도 여러가지 방식들을 잘 설명해 놓았다.

자료의 출처는 PLUS at POSTECH 인듯. (학부생)
역시 대단한 사람들이 많구나.

나랑 비슷한 나이또래 ( 동갑 아니면 한살 많거나.) 같은데 정말 대단한 듯.
능력의 차이라기보다는 경험과 환경의 차이라고 믿고 싶다.
그런만큼 나도 열심히 하련다.

Response : ,

DLL Injection - 참고

Posted 2007. 6. 19. 14:16, Filed under: Study/Computer Science

================================================================================
Title : DLL Injection

Author : proXima
Contact : proxima ]at[ postech.ac.kr
Date : 2006/11/15 - 2006/11/15
================================================================================

2부에서 DLL Injection에 대해 간단하게 언급했었다. 이번 글에서는 DLL Injection이 무엇인지, 어떤 방법으로 이루어질 수 있는지를 알아보도록 하자.

일단, DLL Injection이 무엇인지부터 간단하게 알아보는 것이 좋을 것 같다.
단어 그대로 해석해 보자면, DLL Injection이라는 것은 'DLL 주입'이라는 뜻을 가지는데, 그냥 이 말만 가지고는 뜻이 명확하지가 않다. DLL을 주입한다고? 그게 무슨 뜻이지?

1. DLL을 주입하다
다들 알고 있겠지만(몰랐다면 앞으로 알면 좋다), 프로세스는 실행파일 하나만 메모리에 달랑 올린다고 실행이 되는 것이 아니라, 실행에 필요한 동적 라이브러리들을 같이 메모리에 올려야만 실행이 가능하다. DLL이라는 것은 Windows에서 제공하는 동적 라이브러리 형태로서, 리눅스에서의 .so 파일과 같은 역할을 한다고 보면 된다.
방금 설명했듯이, 동적 라이브러리도 프로세스의 메모리 공간에 올라가게 되는데, 디버거를 통해 확인해 보면 아마 보통 ntdll.dll, kernel32.dll, user32.dll 등의 dll 파일들이 프로세스의 실행파일 이미지와 같이 메모리에 올라가 있는 것을 확인할 수 있을 것이다.
DLL은 실행파일과 비슷하다. 그 자체로 실행파일이 되지 않는다는 것을 제외한다면, 파일의 내부는 실행파일과 다른 점이 없다. (.exe 파일도 함수를 export할 수 있다.)
그러면 DLL을 다른 프로세스에 주입한다는 게 무슨 뜻인가 하면... 다른 프로세스의 메모리 공간에 내가 만든 DLL을 매핑한다는 뜻이다. 하지만 단순이 메모리에 DLL을 매핑하는 것이 다는 아니다. DLL이 로드될 때 자동으로 실행되는 DllMain 에서 내가 원하는 코드를 '다른 프로세스 내에서' 실행시킬 수도 있다. 바로 이게 핵심이다.
DLL Injection을 통해 내가 원하는 코드를 '다른 프로세스 내에서' 실행시킬 수 있다.

2. 이게 어째서 가능한가
앞에서 이것저것 설명했었지만, 이게 가능한 이유는 Windows가 다음와 같은 환경을 제공해 주기 때문이다.
1) 런타임에 동적으로 DLL 파일을 로드할 수 있다.
2) 다른 프로세스의 메모리 공간에 데이터를 쓸 수 있다.
3) 다른 프로세스에서 함수를 실행시킬 수 있다
4) DLL이 로드될 때 로드된 DLL 파일 내의 DllMain 함수가 실행된다!

3. DLL Injection을 발생시키는 과정
Windows에서는 프로세스가 런타임에 동적으로 DLL 파일을 로드하도록 해 주는 LoadLibrary라는 함수가 있다. 그리고 다른 프로세스에서 그 LoadLibrary를 실행할 수가 있다. 그렇다면 내가 DLL을 만든 뒤에 그 DLL을 다른 프로세스에서 LoadLibrary를 통해 로드하도록 하면, 내가 만든 DLL을 주입할 수 있는 것이다.
그렇다면 어떻게 다른 프로세스에서 함수를 실행시킬 수 있을까? 바로 CreateRemoteThread라는 함수를 이용하는 것이다. CreateRemoteThread는 다른 프로세스 내에 새로운 쓰레드를 생성시키는데, 그 생성된 쓰레드로 하여금 어떤 함수를 실행하게 할 것인지를 인자로 넘길 수 있다.
그렇기 때문에 CreateRemoteThread를 이용하여 LoadLibrary를 실행하게 한다면, 내가 만든 DLL의 DllMain이 실행된다.
하지만 넘어가야 하는 난관이 조금 있는데, 일단 CreateRemoteThread와 LoadLibrary의 프로토타입을 보자.


 HANDLE CreateRemoteThread(  HANDLE hProcess,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  SIZE_T dwStackSize,
  LPTHREAD_START_ROUTINE lpStartAddress,
  LPVOID lpParameter, 
  DWORD dwCreationFlags,  
  LPDWORD lpThreadId
 );
 
 HMODULE LoadLibrary(
   LPCTSTR lpFileName
 );

프로토타입을 보면서 조금 더 설명을 하자면, DLL Injection이 가능한 이유는, LoadLibrary가 인자를 '단 하나'만 받기 때문이다. CreateRemoteThread는 쓰레드를 새로 만들면서 쓰레드로 실행되는 함수에게 인자를 하나 넘길 수 있는데, LoadLibrary는 아주 다행스럽게 인자를 '단 하나'만 받는다.

하지만, LoadLibrary를 실행하기 위해서는 '로드할 DLL 파일명'을 LoadLibrary의 인자로 넘겨주어야 한다. 그렇다면 다른 프로세스의 메모리 공간에 내가 원하는 '로드할 DLL 파일명'을 써 넣어야 하는데, 그것은 이 전에 쓴 글인 'Controlling Memory Space of Other Process'에서 언급했듯이, Windows 에서 제공해 주는 API들을 사용해서 가능하게 할 수 있다.

그렇다고 하더라도 가장 큰 문제가 있는데, 그게 무엇인가 하면 바로 LoadLibrary의 주소는 '타겟 프로세스'의 가상메모리 상에서의 주소여야 한다는 점이다. 알고 있다시피, DLL들은 프로그램이 실행될 때마다 다른 메모리 주소에 매핑될 수 있는데, 그것 때문에 타겟 프로세스의 LoadLibrary가 어떤 주소에 위치하는지를 모른다면 이것은 말짱 꽝이 될 수도 있다.
그래도 이걸 해결하는 방법이 있다. 다른 프로세스의 메모리를 읽어 kernel32.dll 이 그 프로세스의 어느 메모리 주소에 위치하는지 알아내고, 그 kernel32.dll 이 export하는 함수들을 읽으면서 LoadLibrary의 주소가 어디 있는지 알아낼 수 있다. 뭐 그 밖에도 다른 방법도 있을 수 있지만, 지금은 이게 문제가 되지 않는다. 왜냐하면...

서로 다른 프로세스라도 kernel32.dll 은 가상메모리 상에서 거의 항상 같은 메모리 주소에 매핑되기 때문에, 그냥 내 프로세스의 LoadLibrary 주소를 넘기면 된다.

4. 코드를 짜 보자


 HANDLE hProcess;
 hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
 
 LPVOID pFileName;
 pFileName = HeapAlloc(NULL, strlen(fileName)+1, MEM_COMMIT, \
                              PAGE_READWRITE);
 
 WriteProcessMemory(hProcess, pFileName, fileName, strlen(fileName)+1, \
                    &nWritten);
 
 HANDLE hRemoteThread;
 hRemoteThread = CreateRemoteThread(hProcess, NULL, 0, \
                                    (LPTHREAD_START_ROUTINE)LoadLibrary,
                                    pFileName, 0, NULL);
 
 CloseHandle(hRemoteThread);
 CloseHandle(hProcess);

이제 DLL Injection 을 할 수가 있게 됐다. 내가 DLL을 만들어서 다른 프로세스에 넣어보자. 실제로 스피드핵의 경우 timeGetTime 함수를 뺏는 역할을 하는 DLL을 프로세스에 주입함으로써 빠르게 돌아가게 하는 방법도 사용하는 프로그램도 있다.

다른 프로세스의 내부에 내가 원하는 코드를 집어넣는다는 것은 굉장히 강력할 수 있다. 때문에 악용될 경우 큰 피해가 날 수도 있는데, 아무쪼록 좋은 곳에 사용하길 바란다.
4부에서는 Windows Message Hooking을 다루도록 하겠다.

Response : ,

DLL injction

Posted 2007. 6. 19. 12:34, Filed under: Study/Computer Science

VirtualAllocEx

Reserves or commits a region of memory within the virtual address space of a specified process. The function initializes the memory it allocates to zero, unless MEM_RESET is used.

LPVOID WINAPI VirtualAllocEx(
  HANDLE hProcess,
  LPVOID lpAddress,
  SIZE_T dwSize,
  DWORD flAllocationType,
  DWORD flProtect
);

Parameters

hProcess

[in] The handle to a process. The function allocates memory within the virtual address space of this process.

The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.

lpAddress

[in] The pointer that specifies a desired starting address for the region of pages that you want to allocate.

If you are reserving memory, the function rounds this address down to the nearest multiple of the allocation granularity.

If you are committing memory that is already reserved, the function rounds this address down to the nearest page boundary. To determine the size of a page and the allocation granularity on the host computer, use the GetSystemInfo function.

If lpAddress is NULL, the function determines where to allocate the region.

dwSize

[in] The size of the region of memory to allocate, in bytes.

If lpAddress is NULL, the function rounds dwSize up to the next page boundary.

If lpAddress is not NULL, the function allocates all pages that contain one or more bytes in the range from lpAddress to lpAddress+dwSize. This means, for example, that a 2-byte range that straddles a page boundary causes the function to allocate both pages.

flAllocationType

[in] The type of memory allocation. This parameter must contain one of the following values.

Value	Meaning
MEM_COMMIT 0x1000	Allocates physical storage in memory or in the paging file on disk for the specified reserved memory pages. The function initializes the memory to zero. To reserve and commit pages in one step, call VirtualAllocEx with MEM_COMMIT \| MEM_RESERVE. The function fails if you attempt to commit a page that has not been reserved. The resulting error code is ERROR_INVALID_ADDRESS. An attempt to commit a page that is already committed does not cause the function to fail. This means that you can commit pages without first determining the current commitment state of each page.
MEM_RESERVE 0x2000	Reserves a range of the process's virtual address space without allocating any actual physical storage in memory or in the paging file on disk. You commit reserved pages by calling VirtualAllocEx again with MEM_COMMIT. To reserve and commit pages in one step, call VirtualAllocEx with MEM_COMMIT \|MEM_RESERVE. Other memory allocation functions, such as malloc and LocalAlloc, cannot use reserved memory until it has been released.
MEM_RESET 0x80000	Indicates that data in the memory range specified by lpAddress and dwSize is no longer of interest. The pages should not be read from or written to the paging file. However, the memory block will be used again later, so it should not be decommitted. This value cannot be used with any other value. Using this value does not guarantee that the range operated on with MEM_RESET will contain zeroes. If you want the range to contain zeroes, decommit the memory and then recommit it. When you use MEM_RESET, the VirtualAllocEx function ignores the value of fProtect. However, you must still set fProtect to a valid protection value, such as PAGE_NOACCESS. VirtualAllocEx returns an error if you use MEM_RESET and the range of memory is mapped to a file. A shared view is only acceptable if it is mapped to a paging file.

Value

Meaning

MEM_COMMIT
0x1000

Allocates physical storage in memory or in the paging file on disk for the specified reserved memory pages. The function initializes the memory to zero.

To reserve and commit pages in one step, call VirtualAllocEx with MEM_COMMIT | MEM_RESERVE.

The function fails if you attempt to commit a page that has not been reserved. The resulting error code is ERROR_INVALID_ADDRESS.

An attempt to commit a page that is already committed does not cause the function to fail. This means that you can commit pages without first determining the current commitment state of each page.

MEM_RESERVE
0x2000

Reserves a range of the process's virtual address space without allocating any actual physical storage in memory or in the paging file on disk.

You commit reserved pages by calling VirtualAllocEx again with MEM_COMMIT. To reserve and commit pages in one step, call VirtualAllocEx with MEM_COMMIT |MEM_RESERVE.

Other memory allocation functions, such as malloc and LocalAlloc, cannot use reserved memory until it has been released.

MEM_RESET
0x80000

Indicates that data in the memory range specified by lpAddress and dwSize is no longer of interest. The pages should not be read from or written to the paging file. However, the memory block will be used again later, so it should not be decommitted. This value cannot be used with any other value.

Using this value does not guarantee that the range operated on with MEM_RESET will contain zeroes. If you want the range to contain zeroes, decommit the memory and then recommit it.

When you use MEM_RESET, the VirtualAllocEx function ignores the value of fProtect. However, you must still set fProtect to a valid protection value, such as PAGE_NOACCESS.

VirtualAllocEx returns an error if you use MEM_RESET and the range of memory is mapped to a file. A shared view is only acceptable if it is mapped to a paging file.

This parameter can also specify the following values as indicated.

Value	Meaning
MEM_LARGE_PAGES 0x20000000	Allocates memory using large page support. The size and alignment must be a multiple of the large-page minimum. To obtain this value, use the GetLargePageMinimum function. Windows XP/2000/NT: This flag is not supported.
MEM_PHYSICAL 0x400000	Allocates physical memory with read-write access. This value is solely for use with Address Windowing Extensions (AWE) memory. This value must be used with MEM_RESERVE and no other values.
MEM_TOP_DOWN 0x100000	Allocates memory at the highest possible address.

Value

Meaning

MEM_LARGE_PAGES
0x20000000

Allocates memory using large page support.

The size and alignment must be a multiple of the large-page minimum. To obtain this value, use the GetLargePageMinimum function.

Windows XP/2000/NT: This flag is not supported.

MEM_PHYSICAL
0x400000

Allocates physical memory with read-write access. This value is solely for use with Address Windowing Extensions (AWE) memory.

This value must be used with MEM_RESERVE and no other values.

MEM_TOP_DOWN
0x100000

Allocates memory at the highest possible address.

flProtect

[in] The memory protection for the region of pages to be allocated. If the pages are being committed, you can specify any one of the memory protection constants.

Protection attributes specified when protecting a page cannot conflict with those specified when allocating a page.

Return Value

If the function succeeds, the return value is the base address of the allocated region of pages.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

There are two ways to 'Inject' a series of bytes into an already running process. VirtualAllocEx() - which isn't supported in Win9x/ME - will allow a process to reserve or commit a region of memory within the virtual address space of a separate specified process. Use WriteProcessMemory() to write the data in the reserved/committed area of the target process' memory.

The other way is to directly use ReadProcessMemory() and WriteProcessMemory() - which is supported in all versions of Windows - to search for some accessible area of the target process' memory and replace the bytes within the area size equal to the size of the code. Of course, you will be saving a backup of the replaced bytes in order to put them all back later on.

(Of course, you can use CreateRemoteThread() instead of all this, but it's not supported in all versions of Windows.)

One good yet slow method of injecting the code is using Windows' debugging functions. Suspend the threads of the running process (using the debugging functions) and use GetThreadContext() and SetThreadContext() to save a backup of all the registers and then modify the EIP register, which is the register that contains the offset of the current to-be-executed code, to point it to the 'Injected' code. The injected code block will have a breakpoint set at the end of it (Interrupt 3h -int 3h-). Again, use the debugging functions to resume the threads, which will then continue executing till the first breakpoint is reached. Once your application receives the notification, all you have to do is restore the modified bytes and/or un-allocate any allocated space in memory, and finally restore the registers (SetThreadContext()). That's all there is to it. The application has no idea of what has happened! The code was executed, and probably loaded a DLL. As you know, loaded DLLs are in an application's address space, therefore, the DLLs can access all memory and control the whole application. Very interesting.

----

DLL을 다른 프로세스에 주입한다는 것은 다른 프로세스의 메모리 공간에 내가 만든 DLL을 매핑한다는 뜻이다. 하지만 단순이 메모리에 DLL을 매핑하는 것이 다는 아니다. DLL이 로드될 때 자동으로 실행되는 DllMain 에서 내가 원하는 코드를 '다른 프로세스 내에서' 실행시킬 수도 있다.

참고 - http://www.codeproject.com/dll/DLL_Injection_tutorial.asp
http://fatdogs.egloos.com/3149489

Response : ,

구글의 웹서버

Posted 2007. 6. 18. 12:43, Filed under: Study/Computer Science

출처 - http://kr.blog.yahoo.com/jhrogue/1356979

-= IMAGE 1 =-

(사진: 구글 클러스터)

원래 '새소식 정리' 부문은 컴퓨터 업계 동향이나 새로운 소프트웨어 소개를 위한 장으로 마련했는데, 요즘은 거의 매주 구글 관련 소식을 싣지 않으면 입안에 가시라도 돋히는 모양이다.

이번 주는 구글을 움직이는 하드웨어와 소프트웨어 원동력에 대해 한번 살펴보기로 하자.

1. 숫자로 보는 구글
* 이 글을 쓰는 현재 구글 웹 페이지 색인 숫자는 8,058,044,651 개이며, 평균 페이지는 10킬로바이트 정도이며, 메타태그가 아닌 본문 전체를 대상으로 전문 색인을 수행한다.
* 클러스터 하나당 PC 2000대이다.
* 30개가 넘는 클러스터가 존재한다.
* Klingon(http://www.omniglot.com/writing/klingon.htm)과 Tagalog(http://www.omniglot.com/writing/tagalog.htm)을 포함하여 104개 언어를 지원한다.
* 클러스터당 1 페타바이트(http://www.webopedia.com/TERM/P/petabyte.html)를 차지한다.
* 클러스터 내부에서 2Gbps로 자료를 전송한다.
* 클러스터당 매일 컴퓨터 두 대가 고장난다.
* 2000년 2월 이후 한번도 심각한 장애가 생긴적이 없다.
* 단일 클러스터 프로젝트 중 최고 인력 투입: 박사급 연구원 200명, 기타 600명

2. 하드웨어

* 일반 x86 CPU에 표준 IDE를 장착한 일반 PC를 사용한다.
* 평균적으로 하루에 한 대 이상 고장난다.
* 모든 서버는 복사본이 50개 존재한다.
* 서버는 전원선과 네트워크 선만 연결하면 자동으로 프로그램과 데이터를 내려받는다.
* 블레이드 서버가 아닌 일반 서버이므로, 제곱 피트당 전력을 500W 정도 소모한다.

3. 소프트웨어

* GFS(Google File System)을 통해 SCSI도 아니며 RAID도 아닌 표준 IDE 디스크에 색인 자료를 저장
- GFS는 범용 파일 시스템이 아니라 색인 저장을 위한 전용 파일 시스템이다. 블록 크기가 자그마치 64Mbytes이다.
* 디버깅을 위한 별도 환경을 갖추고 있다.
* 철자 교정기: 학습을 통해 끊임없이 정확한 철자를 학습하는 시스템을 갖추고 있다.

클러스터에 존재하는 80대에 이르는 컴퓨터 케이블을 동시에 뽑아버리더라도 잠깐 느려지다가 다시 원래대로 복원하는 클러스터링 기술에는 감탄을 금할 수 없다.

뱀다리) 구글 뉴스 그룹 서비스(http://groups-beta.google.com/)에 또 한차례 기능 추가를 한 모양이다. 아무리 생각해도 정말 대단한 회사가 아닐 수 없다.

http://www.zdnet.com.au/insight/software/0,39023769,39168647,00.htm
http://internet.watch.impress.co.jp/cda/event/2004/11/16/5430.html

EOF

----

조엘 온 소프트웨어를 읽다가 구글 웹서버에 대해서 번역하신 분께서 포스팅해 놓은 블로그주소를 적어주셨길래 들어가봤다.

역시 보통 회사가 아니다-_-;
단순한 검색엔진 개발자라고 하기에는 너무도 엄청나다.
철저하게 자기만의 철학을 가지고 모든 것을 스스로 구현해가고 있다.;

x86 컴퓨터를 사용한 클러스터링과 자체 파일 시스템.. 진짜 대단하다~

Response : ,

« Previous : 1 : ··· : 7 : 8 : 9 : 10 : 11 : 12 : 13 : ··· : 20 : Next »

Search Results for 'Study'

98 POSTS

DLL 관련 MSDN 문서

Creating Source Files

Exporting Functions

Creating an Import Library

See Also

Calling Conventions in Win32 System

DLL Injection - 참고

DLL injction

Parameters

Return Value

Parameters

Return Value

Remarks

구글의 웹서버

Categories

Recent Posts

Recent Comments

Recent Trackbacks

티스토리툴바