XeroNic(HS) BLOG

새 블로그에서 새롭게...

XeroNic(HS) — Sun, 31 Jan 2016 23:00:24 +0900

블로깅을 다시 시작해볼까 합니다~ @_@;;;

http://www.xeronichs.com

티스토리는 기존 게시물들도 있고 하니 계속 유지해두는 걸로~ :)

PC Hunter V1.4 업데이트

XeroNic(HS) — Sun, 25 Oct 2015 01:56:42 +0900

10월 18일자로 PC Hunter V1.4 버전이 업데이트 되었습니다.

[ PC Hunter 홈페이지 : http://www.epoolsoft.com, http://www.xuetr.com ]

PCHunter_free.zip

Visual Studio Community 2013 공개

XeroNic(HS) — Fri, 14 Nov 2014 15:22:01 +0900

MS 에서 Visual Studio 2013 Professional 와 동급(?)의 패키지를...

무료로 공개했네요... @_@;;;

개인개발자의 경우 개발하는 제품이 유/무료 상관없이 사용 가능하군요..

( 물론... 대기업 등에선 사용불가..;;; )

[ 사이트 : http://www.visualstudio.com/en-us/products/visual-studio-community-vs ]

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

Q: Who can use Visual Studio Community?
A: Here’s how individual developers can use Visual Studio Community:

Any individual developer can use Visual Studio Community to create their own free or paid apps.

Here’s how Visual Studio Community can be used in organizations:

An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
For all other usage scenarios: In non-enterprise organizations, up to 5 users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or > $1MM in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.

Q: How does Visual Studio Community 2013 compare to other Visual Studio editions?
A: Visual Studio Community 2013 includes all the great functionality of Visual Studio Professional 2013, designed and optimized for individual developers, students, open source contributors, and small teams.

Q: How do I create a Visual Studio extension?
A: Millions of developers use Visual Studio extensions every day. Check out http://integrate.visualstudio.com for more information on building on any of the Visual Studio development tools and services.

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

PC Hunter V1.35 업데이트

XeroNic(HS) — Thu, 23 Oct 2014 11:17:44 +0900

10월 22일자로 PC Hunter V1.35 버전이 업데이트 되었습니다.

[ PC Hunter 홈페이지 : http://www.epoolsoft.com, http://www.xuetr.com ]

PCHunter_free.zip

PC Hunter V1.331 업데이트

XeroNic(HS) — Tue, 8 Jul 2014 23:11:28 +0900

7월 8일자로 PC Hunter V1.331 버전이 업데이트 되었습니다.

[ PC Hunter 홈페이지 : http://www.epoolsoft.com, http://www.xuetr.com ]

PCHunter_free.zip

PC Hunter V1.33 업데이트

XeroNic(HS) — Thu, 3 Jul 2014 17:32:10 +0900

7월 2일자로 PC Hunter V1.33 버전이 업데이트 되었습니다.

[ PC Hunter 홈페이지 : http://www.epoolsoft.com, http://www.xuetr.com ]

PCHunter_free.zip

마이크로소프트, MS-DOS & Word 초기버전 소스코드 공개

XeroNic(HS) — Wed, 26 Mar 2014 11:22:11 +0900

MS 가 DOS 와 Word 의 초창기 버전 소스코드를 CHM(Computer History Museum)에 기증했다는군요.. @_@

공개된 버전은 DOS v1.1 과 v2.0... 워드는 윈도우용 v1.1a 군요...ㅎ

[ CHM 링크 ]

MS-DOS : http://www.computerhistory.org/_static/atchm/microsoft-ms-dos-early-source-code/

MS-WORD : http://www.computerhistory.org/_static/atchm/microsoft-word-for-windows-1-1a-source-code/

시간날 때~ 슬쩍 구경한번 해봐야겠습니다..ㅎㅎㅎ :)

dotPeek - Free .NET Decompiler and Assembly Browser

XeroNic(HS) — Sun, 9 Mar 2014 12:39:34 +0900

해킹툴 분석 작업을 하다보면 한번씩 C# 으로 빌드된 바이너리를 보게되는 경우가 있습니다.

C# 으로 빌드된 녀석들은 C/C++ 로 빌드된 바이너리와는 코드 구성이 다른데요..

C/C++ 로 빌드된 바이너리는 Native Code 로 구성되지만~~

C# 으로 빌드된 바이너리는 Managed Code 로 구성이 되기 때문이라고 할 수 있겠죠.. ^^;;

제가 해킹툴을 분석할 때 가장 많이 쓰는 도구가 OllyDBG 인데...

OllyDBG 는 Native Code 전용이라 이 툴로는 C# 으로 빌드된 바이너리를 분석하기가 어렵습니다..

그래서 필요한게 Managed Code 를 지원하는 분석도구인데요...

그 중 가장(?) 유명한게 .NET Reflector 가 아닐까 생각됩니다...

지금은 유료가 됐지만 무료버전일 때 C# 바이너리 분석용으로 자주 썼던 툴이기도 하구요..

회사에서는 유료버전을 함부로 쓸 수가 없기에..

이것저것 뒤지다보니 무료버전 .NET Decompiler 가 있더군요.. @_@

바로 dotPeek [ http://www.jetbrains.com/decompiler/ ] 이라는 툴입니다...ㅎ

써본 바로는 코드 난독화를 심어놨거나... 바이너리를 패킹을 했다거나...

요런 특수한 경우가 아니면 왠만해서는 Decompile 을 훌륭하게 수행해주더군요.. @_@

무료버전 .NET Decompiler 를 찾으시는 분께 살포시 dotPeek 을 추천합니다..

KT, 1200만 고객정보 유출

XeroNic(HS) — Thu, 6 Mar 2014 15:27:38 +0900

KT 도 해킹으로 1200만명 고객정보가 유출됐다는군요..;;;;

1600만 중에 1200만이면 대부분이라고 보아도 될듯한...;;;

큰 이슈들이 연이어 터지네요..ㅜㅜ..

[YTN] [속보] KT 해킹... 1200만명 개인정보 유출

[경향신문] [속보] KT 홈페이지 해킹 1200만명 개인정보 유출

[머니투데이] 1200만명 해킹당한 KT, "경위-피해규모 파악 중"

Syntax Highlighter 3.0.83 적용 완료 !!!

XeroNic(HS) — Thu, 20 Feb 2014 23:59:37 +0900

사실 예~~~전에 처음 Syntax Highlighter 적용할 떄~

그 당시 최신 버전을 적용하려고 했는데...

제 블로그에서만 이~~상한 형태로 코드가 출력이 되는걸 보고...

최신 버전을 버리고 구버전(2.0.320)을 설치를 했습니다.

토큰별로 개행되는 신기한 현상

그러다가 오늘 문득...=_=;; 다시 생각이 나서 시도를 했고...

결국은 성공했습니다~!!!

블로그의 skin.html, style.css 파일을 PC 로 가져와서~~

직접 하나하나 테스트를 해봤더니 유독 <div class= "article"> ~ </div> 안에서만 문제가 생기고...

다른 곳에서는 정상적으로 출력이 되더군요..

이게 원하는 출력!!!

꽤 오래전 일입니다...

Syntax Highlighter 적용하기 전에 VI 에서 코드를 HTML 로 변환해주는 툴을 써서~

코드를 올린 적이 있는데 그 당시 css 에 추가한 코드때문에 문제가 발생하더군요..

문제의 코드... oTL;;;

저 코드를 제거한 후 3.0.83 버전으로도 정상적으로 출력이 될 때의 그 희열이란~!!!

결국 위의 코드를 제거하고 예전에 소스코드를 올렸던 글들 하나하나 들어가서~~

<code> ~ </code> 로 감쌌던 부분에 Syntax Highlighter 를 적용시키는 삽질을 조금 전에 완료했습니다.. =_=v...

( 물론 오래된 글 중 귀찮아서 안한것도..;;; )

ps...

페이스북 / 트위터 연동시켜둔 바람에 예전 글들이 주르륵 공유된 걸 보고...

다시 하나하나 삭제했다는게 함정...

[TIP] Sublime Text 3 - Visual C++ 빌드 환경 설정

XeroNic(HS) — Sun, 16 Feb 2014 20:11:48 +0900

Sublime Text 3

예전에 우연한 계기로 Sublime Text(http://www.sublimetext.com)라는 에디터를 알게 됐고~

공식 홈페이지 첫화면에 나오는 대표기능(?) 영상을 보고 감동을 받은 후로~~

지금까지 계속 사용하고 있습니다 ㅎㅎㅎ ~ :))

보란듯이 등록 유저 인증 -_-v

Sublime Text 3 를 처음 설치하면 기본적으로 C++ 에 대해서는 gcc/g++ 을 컴파일러로 인식하도록 되어있습니다.

운영체제가 리눅스거나 윈도우라도 MinGW (or Cygwin) 가 설치된 상태라면 상관없겠지만...

Visual C++ 만 설치된 환경이라면 조금 답답하죠~ :((

그래서 Visual C++ 사용자들 입맛(?)에 맞게 빌드 환경을 설정하는 과정을 정리해봤습니다.

Sublie Text 3 가 설치된 폴더를 보시면 "Packages" 라는 폴더가 있고...

그 폴더 안에 '.sublime-package' 확장자를 가진 파일들이 많이 있는데,

이 파일들이 Sublie Text 3 에서 제공하는 기본 설정 파일들입니다.

Sublime Text 3 가 설치된 경로의 "Packages" 폴더

파일들 중 '[언어].sublime-package' 파일들이 각 언어에 대한 기본 설정 파일입니다.

이 파일들은 ZIP 포맷으로 압축이 되어있으며~ ZIP 포맷을 지원하는 압축 관련 유틸로 풀 수 있습니다.

우리가 설정하려고 하는 언어는 'C++' 이니 'C++.sublime-package' 압축을 풀어봅시다~

"C++.sublime-package" 파일 안에 들어있는 내용들

위에 보이는 'C++.sublime-build' 파일이 빌드 환경에 대한 설정 파일입니다. :)

JSON 형식이라 일반 텍스트 에디터로도 편집이 가능한데요~

저 파일을 열어보면 기본적으로는 아래와 같이 되어있을 겁니다.

'C++.sublime-build' 파일의 내용

g++ 이 설정되어있는 게 보이시죠...??

여기서 g++ 로 빌드 명령을 조합하는 부분들을 Visual C++ 에 맞게 고쳐주면~

Visual C++ 를 기본 컴파일러로 사용할 수 있습니다.

참고로 저는 아래와 같이 설정을 해두었습니다.

Visual C++ 용 빌드 환경 설정

{
	"cmd":
	[
		"C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\bin\\vcvars32.bat",
		"&&",
		"cl.exe", "/EHsc", "/O2", "/GS", "/Fm", "${file}"
	],
	"file_regex": "^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$",
	"working_dir": "${file_path}",
	"selector": "source.c, source.c++",
	"encoding": "cp949",

	"variants":
	[
		{
			"name": "Run",
			"cmd":
			[
				"C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\bin\\vcvars32.bat",
				"&&",
				"cl.exe", "/EHsc", "/O2", "/GS", "/Fm", "${file}",
				"&&",
				"${file_path}/${file_base_name}.exe"
			],
		},
		{
			"name": "Build_Dll",
			"cmd":
			[
				"C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\VC\\bin\\vcvars32.bat",
				"&&",
				"cl.exe", "/EHsc", "/O2", "/GS", "/Fm", "/LD", "${file}",
			],
		},
		{
			"name": "Build_sys",
			"cmd":
			[
				"C:\\Windows\\System32\\cmd.exe", "/k",
				"C:\\WinDDK\\7600.16385.1\\bin\\setenv.bat", "C:\\WinDDK\\7600.16385.1\\", "fre", "x86", "WNET",
				"&&",
				"DDKBUILD.cmd", "-WNETXP", "fre", "${file_path}", "-cZ",
			],
		}
	]
}

'C++.sublime-build' 파일을 자신에 맞게 수정했으면~

다시 원래대로 다른 파일들과 함께~ 'C++.sublime-package' 라는 이름으로 ZIP 포맷으로 압축을 하고

"Packages" 폴더에 넣어주시면 됩니다.

( 혹시라도 잘못 수정할 경우를 대비해 원래 파일은 백업해 두시는걸 권장합니다. ㅎㅎ )

위와 같은 일련의 과정들이 끝나면 C++ 에 대해서 Visual C++ 컴파일러가 동작하는 것을 볼 수 있습니다. :))

( 개인적으로는 Sublime Text 에 손이 익숙해지니 Visual C++ IDE 에서 작업하는게 엄청 답답하더군요;;;.. )

보너스로... 빌드를 조금 더 쉽게(?)하기 위한 단축키 설정입니다.

( 'Preferences -> Key Binding - User' 에서 설정할 수 있습니다. )

단축키 설정

[
	// Alignment
	{ "keys": ["ctrl+alt+a"], "command": "alignment" },

	// Build
	{ "keys": ["f5"], "command": "build" },
	{ "keys": ["ctrl+f5"], "command": "build", "args": {"variant": "Run"} },	
	{ "keys": ["ctrl+b", "ctrl+b"], "command": "build" },
	{ "keys": ["ctrl+b", "ctrl+d"], "command": "build", "args": {"variant": "Build_Dll"} },	
	{ "keys": ["ctrl+b", "ctrl+s"], "command": "build", "args": {"variant": "Build_sys"} },	
]

[ Sublime 기능 관련 영상 ]

윈도우 시스템 모듈(kernel32.dll)을 복사해서 로딩할 경우 주의점

XeroNic(HS) — Sat, 15 Feb 2014 13:22:02 +0900

일부 보안 모듈의 경우 윈도우 API 를 조금 더 안전한(?) 채널을 통해 사용하기 위해...

필요한 모듈을 다른 이름으로 복사 후 로딩하는 경우가 있습니다.

여기선 kernel32.dll 을 복사해서 로딩할 때 조심해야 될 부분을 가볍게(?) 살펴보고자 합니다.

kernel32.dll 이 로딩될 때 ntdll.dll 모듈의 데이터 영역에 영향을 미치는 부분을 확인했는데요...

다음과 같은 부분들이 영향을 받더군요.

일반적인 상태의 ntdll.dll 의 데이터 영역

프로세스를 실행하면 보통~ ntdll.dll 의 데이터 영역은 위와 같이 kernel32.dll 의 함수를 가리킵니다.

이후 kernel32.dll 을 복사해서 로딩하면...

새로운 kernel32.dll 로딩 후 ntdll.dll 의 데이터 영역

붉은 박스 표시한 부분의 데이터가 바뀌면서 새로 로딩한 kernel32.dll 의 함수를 가리키더군요...

호기심에 kernel32.dll 의 코드를 살짝 봤습니다.

실행의 시작은 EntryPoint ...

kernel32.dll 의 초기화 코드의 일부

kernel32.dll 의 초기화 코드 중 위와 같은 부분이 있더군요... @_@

자기자신의 함수 주소를 RtlSetThreadPoolStartFunc, LdrSetDllManifestProber 등을 이용해...

설정을 하는 부분인데요..

호출되는 함수의 코드는 다음과 같습니다.

RtlSetThreadPoolStartFunc, LdrSetDllManifestProber

RtlSetThreadPoolStartFunc 와 LdrSetDllManifestProber 는 ntdll.dll 의 함수이구요...

ntdll.dll 의 특정 영역에 인자로 전달받은 함수 주소를 쓰는 것을 알 수 있습니다.

( RtlpStartThreadFunc, RtlpExitThreadFunc, LdrpManifestProberRoutine, LdrpCreateActCtxLanguageW )

즉... kernel32.dll 을 복사해서 로딩을 하면 개발자의 의도(?)와는 전혀 상관없이...

ntdll.dll 의 일부 데이터가 복사본을 가리키도록 되어있고...

그 순간부터 시스템 내부적으로 동작하는 일부 코드들은 복사본에 대한 의존성이 생기게 됩니다.

나만 사용해야지(?) 하고 로딩한 모듈인데... 실제로는 그게 아닌거죠...;;;

개발자가 인지하기 힘든 백그라운드에서 알게 모르게 복사본 코드가 실행이 될 수 있다는 거...

요런 상황에서 복사본을 Free 시켜버리면 문제가 발생합니다.

복사본이 로딩될 때 변경한 ntdll.dll 의 데이터들은 여전히 복사본을 가리키고 있거든요...

복사본이 Free 된 후에 해당 데이터들을 호출하려는 코드에서는 Access Violation 이 발생하는거죠.. @_@

일단 kernel32.dll 복사본을 로딩했으면...

이 녀석은 프로세스 종료될 때 알아서 증발하도록 내버려두는게 상책입니다... @_@ ;;

ps...

꼭 kernel32.dll 모듈이 아니더라도 시스템 모듈의 경우 비슷한 문제가 발생할 수 있습니다.

Oreans UnVirtualizer v1.8 (OllyDbg Plugin) 업데이트

XeroNic(HS) — Sat, 15 Feb 2014 12:11:32 +0900

얼마 전 OllyDbg 플러그인 Oreans UnVirtualizer v1.8 이 업데이트 되었네요.. @_@

Themida 를 입은 해킹툴을 분석할 때 가장 난감한게 VM 인데~~

이 플러그인은 Themida VM 을 벗겨주죠~ (*-_-*)

물론 경우에 따라서 이 플러그인으로도 불가능한 경우가 다소 있긴 하지만...

이게 있고 없고의 차이는 꽤 크더라구요..ㅎㅎ @_@

v1.8 에는 다음과 같은 부분이 변경되었습니다...

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

[v1.8]

- FISH BLACK variant avaible

- Fixed deofuscation order (GenV6)

- New deofucation scheme for FISH machine

- New smart code tracer for FISH machines

- Stack sort for FISH commands

- Improved management of memory (faster deofuscation)

- Added movzx reg32, [esp+eax+memoffset] on CISC machines

- Added a message prompt when the opcode buffer is not enough

- Added LEAVE instruction for FISH machines

- Added support for CALLs to VM section in FISH machines

- CHECK_PROTECTION macro disabled, now it must be restored by hand

- Fixed QWORD incorrect names for some opcodes

- Fixed a problem when deofuscating RISC machines

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

Oreans UnVirtualizer 만세~!!

Oreans UnVirtualizer v1.8.rar

출처 : Tuts 4 You (http://www.tuts4you.com)

Themida VM 매크로 사용시 주의점

XeroNic(HS) — Sat, 8 Feb 2014 00:41:49 +0900

실행 파일 바이너리를 보호하기 위한 솔루션 Themida [ http://www.oreans.com ]

Themida 의 기능 중 가장 강력한 보안 기능을 꼽으라면 VM(Virtual Machine) 을 꼽을 수 있는데요.. :)

이 기능은 프로그램 개발시 보호하고 싶은 소스코드를 VM 매크로로 감싸두면

Themida 로 패킹된 파일을 실행할 때 VM 매크로로 감싼 코드 부분이...

Themida 가 제공하는 가상의 CPU 머신을 통해서 실행이 됩니다.

Themida 에서 제공하는 Virtual Machine

VM 으로 실행되는 코드의 경우 우리가 흔히 인지하는 Intel CPU 명령과는 달라서...

실행되는 과정을 분석하기가 매우 까다롭습니다.

( 실제 소스코드 상에서 입력한 코드에 대한 디버깅이 거의 불가능합니다.. ^^;;; )

이런 강력함으로 인해 강력한 보안이 필요한 코드에 대해서 VM 을 적용하는 경우가 있는데요...

VM 을 적용할 때 몇가지 주의해야 할 점을 분석해볼까 합니다.

우선 먼저 Themida Help 문서를 보면 다음과 같이 주의점에 대해 안내가 되어있습니다. :))

Themida VM 사용 시 주의점

#1. for, while, do ... 등의 반복 루프를 피하라.

VM 이라는 기능 자체가 소프트웨어적으로 구현된 가상의 CPU 를 통해

가상의 CPU 가 해석할 수 있는 명령어를 실행하는 방식인데...

이런 방식 자체가 실제 물리 CPU 상에서 코드를 실행하는 것보다는 퍼포먼스가 떨어집니다.

( 조금 더 자세한 내용은 Ezbeat 님 블로그 - "Themida 2.1.2.0 Virtual Machine" 참고... )

MOV EAX, 1

위와 같은 코드의 경우 실제 CPU 로는 한 스텝(Intel CPU 어셈블리 명령 처리 기준)이면 실행이 가능하지만...

동일한 코드를 Themida VM 으로 실행하면 실제 CPU 기준에서는 수십에서 수백 스텝이 걸릴 수도 있습니다.

단일 코드만 해도 이렇기 때문에 수없이 반복하는 코드를 VM 안에서 실행시키면...

그 만큼 퍼포먼스가 저하됩니다..

for 루프 반복 수에 따른 Performance

#2. VM 매크로 내부에서 switch 구문이 동작하지 않을 수 있다.

우선 간단한(?) switch 구문을 살펴봅시다~ :)

VM_START
	switch (nNumber)
	{
	case 1:
		printf("Number 1\n\r");
		break;

	case 2:
		printf("Number 2\n\r");
		break;

	case 3:
		printf("Number 3\n\r");
		break;

	case 4:
		printf("Number 4\n\r");
		break;

	case 5:
		printf("Number 5\n\r");
		break;

	default:
		printf("Other...\n\r");		

	}
VM_END

위의 코드가 컴파일되면 다음과 같은 어셈블리 코드로 변환이 됩니다.

switch 구문에서 각각의 case 구문을 실행하는 방식은 주소 테이블을 참조한 JMP 입니다.

0x85108C 위치 각 case 구문에서 실행될 코드의 주소가 저장되어 있습니다.

;------------------------------------------------------

0x85108C : case 1: 일 때 참조됨 -> 0x851047

0x851090 : case 2: 일 때 참조됨 -> 0x85104E

0x851094 : case 3: 일 때 참조됨 -> 0x851055

0x851098 : case 4: 일 때 참조됨 -> 0x85105C

0x85109C : case 5: 일 때 참조됨 -> 0x851063

;------------------------------------------------------

이 코드에 VM 이 적용되면 VM_START 가 마크된 0x851025 부분이 VM 을 호출하는 코드로 변경되고..

그 이후부터 VM_END 가 끝나는 0x851089 앞부분 까지의 코드가 변합니다..

여기서 문제가 발생하는데요...

바로 위의 캡쳐를 보면 아시겠지만... switch 구문 실행 시 참고하는 테이블은...

그 위치 그대로... 같은 내용물(case 구문에서 실행될 코드의 원래 주소)이 담겨져 있는 것을 알 수 있습니다.

( 윈도우의 ASLR 으로 인해 이미지 베이스가 변경되긴 했지만 오프셋은 동일합니다. )

VM 매크로 안의 코드는 패킹하는 과정에서 코드가 달라졌지만...

switch 구문에서 참조하는 테이블은 변경되기 전의 코드 주소를 가지고 있고...

case 구문이 실행될 때 해당 주소를 가보면... @_@ ;;; 정상적인 코드가 아니기 때문에 크래쉬가 발생합니다..

VM 매크로 영역 안에 있는 switch 구문이 컴파일될 때,

위와 같이 매크로 영역 밖의 테이블을 참조해서 case 구문을 실행하는 형태가 될 경우는...

100% 문제가 발생합니다...

참고로 ... 간혹 switch 내부의 case 수가 적은 경우는...

참조 테이블을 생성하지 않고 단순 조건비교( if 구문처럼 )로 처리되기도 하는데...

이런 경우는 VM 매크로가 적용된다고 해도 문제가 없습니다.. ^^;;;

안전성을 위해서는 왠만하면 VM 매크로 내부에 switch 구문을 사용하지 않는 것이 좋겠죠...

#3. 예외처리가 제대로 동작하지 않는다. try - except 를 VM 매크로로 감싸는 것을 피하라.

따지고 보면 #2 와 같은 이유에서 발생하는 문제입니다.

VM 매크로 밖의 코드에서 VM 매크로 안쪽의 코드에 접근하려다가 문제가 발생하는 거죠..

VM_START

	__try {
		int nResult = nNumber / 0;
		printf("nNumber= %d, nResult : %d\n\r", nNumber, nResult);
	}
	__except(EXCEPTION_EXECUTE_HANDLER) {
		printf("Exception !!! \n\r");
	}

VM_END

일반적으로 예외처리기 등록은 함수 시작 극초반부에서 이루어 집니다..

소스코드 상에서는 함수내에서 VM 매크로를 아무리 끌어올려도... ( 함수 여는 괄호 '{' 바로 밑에 둬도.. )

예외처리기 등록부는 항상 그보다 더 위에 있습니다... :(

예외처리기 등록은 함수 시작부분부터 0xA5102A 까지해서 이루어지고..

예외처리기 주소는 0xA51220, 예외처리기가 참고하는 scopetable 은0xA5BA30 으로..

둘 다 VM 매크로 영역 밖입니다.

scopetable 에는 예외처리에 대한 Filter 함수(?), Handler 함수(?)의 주소가 담겨져 있습니다.

( 조금 더 자세한 내용은 Ezbea t 님 블로그 - "Visual C++ SEH Filter, Handler 루틴" 참고... )

코드가 실행되다가 예외가 발생할 경우 예외처리기에서는 scopetable 을 참고하여...

Filter 함수 및 Handler 함수를 호출하게 되는데, 이 때 #2 와 마찬가지로 문제가 발생합니다.

scopetable 에 담겨져있는 Filter 함수 및 Handler 함수 주소는 패킹하기 전 그대로인데...

패킹 후에는 해당 주소부분이 다른 코드로 바뀌어 버린거죠.. @_@ ;;;;

개발 중인 제품에 Themida VM 매크로 적용하려는데...

뭔가 계속 문제가 발생한다... 싶으면 위와 같은 요소들을 살펴보시기 바랍니다..ㅎ

[Python] pefile-1.2.10-139 ( for Python3 )

XeroNic(HS) — Sat, 1 Feb 2014 02:31:14 +0900

요 얼마간 파이썬 2.7 버전으로 계속 작업했는데...

문득....!!!!!

그래도 최신 버전이 낫지 않을까...?

하는 생각이 들어서...

파이썬 3.3 을 설치하고 이것저것 건드려 봤습니다...;;;

2.7 ===> 3.3 으로 버전업되면서 바뀐 변화를 처음 접한 느낌은 대략 멘.붕...;;;;

바뀐 문법으로 인해 라이브러리 설치 단계부터 에러가 나기 시작하는데..;;;

생각보다 난감하더군요.. @_@;;;

제가 개인적으로 파이썬에 대한 강력함을 느낀 첫번째 이유가 라이브러리로 인한~

작업 효율 향상이었는데..;; 라이브러리 설치부터 막혀버리니..;;

( 업무 특성상 pefile, pydasm 뭐 요런 것들을 사용하는지라..;; )

한차례 좌절감을 맛본 후...

인터넷으로 파이썬3 에 대한 이런저런(?) 정보들을 먼저 수집했습니다..

print 는 함수처럼 '(', ')' 로 감싸줘야한다.
예외처리부에서는 'exception, e' -> 'exception as e' .
문자열은 기본적으로 '유니코드' 이다.
(int) / (int) 는 (float) ... (int) // (int) = (int)
일부 내장 함수들 및 자료형이 사라지고 추가되었다...
기타 등등..

뭐... 생각보다 많은 변화(?)가 있더군요..

달라진 내용을 기반으로 기존의 2.x 코드를 포팅하는 방법에 대한 글들을 읽어보면서~

' pefile ' 을 대상으로 하나하나 적용시켜봤습니다.. :))

[ pefile - project home ]

일단 결과는 나름 성공(!?)인듯해서... 살포시 블로그에 올려봅니다. ^^;;;

하지만 모든 부분을 테스트 해보지는 못했기에 중간중간 문제가 발생할 수도 있을 것 같네요...;;;

그런 버그들은 추후... 발견이 되면 수정을 하는 방향으로..^^;;;;

[ pefile_py3 GitHub - https://github.com/BlackXeronic/pefile_py3 ]

ps... 포팅작업 은근 토나오네요...;;;

pefile_py3-master.zip

[TIP] Visual Studio 2010 으로 파이썬 2.7.x 모듈 빌드하기

XeroNic(HS) — Sat, 18 Jan 2014 02:59:43 +0900

파이썬 2.7 에서 디스어셈블러 모듈을 써보고 싶어서~

파이썬 전반적인 활용능력도 익힐겸(?) "libdasm" [ libdasm 사이트 ] 라이브러리 가져와

직접 "PyDasm" 모듈을 빌드하기로 결정했습니다.

그런데 이게 왠걸...? "vcvarsall.bat" 파일을 찾을 수 없다는 에러를 뱉으며 빌드가 되지 않더군요;;;

처음 시도시 PyDasm 빌드 실패

구글링을 하며 이런저런 정보를 뒤지다 보니~

Python 2.7 버전대는 Visual Studio 2008 을 기준으로 되어있다는 그런 글들이 많이 보이더군요..;;

제 PC 에는 Visual Studio 2010, Visual Studio 2013 Express ... 이렇게 설치가 되어있는데 말이죠;;;

근데 아무리 생각해도 저 에러는 "vcvarsall.bat" 파일만 제대로 찾으면 왠지 될거 같다는 생각에~

파이썬의 "Disutils" 라이브러리에서 "vcvarsall.bat" 를 찾는 부분을 뒤져봤습니다.

이것저것 뒤지다보니 MS Visual C++ 컴파일러 계열에 대해서 처리하는 방식이 눈에 들어오더군요.. @_@;;

C 컴파일러에 대한 기본 설정

"msvc" 의 경우는 "msvccompiler" 모듈의 "MSVCCompiler" 클래스를 사용하더군요~ :)

msvccompiler 모듈을 열어봤더니... 맨 마지막에 아래와 같은 내용이 있더군요.. @_@ ;;;

msvccompiler.py

get_build_version() 을 해서 8.0 이상이면 "msvc9compiler" 모듈의 "MSVCCompiler" 을 IMPORT~!!

get_build_version() 은 뭘까요..?? @_@ ;;

get_build_version()

코드 자체는 어려운 코드가 아닙니다.

저 코드 결과가 어떻게 되는지 파이썬 콘솔로 테스트 해볼까요..? :)

파이썬 콘솔 테스트

간단히 설명하면 sys.version 내에서 "MSC v." 문자열을 기준으로 그 뒤의 문자열을 찾아서~

majorVersion, minorVersion 을 계산하는 코드입니다.

( 특이한 점은 majorVersion 을 구할 때 15 에 6 을 빼서~ 9 를 구하는 점이랄까요..; )

다시 돌아가서 어쨌든 결과는 9.0 으로 8.0 보다 크기때문에~

"msvc9compiler" 모듈의 "MSVCCompiler" 클래스를 사용합니다.

"msvc9compiler" 모듈엔 대략 다음과 같은 코드들이 있습니다.

참조할 레지스트리 정보

vcvarsall.bat 경로 설정

드디어 "vcvarsall.bat" 파일 경로를 설정하는 부분을 찾았습니다.

Visual Studio 설치시 생성되는 레지스트리 정보를 읽어와서 경로를 지정하는군요~

[ 키포인트 ]

코드를 보면 아시겠지만 "version" 값에 따라 레지스트리 접근 경로가 달라지는데요...

이 "version" 값은 앞서 언급한 get_build_version() 으로 리턴되는 값을 말합니다.

"msvc9compiler" 모듈에도 get_build_version() 이 있는데~

여기서 majorVersion 연산하는 부분을 살짝 고쳐서 10.0 이 리턴되도록 하면~

Visual Studio 2010 의 레지스트리를 정상적으로 참고하면서 모듈 빌드도 정상적으로 됩니다~ :)

msvc9compiler.py 의 get_build_version()

Visual Studio 2012 나 2013 의 경우도 동일한 방식으로 majorVersion 부분을 고쳐서~

11.0, 12.0 이 리턴되도록 하면 해당 버전에 맞게 잘 된답니다... ^^;;;

마무리는 일단 기분좋게 빌드는 완료된 화면으로~ :))

majorVersion 수정 후 빌드 성공한 화면

ps... 환경변수만 살짝 건드려서 더 간단히 해결할수 있을지도 모른다는건 함정... =_=;;;;

YARA 2.0 이 나왔었군요.

XeroNic(HS) — Thu, 16 Jan 2014 21:42:23 +0900

예전에~ 게임 프로세스 메모리 스캔 엔진을 조금 바꿔볼까 싶어서...

이것저것 정보를 모으던 중 알게된 녀석입니다.

그 당시 룰을 직접 만들면서 "오호... 요놈봐라..!?" 하면서 감탄했던 녀석인데..

얼마 전(2013년 12월 26일)에 2.0 이 나왔네요.. @_@ ;;;

매칭 알고리즘이 더 빨라졌다고 하는데... 살포시 소스 한번 봐줘야겠네요..ㅎㅎ

[ YARA 사이트 ] - http://plusvic.github.io/yara/

[C/C++] Vista 이상의 윈도우 "관리자 권한" 에서 Drag & Drop 처리

XeroNic(HS) — Sun, 12 Jan 2014 23:37:27 +0900

예~~~전에 지극히 개인적인 편의를 위해 만든 인젝터가 하나 있습니다. ㅎㅎㅎ

이름도 거창한(?) "건담 인젝터" ;;;

2011/07/31 - [My Portfolio] - [APP] GInjector (Gundam Injector)

이 당시 가장 신경을 썼던 기능이 "Drag & Drop" 인데요~~

( 기존의 다른 인젝터들을 쓸 때 매번 버튼을 눌러서 인젝션 할 대상파일을 지정하는게 귀찮아져서~

Drag & Drop 을 지원하는 걸 그냥 만들자~~ 해서 뚝딱뚝딱 만든거랄까요.. ^^;;;; )

이때만해도 주로 인젝션 작업을 한 OS 가 XP 였기에~ 별다른 불편함없이 잘 썼습니다.

그러다가 이런저런 이유로 몇 달 전부터 주 작업 OS 를 Win7 으로 바꿨는데~

인젝터를 '관리자 권한으로 실행' 만 하면~~ 탐색기(낮은 권한 상태)로부터 Drag & Drop 이 안먹히더군요;;;

Drag & Drop 때문에 만든 인젝터인데 그게 안먹힐 때의 그... 허탈함이란..;;;

'수정해야지... 수정해야지...' 생각만 해오다가 불과 2 ~ 3일 전에서야 수정을 했습니다.

키포인트는 비스타부터 지원되는 "ChangeWindowMessageFilter" API 인데요~~

( MSDN - http://msdn.microsoft.com/en-us/library/windows/desktop/ms632675(v=vs.85).aspx )

일반적으로는 권한이 낮은 프로세스에서 권한이 높은 프로세스로 메시지 전달이 안되는데

메시지를 받는 프로세스쪽(저의 경우는 인젝터가 되겠죠~)에서

위의 API 를 이용해서 메시지 필터 설정을 해주면 메시지 전달이 가능하더군요~ :)

Drag & Drop 과 관련된 메시지를 허용하도록 설정하는 코드는 다음과 같습니다.

//
// 컴파일러 버전에 따라 "ChangeWindowMessageFilter" 를 바로 쓸 수 없는 경우도 있어서
// 동적으로 구해오는 방식으로 했습니다.
//
#ifndef WM_COPYGLOBALDATA
#define WM_COPYGLOBALDATA 0x0049

#ifndef MSGFLT_ADD
#define MSGFLT_ADD 1

typedef BOOL (WINAPI *pfnChangeWindowMessageFilter)(UINT, DWORD);

.
.
.

HMODULE hUser32Mod = LoadLibrary("USER32.DLL");
if (hUser32Mod != NULL) {
    pfnChangeWindowMessageFilter pChangeWindowMessageFilter =
        (pfnChangeWindowMessageFilter)GetProcAddress(hUser32Mod, "ChangeWindowMessageFilter");

    // XP 이하의 OS 는 해당 API 가 없음. API 가 있는 경우만 실행될 수 있도록 함...
    if (pChangeWindowMessageFilter != NULL) {
        pChangeWindowMessageFilter(WM_DROPFILES, MSGFLT_ADD);
        pChangeWindowMessageFilter(WM_COPYDATA, MSGFLT_ADD);
        pChangeWindowMessageFilter(WM_COPYGLOBALDATA, MSGFLT_ADD);
    }
}
// 이후 필요없는 경우 USER32.DLL 은 언로드~
// if (hUser32Mod) FreeLibrary(hUser32Mod);

덕분에 지금은 Win7 에서 인젝터를 "관리자 권한으로 실행" 해도 Drag & Drop 이 잘 동작해서~

인젝터가 존재의 이유를 다시 찾았습니다... =_=v...

PC Hunter V1.32 업데이트

XeroNic(HS) — Thu, 12 Dec 2013 13:23:14 +0900

12월 10일자로 PC Hunter V1.32 버전이 업데이트 되었습니다.

[ PC Hunter 홈페이지 : http://www.epoolsoft.com, http://www.xuetr.com ]

PCHunter_free.zip

[Python] PE Rebase :)

XeroNic(HS) — Fri, 6 Dec 2013 22:58:52 +0900

저는 회사에서 대부분의 분석 업무를 "윈도우7" 환경에서 진행합니다.

( 단순히 XP 에 비해서 Win7 이 조금 더 손에 익었다는 이유로..;;; )

윈도우7 에서 DLL 파일을 분석할 때,

올리디버거로 열고 한 번만 로딩해서 분석이 완료되면 상관없지만...

어떤 파일들은 크래쉬 등의 이유로 여러번 로딩을 해야하는 경우도 간혹 있습니다.

이때 해당 DLL 파일에 DYNAMIC_BASE 옵션이 적용되어 있다면...

심히 피곤해질 수도 있는데요...;;;

가령 분석자료를 작성하기 위해 DLL 의 디스어셈블 코드를 캡쳐하면서...

분석을 하고 있는데 크래쉬가 발생해서 DLL 을 다시 로딩했다..;;

이러면 조금전까지 캡쳐해둔 DLL 의 주소와 새로 로딩된 주소가 달라져서...

살포시 멘.붕(까지는 아니려나요..?)이 올 수도 있습니다.

어제군요...

게임 해킹툴 DLL 파일 하나를 분석하면서 열심히 코드 복사해가며..

분석자료를 정리하던 중에 크래쉬가 발생한 바람에...;;;

분석자료에 기록된 그 번지에 DLL 이 로딩될 때까지...

DLL 로딩만 수십번하는 뻘짓을 했습니다;;;;

뻘짓을 하는 도중에 '귀차니즘' 이 스믈스믈 발동되면서...

아!!! DLL 파일의 이미지 베이스를 내가 보던 그 주소로 지정하고...
DYNAMIC_BASE 옵션을 제거하면 되겠구나~!! @_@

하는 생각을 하고는 정말 단순하게 이미지 베이스랑 DYNAMIC_BASE 옵션만 수정하고...

다시 DLL 을 로딩하려는데... 이게 왠걸..? 일부 코드가 희안하게 깨져서 나오더군요..

이미지 베이스 값만 바뀌었을뿐 재배치 정보들은 여전히 이전 베이스 주소를 기준으로 되어 있어서...

문제가 된거였습니다...

결국 재배치 정보들도 새로운 이미지 베이스 값에 맞게 바꿔줘야겠구나 싶어서...

머리를 한참 굴리다가 파이썬으로 만들어 봤습니다..

# PE Rebase tool

import sys
import pefile

IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE = 0x40

def main():
	if len(sys.argv) != 3:
		print "# [ PE Rebase Tool ] #\n"
		print "Usage : rebase.py [Target PE File] [New Base Address]"

	else:
		pe = pefile.PE(sys.argv[1])
		curBaseAddr = pe.OPTIONAL_HEADER.ImageBase;
		newBaseAddr = int(sys.argv[2], 0)

		print "# Target File : " + sys.argv[1]
		print "# Current Base Address : 0x%X" % (curBaseAddr)
		print "#  -> New Base Address : 0x%X" % (newBaseAddr)

		# ImageBase 
		pe.OPTIONAL_HEADER.ImageBase = newBaseAddr

		# DLL Characteristics : IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE off
		pe.OPTIONAL_HEADER.DllCharacteristics = pe.OPTIONAL_HEADER.DllCharacteristics & ~IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE

		# Relocation Information
		pe.parse_data_directories()

		for relocTbl in pe.DIRECTORY_ENTRY_BASERELOC:
			print "-----------------------------------------------------------------------"
			print "@ RVA : %X, (Size : %X)" % (relocTbl.struct.VirtualAddress, relocTbl.struct.SizeOfBlock)
			print "-----------------------------------------------------------------------"
			reloc = relocTbl.entries
			for idx in reloc:
				reloc_offset = idx.rva - idx.base_rva
				if reloc_offset != 0:
					curAddr = pe.get_dword_at_rva(idx.rva)
					newAddr = curAddr - curBaseAddr + newBaseAddr
					print "[0x%X] : %X ==> %X" % (idx.rva, curAddr, newAddr)
					pe.set_dword_at_rva(idx.rva, newAddr)

		pe.write(filename = sys.argv[1] + ".patched")

if __name__ == "__main__":
	sys.exit(main())

이번에 파이썬을 처음 건드려본건데...

제대로 알고 활용만 잘하면 정말 편하겠구나~~ @_@ 하는 생각이 확~~ 들더군요 ㅎㅎㅎㅎ

본격적으로 파이썬도 익혀봐야겠습니다... :))

ps...

잘모르는 파이썬 문법 익혀가며 시간 투자해서 스크립트 다 짰는데..;;;

editbin 툴이 있었다는걸 뒤늦게 떠올린게 함정...ㅠㅠ...

하아... =3=3=3