2011.05.11 18:34 System

[+] Beginning



약 1년 전에 Google Chrome에서 웹페이지가 로딩 되지 않는 것에 대한 포스팅을 했습니다.

http://linkc.tistory.com/entry/Google-Chrome-Loading-Problem

sandbox 옵션을 사용하지 않으면 해결되는 문제였죠.

그 땐 그런가 보다 하고 넘어갔는데, 최근 다시 그런 문제가 생겨

왜 이런 문제가 일어나는지 , 해당 옵션을 사용하지 않으면 정상적으로 동작하는지

한 번 살펴보기로 했습니다.


[+] Problem



앞서 설명했던 대로입니다.

Chrome을 실행 하면 웹 페이지가 로딩 되지 않습니다.

또 가끔 페이지가 로딩 되더라도 다음과 같은 메세지를 뱉으며 죽어버리기 일수죠.

<Fig1. 크롬이 오류를 내며 죽는 경우>

개발자들의 센스가 보이는 문구네요. 귀엽죠?

<Fig1-2. 귀여워>


크롬을 실행 할 때는 물론, 실행 중에도 간혹 페이지가 뜨지 않는 현상이 발생합니다.


[+] Analysis


 

1. Session 및 Desktop의 생성

크롬은 Sandbox 기능을 사용하고 있습니다.

다음은 실제 크롬을 막 실행 시킨 직후의 모습입니다.


  <Fig2.  메인 크롬 Process의 WindowsStation>



크롬은 각 탭 하나마다 새로운 자식 프로세스를 생성하며, 탭 이외에도 Plug in 이나 확장프로그램을 사용하면 하나씩 늘어납니다.

<Fig2>를 찍을 땐 , 모든 확장 프로그램을 작동 중지한 상태에서 찍어서 2개만 떴지만, 실제 사용하는 확장 프로그램을 모두

사용하면 6~7개 정도의 크롬이 등장합니다.

아무튼 <Fig2>를 보면 아시겠지만 크롬의 WindowStation이 WinSta0 이외에도 하나 더 생성되어 있는 것을 확인할 수 있습니다.

WindowStation?

Session의 하위 개념입니다.

Session > Station > Desktop > Process 순으로 보시면 되겠네요.

자세한 사항은 다음 블로그에 상당히 정리가 잘 되어있으니 참고하시면 도움이 될겁니다 :D

http://www.benjaminlog.com/tag/%EC%9C%88%EB%8F%84%EC%9A%B0%20%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%85%98



메인 프로세스는 이렇게 2개가 혼재하고 일반 탭의 자식 프로세스는 가장 하단의 WindowStation인 Service 어쩌구 하는

Station 만 존재합니다.

<Fig3. CreateWindowStation을 호출하여 Station을 만드는 모습 >

이후에 GetUserObjectInformation 을 이용하여

만든 Station의 이름을 가져옵니다.

<Fig4. GetUserObjectInformation을 호출하여 이름을 얻어온 모습. Service ~ >

확인해보면 <Fig2>와 같은 형식을 지닌 것을 알 수 있죠.

이후 호출하는 함수를 따라가보면 다음 함수를 호출합니다.

<Fig5. CreateDesktop을 호출하여 Fig3에서 생성한 Station 내부에 Desktop을 생성한 모습>

sbox . Sand Box 를 의미하는 것이겠죠?

0xD64 는 해당 메인 Process 의 PID 입니다.



2. Process 생성

<Fig6. CreateProcessAsUsesr를 호출하여 Process를 생성하는 모습>

해당 함수를 MSDN에서 살펴보면

<Fig7. MSDN에서 살펴본 CreateProcessAsUser>


CreateProcess 와 다른 점은 첫번째 인자가 추가되었다는 점 하나 뿐입니다.

이 hToken 값은 생성될 User의 Handle값이 되겠죠.

그리고  STARTUPINFO  구조체의 lpDesktop 변수에 앞서 생성해준 Station 과 Desktop 정보가 들어갑니다.

또한 , 바로 실행하지 않고 Suspend 상태로 Process를 생성하구요.

흠. 보통 일반적인 Process를 생성하는 방법과는 약간 차이가 있네요.

이후에 CreateJobObejct 를 통해 미리 생성해둔 Job에

AssignProcessToJobOjbect 를 통해 Fig6에서 생성이 완료된 Process를 Job에 추가시킵니다.

Job은 일련의 속한 Process에게 공통적인 정책을 적용하기 위해 사용한다고만 알아두시면 될 것 같네요.



3. Check Integrity

이 후 메모리의 무결성을 검사합니다.

이 무결성을 통과하지 못하고 문제가 발생한 경우는 제가 확인했을 때 IAT Hooking 이 이루어질 때 였습니다.

[ 다른 경우가 있다면 알려주세요! ]

해당 Hooking을 거는 프로그램이라고 하면 보안 프로그램이나 악성 프로그램정도가 되겠죠.

Sandbox 내에서 생성된 탭은 일반적인 방법으로는 Hooking 이 되지 않기 때문에

[ 물론 외부 Process와 통신이 필요한 tab은 Sandbox로 생성하지 않습니다. 그런 tab은 Hooking 이 걸리게 되죠. ]

부모, 자기 자신의 Process만 검사하는 것으로 보입니다.

체크후에는 VirtualAllocEx를 통해 Sandbox에 생성한 Process의 메모리에 접근합니다.

제가 확인한 경우는 2가지 입니다.

첫번째는 VirtualAllocEx에서 해당 Process로 접근 하는 메모리에 권한을 주지 않는 방법으로 차단하는 경우,

두번째는 특정 함수를 선택하고  ReadProcessMemory 를 이용하여 Hooking이 되었는지 여부를 확인하고 차단 하는 경우


입니다.

2가지 프로그램 밖에 테스트 해보지 않았지만 다른 것도 비슷할 것으로 보입니다.




4. Terminate Process Or Resume Process

3번의 Integrity 를 통과하지 못하면 Process를 Terminate 합니다.

Terminate Process가 실패하면 GetExitCodeProcess을 통해서 Process를 종료하구요.

뭐 통과를 하게 되면 생성해둔 Process를 다시 동작시킵니다.



5. Conclusion

<Fig2>를 보면 아시겠지만 크롬은 최소 Process가 2개 입니다

하나는 부모 Process , 하나는 탭에 할당된 Process죠.

부모는 다른 Station에서 실행되고 있는 Process를 Control 하는 역할을 하게 되고

실제 페이지를 뿌려주는건 자식 Process 입니다.

만약, 3번 Check를 통과하지 못했다면 결과적으로 남는 것은 부모 Process 하나 뿐입니다.

이렇게 되면 페이지를 탐색할 자식 Process가 없는 꼴이 되니 정상적으로 실행 될 수 없다는 겁니다.

이해 되시나요?

물론 Plug in 이나 확장 프로그램도 모두 실행이 안되더군요.





[+] Solution



정리하자면

1. IAT Hooking을 거는 특정 프로그램을 종료시킨다.

2. [ 위 Hooking을 거는 Process가 사용자 권한일 경우에 한함 ] 크롬을 관리자 권한으로 실행시켜 Hooking을 못 걸게 한다.

3. 크롬에 --no-sandbox 옵션을 줘서 실행한다.



정도가 되겠습니다.

해당 문제 때문에 크롬을 못쓰는 분들이 해결 하시고 잘 사용하실 수 있길 기원합니다 :D


Posted by LinkC

2010.09.29 21:17 System

이번에는 UAC가 적용되는 조건 이나 사례를 알아보도록 하겠습니다

자기가 UAC를 걸지도 않았는데 방패 모양이 박혀서 UAC 를 요구 하는 경우나

분명 방패 모양도 없는데 실행시켜보니 UAC를 요구하는 그런 황당한 일을 겪어보셨을 겁니다

그런 고로 이번 포스팅의 목표는 UAC입니다

UAC가 걸린 파일들은 다음과 같은 분류로 나누어지게 됩니다


1. Installer

2. Manifest

3. Application Compatibility Database

4. 프로그램 내부 코드에 의해 


[+] Installer

Wise, Install Shield, NSIS 등의 전용 Installer 등은 기본적으로 UAC를 넣어주도록 설정 되어 있습니다

이런 실제 Installer 이외에 문제가 될 만한 특이점이 하나 있는데요

컴파일 된 실제 실행 파일이 바로 그 주인공입니다

Visual 6를 기준으로 컴파일 된 실행 파일들은

Install, Update, Setup 이라는 문자열이 파일명, Descriptor , 등등 프로그램 정보에 해당하는 항목에 있을 경우 

방패를 달게 됩니다

<그림1. 파일명에 Update라는 문자열이 들어가는 것만으로도 UAC가 걸린 모습>

Visual Studio 2008 의 경우는 6와 조건은 같지만 

UAC 대신에 호환성 관리자가 실행 되어 이 파일이 정상적으로 설치 되었는가를 물어보게 됩니다

<그림2. Visual Studio 2008 에서 컴파일한 실행파일명에 해당 문자열을 넣고 실행한 모습>

그런 고로 이런 파일명이나 프로그램 정보등에 Install, Update, Setup 등의 문자열이 들어가는 것을 주의해야 합니다

[+] Manifest

두번째는 Manifest 입니다

가장 보편적으로 UAC를 삽입하는 방법이죠

이는 실행파일등의 Resource에서 Configuration Files 정보에서 확인합니다



<그림3. UAC가 걸려있는 파일의 실제 Manifest 적용 정보>

이에 해당하는 level의 항목은 다음과 같습니다

<그림4. Manifest 설정 파일 내의 항목에 따른 요구 권한>

requestedExecution level 옆의 uiAccess 같은 경우는 기본으로 False가 설정되어 있는데요

이는 사용자 인터페이스 권한 격리 [ UIPI ]를 사용한다는 의미입니다

이게 무슨 소린고 하니, 낮은 신뢰 등급을 가진 프로세스가 높은 신뢰등급을 가진 프로세스에 메세지를 보내는 것은 제한 한다는 것이죠

True로 설정되어 있다면 이를 해제 합니다




[+] Application Compatibility Database

Windows 에서는 기존에 호환성에 문제가 있따고 밝혀진 기존의 파일에 대한 DB가 존재합니다

그 DB에는 더이상 업데이트 되지 않는데 적절한 수정이 없으면 현재 OS에서는 정상동작하지 않는, 그런 프로그램들에 대한 정보가 있습니다
이에 대한 정보는 프로그램 실행 전에 체크 되며

DB에 있는 파일들은 설정된 지시를 따르게 됩니다

이러한 DB를 보려면 Application Compatibility Manager라는 관리툴을 깔아야 하며

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en

에서 다운 받을 수 있습니다 :D

만약 호환성 문제가 되어있되, 지시가 적히지 않은 프로그램의 경우가 있다면, 다음과 같은 메세지를 보이게 됩니다


<그림5. 2.0 버전의 Gom Player에 대한 호환성 DB가 존재하여 프로그램 호환성 관리자 창이 뜬 모습>

이 DB에서 만약 특정 프로그램은 관리자 권한으로 실행해야 한다고 지시가 있으면

그렇게 행하게 됩니다

예를 들면 Filemon이 있죠

<그림6. DB에 관리자로 실행되게 끔 되어 있는 Filemon>

Filemon은 현재 Process Monitor 로 Regimon 과 함께 통합이 되어 더이상 업데이트를 하지 않는데

관리자 권한이 아니면 정상동작하지 않는 고로 호환성 DB에는 관리자 권한으로 실행되라고 하는 지시를 발견할 수 있습니다




[+] 프로그램 내부 코드에 의해

이 경우가 대부분의 방패 모양은 없는데 UAC가 걸리는 그런 상황입니다

특정 프로그램들은 OS Version 에 따라 다른 코드가 실행되곤 하는데 Windows Vista 이상부터는 권한을 상승시켜 재실행 하는 경우를

종종 볼 수 있습니다

그냥 프로그램 권한을 상승시키면 되지 재 실행 할 필요는 없지 않느냐 하는 질문이 있을 수 있는데요

프로그램은 재 실행 되지 않고서 , 권한만 상승 시킬 수는 없습니다

이 점 유의해두시면 좋겠네요 

간혹, 특정 버튼에만 UAC를 걸어 프로그램을 실행 시키되, 보이지 않게 하는 경우도 있다는 걸 알아두시면 좋겠죠?

작업 관리자가 대표적인 경우 입니다


<그림7. 특정 버튼, 동작에만 권한 상승이 걸려있는 모습>

 
이상 UAC가 적용되는 조건에 대해서 써봤습니다

생각보다 복잡하네요

특히 마지막 경우  방패 모양이 실행 파일에 찍히지 않아, 실수하기 쉬운 경우가 되겠죠?
Posted by LinkC

2010.09.06 22:01 System

Matt 님 블로그를 돌아다니다가 발견했습니다


Windows Movie Maker vulnerability 라고 쳐봤더니

최근에 Remote Exploit 이 있었던 모양입니다


OS 종속적인 버그가 있었던 모양이네요

특이하게도, Vista는 Exploit 되는데, Server 제품군 들과 7은 영향 받지 않았습니다


<그림1. Bug에 영향받지 않는 OS들>

패치 전, 후 파일을 받아서 비교해봤는데

한 두 군데 고친것도 아니었고

Binary Differ 프로그램을 이용해봐도 아직 감이 안오더라구요 -.-

아무튼 각설 하고 본론으로 들어갑니다

앞서 발표된 Remote 취약점과는 달리 기술적 난이도도 높지 않고 

아 이런 경우도 있구나 하고 넘어갈 정도의 버그입니다

DLL Hijacking 역시 상당한 위협수준이 될 수 있습니다

아래 동영상을 보시면 감이 오실겁니다

KB: We can"t fix this one - Microsoft DLL Hijacking Exploit from Offensive Security on Vimeo.






위 링크를 보셨으면 금방 이해하셨겠지만

간단히 설명해보겠습니다

Windows Movie Maker의 확장자 , mswmm 혹은 프로그램이 설치된 폴더에

%SystemRoot% 폴더를 만듭니다

그 폴더 안에 system32폴더를 만들고

해당 소스로 hhctrl.ocx를 컴파일하여 system32 폴더 안에 넣으면 됩니다

어때요? 정말 쉽죠?


<코드1. hhctrl.ocx의 소스>

이제 mswmm 이나 프로그램을 실행시키게 되면

떠야 할 Windows Movie Maker는 실행되지 않고 

계산기가 실행되는 것을 볼 수 있습니다

이를 야기하는 코드를 찾아볼까요?


<그림2. 버그를 야기하고 있는 부분>

환경변수를 이용하는것 이외에는 별 이상도 없는 그런 코드입니다만

바로 그 환경 변수가 문제가 됩니다

절대 경로라면 이상 없이 넘어갔을 테지만 말이죠

그 원인이 되는 것은 바로

DLL이 로딩되는 경로 순서 입니다


1) dll을 로드하려는 프로그램의 current directory
2) 현재 windows의 current directory
3) system path = %SystemRoot%
4) windows path = %windir%
5) path 환경변수에 등록된 곳들


3번 System path 보다  1번을 먼저 찾기 때문에

해당 디렉토리에 %SystemRoot%system32가 있으면 그곳을 먼저 찾는 거죠

그래서 hhctrl.ocx를 로딩하는데, 그 파일이 조작되었다면 말 다한거죠

실행 시키고 싶은 코드를 실행 시킬 수가 있는 겁니다

예를 들어, 관리자 권한으로 실행되는 프로그램에서 이러한 취약점이 있다면

관리자 권한으로 프로그램을 실행 할 수가 있게 되구요

심각한 버그는 아니지만, 아주 사소한 것으로도 이러한 Hijacking 이 일어날 수 있다는 것이

정말 재밌네요 :D


Posted by LinkC

2010.08.17 10:32 System

<그림 1. Windows 버전별 적용 Memory Protection>

08년도 Black hat 에서 공개된 문서입니다

벌써 2년이나 지났네요

주인장은 나날이 잉여력을 뽐내는데 배울건 한없이 늘어나네요 

이 기술들을 일일히 나열하려면 끝이 없을거 같으니 

간단히 소개하는 정도로 포스팅을 마치겠습니다

[+]GS

GS Flag를 셋팅하여 Buffer가 변조되었는지 체크 합니다

해당 옵션은 VC 옵션에서도 찾아볼 수가 있죠

<그림 2. VC에서 GS Flag를 설정하여 Stack Cookie Option을 On 시킨 모습 - Default>

이 Protection Mechanisms 은 Linux 의 StackGuard 형식과 유사합니다

스택상의 Return Address 앞에 공간을 할당하여 Cookie를 가리키는 포인터를 저장하는 거죠[ 이를 Security Cookies 혹은 Stack Cookie 라고 합니다 ] 

<그림 3. 함수 내에서 Security Cookie 를 체크하는 부분>

함수가 시작 될 때와 종료될 때 가리키는 Cookie 값을 비교하여 다르면 Process를 종료하는 식입니다


[+] Safe SEH [ Structured Exception Handling ]

SEH 는 프로그램 내에 예외상황이 발생했을 때 실행되는 코드입니다. 

런타임에 예외가 발생하면 OS는 이미지 헤더를 확인해서 SEH 주소가 올바른지 여부를 판단하고, 그렇지 않을 경우 

종료합니다


[+] DEP

프로그램 내 Exploit 코드 실행을 방지 합니다

일반적으로 Code Injection 등을 통해서 쉘코드를 실행시키려고 하면 이 Prtoection 에 걸려버리는걸 확인할 수 있죠



해커들이 DEP를 꺼버리고 공격하는 방법을 이용 하자, 영구 DEP를 걸어버리죠

물론 이 마저도 우회하는 방법이 추후에 나왔지만요

[+] ASLR

Windows Vista 나 7 환경에서 디버깅을 해보신 분은 알겠지만 

프로그램이 로딩되는 OEP의 주소나 스택, 힙 모든 값이 실행할 때마다 변하는걸 보신 적이 있을 겁니다

바로 이 기술의 적용 때문인데요

PEB나 TEB는 XP에서부터 적용이 되고 있었군요 :D



살펴보면 Memory Protection 이 정말 많네요

물론 한번에 적용되었던 것이 아니라 몇년에 걸쳐서 이루어진것입니다

후에 적용된 기술이 아무래도 Exploit 하는데 좀 더 까다로운 모습을 보이죠

*Dino A.Dai zovi의 다음 문서를 참고했음을 알립니다



<그림 4. 기술들의 Exploit 어려움 정도>



또한, 이러한 기술들은 단순히 한가지 분류가 아니라 3가지

Compiler 와 Application  , OS Run- Time 으로 나눠 보여주는군요


<그림 5. OS, Compiler, App 가 Base가 되는 기술들  >



간략히 Memory Protection 에 대해서 정리했습니다

물론 앞으로도 이러한 Protection 을 우회하는 방법은 나올 것이고

그에 따라 Protection 기법들도 업그레이드 해나가겠죠

절대적인 창도 , 방패도 없는 그런 분야니까요

각 기술들에 대한 자세한 정리는 차후에 차근차근 해나가야겠네요

그 날짜가 언제가 될지 모르겠다는게 문제지만요 :(

뭔가 알맹이가 없는 포스팅만 하는거 같네요
 
럭셔리한 포스팅을 하는 그날까지 분발해야겠습니다

...

라고 말하는것도 몇번짼지 모르겠네요


'System' 카테고리의 다른 글

UAC 적용 조건 및 사례  (0) 2010.09.29
DLL Hijaking Exploit in Windows Movie Maker  (0) 2010.09.06
Memory protection mechanisms in Windows  (4) 2010.08.17
DLL injection on 64 Bit OS  (2) 2010.08.03
Screen Capture with DLL injection  (2) 2010.07.27
서비스 프로그래밍  (3) 2010.04.27
Posted by LinkC

2010.08.03 19:24 System

얼마전에 ReverseCore님께서 Windows 7 에서 Injection 하는 방법을 포스팅 하셨죠

얼마전이라기 보단 꽤 됐지만..

http://www.reversecore.com/73

굉장히 정리가 잘되어있으니 한번 보시면 큰 도움이 될겁니다 :D

아무튼 요는 Windows7 에서 Session 관리 정책이 변경되면서

CreateRemoteThread()가 먹히지 않게 되었고

ntdll!ZwCreateThreadEx()를 직접 호출함으로써 해결 할 수 있다는 것입니다

하지만 이 방법도 64bit 에서는 되지 않더군요

64bit OS에 Global API Hooking을 할 때 , 이건 문제가 되겠죠

64bit process를 차근차근히 보시면  , 64bit 에는 64bit dll만 로드 되어 있는 것을 볼 수 있습니다



그림1. 64bit Process 내에 Load 되어 있는 kernel32.dll 의 정보


*32bit process 에서 사용 되는 시스템 dll 의 경우 syswow64 폴더의 dll을 쓰게 됩니다


그림2. 32bit Process 내에 Load 되어 있는 kernel32.dll 의 정보

그리고 이 64bit dll 을 Injection 할 때 32bit Program 으로는 되지 않는 것 까지 확인했습니다


그림3. 32bit Program 에서 64bit dll 을 Injection 할 때 실패하는 모습



64bit dll 을 Injection 할 때는 64bit Program 이 필요한게 아닌가 싶었습니다

64bit 로 컴파일 하여 시도해보니


그림4. 64bit Process 내에 성공적으로 Injection 된 모습

네, 제대로 Injection 이 성공한 것을 볼 수 있습니다

즉, 64Bit Process 에 Injection 을 하고자 하면

64Bit Injection Program 으로 64Bit dll 을 Injection 해야 한다


는 것이 이 포스팅의 요입니다

고로 , Global API hooking 등을 하고자 할 때는

64bit용, 32bit 용으로 나눠

32bit injection program, 32bit dll

64bit injection program, 64bit dll

이렇게 제작해야 올바르게 작동합니다

64bit dll 은 64bit로

아, 어찌보면 정말 당연한 건지도 모르겠지만

처음에 부딪혔을 때는 왜안되나 했네요 :D



How to Compile a 64bit application or dll?

64bit 용 dll 과 application을 얻고자 하신다면

64bit 용으로 compile 하셔야 합니다

찾아보니 대략 2가지 정도가 있던데요

물론 더 있는데 제가 못본거겠지만..

Microsoft Platform SDK 의 64bit Build Enviorment 를 이용하시는 방법과

Visual Studio 2005 이상의 버전을 이용하시는 법이 있습니다

전자의 경우 Visual Studio 6에서도 적용가능한 방법이지만

MakeFile 을 작성해서 64bit Build Enviroment 창에서 Compile을 시키는 형태입니다

필자의 경우 후자의 경우가 더 편해보여서 이를 이용했습니다

다만, Visual Studio 설치 시 별달리 건드린게 없으시다면

64bit Compile Tool 이 깔려있지 않을 겁니다

그런분은 제어판의 프로그램 추가/제거에서 Visual Studio 2005 이상의 버전을 누르셔서

메뉴를 보시면~

다음과 같이 x64 Compilers and Tools를 발견하실수 있습니다

이를 체크하시고 설치하시면 됩니다 :D




이 설정을 해 주셨다면 Visual Studio 를 실행하시고

Compile 시에 상단의



Platform 의 new 부분에 들어가셔서

x64로 설정하시면 됩니다

다만, Compile 시에 64bit 와 32bit 의 차이점은 고려하셔야 겠죠? :D



'System' 카테고리의 다른 글

DLL Hijaking Exploit in Windows Movie Maker  (0) 2010.09.06
Memory protection mechanisms in Windows  (4) 2010.08.17
DLL injection on 64 Bit OS  (2) 2010.08.03
Screen Capture with DLL injection  (2) 2010.07.27
서비스 프로그래밍  (3) 2010.04.27
System Information 을 가져오는 API  (2) 2010.04.21
Posted by LinkC

2010.07.27 22:26 System



네 몇몇 분들은 알아보셨을지 모르겠지만

게임 촬영등에 자주 쓰이는 Fraps 란 녀석입니다

어쩌다보니 이 프로그램이 찍는 스크린샷의 방법에 대해 볼 일이 생겼습니다

대략 뒤적거리다 보니 인터넷에서는 이런 소스를 볼 수 있었습니다



문제는 IDirect3DDevice9 인터페이스 참조인 g_pd3dDevice 인데요

보통의 경우 CreateDevice()나 new Device()를 이용하면 됐습니다만

Fraps의 경우, 현재 프로세스에서 대상 프로세스의 Device를 얻어오는 방법이 좀 특이하더군요

화면 전체를 찍는 경우와는 달리 대상 프로세스의 핸들을 얻어와야 했는데

이를 넘기면 오류가 발생합니다

흠 대상 프로세스에서 직접 핸들을 전해주면 해결될텐데 말이죠

Process Explorer로 살펴보다 보니 , 다른 프로세스에 fraps.dll 이 로딩되어 있는 것을 볼 수 있었습니다

 


그러니까 fraps.dll 이 DLL injection 되었다고 볼 수 있죠

아마 Fraps는 fraps.dll 을 injection 하고 대상 프로세스에서 캡처에 필요한 정보를 받은다음

이를 토대로 파일을 생성하는 식일껍니다

실제로 Fraps 를 attach 시킨 후에

kernel32.dll 에 있는 CreateFile에 BP를 걸고 확인해보면

맞다는 것을 볼 수 있죠

그렇다면 Injection 된 dll이 어떤 역할을 하는지

잠깐 살펴보겠습니다

fraps32.dll [ 64bit 에서는 fraps64.dll 이 Injection 되겠죠? ]





뭐 대략 이런 DLL 입니다

아마 Fraps.dll 이 Loading 됨과 동시에 FrapsSetup을 통해서 가능한 Process에 Injection 을 할 겁니다

그리고 Screen shot 이나 동영상 촬영등을 할 때 필요한 단축키들을 잡아내야 하니까

Key Hooking도 하겠죠

의외로 하는일이 많군요

처음보시는 분이라면 ReverseCore님의 강좌를 보고 오시면 좀 더 쉽게 이해하실 수 있을겁니다

http://www.reversecore.com/30

그러니까 요는 Injection 된 프로세스 내부에서 입력된 Key Message 를 후킹한다는 거죠

설정된 키가 아니면 CallNextHookEx 을 통해서 통과시켜주구요

이렇게 잡은 Key 중에서 Screen shot 키를 걸러내서 따라가 보면

다음과 같은 부분을 보실 수 있습니다




OpenFileMapping 이라..

FileMapping는 메모리를 선언하고 선언한 메모리를 두개 이상의 모듈에서 서로 공유하여 사용할 때 쓰는 함수입니다.

기본적인 개념은 메모리를 파일처럼 오픈하고 한쪽에서는 데이터를 기록하고

한쪽에서는 데이터를 읽는 방식으로 데이터를 공유합니다.

서로 다른 모듈이 메모리를 공유할 수 있기 때문에 서로 다른 프로그램에서

데이터를 전송하고 전송 받고자 할 때 주로 사용하고 있습니다.

 즉, Fraps.exe와 Fraps32.dll이 Injection 된 프로그램간에 메모리를 공유하고 있다고 보시면 됩니다.

이를 좀 더 살펴보면 스크린샷 버튼을 눌렀을 때 , Injcetion된 프로그램에서
 
프로그램 내부에서 캡처된 화면의 정보를 Fraps.exe에 전달하고
 
이렇게 모은 정보를 Fraps.exe에서 Createfile을 통해 파일을 완성합니다.


뭐 Fraps는 이런 식입니다

다른 capture 프로그램도 이런 방식을 이용하는지는 모르겠네요

아마 영역을 지정해서 하는 프로그램이라면 DLL injection을 쓰지는 않을 거 같군요 흠흠

이런식으로 Capture를 구현할지는 몰랐네요

정말 배울게 너무나 많군요 :D





'System' 카테고리의 다른 글

Memory protection mechanisms in Windows  (4) 2010.08.17
DLL injection on 64 Bit OS  (2) 2010.08.03
Screen Capture with DLL injection  (2) 2010.07.27
서비스 프로그래밍  (3) 2010.04.27
System Information 을 가져오는 API  (2) 2010.04.21
What is VCP[Virtualized Code Protection]?  (0) 2010.01.29
Posted by LinkC

2010.04.27 15:44 System

*이 서비스 프로그래밍 포스팅은 전체적으로 WIndows API 정복의 '서비스' 챕터 부분을 참고하셨음을 알려드립니다




어쩌다 보니 서비스 프로그램을 하나 만들게 되었습니다

서비스 프로그램이란

Linux 의 데몬처럼 Windows background 환경에서 작동하는 프로그램을 말합니다

Windows7 에서는 작업 관리자를 통해서 보거나




서비스 창을 통해서 확인하실수 있죠




먼저 서비스 프로그램을 돌리기 위해서는

자체적으로 돌아가는 서비스 프로그램과 이를 제어하기 위한 제어 프로그램이 필요합니다

서비스 프로그램은 Back Ground 에서 돌아가기 때문에 사용자와 상호 대화할 필요가 없죠

그래서 보통은 Console Application 으로 만들어지고

제어 프로그램은 이를 사용자가 제어하기 위해 만들어졌기 때문에

GUI 를 지니게 됩니다

또한, 서비스 프로그램은 직접 제어 프로그램과 통신하지 않고

SCM [ Service Control Manager ] 를 통해서 하게 됩니다

이때, SCM 과 서비스 프로그램과 통신을 담당하는 것을 ' Dispather ' 라고 하구요

전체적인 통신 방법을 살펴보자면..

1.      SCM은 해당 서비스를 가지고 있는 프로세스의 경로를 레지스트리에서 찾는다. 만약 이 프로세스가 실행중이 아니라면 프로세스를 실행시킨다.

 

2.      서비스 프로세스의 Main 함수에서 디스패처 쓰레드를 생성하며, 이때 Main 은 디스패처에게 자신이 가지고 있는 서비스의 목록과 서비스 메인 함수의 시작 번지 등을 전달해 준다. 디스패처는 프로세스에 속한 서비스의 정보를 가지고 SCM 과 통신을 시작한다.

 

3.      해당 서비스를 시작하기 위해 별도의 쓰레드를 생성하고, 서비스 메인 함수를 호출하여 서비스를 시작한다. 이때, 서비스 메인에서는 서비스를 위한 초기화와 핸들러 등록을 한다.

 

4.      서비스는 실행중에 자신의 상태를 SCM에 보고 한다. 그리고 SCM으로 부터 제어 신호가 들어오면 디스패처가 이를 서비스의 핸들러에게 전달해주며, 핸들러가 이 제어 신호를 처리한다.

 

5.      서비스가 종료되면 디스패처는 실행중인 서비스 카운터를 1 감소시키며, 0이면 디스패처도 종료되고 Main 함수로 리턴된다. 즉, 디스패처는 자신이 생성한 모든 서비스가 종료될  때까지 계속 무한 루프에서 대기하며 모든 서비스가 종료될 때 비로소 리턴한다.



뭐 이런 식입니다

그럼 구체적인 구현 방법을 볼까요?

먼저 서비스 프로그램 부터 봅시다

서비스 프로그램은 크게

Main 함수,  서비스 Main ,  핸들러

정도로 나뉩니다

이를 자세히 살펴보면

1. Main 함수
 

상당히 간단하죠? 

Main 함수는  디스패처 스레드를 실행시키는 일만을 맡고 있습니다


2.  서비스 Main

 

실제 서비스 작업을 하는 서비스의 본체입니다

일단, 10초에 한번씩 실행하도록 코드를 짜두었습니다

저~ 기 중앙에 실행시키고자 하는 code를 집어넣으면 되구요



3. 핸들러



제어 프로그램에서 오는 신호를 처리합니다

여기서는 PAUSE, CONTINUE, STOP 의 처리를 해주었습니다



4. 상태제어 함수



현재 상태를 변경하는 역할을 맡고 있습니다







이번엔 서비스 제어 프로그램을 살퍼보겠습니다

서비스 제어 프로그램의 역할은 크게 2가지로 나눌 수 있습니다

설치/삭제와

제어 부분 입니다

2가지 프로그램으로 만들 수도 있겠습니다만,

괜히 여러프로그램을 만드는건 좀 아니죠

먼저 서비스 제어 프로그램의 전체적인 모습입니다



Install / Uninstall 로 서비스를 설치 / 제거 하고

설치가 되었다면 상태 제어를 할 수 있도록 짰습니다


1.Install 버튼



제어 프로그램과 같은 폴더에서 서비스 프로그램을 검색하고 있다면 설치합니다

여기서 EXENAME 은 설치될 서비스 프로그램의 파일명이구요

저기 에러 처리는 권한이 없을 때 보통 뜨더군요

다른 경우라면  define 을 잘못해준 경우겠죠?



2.Uninstall 버튼


서비스를 제거합니다



3.Start 버튼
 


다른 버튼과는 다소 차이가 있는데 구조가 크게 다르진 않습니다


4. 나머지 버튼


간단하네요  각 버튼에 맞는 MemControl 을 호출합니다


5. MemControl



서비스 프로그램에 각 상태를 전달합니다


6.  QueryService



dwCurrentState 를 이용해 서비스 프로그램의 상태를 가져온다음에 이를 제어 프로그램

버튼 활성화/비활성화에 적용합니다


7. Timer



이는 제가 추가해준 부분이긴 한데, 아시다 시피 서비스 프로그램은 설치만 되면

서비스 제어 프로그램 외에도 관리도구에서도 쉽게 제어 할 수 있습니다

제어 프로그램은 서비스 프로그램으로 일방적으로 메시지를 보내서

서비스 프로그램의 상태를 실시간으로 받아올 수 없다는 단점이 있지요

그래서 이러한 Timer 함수를 만들어 두고 주기적으로 QueryService 를 호출해주면

실시간으로 반영이 된다는 것입니다

OnInitDialog 같은 함수에 Timer 를 셋팅해놓으면 되겠죠



8. OnInitDialog



처음에 Dialog 가 실행이 되면서 설치/비 설치 여부를 판단하고

설치 되었으면 기존의 서비스 프로그램의 설명 부분을 가져옵니다




이렇게 대략적인 서비스 프로그램의 설명은 끝났습니다

실험해본 결과  서비스 설치/ 삭제/ 시작 모두 '관리자 계정' 일 때만 올바르게 작동합니다

일단 관리자 계정으로 설치하고 시작하면 '사용자 계정'은 그 서비스에 터치를 못한다는 거죠

또한 windows 7 의 경우는 관리자 계정에서도 '관리자 권한으로 실행' 으로 해주실 때 올바르게 작동 한다는거~

이점 유의하시길 바랍니다 :D

'System' 카테고리의 다른 글

DLL injection on 64 Bit OS  (2) 2010.08.03
Screen Capture with DLL injection  (2) 2010.07.27
서비스 프로그래밍  (3) 2010.04.27
System Information 을 가져오는 API  (2) 2010.04.21
What is VCP[Virtualized Code Protection]?  (0) 2010.01.29
셸 코드 작성  (0) 2010.01.17
Posted by LinkC

2010.04.21 11:49 System

*아래 코드는 제가 수정을 했지만, 인터넷에서 구한 코드를 토대로 하였습니다

함수를 모두 완성하고 나니 출처를 미처 챙기지 못했네요

혹시 , 내가 작성한 코드가 떡하니 올려져 있어 기분이 좀 상했다 하는분은 바로 말씀해주세요 :D





1. Computer Name 가져오기
-  GetComputerName









2. CPU Information 가져오기
 - GetSystemInfo



다만 이 함수는 구체적인 정보를 얻을 수 없더군요

그래서 다른 방법을 찾아봤고 Registry를 이용하는 방법을 찾아냈습니다



- RegOpenKeyEx  -> RegQueryValueEX












3. OS Information

-          GetVersionEx



OS 같은 경우도 좀 까다로운데 ..

각 버전마다 일치하는 OS를 지정해줘야합니다

일단 MS 에서 예제로 제공한 코드입니다

상당히 자세한 정보를 얻을 수 있지만

하위 Windows 에서는 안돌아가는 걸로 확인했습니다

제가 7을 쓰고 있는데 7은 정상작동합니다 :D



좀더 간략한 정보를 얻는 것이 목적이라면 다음과 같이 수정할 수 있습니다[ 2000 이하의 OS는 생각하지 않았습니다 ]


다른 방법으로 레지스트리에서 가져오는 방법도 있습니다 이 방법이 가장 간단하군요


4. Hard Disk Information 가져오기
- GetDiskFreeSpaceEX

하드의 사용용량/ 전체용량을 구합니다








5. IP Information 가져오기
- gethostname -> gethostbyname

IP를  한번에 가져오는 API 없고 다음과 같이 2개의 API를 이용하는 방법이 있습니다








6. Mac Address 가져오기

GetAdaptersInfo

UuidCreate

NetWkstaTransportEnum NETBIOS 이용

Mac Address를 가져오는 방법은 좀 다양한데 대표적인 3가지 방법이 위 3 가지 입니다

그중에서 저는 GetAdaptersInfo를 이용해서 구해보도록 하죠











'System' 카테고리의 다른 글

Screen Capture with DLL injection  (2) 2010.07.27
서비스 프로그래밍  (3) 2010.04.27
System Information 을 가져오는 API  (2) 2010.04.21
What is VCP[Virtualized Code Protection]?  (0) 2010.01.29
셸 코드 작성  (0) 2010.01.17
2008 JFF 8번 문제 풀이  (0) 2010.01.10
Posted by LinkC

2010.01.29 10:29 System


리버싱 문제를 풀던 도중

일명 VM 문제를 만났다


메모리 구조를 살펴보면

dll3 에 VM 평소에 보던 영역외에 VM 영역이 잡혀있는걸 볼 수 있었는데

개념정리가 안돼 손도 댈 수 없었다

먼저 VCP에 대해 짚고 넘어가자

VCP는 안티 크랙의 기술로 , VM 만이 해석할 수 있는 가상화된 코드 영역으로

주요 코드 영역을 변환하는 기법이다

마침 이에 대한 기술 문서가

Beist Lab에 올라와있으니 참고하자

http://beist.org/research/public/yong/vcp.pdf

아직 문서를 이해하고 문제를 풀 수준이 아닌데

잊어버릴까봐 일단 포스팅!


'System' 카테고리의 다른 글

서비스 프로그래밍  (3) 2010.04.27
System Information 을 가져오는 API  (2) 2010.04.21
What is VCP[Virtualized Code Protection]?  (0) 2010.01.29
셸 코드 작성  (0) 2010.01.17
2008 JFF 8번 문제 풀이  (0) 2010.01.10
[펌]교착 상태와 그 조건  (0) 2010.01.02
Posted by LinkC

2010.01.17 14:04 System


Exploit 을 하기 위해 반드시 필요한 셸 코드 작성법

한참 BOF나 FSB 공부할때 익혔던 방법들이 슬슬 가물가물해 지는 타이밍이라

기억도 되살릴겸 포스팅 하기로 했다

셸 코드에는 Null byte가 들어가서는 안되고 작으면 작을 수록 그 가치는 상승한다

물론 최신 셸 코드 작성법에는 아직 손을 못댔지만

일단 내가 할 수 있는 범위까지 줄여보도록 하겠다

먼저  우리가 이용할 함수들을 파악하자

1. setreuid ( uid_t ruid, uid_t euid)
2. execve ( const char *filenam, char *const argv[] , char *const envp[])

이대로 각각 인자들을 삽입해주고 시스템 콜을 실행하면 된다

완성된 코드를 먼저 보자



3~7 번째 줄은 : setreuid 를 호출하는 부분이다

3번째에서 eax를 초기화 해주고

setreuid의 시스템 콜 번호 70을 al에 넣어준다

그 후에 나머지 ruid, euid 를 0으로 넣어주고 시스템 콜을 호출 하면 끝


다음은 execve 함수를 호출하는 부분인데

setreuid 보다는 살짝 복잡하다

인자 하나씩 살펴보자

먼저 실행된 후의 stack 구조를 살펴보면 다음과 같다


 0  push ecx
 \x68732f2f ;"/sh"  push 0x68732f2f
 \x6e69622f ;"/bin"  push 0x6e69622f 
 mov ebx, esp
 0  push eax
 /bin//sh 문자열 주소  push ebx
 mov ecx, esp


여기서 ebx 는 3번째 mov ebx, esp 에 의해

/bin//sh의 문자열 주소를 가지고 있고

ecx 는 mov ecx, esp 에 의해 /bin//sh 와 0 을 배열로 갖는 포인터의 주소를 갖게 된다

edx는 0으로 초기화 해주고

execve의 시스템 콜 번호인 11번을 넣고

시스템 콜을 호출하면 끝이다

여기에서 좀 더 크기를 줄일 수 있는 방법이 있는데

xor eax, eax
mov al, 70


push byte 70
pop eax

로 바꾸고

xor edx, edx

cdq

로 바꾸는 것이다.

첫번째 기법은 stack 이 4바이트 단위로 이루어져있으며 한byte만 넣을경우

나머지 3byte가 0으로 채워지는 것을 이용한 것이다

두번째는 cdq가 eax가 0 이상이면 edx는 1로 채워지고 eax가 0 이상이면

edx가 0으로 채워지는 것을 이용한 것이다

이를 이용해서 최종적으로 쉘 코드를 구해보면


다음과 같이 31바이트로 쉘코드를 완성한것을 볼 수 있다.




참조: 해킹, 공격의 예술

'System' 카테고리의 다른 글

System Information 을 가져오는 API  (2) 2010.04.21
What is VCP[Virtualized Code Protection]?  (0) 2010.01.29
셸 코드 작성  (0) 2010.01.17
2008 JFF 8번 문제 풀이  (0) 2010.01.10
[펌]교착 상태와 그 조건  (0) 2010.01.02
What is CALLBACK function?  (0) 2010.01.01
Posted by LinkC
이전버튼 1 2 3 이전버튼

블로그 이미지
LinkC

태그목록

Tistory Cumulus Flash tag cloud by BLUEnLIVE requires Flash Player 9 or better.

공지사항

Yesterday30
Today7
Total328,679

달력

 « |  » 2019.5
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

최근에 받은 트랙백

글 보관함


. .