본문 바로가기

High Level Technique/Reversing

Advanced Anti Debugging

Advanced Anti Debugging


PE Protector에서 주로 사용되는 기법의 공통된 특징은 리버싱을 하는 사람을 힘들게 합니다.

가비지 코드, 조건 분기문, 루프문, 암호화/복호화 코드 그리고 Call_Tree에 빠져서 정작 분석하고 싶은 코드에 접근 조차 못하게 합니다.




Garbage Code


말 그대로 쓰레기 코드 입니다. 아무 의미없는 어셈블리어들을 이용해서 분석을 어렵게 합니다. 아니면 단순히 JMP 0x00000000과 같은 명령을 통해서 간단히 구현이 가능한 것을

0x00000000을 여러 연산을 통해서 만들어 내기도 합니다.





Breaking Code Alignment


디스 어셈블리 코드를 깨트리는 것을 말합니다. 예를 들어 JMP 0x12345678 명령어가 있는데 해당 주소가 정확히 나타나지 않는 경우를 말합니다.

실제 디버깅 시에 Step Into를 하게되면 정상적으로 코드가 나타납니다. IDA와 같은 툴을 이용할 때 쉽게 분석하지 못하도록 하는 것입니다.






Encryption / Decryption


암호화 복호화 기법은 프로그램의 코드와 데이터를 숨기기 위해 패커 / 프로텍터에서 자주 사용되는 기법입니다.


코드 재조합


분석 도중에 코드의 위치를 변경하여 실제 동작시 복구해 진행되는 경우를 말합니다. 이때 복구 과정에 BreakPoint를 걸게되면 0xCC의 값이 들어가게 되면서 전혀 다른 명령어를 실행하게 됩니다.






Stolen Bytes(Remove OEP)


Stolen Bytes 기법은 원본 코드의 일부를 Packer / Protector가 생성한 메모리 영역으로 옮겨 실행시키는 기법입니다.


메모리를 덤프시켰을 때 OEP 코드의 일부분이 제거되었기 때문에 덤프된 파일은 정상적으로 실행되지 않습니다. 이러한 것을 Anti Dump 기법이라고 합니다.


Stolen Bytes 기법이 적용된 프록램에 다시 Packer / Protector 로 압축했을 때 리버서에게 혼란을 줄 수 있습니다.



실습예제의 Stolen_bytes_pespin.exe와 Stolen_bytes.exe 를 비교해 보도록 하겠습니다.



위 코드가 정상적인 OEP가 나타난 경우 입니다.



위 코드는 정상적으로 OEP가 나타나지 않는 경우 입니다.










API Redirection


디버깅을 할 때 빨리 분석을 하는 방법은 해당 API에 BreakPoint를 걸고 분석을 하는 것입니다.

BreakPoint가 걸린 API를 호출하면 실행이 멈추고 스택에는 리턴 주소가 저장됩니다.



ap_redirection_org.exe 의 코드를 보면 아래와 같습니다.



GetCommandLineA의 주소를 확인해보면 406000으로  IAT 영역입니다. 



해당 주소를 따라 들어가보면 74B375334의 주소가 들어있습니다. .data section에 저장된 값을 리턴하는 것입니다.



api_redirection1.exe를 보도록 하겠습니다. 



위 주소에서 뻑나서 더이상 진행이 되지 않았습니다.


Windows10, 7, xp 에서 모두 진행해 보았지만 모두 같은 상황이였습니다.


API Redirection의 개념만 정리해 두고 다음에 다시 분석해 보는걸로.


API Redirection이 적용되면 실제 동작하던 코드와는 다르게 주소가 바뀌게 되지만 패커 / 프로텍터의 압축 해제를 진행하고 나면 결국에 같은 API로 이동합니다.

단지 주소가 달라집니다.











Debug Blocker(Self Debugging)


자기 자신을 디버깅 모드로 실행시키는 안티 디버깅 기법입니다. 


실습예제의 PESpin.exe를 실행시켜서 확인해보겠습니다.



처음에 PESpin.exe를 실행시켜서 확인해 봤는데 Tree 형태로 나타나지 않아서 자식 프로세스를 생성하지 않는것인가 확인해봤는데 상단에 PESpin.exe가 하나 더 있었고, 아래처럼 PESpin.exe를 자식 프로세스로 실행시키는 것을 볼 수 있었습니다.



Debug Blocker 기법이 장점은 첫째로 실제 원본 코드를 실행하는 자식 프로세스는 이미 디버깅 중이므로 원칙적으로 다른 디버거를 이용해서 Attach할 수 없습니다.

둘째로 자식 프로세스를 제어할 수 있다는 것입니다.


디버기 프로세스의 예외를 처리하고 실행 흐름을 제어하는 등의 작업을 수행할 수 있습니다.



일반적인 안티 디버깅이 적용된 곳은 예외가 발생하면 SEH로 이동합니다. 하지만 자식 프로세스를 만드는 프로세스는 자식 프로세스에서 예외가 발생하면 부모 프로세스의 SEH로 이동합니다.


부모 프로세스를 디버깅하다가 자식 프로세스에서 예외가 발생할 경우 자식 프로세스를 디버깅 해야하는데 이 경우에 부모 프로세스를 끊고 자식 프로세스에 연결해야 합니다.

하지만 디버깅 중에 끊어버리면 더이상 디버깅이 진행이 안됩니다.

















Nanomite


Debug Blocker의 발전된 형태입니다.


프로세스의 내부 코드를 분석해서 Conditional Jump (JCC)를 INT3(0xCC), 기타 예외 발생 코드로 패치합니다. 그리고 패치시킨 JCC 명령어의 실제 주소와 점프할 주소를 디버거 내부에 테이블 형태로 저장합니다. 디버거는 예외가 발생한 주소를 이용해 테이블에서 점프해야할 주소를 얻어서 프로세스에게 알려줍니다.


'High Level Technique > Reversing' 카테고리의 다른 글

Self Creation Debugging  (0) 2016.08.09
Service Debugging  (0) 2016.08.09
Anti Debugging - Dynamic  (1) 2016.08.08
Anti Debugging - Static  (0) 2016.08.07
Anti Debugging  (0) 2016.08.05