프로니어 | Security is a people problem...
어플리케이션 바인딩(Application Binding)이라는 말이 생소하게 들릴지도 모르겠다. 바인딩 이라는 말은 서로 엮는 다는 의미이다. 네트워크 소켓 프로그래밍에서도 목적지의 IP, Port를 통해 서로 연결시키는 작업을 Bind 라고 하며 이를 위한 bind() 함수를 제공한다. 이와 같이 어플리케이션 바인딩 또한 적절한 어플리케이션과 연결시켜준다는 의미이다.
좀 더 자세히 말하면 우리가 어떤 파일을 실행했을때 (Windows의 경우는 더블 클릭) 해당 파일이 자동적으로 어떤 특정 어플리케이션과 연결되어 실행된다. 이렇듯 파일과 어플리케이션을 연결시켜주는 작업을 어플리케이션 바인딩 이라고 한다. 어플리케이션 바인딩은 각 운영체제별로 설계 방식에 따라 다르다. 그럼 Windows, Unix-like, Max OS 시스템에서 어떤 방식으로 바인딩을 하는지 알아보자.
Windows Application Binding
윈도우는 확장자에 기반하여 어플리케이션 바인딩을 수행한다. 따라서 확장자를 변경하면 해당 어플리케이션으로 연결이 되지 않는다. 예를 들어 jpg 파일의 확장자를 pdf로 변경하게 되면 이미지를 볼 수 있는 뷰어가 뜨는 것이 아니라 Adobe Acrobat이 실행된다. 당연히 해당 파일은 PDF 포맷을 가지고 있지 않기 때문에 포맷이 잘못되었다는 오류가 발생한다.
하지만 많은 이미지 파일을 다루는 뷰어의 경우 jpg 파일을 png로 변경하여도 문제 없이 뜨는 것을 알 수 있다. 이러한 이유는 해당 어플리케이션이 png 파일도 해석할 수 있기 때문이다. 결국, 바인딩은 단순히 어플리케이션으로 단지 연결만 시켜주는 역할을 수행한다는 점이다. 이후의 작업은 해당 어플리케이션의 동작에 의존한다.
실험을 하면서 특이한 점은 jpg 파일을 hwp로 바꿔도 한글에서 해석을 한다는 점이다. 빈문서에 jpg 파일을 넣어 실행시켜 준다. doc를 대상으로 해 본 결과 이러한 결과를 얻을 수 없었다. 이를 볼 때 한글 개발자들이 좀 더 사용자의 행위에 기반해 좀 더 많은 공을 들인 것을 알 수 있다.
그럼 본론으로 들어가서 어플리케이션 바인딩 정보는 어디에 있을까?
윈도우 NT 이후 다중 사용자 시스템이기 때문에 이러한 바인딩 정보는 사용자에 따라 다르게 존재한다. 사용자 별로 독립적인 바인딩을 지원하지 않는다면 다른 사용자는 그냥 따를 수 밖에 없을 것이다.
개인의 개별적인 바인딩 정보는 사용자 레지스트리 정보인 "NTUSER.DAT" 레지스트리 파일에 저장된다. 레지스트리를 열어 보면 (regedit.exe) 기본적으로 5개의 키가 보인다. 이 중 HKEY_USER 키가 NTUSER.DAT 파일의 내용을 보여준다. HKEY_CURRENT_USER 항목은 현재 로그인한 사용자의 정보를 유지하고 있는데 로그아웃하거나 종료하면 각각 HKEY_USER로 복사가 된다.
이 HKEY_USER 정보는 "C:\Documents and Settings\<user_name>\" 폴더에 "보호된 운영체제 파일 숨기기" 폴더 옵션을 체크 해제하면 보이는 NTUSER.DAT 파일에 기록된다. 자꾸만 삼천포로 빠지는 느낌이다. 레지스트리나 기타 얘기는 나중에 시간이 나면 작성하도록 하겠다.
윈도우의 어플리케이션 바인딩 정보는 다음의 위치에 기록된다.
각 사용자 SID(Security Identifier)로 구분되어 사용자별 어플리케이션 바인딩 정보가 저장되는 것이다. 해당 키 값을 살펴보면 하위에 많은 확장자 이름별로 키가 존재한다. 각각 확장자를 클릭해보면 연결되는 프로그램 정보가 저장되어 있다. 그리고 기본적으로 정의되지 않은 파일을 실행하거나 사용자가 임의로 바인딩을 지정하고 싶을 때는 파일에서 오른쪽 마우스를 클릭하고 "연결 프로그램"을 지정하면 된다.
위와 같이 연결프로그램을 지정할 때 "이 종류의 파일을 열 때 항상 선택된 프로그램 사용" 이라는 항목을 체크하면 다음에 같은 확장자를 가진 파일은 항상 선택된 어플리케이션으로 열린다. 하지만 이 부분을 선택하지 않는다면 한번만 지정한 어플리케이션으로 열고 다시 원래 바인딩된 어플리케이션으로 열린다.
Unix-like Application Binding
유닉스 계열(리눅스 포함)의 운영체제를 사용해본 사용자라면 이 부분에 대해서는 다들 알고 있을 것이다. 유닉스 계열은 확장자 기반의 바인딩이 아닌 파일의 고유한 헤더 시그니처를 기반으로 바인딩을 수행한다. 따라서 유닉스 계열에서는 확장자를 .jpg로 변경한 COFF 포맷의 파일도 실행권한만 주어지면 정상적으로 동작한다.
MAC OS X Application Binding
MAC OS는 위의 운영체제에 비해 좀 더 향상된 바인딩을 지원한다. 윈도우의 확장자 기반 바인딩은 확장자에 종속적이기 때문에 항상 같은 어플리케이션으로 바인딩된다. 또한 유닉스 계열의 바인딩도 파일의 고유한 헤더 시그니처를 사용한다는 점에서 시그니처가 같다면 항상 같은 어플리케이션으로 연결이 된다.
우선 MAC OS에서는 확장자 기반의 바인딩을 사용하지 않는다. 그렇다고 헤더 시그니처 기반의 바인딩을 사용하는 것도 아니다. MAC OS는 파일시스템의 메타정보 부분에 파일타입을 구분하기 위한 32비트(4바이트)의 file type code 값을 가지고 있다. 그리고 각 어플리케이션에 바인딩을 위한 creator code 가 존재하는데 이 두개의 값을 사용하여 바인딩을 수행한다.
결과적으로 동일한 file type code를 가졌어도(파일타입이 동일하여도) 각 파일에 할당된 creator code가 다르다면 각기 다른 어플리케이션으로의 바인딩이 가능하다는 점이다. 따라서 같은 JPEG 포맷을 가진 파일이래도 바인딩을 서로 다른 뷰어로 설정이 가능하다. 혹은 Hex View와 같이 해당 파일을 해석할 수 있는 어플리케이션이라면 바인딩이 가능할 것이다.
혹자는 이런 기능이 무슨 필요가 있냐고 반문할지 모른다. 하지만 사용자들마다 업무가 틀리기 때문에 그만큼 유연할 수 있다. 예를 들어, 필자는 파일 포맷을 분석하기 위해 Hex Workshop과 같은 파일의 바이너리 값을 볼 수 있는 프로그램들을 자주 사용한다. 어떤 특정 파일을 분석할 때 항상 마우스 오른쪽을 클릭하고 해당 프로그램으로 연결시키는 작업은 번거로운 작업이 될 것이다.
한번 바인딩만 시켜주면 다음에 해당 파일을 클릭했을 경우 항상 그 어플리케이션으로 연결해 준다면 얼마나 편하겠는가? 솔직히 현재는 윈도우에 익숙해져서 조금 불편함을 감수하면 된다고 생각할지 모르지만 이런 세세한 부분까지 신경을 써서 설계된 MAC OS에 좀 더 정이가는건 사실이다.
어플리케이션 바인딩 (Application Binding)
어플리케이션 바인딩(Application Binding)이라는 말이 생소하게 들릴지도 모르겠다. 바인딩 이라는 말은 서로 엮는 다는 의미이다. 네트워크 소켓 프로그래밍에서도 목적지의 IP, Port를 통해 서로 연결시키는 작업을 Bind 라고 하며 이를 위한 bind() 함수를 제공한다. 이와 같이 어플리케이션 바인딩 또한 적절한 어플리케이션과 연결시켜준다는 의미이다.
좀 더 자세히 말하면 우리가 어떤 파일을 실행했을때 (Windows의 경우는 더블 클릭) 해당 파일이 자동적으로 어떤 특정 어플리케이션과 연결되어 실행된다. 이렇듯 파일과 어플리케이션을 연결시켜주는 작업을 어플리케이션 바인딩 이라고 한다. 어플리케이션 바인딩은 각 운영체제별로 설계 방식에 따라 다르다. 그럼 Windows, Unix-like, Max OS 시스템에서 어떤 방식으로 바인딩을 하는지 알아보자.
Windows Application Binding
윈도우는 확장자에 기반하여 어플리케이션 바인딩을 수행한다. 따라서 확장자를 변경하면 해당 어플리케이션으로 연결이 되지 않는다. 예를 들어 jpg 파일의 확장자를 pdf로 변경하게 되면 이미지를 볼 수 있는 뷰어가 뜨는 것이 아니라 Adobe Acrobat이 실행된다. 당연히 해당 파일은 PDF 포맷을 가지고 있지 않기 때문에 포맷이 잘못되었다는 오류가 발생한다.
하지만 많은 이미지 파일을 다루는 뷰어의 경우 jpg 파일을 png로 변경하여도 문제 없이 뜨는 것을 알 수 있다. 이러한 이유는 해당 어플리케이션이 png 파일도 해석할 수 있기 때문이다. 결국, 바인딩은 단순히 어플리케이션으로 단지 연결만 시켜주는 역할을 수행한다는 점이다. 이후의 작업은 해당 어플리케이션의 동작에 의존한다.
실험을 하면서 특이한 점은 jpg 파일을 hwp로 바꿔도 한글에서 해석을 한다는 점이다. 빈문서에 jpg 파일을 넣어 실행시켜 준다. doc를 대상으로 해 본 결과 이러한 결과를 얻을 수 없었다. 이를 볼 때 한글 개발자들이 좀 더 사용자의 행위에 기반해 좀 더 많은 공을 들인 것을 알 수 있다.
그럼 본론으로 들어가서 어플리케이션 바인딩 정보는 어디에 있을까?
윈도우 NT 이후 다중 사용자 시스템이기 때문에 이러한 바인딩 정보는 사용자에 따라 다르게 존재한다. 사용자 별로 독립적인 바인딩을 지원하지 않는다면 다른 사용자는 그냥 따를 수 밖에 없을 것이다.
개인의 개별적인 바인딩 정보는 사용자 레지스트리 정보인 "NTUSER.DAT" 레지스트리 파일에 저장된다. 레지스트리를 열어 보면 (regedit.exe) 기본적으로 5개의 키가 보인다. 이 중 HKEY_USER 키가 NTUSER.DAT 파일의 내용을 보여준다. HKEY_CURRENT_USER 항목은 현재 로그인한 사용자의 정보를 유지하고 있는데 로그아웃하거나 종료하면 각각 HKEY_USER로 복사가 된다.
이 HKEY_USER 정보는 "C:\Documents and Settings\<user_name>\" 폴더에 "보호된 운영체제 파일 숨기기" 폴더 옵션을 체크 해제하면 보이는 NTUSER.DAT 파일에 기록된다. 자꾸만 삼천포로 빠지는 느낌이다. 레지스트리나 기타 얘기는 나중에 시간이 나면 작성하도록 하겠다.
윈도우의 어플리케이션 바인딩 정보는 다음의 위치에 기록된다.
- HKEY_USERS\<user_SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
 |
각 사용자 SID(Security Identifier)로 구분되어 사용자별 어플리케이션 바인딩 정보가 저장되는 것이다. 해당 키 값을 살펴보면 하위에 많은 확장자 이름별로 키가 존재한다. 각각 확장자를 클릭해보면 연결되는 프로그램 정보가 저장되어 있다. 그리고 기본적으로 정의되지 않은 파일을 실행하거나 사용자가 임의로 바인딩을 지정하고 싶을 때는 파일에서 오른쪽 마우스를 클릭하고 "연결 프로그램"을 지정하면 된다.
 |
위와 같이 연결프로그램을 지정할 때 "이 종류의 파일을 열 때 항상 선택된 프로그램 사용" 이라는 항목을 체크하면 다음에 같은 확장자를 가진 파일은 항상 선택된 어플리케이션으로 열린다. 하지만 이 부분을 선택하지 않는다면 한번만 지정한 어플리케이션으로 열고 다시 원래 바인딩된 어플리케이션으로 열린다.
Unix-like Application Binding
유닉스 계열(리눅스 포함)의 운영체제를 사용해본 사용자라면 이 부분에 대해서는 다들 알고 있을 것이다. 유닉스 계열은 확장자 기반의 바인딩이 아닌 파일의 고유한 헤더 시그니처를 기반으로 바인딩을 수행한다. 따라서 유닉스 계열에서는 확장자를 .jpg로 변경한 COFF 포맷의 파일도 실행권한만 주어지면 정상적으로 동작한다.
MAC OS X Application Binding
MAC OS는 위의 운영체제에 비해 좀 더 향상된 바인딩을 지원한다. 윈도우의 확장자 기반 바인딩은 확장자에 종속적이기 때문에 항상 같은 어플리케이션으로 바인딩된다. 또한 유닉스 계열의 바인딩도 파일의 고유한 헤더 시그니처를 사용한다는 점에서 시그니처가 같다면 항상 같은 어플리케이션으로 연결이 된다.
우선 MAC OS에서는 확장자 기반의 바인딩을 사용하지 않는다. 그렇다고 헤더 시그니처 기반의 바인딩을 사용하는 것도 아니다. MAC OS는 파일시스템의 메타정보 부분에 파일타입을 구분하기 위한 32비트(4바이트)의 file type code 값을 가지고 있다. 그리고 각 어플리케이션에 바인딩을 위한 creator code 가 존재하는데 이 두개의 값을 사용하여 바인딩을 수행한다.
결과적으로 동일한 file type code를 가졌어도(파일타입이 동일하여도) 각 파일에 할당된 creator code가 다르다면 각기 다른 어플리케이션으로의 바인딩이 가능하다는 점이다. 따라서 같은 JPEG 포맷을 가진 파일이래도 바인딩을 서로 다른 뷰어로 설정이 가능하다. 혹은 Hex View와 같이 해당 파일을 해석할 수 있는 어플리케이션이라면 바인딩이 가능할 것이다.
혹자는 이런 기능이 무슨 필요가 있냐고 반문할지 모른다. 하지만 사용자들마다 업무가 틀리기 때문에 그만큼 유연할 수 있다. 예를 들어, 필자는 파일 포맷을 분석하기 위해 Hex Workshop과 같은 파일의 바이너리 값을 볼 수 있는 프로그램들을 자주 사용한다. 어떤 특정 파일을 분석할 때 항상 마우스 오른쪽을 클릭하고 해당 프로그램으로 연결시키는 작업은 번거로운 작업이 될 것이다.
한번 바인딩만 시켜주면 다음에 해당 파일을 클릭했을 경우 항상 그 어플리케이션으로 연결해 준다면 얼마나 편하겠는가? 솔직히 현재는 윈도우에 익숙해져서 조금 불편함을 감수하면 된다고 생각할지 모르지만 이런 세세한 부분까지 신경을 써서 설계된 MAC OS에 좀 더 정이가는건 사실이다.
'Data Foreniscs' 카테고리의 다른 글
| Common File Signatures (4) | 2009/10/23 |
|---|---|
| INFO2 File Analysis (0) | 2009/10/23 |
| 어플리케이션 바인딩 (Application Binding) (0) | 2009/10/17 |
| Windows Recycle Bin Analysis (0) | 2009/10/16 |
| 휴지통 아이콘 제거/복구 (3) | 2009/10/07 |
| Flash Cookie Forensics (4) | 2009/09/28 |
댓글을 달아 주세요