MOLOKINI

프로세스들 사이에서 커널 오브젝트를 공유하는 방법은 세가지가 있습니다. 1. 핸들 상속2. 네임드 오브젝트3. 오브젝트 핸들 복사 핸들 값이 프로세스별로 고유하게 설계된 이유는 바로 안정성 때문입니다.만약, 프로세스 핸들 값이 전역적으로 설계되어 있었다면 관련 없는 프로세스의 핸들 값을 가져와 다른 프로세스를 오동작시킬 수 있는 가능성들이 있기 때문입니다.그럼에도 불구하고, 프로세스 사이에서 커널 오브젝트를 공유하려고 하는 이유는 바로 연관성 있는 프로세스들이 동작 할 수 있게 하기 위함입니다.  1. 핸들 상속핸들 상속은 핸들 값을 공유하려고 하는 프로세스들이 부모-자식 관계를 이루어야 가능합니다.커널 오브젝트 핸들이 부모 프로세스에서 사용되고 있고, 이 부모 프로세스가 새로운 자식 프로세스를 생성하게..

핸들(Handle)이란 무엇인가? 우리가 흔히 핸들이라고 생각하면 자동차의 핸들(Steering Wheel)을 떠올리기 마련인데요,자동차 바퀴의 방향을 제어하기 위해 이 핸들을 사용하게 됩니다. 윈도우의 핸들이 바로 이 자동차의 핸들과 개념이 유사합니다. (갖다 붙이기 나름이죠?) 좌회전을 한다고 가정해봅시다.그러면 운전자는 바퀴를 움직이기 위해 직접 손으로 바퀴를 움켜잡고 돌리지 않고 핸들이라는 조향 장치를 이용해 간접적으로 바퀴의 방향을 제어하게 됩니다. 마찬가지로 윈도우의 핸들도 커널 오브젝트(혹은 GDI, 사용자 오브젝트)를 사용하기 위해 필요한 하나의 장치라고 보시면 됩니다. 프로세스가 초기화되면 운영체제는 프로세스가 커널 오브젝트를 사용할 수 있게 하려고 핸들 테이블을 할당하게 됩니다.(GDI..

에러 핸들링은 말 그대로 윈도우 프로그램이 내부 함수들을 진행하면서 발생시킬 수 있는 에러들을 제어하는 것을 말합니다.윈도우 프로그램 뿐만 아니라 기본적으로 모든 애플리케이션에서는 에러를 잘 처리해줘야 예기치 못한 기능 실패시에 프로그램이 Crash 되는 것을 막아줄 수 있습니다. (기능은 처리되지 못할 지라도 프로그램은 계속 동작할 수 있도록) 아래는 윈도우 함수들이 사용하고 있는 리턴형들입니다. 자료형 실패  VOID 실패하지 않음, 리턴형 없음  - 필요 외 프로그래밍시에 VOID형 함수 설계는 피하는것이 좋습니다. BOOL 실패시 0 리턴, 성공시 0이 아닌 값 - 때문에 TRUE(1)를 비교하면 성공했더라도 제대로 된 결과를 얻지 못할 수 있습니다. - 함수 내에서 명시적으로 TRUE를 리턴하는..

문자열 함수는 말 그대로 문자열을 버퍼에 담고 출력하는 함수입니다.주로 문자열 함수들은 문자열 버퍼의 포인터를 리턴하게 되는데요, 이 때문에 버퍼 오버플로우 현상이 일어날 수 있습니다. TCHAR* alphabet = "ABCDEFGH"TCHAR  buf[3];_tcscpy(buf, alphabet); 이와 같은 경우, 담을 수 있는 버퍼(2글자 + NULL)보다 큰 포인터가 들어오게 되고 이 버퍼 이후에 진행될 스택의 내용을 문자열들이 덮어버려 의도하지 않은 결과를 가져올 수 있습니다. 이런 문제를 보완하기 위해 Windows에서는 안전한 문자열 함수들을 제공하고 있습니다. strsafe.h 헤더를 포함시키면 사용할 수 있으며 그 종류들은 아래와 같습니다. 기존 함수안전한 문자열 함수  strcpySt..

범용 레지스터인 EAX, EBX, ECX, EDX, ESI, EDI, EIP, ESP, EBP 에 대해서 알아보겠습니다. 디스어셈블 할 때 기본적으로 알아두어야 할 레지스터들입니다. 커널디버깅 중 Bugcheck Analysis 중 일부입니다. 이런식으로 BSOD 시점에 CPU의 각 레지스터 별로 어떤 내용을 담고있었는지 출력되게 됩니다. 위 그림에는 RAX, RBX....로 위에서 명시한 EAX, EBX...와 다른데 이유는 64bit에서 사용된 레지스터이기 때문입니다. 즉, 32bit : EAX, EBX, ECX...... 64bit : RAX, RBX, RCX...... 32bit 레지스터가 64bit에서 사용가능하도록 확장되어 명칭이 변경되었다 정도로 알아두시면 됩니다. 1. EAX (Extend..

FLT_IO_PARAMETER_BLOCK은 FLT_CALLBACK_DATA 구조체의 Iopb 부분으로 I/O 오퍼레이션의 파라미터들을 담고 있습니다.  https://msdn.microsoft.com/en-us/library/windows/hardware/ff544638(v=vs.85).aspx IrpFlags : 어떤 I/O 오퍼레이션인지 표시하는 플래그 MajorFunction : I/O 오퍼레이션의 Major IRPMinorFunction : I/O 오퍼레이션의 Minor IRPOperationFlags : I/O 오퍼레이션의 동작 내용을 표시하는 플래그로 IO_STACK_LOCATION의 Flags를 복사해 표시  Reserved : 사용안함TargetFileObject : 구조체의 I/O 오퍼레..

필터매니저를 공부하다보니 미니필터와 필터매니저에서 사용하는 FLT_CALLBACK_DATA 구조체를 다루게 되었습니다.  FLT_CALLBACK_DATA 구조체는 I/O 오퍼레이션의 정보들을 담고 있습니다.요렇게 구성되어 있습니다.- https://msdn.microsoft.com/en-us/library/windows/hardware/ff544620(v=vs.85).aspx Flags : 비트마스크로 표현되는 IO 입출력 동작을 담는 공간아래는 미니필터에서만 사용되는 플래그- FLTFL_CALLBACK_DATA_DIRTY : 구조체의 값이 변경된 적이 있으면 세팅 아래는 필터매니저에서만 사용되는 플래그로 필터링 할 I/O 동작의 콜백 구조체를 가리키는 플래그들입니다.- FLTFL_CALLBACK_DAT..

제 컴퓨터에서 잠자고 있는 덤프 파일을 하나 열어보도록 하겠습니다. 덤프 파일을 열어보면 가장 먼저 보이는 화면은 아래와 유사합니다.  - 덤프 파일의 위치, 덤프 종류 (위 예제에서는 커널덤프 입니다.)- 덤프가 발생한 OS- 덤프 발생 시점의 시간 (4월 19일 13시 24분 41초)- 부팅 이후 동작시간 (2시간 32분)- 버그체크 번호 (BugCheck 3B, BSOD의 종류) 위 화면을 보면, !analyze -v 가 하늘색으로 써져있음을 확인할 수 있습니다.BSOD에 대한 자세한 정보를 확인할 수 있는 명령어입니다. 눌러보죠  내용들이 길기 때문에 우선 여기까지만 자르고 요런 내용들이 나오게 됩니다.가장 먼저 나타나는 부분은 버그체크 번호에 대한 설명입니다.- 시스템 서비스 루틴이 실행 중에 ..

윈도우 디버깅을 하는 방법은 크게 두 가지로 라이브 디버깅과 크래시 덤프 디버깅이 있습니다.- 라이브 디버깅 : 코드를 실행시키면서 디버깅을 동시에 진행하는 방법- 크래시 덤프 디버깅 : 윈도우가 스스로 BSOD(Blue Screen of Death)가 발생한 시점에 덤프 파일을 생성(커널모드)하거나 유저모드 오류가 발생했을 때 생성한 덤프 파일을 디버깅 하는 방법 이 포스트에서는 크래시 덤프 디버깅을 위한 크래시 덤프를 수집하는 방법을 설명하도록 하겠습니다.  유저모드 덤프 수집 방법프로세스 익스플로러를 이용해 덤프를 수집하는 방법입니다. - 프로세스 우클릭 -> Create Dump -> Create Mini or Full Dump를 클릭- 프로세스 익스플로러가 존재하는 폴더에 덤프 파일이 생성됩니다..

SingletonClass가 있고 이 Class의 Instance가 생성될 때 Instance가 단 하나만 생성되게 하는 방법입니다. - 일반적으로는 Class의 Instance는 여러 개가 생성될 수 있습니다. - 하지만, 때로는 클래스 내부 값이 여러 컨텍스트에서 값을 잃지 말고 지속적으로 유지해야할 때가 있기 때문에 Singleton은 필요한 기법입니다. - 데이터베이스를 사용하는 등의 동작을 예로 들 수 있습니다. 예를 들어 보도록 하겠습니다. - Code는 Python 2.7 기준입니다.  1 ~ 10 Singleton Class - Singleton Class를 만드는 방법에는 여러가지 방법이 있는데 그 중 Metaclass를 이용하는 방법입니다. - Metaclass는 Instance를 Cl..