'리버싱'에 해당되는 글 9건

앞서 안티 디버깅에 대한 간단한 예제를 살펴보았다.

2020/08/04 - [SECURITY/REVERSING] - 안티 리버싱 :: 03 - 안티 디버깅 예제

이제는 안티 디버깅에 대한 이론적인 것들을 간단하게 개념적으로 정리해볼 것이다.

대다수 안티 디버깅 기법은 FS:[0x30] 에 접근해 윈도우 API 를 이용하거나, 

디버깅하면 그냥 실행했을 때보다 실행 시간이 길어짐을 이용하여 시간을 검사하는 기법을 자주 사용한다.

------------------- 목차 -------------------

1. Windows API 

1.1 IsDebuggerPresent
1.2 CheckRemoteDebuggerPresent

1.3 NTQueryInformationProcess

1.4 OutputDebugString

1.5 FindWindow

2. structure (구조체) 를 수동으로 검사

2.1 BeingDebugged 플래그

3. 디버거로 실행할 때 프로세스에 미치는 변화를 감지

3.1 INT

3.2 Checksums

3.3 시간 체크

4. TLS Callback

-------------------------------------------- 

1. Windows API 

1.1 IsDebuggerPresent

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-isdebuggerpresent

앞선 예제에서 살펴본, 가장 간단한 디버거 탐지 윈도우 API 함수이다.

이 함수는 PEB 구조에서 IsDebugged 필드를 찾아 디버그가 동작 중인지 판단하여 동작 중이 아니라면 0을, 동작 중이라면 0이 아닌 값을 반환한다.

** PEB 는 FS 레지스터를 통해 접근 가능. TEB 의 0x30 이 PEB 를 가리킴

  --> FS:[0x30] 이라 되어있으면 PEB 를 가리키는 것

** TEB, PEB 란?

실제로 함수 실행에 들어가보면 FS:[30] 으로 PEB 구조체에서 +2 를 하여 BeingDebugged 를 확인하는 것을 볼 수 있다.

1.2 CheckRemoteDebuggerPresent

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-checkremotedebuggerpresent

PEB 구조의 IsDebugged 필드를 확인하며 IsDebuggerPresent 와 거의 동일한 기능을 한다. 

다만 자신이나 로컬 컴퓨터의 프로세스에 대해서만 검사할 수 있다.

파라미터로 프로세스 헨들을 받아 프로세스가 디버거 환경에서 실행 중인지를 판단한다.

Use the IsDebuggerPresent function to detect whether the calling process is running under the debugger.

1.3 NTQueryInformationProcess

https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntqueryinformationprocess

첫 번쨰 파라미터로 프로세스 헨들을, 두 번째 파라미터로 얻고자 하는 프로세스 정보의 타입을 요구한다.

두 번째 파라미터인 ProcessInformationClass 에 ProcessDebugPort(0x7) 을 준다면 해당 프로세스가 디버깅 중인지에 대한 여부를 반환한다.

디버깅 중이라면 0, 아니면 디버거 포트 번호를 반환한다.

(NT ZW ?? -> https://blog.naver.com/stgavriel/80044878343)

1.4 OutputDebugString

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringw

디버거에 출력할 문자열을 전달하는 데 사용되는 함수이므로 디버거의 존재를 탐지하는 데 사용할 수 있다.

이 함수를 실행했는데 오류가 발생하지 않는다면 디버거로 실행중이라는 의미이다.

1.5 FindWindow

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa

특정 프로그램(디버그)가 실행되고 있는지 검색할 수 있다.

첫번째 파라미터로 검색할 프로그램(디버그) 이름을 주고, 만일 해당 프로그램이 실행 중이라면 그 헨들을, 실행하고 있지 않다면 NULL 값을 반환한다.

ex. FindWindow("OllyDbg", NULL)

2. Structure (구조체) 를 수동으로 검사

PEB 구조체에서 디버거가 존재하는지에 대한 정보를 제공한다.

운영 체제는 실행 중인 각 프로세스에 대해 윈도우 PEB 구조체를 관리한다.

환경 변수 값, 로드된 모듈 목록, 메모리 주소, 디버거 상태 등의 프로세스 환경 데이터를 포함한다.

프로세스 실행 중에 FS:[0x30] 으로 PEB 를 접근할 수 있다.

https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb

2.1 BeingDebugged 플래그

이 플래그는 PEB 구조체의 오프셋 2에 있다. (0x2) (향후 윈도우 버전에 따라 변경 가능)

이 플래그 값이 0 이면 디버거가 동작하고 있지 않다는 것이고, 1 이면 디버거가 동작하고 있다는 뜻이다.

그리고 다른 플래그들이 존재하지만, 향후 윈도우 버전에 의해 구조가 달라질 수 있으므로 해당 문서를 참조하길 바란다.

3. 디버거로 실행할 때 프로세스에 미치는 변화를 감지

3.1 INT 3

INT 3 는 소프트웨어 BP 를 설정하는 기본 메커니즘이다.

INT 3 의 OPCODE 는 0xCC 로, 이 OPCODE 를 검색하여 본래의 코드가 INT 3 로 변경되었는지 프로세스를 스캔한다.

0xCC 가 발견되면 디버거가 존재한다는 뜻이다.

혹은 코드에 INT 3 구문이 있을 때, 디버거로 실행하면 오류가 나지 않지만 그냥 실행하면 해당 구문은 오류를 뱉는다. 오류를 뱉는지에 대한 여부로도 디버그의 존재 여부를 파악할 수 있다.

이를 우회하기 위해서는 소프트웨어 BP 대신 하드웨어 BP 를 설정하면 된다.

3.2 Checksums

특정 코드 영역의 CheckSum 값을 구하고, 원본 CheckSum 과 비교하여 BP 설정 혹은 각종 코드 패치 여부를 검사할 수 있다. 

그 중 Hash Checking 기법은 함수 코드들의 Hash 값을 미리 구해 둔 다음, 그 값과 실행 중간에 호가인한 Hash 값이 같은지 확인하여 패치 여부를 탐지하는 것이다.

3.3 시간 체크

디버거로 프로세스를 실행하면 그냥 프로세스를 실행했을 때보다 속도가 현저히 느려진다.

이런 시간 차이를 탐지하는 몇 가지 기술이 존재한다.

3.3.1 타임 스탬프

특정 동작 수행 전후에 타임 스탬프를 기록하고 비교한다.

혹은 예외 발생 전후의 타임 스탬프를 가져와서 비교한다. 디버거가 예외를 처리하는 경우 상당한 지연이 발생하기 때문에 구분할 수 있다. (예외를 무시하거나 지나치게 하는 기능을 제공하는 디버거들도 있지만, 그럼에도 차이가 발생한다.)

3.3.2 rdtsc (OPCODE 0x0F31)

가장 일반적인 시간 검사 방법이다.

가장 최근에 시스템이 리부팅한 이후 흐른 시간 값을 저장한 64비트를 반환한다.

이 명령어를 실행한 후 두 값의 차가 특정한 정도를 넘으면 디버거가 실행 중임으로 판단할 수 있다.

3.3.3 QueryPerformanceCounter & GetTickCount

https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount

rdtsc 와 같이 시간차를 분석할 수 있는 윈도우 API 함수이다.

4. TLS Callback

일반적으로 대다수 디버거는 PE 헤더에서 정의한 프로그램 지입점에서 시작한다.

그런데 TLS(Thread Local Storage) Callback 은 진입점 전에 실행되는 코드로, 디버거 몰래 실행할 수 있다.

즉, TLS Callback 에 악성 코드 기능을 삽입한다면 디버거로는 감지하지 못한다.

일반적인 프로그램은 .tls 섹션을 사용하지 않기 때문에 .tls 섹션이 있는 경우 가장 먼저 안티 디버깅을 의심해야 한다.

출처: https://kali-km.tistory.com/entry/Anti-Debugging?category=490391

관련 내용을 더 알고 싶다면 - https://flack3r.tistory.com/entry/TLS-%EC%BD%9C%EB%B0%B1-%EC%95%88%ED%8B%B0%EB%94%94%EB%B2%84%EA%B9%85

참고 사이트들

https://blog.naver.com/sol9501/70128619541

https://kali-km.tistory.com/entry/Anti-Debugging?category=490391

1. DllMain 주소

2. Import 윈도우를 이용해

Import -> getbyhostname 찾기

3. gethostbyname 함수는 몇 개인가? 18개

Import -> gethostbyname -> x

4. 0x10001757 에 위치한 gethostbyname 호출을 보면 어떤 DNS 요청이 이뤄지나?

g -> 0x10001757

add eax, 0D 통해 포인터 뒤를 알 수 있다.

6. 0x10001656 서브루틴 IDA Pro 지역변수 음(-) var_ 갯수? 

var 23개

7. 0x10001656 서브루틴 양(+) 오프셋 대응, arg_ ?

8. \cmd.exe /c 를 참조하는 코드 영역에서 무슨일?

-> 0x10095B20 주소에 더 가까움

9. 같은 영역 0x100101C8 에서 Dword_1008E5C4는 경로를 지정하는 전역변수로 보이고, 악코는

Dword_1008E5C4를 설정???

- 즉, sub_!0003695 함수의 호출 반환값(eax)를 Dword_1008E5C4에 저장한다.

- sub_10003695 함수는 GetVersionExa 함수를 호출하는 부분 윈도우 시스템 정보 확인

- Dword_1008E5C4 상호 참조 이용

10. 0x1000FF58에서 서브루틴으로 수백 라인은 문자를 비교 memcmp 비교다.

rotbotwork와 문자열 비교가 성공적으로 이뤄지면 어떤 현상??

- 문자열이 robotwork 와 일치하면 push [ebp+8] / 일치하지 않으면 jnz short loc_10010468 실행

11. PSLIST 익스포트?

Export > PSLIST

- sub_!00036C3 함수의 기능은 윈도우 버전을 확인, 이 함수 결과에 따라 분기문이 달라짐

- 각 분기문에서 sub_10006518, sub_1000664C를 각각 호출하는데 두 함수 모두 CreateToolhelp32Snapshot 이용

- 결론 프로세스 리스트 반환

18~19번

https://kw470.tistory.com/25

https://yokang90.tistory.com/26

https://k4keye.tistory.com/28

https://yokang90.tistory.com/21

https://maple19out.tistory.com/20

https://johyungen.tistory.com/436

https://idlecomputer.tistory.com/182

https://docs.microsoft.com/ko-kr/dotnet/api/system.security.securestring?view=net-5.0 

C#은 SecureSting이라는 클래스를 따로 지원해서 메모리 내에 중요정보 문자열이 안남게 관리한다고 하네요

two2sh.tistory.com/24

www.cnblogs.com/chucklu/p/11396092.html

mindlocksite.wordpress.com/2017/02/11/easy-way-to-unpack-confuserex-1-0-max-settings/

www.cnblogs.com/chucklu/p/11396092.html

theori.io/research/korean/game-hacking-1/

http://blog.naver.com/ljsk139/30143768284

__cdecl (default 설정)

• 인자전달방법 : 스택에 저장하여 전달
• 인자전달순서 : 오른쪽에서 왼쪽으로
• 스택의 정리 : Caller에서 정리
• 장점 : 가변인자를 사용할 수 있다.

__stdcall

• 인자전달방법 : 스택에 저장하여 전달
• 인자전달순서 : 오른쪽에서 왼쪽으로
• 스택의 정리 : Callee에서 정리
• 장점 : __cdecl보다 코드의 길이가 짧다. (좀 더 빠르다.)

__fastcall

• 인자전달방법 : 처음 두개는 ECX, EDX를 이용, 나머지는 스택에 저장하여 전달
• 인자전달순서 : 오른쪽에서 왼쪽으로
• 스택의 정리 : Callee에서 정리
• 장점 : 레지스터에 인자를 저장하기 때문에 속도가 더 빠르다.

Calling Convention에서의 중요한 것은 스택의 정리를 Caller에서 하느냐 Callee에서 하느냐이다.

  왼쪽의 그림의 경우는 Caller에 인자를 저장하는 형태이고 오른쪽 그림의 경우는 Callee에 인자를 저장하는 형태이다.

왼쪽의 그림에서 Callee가 스택을 정리한다고 생각을 해보자.

Callee는 인자가 자신의 스택영역에 있는 것이 아니기 때문에 인자의 개수가 몇개인지 체크를 해야하고, 그 이후에 정리를 해야한다. 그렇기에 절차가 복잡해 진다. 

하지만 Caller가 스택을 정리한다면 Callee를 호출하는 순간 인자의 개수를 이미 알고 있기 때문에, 스택을 정리하는 작업이 복잡하지 않다. 

그리고 또한 Caller에서 인자의 개수를 정해서 함수를 호출하는 것이기 때문에 인자의 개수는 변할 수가 있다. 그렇기에 __cdecl에서 가변인자함수를 지원하는 것이다.

반대로 오른쪽의 경우는 Caller보다 Callee가 스택을 정리하는 것이 유리하다. 하지만 이 경우는 가변인자함수를 지원할 수 없다. 

왜냐하면 스택의 정리 코드를 작성하려면 인자의 총 크기를 미리 알아야 하는데 가변인자함수의 경우는 인자의 개수가 가변적이므로 미리 예측할 수 없기 때문이다.

__cdecl과 __stdcall이 속도차이가 나는 이유는 정리 코드에서의 차이 때문이다.

__stdcall의 경우는 Callee가 작업을 마치고 스택을 정리할 때 

ret (인자의 총 크기)

로 정리를 한다.

__cdecl의 경우에는 Callee가 ret을 하고 나면 Caller가

add esp, (인자의 총 크기)

로 정리를 한다.

[정리]

https://ezbeat.tistory.com/425