API Hooking 이라는 것을 DRM 솔루션에 한정하여 이야기 해 보겠습니다.(다른 보안 솔루션에서도 절찬리 채택 중이랍니다. 쩝.)
DRM의 본연의 역할이 파일 등의 매체로 저장 될 때 원본과 달리 권한, 암호와 같은 부가 정보와 함께, 원본을 암호화(Encryption)하게 됩니다. 그리고 다시 읽어 들이게 되면, 부가 정보를 확인 하여 권한이 있는 사용자일 경우 암호화된 부분을 원복(Decryption)하여 문서를 볼 수 있게 됩니다.
이러한 과정은 결국 매체(HDD 혹은 네트웍 드라이브 등등)로의 파일 저장 혹은 파일 읽기로 요약 될 수 있습니다.
그런데 API Hooking 기반 DRM은 이러한 과정에서 필수 적으로 사용되는 OS API를 가로채기를 하여 OS에서 만들어진 동작을 하는게 아니라 자기의 부가 동작을 하게 됩니다.
즉 워드프로세스에서 저장을 하게 되면 파일로 문서가 저장이 되는데, 이 파일 저장 과정에 가로채기를 하여 원본 자료가 아닌 다르게 변화가 된 자료가 저장 되게 되는 것입니다.
하지만 이 API Hooking에는 많은 '비용'을 지불하게 됩니다.
대부분 Hooking 기법에는 부가적인 DLL 사용이 이루어지게 되고, 이로인해 시스템 메모리 증가, 특히 성능이 낮은 PC에서는 엄청난 부하로서 동작을 하게 됩니다.
한가지 더 슬픈 소식은, 의외로 많은 '보안'관련 솔루션이 앞다투어서 API Hooking을 행한다는 사실!
그래서 솔루션끼라 박치기 하는 일도 흔하게 되어, PC환경이 먹통이 되기도 합니다.
API Hooking은 인터넷에 많은 자료가 이미 공게 되어 있습니다. 구글 검색 하기로 가 보시면 좀더 넓은 세상을 보실수 있습니다.
2. Overhead
API Hooking 만으로도 무언가 복잡하고 문제가 있다는 것은 쉽게 이해 갈 듯 합니다 ^^
그러나 실체는 더욱더 엄청난 문제를 가지고 있습니다.
API Hooking을 하게 되면 기존 API 동작으로 그대로 흘러 갈지, 부가 동작여부를 반드시 판단 해야 합니다. 여기서 판단 루틴에 의해 기존 동작에 비해서 느려 질 수 밖에 없습니다.
더구나 이 Hooking 함수의 코드를 살짝만 봐서 너무나 많은 부가 동작을 하고 있습니다. 특히 파일 관련 hooking 함수를 보면 경악 할 수 밖에 없습니다. 많은 솔루션이, 파일명을 통째로 복사를 하거나 파일명에 대한 스트링 확인을 행하는데, "최적화"의 '최' 자도 생각 하지 않은 code가 대부분이었습니다.
그냥 "느리게" 살면 되겠습니다만. 그러기에는 PC 성능 저하가 너무나 심하다는 것에 화가 날 수 밖에 없더군요.
3. 광고만큼 보안을 지키지는 못한다
저마다 자신의 솔루션이 최고라고 자랑들을 많이 합니다. 몇몇 업체는 어찌나 WWW 에서 "얼굴" 알리기를 열심히 하시던지 놀라울 따름입니다!
하지만 그들이 자랑하는 그 솔루션에는 자랑과 함께 '구멍'이 있다는 것을 알아야 합니다. 아니 이미 알고 있습니다.
모든 PC에 대해서 자동으로 철통 보안이라 자랑 하지만 - 특히 API Hooking 기번으로 흥한 자는 API Hooking으로 망할 수 밖에 없습니다!
Easy Come Easy Go !
먼 말이냐! 그들이 자랑하는 API Hooking은 쉽게 구멍을 뚫어서 사용 하는 것입니다. 역으로 그들에게도 그 구멍은 똑같이 적용 된다는 것이죠.
Hooking한 루틴을 제 Hooking 하거나 Hooking 동작에 추가 구멍을 뚫을 수 있다는 이야기 입니다.
별도로 언급하겠지만! 이 API Hooking이 그들의 핵심 기반 기술이고 쉽게 이용하는 만큼 남들에게도 동일한 기회가 있다는 것입니다.
훅(Hook?!)~ 하면 다 날아 가버릴 수 있다고 해야 할까요!
4. 복잡하지만 단순하다.
어떤 자동차업체 담당자 인터뷰에서 말하길 '안전장치가 왜 빠졌냐 라고 질문에' "다르지만 같다"고 하셨는데요 ㅎ~ 동급으로 저는 "복잡하지만 단순하다"를 언급 드릴까 합니다.
각종 DRM 솔수션이 있는데 API Hooking 기반의 경우 기존 Application의 읽고 쓰기 동작을 최대한 막아서 호작질을 하게 됩니다.
그런데, 아무 App.에 대해서만 호작질을 하게 되면 여러 문제가 생가게 되므로, 감시 대상 App.에 대해서만 이런 '지랄'같은 동작을 합니다.
이 부분은 자세히 살펴 보지 못했지만, 최초 Load시에 판단을 하는 것으로 보아서는 아마도 진입 code등을 call-stack등을 확인 하지 않을까 의심이 들구요~. 일단 감시 대상 App.이 판명나면 온갖 API을 Hooking을 걸어 버립니다.
파일 입출력은 물론이고 OLE관련 사항(문서 포함 기술을 방해 해야 하기에!), 표준 Message 처리 까지... 그 갯수가 너무나 많더군요.
철통 보안이 아닌 철통 Hooking 걸기라고 할까요 ㅠㅠ
하지만! 이러한 규모에 비해 결국 핵심은 Hooking이고, 이 것은 쉽게 확인이 된다는 것이죠.
파일을 원본으로 만들고 싶다면! 저장시에 Hooking걸려 이상하게 변하는 것을 Hooking이전으로 돌리면 된다로 단순화 할 수 있습니다.
5. Hooking으로 흥한자 Hooking으로 훅~ 간다
5.1. 들어가기 전에
자~ 이제 좀더 세부적으로 파헤쳐 보겠습니다.
아래 내용은 Hooking을 이용한 여러 솔루션에 공통 적인 내용입니다. 괜시리 도둑 제발저리시지 마시기를 바랍니다.
제가 경험한 솔루션의 예를 들겠습니다. 다만 직접적으로 모두 까발리지 않고 기본 원리 위주로 설명 하겠습니다. 이 솔루션은 몇몇 공공 사이트에서 사용 중이라 직접 경험도 가능 하겠습니다. 다만, 준-바이러스라 한번 설치하고서 삭제하려면 고생좀 할 수 있는 솔루션이기도 합니다.
5.2. DRM파일을 원본으로 저장하기의 다른 접근
이번 시도도 읽기 권한이 있는 문서 파일에 대해서 DRM 솔루션의 제어를 벗어나, Encrypt되지 않은 원본으로 저장 하려고 합니다.
*권한 없는 파일에 대해서는 능력 밖의 일이라, 언급 하지 않습니다.
이전에 올린 내용을 보면 Excel VBA를 이용해서 직접적인 파일 Read, Write를 해서 아주 간단하게 DRM 솔루션의 구멍을 이용하는 방법 이었습니다.
그러나 이 방법은 이제 막혀 버렸죠. 하지만 제목 처럼 "Hooking 기법"에 기반한 솔루션의 경우 결국 Hooking 함수에 있을 수 밖에 없는 "구멍"을 다시금 이용 할 수 있습니다.
지난번 처럼 간단하지 않지만, 지난번 처럼 쉽게 막을 수 있는 구멍이 아니기도 합니다.
5.3. DRM파일을 읽을 수 있는 실행 파일이 시작지점
지난번에 Excel을 이용해서 쉽게 구멍을 이용 했는것과 마찬 가지로, 결국 이번에도 시작은 DRM파일을 읽을 수 있는 프로그램에서 시작 해야 합니다.
뭐~ DRM 솔루션을 완전히 속여 버리면 좋겠지만, 그것 분석하는 것은 결국 맞장 뜨자는 이야기가 되어서 출혈도 너무 크고, 이후에 문제가 될 수도 있기에, 기존 App.을 수정 하는 방법으로 접근 합니다.
이번에도 만만한 App.하나 골라 잡았습니다(Excel은 아닙니다 ㅋ~). 당연히 DRM원본을 읽을 수 있는 App.에 한정합니다. (어떤 App. 이냐구요? 비밀 입니다. 그들이 제 블로그에서 정보만 빼 가고, 저는 엿이나 먹어라는 행동을 미리 막기 위함 입니다. 리버스엔지니어링 취미가 있으신 분들께서는 쉽게 시도 가능한 내용으로 판단 됩니다.)
그리고 아래와 같은 전략을 세웠습니다.
A. 파일 읽는 루틴을 찾는다
B. 찾은 파일 읽기 루틴 직후에 새로이 파일 저장 루틴을 만든다 [이것으로 끝나길 바랬습니다]
C. 파일 저장 루틴이 동작 되기 전에 Hooking을 막게끔 처리한다.
D. 파일 저장 후, Hooking을 다시금 원복 처리 한다.
위와 같이 정리 될 수 있는데, 실제 행해야 할 일은 참으로 많습니다. 왜냐면 읽기 루틴을 손상을 주지 않고 쓰기 동작을 추가 해야 하는 어려움이 있습니다.
그러기 위해서는 Disassembly를 해야 합니다.
대표적은 Tool인 IDA를 이용해서 이 과정을 수행 합니다.
5.4. 기존 App.의 파일 Open 후 Read 루틴 직후 버퍼에서는 원본을 볼 수 있다
당연히 기대한 대로 App.에서 DRM원본 파일을 읽은 직후 해당 버퍼를 확인 하면, 원본을 그대로 확인 할 수 있답니다.(뻔~) App.은 encrypt된 내용을 직접 해석하지 못하므로 후킹꾼이 ReadFile 중간에서 원복 해 주는 것이죠.
결론은 나온듯 합니다. 이 원본 내용을 저장만 다시 하면 되는 것이죠. [실은 말만 쉽다고...]
5.5. 원본을 파일로 저장
공략 대상 App.을 Disassemble 하고, Create, WriteFile을 구성하기 위한 code를 새로이 만드는 과정은 약간의 노가다와 Assembly과정 그리고 그것을 Hex code로 새로이 이식하는 과정이 필요 합니다. 이 부분은 가능하면 공략 대상에 이미 존재하는 code를 최대한 활용하여 자르고 붙여서 이식을 했습니다.
그리하여, 파일을 Create 하고, WriteFile을 했습니다. 그런데 @@. 생각과 달리 파일명, 확장자를 다른 것으로 바꾸고 쇼쇼쇼~ 를 했지만, 결국 원본이 아닌 Encrypt된 파일로만 출력이 되더군요.
휴... 지난번 Excel구멍을 보고 그들이 제대로 막은 듯 합니다.
그래서 한참을 다른 방법으로 파 보았지만... 쉽지 않더군요.
알고보니 이 망할 넘이 거의 모든 File I/O API는 물로 OLE API 까지 다 Hooking으로 말아 먹었더군요!
그렇습니다. 결국 이 보안모듈에 의해서 모든 파일 I/O가 통제 되는 상황에서 좀더 고급 방법을 사용 하지 않고 파일 저장은 불가 합니다.
간단하게는 PIPE를 사용 해서 다른 파일로 전송 후 저장하는 방법도 시도 하려 했으나... 너무나 귀찮다는 것입니다. 또한 실제 사용도 거추장 스럽죠!
저의는 원본을 Drag & Drop으로 해제된 파일을 얻고자 했습니다. 그 꿈을 접기에는 아쉽다는 것이죠.
관련 작업 내용을 살짝 언급하면 아래와 같습니다.
★걍 힌트일 뿐 직접 이용은 불가능 합니다.
낑구기(?!ㅎ) 소스 구성 -수도 코드 구성
아래 코드의 회색 부분에 해당하는 code를 모두 NOP에 준한 처리를 하고, 아래 code를 만들어 넣는다!
//--- Saving용 파일명 준비
nChars = lstrlen( sz );
sz[nChars] = '_';
sz[nChars+1] = 0;
//--- 파일 생성 ?? 0100★★
fp = CreateFile( sz, .... -> 함수 SaveFile의 두번째 argument를 그대로 이용)
//--- 기록
WriteFile( fp, lpBuf, len, &nBytesRead, NULL); // nBytesRead unused !!!
// 혹은 옆에껄로 &nChars --> 주소 넘겨야 함!
//--- 닫고 끝내기
CloaseHandle( fp );
fp=INVALID_HANDLE_VALUE;
//--- 아무일 없었는 것 처럼 끝내기
UnmapViewOfFile( B );
return FALSE; |
실제 assembly 코드 만들기 과정
file path 수정 수행.
nChars = lstrlen( sz );
sz[nChars] = '_';
sz[nChars+1] = 0;
|
mov edi, [ebp+sz]
push edi
ds:lstrlenW
mov ebx, eax
mov [ebp+nChars], ebx
mov ecx, eax
shl ecx, 1 ; wide 이므로!
add edi, ecx
mov ebx, 0x5F
mov [edi], ebx
|
8B 7D ★
57
FF 15 ★★★★
8B D8
89 9D ★★★★
8B C8
C1 E1 01
03 F9
BB 5F 00 00 00
89 1F
|
파일 생성, fp 받아오기
fp = CreateFile( sz,
|
xor esi, esi
push esi ;NULL
push 80h ;FILE_ATTRIBUTE_NORMAL
push 4 ;OPEN_ALWAYS
--> 2 CREATE_ALWAYS 로 바꾸자
push esi ;NULL
push 3 ;~READ|~WRITE
push 0C0000000h ;~READ|~WRITE
push [ebp+sz]
call ds:CreateFileW
mov fp, eax
|
33 F6
56
68 80 00 00 00
6A 04
56
6A 03
68 00 00 00 C0
FF 75 ★
FF 15 ★★★★
A3 ★★★★
|
esi 는 이미 0 상태 (위 코드에서 이어지므로)
파일로 기록, WriteFile( fp,
lpBuf, len, &
nBytesRead, NULL);
WriteFile(fp, ~
|
push esi ;NULL
lea eax, [ebp+nChars]
push eax
push [ebp+len] ; len은 file size OK
push [ebp+B]
push fp
call ds:WriteFile
|
56
8D 85 ★ FD FF FF
50
FF B5 ★ FD FF FF
FF B5 ★ FD FF FF
FF 35 ★★★★
FF 15 ★★★★
|
닫 고 끝내기
CloaseHandle( fp );
fp=INVALID_HANDLE_VALUE;
CloaseHandle( fp );
fp=
INVALID_HANDLE_VALUE;
|
push fp
call ds:CloseHandle
or fp, 0FFFFFFFFh
|
FF 35 ★★ 00 01
FF 15 ★★★★
83 0D ★★ 00 01 FF
|
아무일 없었는 것 처럼 끝내기
UnmapViewOfFile(
lpBuf ); return FALSE;
|
push [ebp+B]
call ds:UnmapViewOfFile
jmp loc_★★★★ ; 0 set, return
|
FF B5 ★★ FF FF
FF 15 ★★ 00 01
E9 ★ 04 00 00
|
* 해당 jmp 명령★★★★ - address - 5 해야 함!
★ 처리 한 것은, 더이상 그들에게 편리를 주지를 않기 위해서 입니다.
5.6. Hooking 을 뒤집어라!
결국 호랑이를 잡기 위해 호랑이 굴로 들어갈 수 밖에 없습니다.
즉 CreateFile, WriteFile에 대해서 Hooking동작을 살펴 보아야 한다는 것입니다. 왜냐면 CreateFile, WriteFile 흐름에서 이 보안 모듈에서 Hooking으로 '호작질'을 하고 있기 때문입니다. 이 호작질을 훌쩍 넘겨 버리고, 기존의 system 함수를 그대로 이용 하게 한다면, 고생끝 행복 시작이 가능 한 것입니다.
다만 호랑이 잡으려다 보니 IDA 디버깅은 죽어 버립니다. 나름 보안장치를 하셨군요! 대신 국민 디버거인 Visual C++ 는 멀쩡히 돌아 가는 군요!
우선 수술한 App.을 실행 시킵니다.
그리고 강제로 Process를 VC에 Attach 시킨 후 우선 Pause 합니다.
그리고 이식 수술한 CreateFile위치에 break point를 설정 합니다.
그리고 Go~
DRM 파일을 하나 Drag & Drop 합니다.
곧 앞서 걸어 두었던 break point가 걸리고, Step을 밟고 들어 갑니다.! 호랑이 굴에 들어 가는 것이죠!
두둥! 넵 진입 했습니다.
그리고 CallStack을 보고, DLL 모듈이 어느 것이지 확인 합니다. 물론 주소값도 미리 기록 합니다.
'역공'의 핵심은 기록입니다.
★c.dll 임을 확인 되었습니다. 이넘이 바로 Hooking을 밥먹듯이 걸어 버리는 주체입니다. 이 넘의 배를 갈라볼 필요가 있는 것이죠!
다시금 IDA를 통해서 Disassembly를 합니다. 그리고 앞서 기록한 주소값에 해당하는 code를 찾습니다.
이넘이 바로 그 CreateFile을 대신하여 Hooking 하는 본체인 것이죠.
그리고 살펴 봅니다.
ㅎㅎ 역시 Hooking함수에서 필연적으로 나타 날수 밖에 없는 패턴이 보입니다.
즉 '호작질' 동작을 계속 할 것인지, Hooking전의 원본 동작을 할 것인지 판단을 하고, 분기 하는 logic이 나타 납니다.
이 logic은 있을 수 밖에 없는 루틴 입니다. 특히나 CreateFile이라면, 모든 파일 I/O 전에서 호출 되어야 하는데... 실제 파일 I/O는 온갖파일이 다 지나가게 되고, 관심 대상인지 아닌지를 판단해야만 합니다.
바로 이 판단하는 부분을 먹통을 만들면, 만사 형통이 되겠습니다.
호랭이 잡는 다는 것이죠!
간단히 디버거에서 해당 판단 루틴을 뒤집어서, 저~ 밑으로 가는 흐름으로 돌려 보았습니다. 슝~
가서 파일 기록 까지 끝내고 나니!!!
5.7. Hooking 함수는 막장 쓰레기!
여기서 잠깐 - 이 함수의 첫 시작이, 파일명을 몽창 변환하는 logic이 등장합니다. 뭐 하긴 제가 살펴본 다른 보안 모듈도 비슷했습니다. 쓸대없이 파일명 복사해다가 파일명을 뒤져서 다른 판단하더군요.
만일 file path가 엄청 길다면 더욱더 끔찍합니다. 단지 파일면 열었을 뿐인데 Hooking함수에서 쓸데없는 시간을 다 잡아 먹어 버리게 됩니다.
5.8. 뒤집고 얻은 원본
파일 기록까지 시켜 보니 원본이 얻어 졌습니다. ㅠㅠ 감동의 결과 입니다.
즉 Hooking 루틴의 특정 흐름만 뒤집으면 그냥 보안 동작 대신 원래 동작으로 원본 파일을 얻을 수 있다는 것입니다.
자! 그렇다면, 이 Hooking 함수 흐름을 수정하여, 원래 동작을 하는 방법을 찾아야 합니다.
의외로 간단합니다.
앞서 언급했지만 Hooking 함수에는 특정 flag혹은 이와 동등한 동작을 하는 메모리 값이 있습니다. 이 메모리 값을 공략대상 App.에서 살짝 다른 값으로 바꾸었다가, 원복 해 주면 됩니다.
이 과정은 단지 메모리 값을 빼와서 보관, 수정, 파일 저장, 원복으로 해결 할 수 있습니다.
더군다나 Hooking DLL은 공략 대상에 기생하는 DLL입니다. 그래서 어려움 없이 동일 process 이므로 걍 메모리 직접 읽고, 쓰기가 되어서 쉽게 원하는 동작이 가능합니다.
그래서 Hooking으로 흥하면 Hooking으로 망한다고 할 수 있겠죠 ㅎㅎ
자~ 위 동작으로 어렵게 다시 Assembly code로 만들고 Hex code로 patch합니다.
그리고, 최종 완성한 우리만의 App.이 만들어 졌습니다.
그리고 원본 파일을 Drag&Drop! - 그러면 원복된 파일이 만들어 지는 것이죠 ㅎㅎ
꿈에 그리던, 원본 던지면, 결과물이 원본 위치에 생성 됩니다.
관련 잡업 내용을 소개하면 아래와 같습니다.
★에서 ★c.dll 의 특정 변수값을 임시 보관 후, 무조건 분기하도록 조건을 수정 한 값을 넣고,
Write작업 후 해당 변수값을 복원하자!
특히나 ★c.dll 은 고정된 메모리값을 가지는 것으로 보인다!
이 변수값은 dword_61★★★ 로 사용 중 void* 로도 사용 중으로 IDA분석 됨
mov eax, dword_61★ ★★ // [61F4AFA8] A1 ★ ★ ★ 61
push eax // 보관하기! 50
mov dword_61★★★★, 0 // ebx가 이미 0 이므로 mov mem, ebx 를 찾아보자
// 89 1D ★ ★ ★ 61
..... Create file기존 patch code ...
pop eax // 58
mov dword_61★★★, eax // A3 ★ ★ ★ 61
..... Create file 이후 patch code
6. Easy Come Easy Go
컴퓨터가 굴러가는 세상에서, 기술은 많습니다. 그중 MS계열에서는 API Hooking 기술도 있는 것입니다.
하지만 이 API Hooking은 쉽게 이용 할 수 있는 만큼, 쉽게 역으로 재이용 당할 수도 있습니다.
Easy Come Easy Go - 바로 API Hooking에서도 적용 된다는 사실.
잊지 않았으면 합니다.
지난 번 처럼 자료를 직접 공유 드리지 못해서 죄송 합니다.
하지만, 위에 언급 드린 내용 만으로도, 관심 있는 매니아들에게는 출발점을 충분히 전달 드렸다고 봅니다.
저는 보안 모듈 자체를 거부하지는 않습니다. 다만 얕은 기술과 외형만 중시하는 일부 몰지각한 솔루션에 대해서 제대로된 기술을 가질 것을 바랄 뿐입니다.
특히나 컴퓨터 성능을 잡아 먹는 그런 솔루션은 없어져야 할 것입니다.
dotnetfx_cleanup_tool.zip
