Broken Code (window31)

마소 2009년 2월호를 마지막으로 올리디버거 플러그인 연재가 끝이 났습니다.

마지막회는 자작 플러그인이 주제라 두가지 기능을 하는 플러그인을 만들었습니다.
1) 메모리상이랑 파일 상에서 바이너리 컴페어를 하여 후킹 탐지나 변조된 코드 검출
2) xor 에 대한 옵코드를 찾으면서 암호화 루틴을 발견

사용방법은 매우 간단합니다.
DLL: 에 dll 이나 exe의 이름을 넣으면 해당 모듈만 스캔하고,
Scan All Process 를 체크하면 현재 어태치된 프로세스의 전체 모듈을 스캔합니다.

Search Hook 은 변조된 코드 탐지, XOR 은 말그대로 xor 옵코드를 찾습니다.
(xor eax, eax 물론 이런건 찾지 않습니다)

아래는 Search Hook 에 대한 결과 화면입니다.
뭔가 검출된 번지가 겁나 많은데 하나만 적당히 설명을 붙혀보자면,
메모리 0x7C801E1A 번지가 원래 0x8B 인데, 0xC2 로 시작하는 옵코드로 바뀌었다는 얘기입니다.
디스어셈블링 라이브러리를 이용하였으므로 retn 8 이라는 코드로 변조되어 있음을 알 수
있습니다.

[pid: 2320] [0x400000] d:\fantastic tools\dlladmin\dlladmin.exe Complete: 0 byte diff [pid: 2320] [0x7C930000] c:\windows\system32\ntdll.dll Diff - [0x7C93D5EA] Mem: E9 : [0xC9EA] File: FF - jmp 7FF70000 Diff - [0x7C93D7EA] Mem: E9 : [0xCBEA] File: FF - jmp 7FF80000 Diff - [0x7C93D87A] Mem: E9 : [0xCC7A] File: FF - jmp 7FF60000 Diff - [0x7C93D91A] Mem: E9 : [0xCD1A] File: FF - jmp 7FF90000 Diff - [0x7C93DC90] Mem: E9 : [0xD090] File: B8 - jmp 7FF50000 Complete: 25 byte diff [pid: 2320] [0x7C800000] c:\windows\system32\kernel32.dll, (system dll !) Diff - [0x7C801E1A] Mem: C2 : [0x121A] File: 8B - retn 8 Diff - [0x7C83974A] Mem: C2 : [0x38B4A] File: 8B - retn 4 Diff - [0x7C85AA23] Mem: 44 : [0x59E23] File: FF - inc esp Diff - [0x7C85AA24] Mem: 24 : [0x59E24] File: 55 - and al, 8 Diff - [0x7C85AA26] Mem: C7 : [0x59E26] File: EC - mov dword ptr ds:[eax], 0 Diff - [0x7C85AA2C] Mem: C2 : [0x59E2C] File: 74 - retn 8 Diff - [0x7C863EF9] Mem: 90 : [0x632F9] File: 0F - nop Diff - [0x7C863EFA] Mem: E9 : [0x632FA] File: 8C - jmp kernel32.7C863FA1 Diff - [0x7C864EC7] Mem: 33 : [0x642C7] File: 8B - xor eax, eax Diff - [0x7C864EC9] Mem: C2 : [0x642C9] File: 55 - retn 8 Complete: 29 byte diff [pid: 2320] [0x76BA0000] c:\windows\system32\psapi.dll, (system dll !) Complete: 0 byte diff [pid: 2320] [0x73D10000] c:\windows\system32\mfc42.dll Complete: 0 byte diff

그럼 실제로 해당 번지가 정말 변조되어있는지 한번 뛰어가 볼까요.
0x7C801E1A 를 살펴보았습니다.


네. retn 8 이 예쁘게 박혀 있는 것을 볼 수 있고요.
TerminateProcess() 의 엔트리 포인트라는 것도 알 수 있네요.
해당 API 를 무력화 시키기 위해 걍 리턴시켜버리는 코드로 변조했음을 알 수 있습니다.

그외에 수많은 번지가 변조되어 있는데요, 대부분의 짓이 사실 OllyAdvance 가 하는 짓들이랍니다.
궁금하신 분들은 OllyAdvance 를 사용한 상태에서 OllyMemScan 으로 풀 스캔해 보시고,
해당 번지를 직접 뛰어가보세요. OllyAdvance 가 어떤 식으로 코드나 API를 바보 만드는지
쉽게 아실 수 있을겁니다 : )

그리고 아래는 XOR 에 대한 결과 화면입니다.

14:24:02:213 Xor - [0x41FDCD] xor al, 17 14:24:02:213 Xor - [0x41FDF2] xor dword ptr ds:[eax], esi 14:24:02:213 Xor - [0x41FF35] xor bh, bl 14:24:02:213 Xor - [0x41FFAC] xor al, 0D9

뭐 이건 별거 없네요 ㅎ
기존에 암복호화 찾는 올리디버거의 플러그인으로 FindCrypt 라는 넘이 있지만
그넘은 기존에 알려져 있는 암호화 라이브러리의 테이블 값을 찾는 원리로 구현되어 있어서
개발자가 걍 xor 로 쉭쉭~ 만든 암호화 루틴은 찾아내지 못하는 단점을 안고 있었습니다.

그래서 xor 에 대한 옵코드를 찾는 기능을 만들어봤습니다. 원리는 xor에 대한 옵코드를 찾아서
동일 레지스터를 xor 하는 쓸모없는 코드는 빼버리고 나머지 코드에 대해 디스어셈블링한겁니다.
간단하죠 :)

SearchHook 은 악성코드나 백도어, 루트킷 등을 분석할때 나름 도움이 되고
XOR은 암호화 코드를 찾을때 FindCrypt 와 함께 사용하면 시너지 효과가 쵸큼 있습니다 :)

본래 아래와 같이 별도의 툴로 만들어서 사용하고 있었던 건데,
플러그인 연재를 진행하며, 이런 플러그인이 공개된게 없어서 올리디버거 SDK를 이용하여
새로이 맹글어봤습니다 :)
(마감의 압뷁에 급하게 만드느라 버그가 있을지 모르겠습니다 ㅠ ㅠ)





window31 2009년 2월.

시스템 프로그래밍 하시는 분들은 메모리 페이지 속성을 확인하기 위해
VMMap을 사용하실 겁니다 (머 직접 구현해서 쓰시는 분들도 계시겠죠. 만들기가 어렵진 않으니)

그런데 이 엿같은 프로그램이 UI는 제공되긴 하지만 다른 프로세스의 쿼리를 보려면
콘솔로 내려가서 파라메타로 PID를 줘야 하기 때문에 상당히 짜증납니다 -_-

그래서 몇년전부터 전직장 팀장님과 UI에서 한방에 되게 좀 만들라고 서로 미루고 있다가
머 그냥 귀차니즘에 대충 쓰고 있었는데
오늘 VMMap을 쓰는데 ㅅㅂ 갑자기 짜증나서 걍 로더 만들어버렸습니다.

뭐 플그램 자체도 간단하고, 사용법도 간단합니다.
VMMapLoader를 실행하시고 페이지 속성을 보고픈 프로세스를 더블클릭 해 주시면 되겠습니다.
(VMMap.exe는 같은 폴더에 있어야 하며, 그거를 바로 실행하시면 안 됩니다)

그럼 필요하신 분은 콘솔로 내려가는 귀차니즘 없이 잘 사용하시길 lol

WinHexKernel ver 0.11 이 릴리즈 되었습니다.
필요하신 분은 다운받으셔도 됩니다.

EXE는 어쩔수 없이 데미다로 했습니다. 용량 커져서 죄송합니다.
드라이버도 요즘 점점 유명세를 타고 있는 C...V...로 무장하려 했지만
엄청난 속도의 저하로 인하여 드라이버쪽은 암호화를 하지 않았고요

겨우 이따위 툴을 데미다로 프로텍팅 했냐고 혹시나 생각하실지 모르는 분들에 대한 반문으로
사실 제가 습작으로 만든 툴에 암호화를 하는 이유는 머 코드를 보호한다 머 그런 취지가 아니고
걍 제가 코딩한 내용을 누군가 디스어셈블링 해서 볼때 그게 쪽팔려서 일 뿐입니다.
누군가가 뜯어보고 야 이자식 이따위로 짜네 라는 말을 들을까봐요
(저같은 경우는 물론 남의 코드를 뜯어 볼때 절대 그런 말은 하지 않습니다 ㅋ)

암튼 별거 아닌 걸로 시간 엄청 끌었군요 ;;
참고로 이 툴로 상용 드라이버 패치 등의 악용을 하거나
현재 돌아가고 있는 드라이버를 겁없이 패치하여 리붓, BSOD등의 현상이 발생할 경우
그 책임은 사용자에게 있습니다.



window31. 2007년 12월.