m2nong

Error: "the directory service was unable to allocate a relative identifier."

DC 서버에서 새로운 개체를 생성하려고 할 때 위와 같은 오류가 발생했다.

이 오류는 해당 DC 서버에 대한 RID Master가 제대로 할당되지 않아서 발생하는 오류이다.

RID Master는 기본적으로 할당되어 있지만, DC 서버를 구축할 때 복제하거나, 백업하는 행위를 했을 경우 위와 같은 오류가 발생한다.

이번 글에서는 "the directory service was unable to allocate a relative identifier." 오류를 해결하기 위해 아래와 같이 진행할 예정이다.

DC03을 새로 구축하여 기본 DC였던 DC01의 FSMO 역할을 DC03에게 이전하고 기본 DC로 구축할 예정이다.

사전 준비

Windows Server 2019를 설치하고 진행한다.

ADDS, DNS Server 설치

1. 새로 생성한 Windows Server 2019에 고정 ip 할당

2. DNS Server 설치 진행

기능에서 SMB1 기능도 꼭 꼭 꼭! 추가하는 것을 잊지말자. 꼭!!!!

DNS Server 설치 완료! 다음 단계로 넘어가자!

이름 변경 및 Domain Join

1. 새로 생성한 Windows Server의 이름을 변경하고 기존에 존재하는 Domain에 Join 한다.

Server의 이름 변경과 Domain Join도 완료!

Domain Controller Server로 승격

1. 자 이제 FSMO 역할을 이전받기 위해서 DC Server로 승격해주자.

자격증명을 입력해야 하는 창이 팝업되면 DC01(기본 DC)의 자격증명을 입력한다.

DC01 복제

DC 승격도 완료! 이제 진짜 다왔다! 

FSMO 역할 이전

진짜 진짜 이것만 하면 끝이다! 

DC03이 성공적으로 DC로 승격됐으면, 기본 DC의 FSMO 역할을 DC01에서 DC03으로 이전하여 DC03을 기본 DC로 만드는 마지막 작업을 진행한다.

이는 DC01 환경에서 진행한다. 

다음 명령어로 통해 FSMO 역할 확인

netdom query fsmo

다음 명령어를 통해 Schmmgnt.dll 등록 (관리자 권한 cmd에서 진행)

다음 명령어를 통해 mmc 실행 (password도 입력하자!)

runas /netonly /user:#{DomainName}\#{Username} mmc

실행된 mmc 창에서 File > Add/Remove Snap-in 클릭

Add Snap-in 창에서 다음과 같이 추가
추가 목록

• Active Directory Domains and Trusts
• Active Directory Schema
• Acitve Directory Sites and Services
• Acitve Directory Users and Computers

FSMO 역할 변경

Acitve Directory Users and Computers에 오른쪽 마우스를 클릭하여 Change Domain
Controller를 클릭

DC03 선택

변경된 모습이다.

RID Master, PDC, Infrastructure 역할 이전

Active Directory Sites and Services > Change Domain Controller 클릭하여 DC03으로 변경

변경 성공!

Schema Master 역할 이전

Domain naming Master 역할 이전

Actice Directory Domains and Trusts > Change Domain Controller 클릭하여 DC03으로 변경

모두 변경됐으니 적용시켜주는 작업을 진행하자.

Domain naming Master 역할 이전 적용

 Change 클릭

적용 완료!

이런 식으로 나머지들도 전부 적용해주자.

Schema Master 역할 이전 적용

RID Master, PDC, Infrastructure 역할 이전 적용

RID Master

PDC

Infrastructure

 모두 적용 완료했다.

Powershell에서 성공적으로 변경된 모습을 확인할 수 있다.

기본 Domain Controller Server 변경 확인

자 다시 DC03 환경으로 와서 기본 DC로 변경됐는지 확인해보자.

다음 Command로 기본 DC인지 확인할 수 있다.

if((Get-WmiObject -Class Win32_ComputerSystem).DomainRole -eq 5) { echo 0 } else { echo 1 }

– Standalone Workstation (0)
– Member Workstation (1)
– Standalone Server (2)
– Member Server (3)
– Backup Domain Controller (4)
– Primary Domain Controller (5)

개체 생성하는 Command를 입력하면 이제 성공적으로 만들 수 있다!!

DC를 복제하여 AD를 구성했을 경우 위와 같은 오류가 날 수 있다.

DC를 백업해두거나 복제했을 때 오류가 나면 당황하지 말고, 새로운 DC를 추가하여 FSMO 역할을 이전해주자!

디지털 포렌식을 공부하면서 디지털 증거에 대해 많이 들어봤을 거다.

디지털 증거를 수집해야 포렌식을 진행할 수 있기에 디지털포렌식과 디지털 증거는 절대 떨어뜨릴 수 없는 관계라고 생각들고, 앞으로도 더 더 계속 마주칠 것이다.

디지털포렌식을 공부하면서 어려움을 겪지 않기 위해 디지털 증거가 무엇인지 공부해보자!!

디지털 증거란?

디지털 증거란 디지털 형태로 저장되거나 전송되는 증거가치가 있는 정보를 말한다.

처음에 들으면 잘 와닿지 않을 수 있다. 예를 한 번 들어보면,

좀 허접한 가정이지만..

여기서 디지털 증거는 선생님의 컴퓨터 로그인 시각, 시험지 열어본 흔적, 이메일 전송 흔적, A 컴퓨터 속 시험지 파일 ... 등

이 된다.

하지만 모두 다 같은 디지털 증거가 아니고 디지털 증거에서도 두 가지의 종류로 나뉜다.

컴퓨터가 자동으로 생성한 증거와 컴퓨터 사용자로 인해 생성된 증거로 나뉜다.

컴퓨터가 생성한 증거

컴퓨터가 생성한 증거는 컴퓨터가 운영체제를 포함한 시스템의 모든 것을 유지하고 관리하기 위한 데이터이다.

대표적으로 시스템 로그가 있는데, 이 또한 잘 와닿지 않을 수 있기 때문에 위에서 들었던 예로 설명하자면

A가 선생님 컴퓨터에서 본인의 이메일로 시험지 파일을 첨부해서 보내기 위해 인터넷에 접속했을 것이다.

그럼 여기서 발생하는 웹 로그들이 컴퓨터가 생성한 증거가 된다.

사용자로 인해 생성된 증거

컴퓨터 사용자로 인해 생성된 증거는 사용자가 인식하는 상태에서 생성하고 저장한 데이터를 말한다.

그렇다면 잠시 헷갈릴 수 있다.

"아니, 그럼 A가 직접 본인의 이메일로 보내려고 인터넷에 접속한 거니까 컴퓨터가 생성한 증거가 아니라 사용자로 인해 생성된 증거가 아닌가?"

응 아니다!!

사용자로 인해 생성된 증거는 사용자가 인식하는 상태에서 생성된 것을 말하는 거다. 

A가 의도적으로 부정행위를 알리기 위해 웹 로그를 생성한 게 아니기 때문에 웹 로그는 컴퓨터가 생성한 증거가 되는 거고,

A가 첨부된 시험지 파일을 본인의 컴퓨터에 저장했을 때 생성된 시험지 파일이 사용자로 인해 생성된 증거가 된다. 

(이는 A가 본인의 컴퓨터에 저장하길 원하고 직접 수행했기 때문)

하지만 디지털 증거가 확보가 됐다고 끝난 게 아니라 신뢰할 만하다는 사실까지 입증을 해야한다.

디지털 증거에는 여러 특성들이 존재하기 때문에 특성을 고려하여 수집해야 한다.

디지털 증거의 특성은 다음에 작성하도록 하겠다!

rev-basic-3

문제

문제는 다음과 같다.

해당 파일을 실행했을 때, Input에 틀린 답을 입력했는지 Wrong이 출력된다.

Correct를 출력하기 위해 올바른 답을 찾아보자.

풀이

값을 입력받는 곳까지 실행해준다. 그럼 Call chall3.7FF6992C1120에서 멈추게 되는데 호출되는 이 함수 안으로 들어가보자.

들어가보면 Correct와 Wrong을 볼 수가 있다.

Correct 직전에 호출되는 함수에서 입력받은 값과 메모리 값을 비교할 것이기 때문에 Call chall3.7FF6992C1000으로 들어가보자.

들어가서 어셈블리어를 확인해보면 반복문을 통해 입력받은 값과 메모리 값을 비교한다는 것을 알 수 있다.

어떤 반복문인지 확인해보기 위해 편리하게... IDA를 이용했다.

A와 B가 같지 않아야 return 0을 실행하고 이를 총 24번 반복하는 반복문이었다.

다시 x64dbg로 돌아가서 어셈블리어를 확인해봤더니

lea rcx, qword prt ds:[7FF6992C3000]을 보면

7FF6992C3000 주소에 rcx 값이 저장되어 있다는 것을 알 수 있다.

rcx에 값이 저장되어 있다는 것을 알게 됐으니 해당 주소로 따라갔다.

해당 주소로 가보면 24개의 문자들이 있는 것을 확인해볼 수 있고, 여기 이 문자들로 우리가 입력한 값을 비교한다는 것을 알았다. 하지만 우리가 입력한 값을 그대로 비교하는 것이 아니라 xor 연산을 통해 바꾸어 rcx 값과 비교한다.

그렇기 때문에 이 값들을 역연산해야 한다. 

24개의 문자들은 우리가 알기 때문에 코드 짜는 데엔 문제가 없을 것이다.

답: I_am_X0_xo_Xor_eXcit1ng

rev-basic-2

문제

문제는 다음과 같다.

해당 파일을 실행해봤을 때 chall0.exe, chall1.exe랑 동일하게 Input에 틀린 답을 입력하면 Wrong이 출력된다.

Correct가 출력되도록 올바른 값을 찾기 위해 분석해본다.

풀이

chall2.exe 파일을 x64dbg로 열어보자.

Input에 값을 입력받는 곳으로 가기 위해 계속해서 실행해본다.

Input을 받는 곳의 함수로 들어간 모습은 아래와 같다.

Correct가 출력되기 전에 값을 비교하므로 Correct를 출력하기 직전에 호출되는 함수로 가보겠다.(Call chall2.7FF613071210)

들어가보면 아래와 같은 모습을 볼 수 있는데,

하나하나 잘 봐보자.

1. rsp + 8 주소의 값에서 8바이트 주소의 값을 rcx로 바꿔라

2. rsp의 값을 18만큼 감소시킨 다음에 rsp에 저장하라 (스택에 공간을 할당함)

3. rsp 주소의 값에서 4바이트 주소의 값을 0으로 바꿔라

4. chall2.7FF61307101A로 점프해라

5. movsxd를 통해 rsp 주소의 값에서 4바이트 주소의 값을 rax에 저장하라

6. rax의 값을 12랑 비교해라 (현재 rax의 값은 0)

7. 비교한 그 값이 12보다 크거나 같으면 chall2.7FF613071048로 점프해라 (크거나 같지 않을 경우 즉, 작을 경우에는 점프하지 않고 다음 코드 진행)

8. rsp 주소의 값에서 4바이트의 주소의 값을 rax에 저장하라

9. 7FF613073000 값에서 8바이트 주소의 값을 rcx에 저장하라

그럼 rcx에 7FF613073000값이 저장되어 있는 것을 확인할 수 있고,

메모리를 확인하기 위해서 7FF613073000 주소로 가보자.

가보면 아스키 코드에 Flag 값이 있는 것을 확인해볼 수 있다.

답: Comp4re_the_arr4y

rev-basic-1

문제

문제는 다음과 같다.

해당 파일을 실행해봤을 때 chall0.exe와 동일하게 Input에 올바르지 않은 값을 입력하면 Wrong이 출력된다.

Correct가 출력되도록 올바른 값을 찾기 위해 분석해보자!

풀이

chall1.exe 파일을 x64dbg로 열어보자.

Input을 입력받는 곳으로 가기 위해 계속 실행해본다.

함수를 호출하는 부분에서 멈췄는데 이 함수를 호출해서 값을 입력받고 입력받은 값을 비교하는 것 같으니

correct 바로 직전 Call 함수 안으로 들어가보겠다.

들어가보면 값을 하나씩 비교하는 부분이 나온다. 한 문자씩 특정 문자와 비교해서 올바르면 Correct로, 틀리면 Wrong으로 간다.

그래서 특정 문자들을 총 종합해보면 Compar3_the_ch4ract3r이 나오는 것을 확인할 수 있다.

답: Compar3_the_ch4ract3r

rev-basic-0

문제

문제는 다음과 같다.

문제를 실행해봤을 때 Input에 값을 입력하니 올바르지 않았는지 Wrong이 출력된다.

올바른 값을 입력했을 때 Correct가 나오기 때문에 우린 그 값을 분석을 통해 알아볼 것이다!

풀이

chall0.exe 파일을 x64dbg로 열어봤다.

(기존에는 OllyDbg를 이용했지만 OllyDbg는 32비트만 지원하고 해당 파일은 64비트이기 때문에 x64dbg를 사용했다.)

데이터를 입력받는 곳까지 계속 실행해봤다.

데이터를 입력받으면 그 값이 올바른 값인지 비교하고 맞으면 correct를 틀리면 wrong을 출력한다는 것을 확인할 수 있다. 그래서 call chall0.7FF783BF1000에 들어가보았다.

들어가보면 call <JMP.&strcmp>를 볼 수가 있는데, 이는 두 값을 비교해서 eax에 틀리면 1을 저장하고 (mov dword ptr ss:[rsp+20], 1), 동일하면 0을 저장해서(mov dword ptr ss:[rsp+20], 0) Correct로 점프한다는 것을 알 수 있다.

그래서 Input에 Compar3_the_str1ng을 입력해봤을 때 값을 계속 비교하는 것을 확인할 수 있었고

마침내 Correct를 출력하는 것도 확인할 수 있다.

답: Compar3_the_str1ng

1. PE파일?

PE파일

- Windows 운영체제에서 사용되는 실행 파일 형식

- 32비트 형태의 실행 파일

PE파일 종류

VA & RVA

VA(Virtual Address)

- 프로세스 가상 메모리의 절대주소

RVA(Real-tive Virtual Address)

- 어느 기준 위치에서부터의 상대주소

VA와 RVA의 관계 

- RVA + ImageBase = VA

PE헤더

- DOS Header

  Header 제일 앞부분에는 IMAGE_DOS_HEADER 구조체 존재

    - e_magic: DOS Signature (4D5A => ASCII 값 "MZ")

    - e_lfanew: NT header의 옵셋을 표시 (파일에 따라 가변적인 값을 가짐)

  모든 PE파일 시작 부분(e_magic)에는 "MZ"(DOS Signature) 존재

  e_lfanew 값이 가리키는 위치에 NT Header 구조체 존재

- DOS Stub

  DOS Header 밑에 존재

  DOS Stub이 없어도 파일 실행에 문제 X (존재 여부는 옵션이며 크기 일정 X)

  코드와 데이터의 혼합으로 이루어짐

- NT Header

  NT Header 구조체 IMAGE_NT_HEADERS

    - Signature 50450000h("PE"00)

    - FileHeader

      파일의 개략적인 속성을 나타냄

      ① Machine

          Machine 넘버는 CPU별 고유한 값

      ② NumberOfSection

          PE파일 섹션의 개수 (0보다 커야함)

      ③ SizeOfOptionalHeader

          IMAGE_OPTIONAL_HEADER32 구조체의 크기를 나타냄

      ④ Characteristics

          파일의 속성의 값을 나타냄

    - OptionalHeader

      ① Magic

          IMAGE_OPTIONAL_HEADER32 -> 10B

          IMAGE_OPTIONAL_HEADER64 -> 20B

      ② AddressOfEntryPoint

          EP의 RVA 값을 가지고 있음 (프로그램에서 최초로 실행되는 코드의 시작 주소)

      ③ ImageBase

          PE 파일이 로딩되는 시작 주소를 나타냄

이외에도 일반 도구로 만들어진 EXE 파일의 ImageBase값은 00400000, DLL 파일의 ImageBase 값은 10000000이다.

PE 로더는 PE 파일을 실행시키기 위해 프로세스를 생성하고 파일을 메모리에 로딩 후 EIP 레지스터 값을 ImageBase + AddressOfEntry Point 값으로 세팅

      ④ SectionAlignment, FileAlignmet

          - FileAlignmet: 파일에서 섹션의 최소 단위

          - SectionAlignment: 메모리에서 섹션의 최소 단위

          파일 메모리의 섹션 크기는 반드시 FileAlignmet/SectionAlignment의 배수가 되어야 함

      ⑤ SizeOfImage

          PE파일이 메모리에 로딩되었을 때 가상 메모리에서 PE Image가 차지하는 크기 (파일의 크기와 메모리에 로딩된 크기는 다름)

      ⑥ SizeOfHeader

          PE 헤더의 전체 크기 

          FileAlignmet의 배수

      ⑦ Subsustem

          Subsustem의 값을 보고 시스템 드라이버 파일인지, 일반 실행 파일인지 구분 가능

      ⑧ NumberOfRvaAndSizes

          DataDirectory 배열의 개수를 나타냄

      ⑨ DataDirectory

          IMAGE_DATA_DIRECTORY 구조체의 배열

          배열의 각 항목마다 정의된 값을 가짐

섹션 헤더

- 각 섹션의 속성 정의

  -> 프로그램의 안정성을 위해 code/data/resource마다 각각의 특성, 접근 권한 등 다르게 설정

함수 호출 규약(Calling Convention)

1. cdecl

- C언어에서 사용되는 방식

- Caller(호출자)에서 스택 정리

- 가변 길이 파마리터 전달 가능

(샘플 파일 첨부하겠습니다.)

위 그림을 보면 2와 1을 역순으로 스택에 입력하고 401000을 CALL한다.

함수를 호출하고 ADD ESP로 스택을 정리하는 것까지 볼 수 있다. 

즉, 함수 파라미터를 직접 정리한다.

2. stdcall

- 함수 내부에서 스택 정리

- cdecl에 비해 코드 크기가 작음

- WInd32 API의 기본방식 -> 호환성 좋음

(마찬가지로 샘플 파일 첨부하겠습니다.)

40100A를 확인해보면 리턴 후 지정된 크기만큼 ESP를 증가시키는 것을 확인할 수 있다.

3. fastcall

- 레지스터를 이용하여 함수에 파라미터 전달

- 빠른 함수 호출 가능