 [잡담] • AppLocale!!!!
|
  Hide_D
|
|
잡담입니다. 그리고 아마 용두사미인 글일거구요. Visio같은게 있으면 그림 그리긴 편하겠지만 이 컴엔 이게 또 없으니 그냥 텍스트로 갑니당 ㅎ 수많은 게임들이 아직도 유니코드기반이 아니라 Shift-JIS(일본어 문자셋)을 쓰고 있는 DBCS기반 프로그램입니다. 유니코드였다면 그냥 실행만 하는것으로 모~든 글자가 일본어도 제대로 나오는 상황이었겠지만, 그렇진 않기 때문에 결국에는 한국어 기반(CP949)에서 일본어 기반 프로그램을 돌리기 위해 AppLocale과 NTLEA와 같은 프로그램을 쓰게 되죠. 이 중에서 AppLocale을 위주로 설명을 해볼까 합니다. 1. 왜 AppLocale이 필요한가? 현재 사용하고 있는 WinAPI들은 대부분 같은 기능을 같지만 눈꼽만큼 다른 두벌의 함수를 갖고 있습니다. Windows C/C++ 프로그래밍을 할때 죽어라 보게되는 CreateFile(파일 생성, 파일 열기 등!등!!등!!!등!!!!) 또한 CreateFileA / CreateFileW 두종류가 있고, A는 Ansi, W는 Wide character(유니코드)의 줄임말입니다. 그런데 진짜 CreateFile함수는 CreateFileW함수입니다. Windows NT(2000, XP, Vista, 7 등 현재 쓰이는 모든 운영체제)기반에서는 OS 내부 작업처리로 유니코드만 사용하니까 A 계열 함수는 단순히 DBCS에서 유니코드로 텍스트를 변환한 다음, W 함수를 불러 일을 마치고, 다시 유니코드에서 원래 코드로 바꾸어서 돌려주는 기능만 합니다. (참조 : Windows Programming via C/C++) 문제는 각 나라가 사용하는 DBCS들을 구분할 방법이 별로 없다는겁니다. 한국어와 일본어 코드페이지(CP949와 Shift-JIS)또한 상당히 많은 부분에서 겹치기도 하고, 상당히 많은 부분에서 다르기도 합니다. 그러면 프로그램을 켤때 DBCS -> 유니코드 -> DBCS를 할때 어떤 녀석을 기준으로 하는가? 이게 바로 "제어판->국가 및 언어 ->유니코드를 지원하지 않는 프로그램용 언어" 가 있는 이유입니다. 즉 모든 A로 끝나는 함수들(MessageBoxA, CreateWindowA, CreateFileA 등)에서는 저 값을 참고로 변환을 수행하게 됩니다. 일본 게임들은 저 '유니코드를 지원하지 않는 프로그램용 언어' 값이 원래는 일본어여야 제대로 돌아가겠지만, 시스템 전체를 바꾸고 싶지 않다! 그래서 AppLocale이 필요해집니다. 2. AppLocale은 어떻게 동작하는가? 아무 실행파일이나 바로가기 우클릭 -> 속성을 눌러보면 '호환성'탭이 있는것을 알 수 있습니다. 여기에서는 예전 버전에선 제대로 돌아가는 프로그램이 지금은 동작하지 않을 때 동작 방식을 '그 프로그램'만 바꾸어서 돌릴 수 있도록 해주는 기능을 담고 있습니다. AppLocale은 사실 이 호환성 탭에서 '숨어있는 또 하나의 체크박스' 같은 구조로 동작합니다. 말하자면 '다음 코드페이지로 실행'과 같은 옵션이구요. 그래서 사실 호환성 모드를 커맨드 라인에서 동작하는 방법과 동일하게 환경 변수를 잡아주면 동작 여부를 묻는 창이 필요없이도 잘 작동합니다. (참조 : http://lab.aralgood.com/42657 , MSDN 어디선가 봤는데 기억이 안나네요) 그러면 이 호환성 모드가 어떻게 동작하는고 하니 요약하자면 [Win API를 가로채서 자신의 일을 하는 proxyDLL을 삽입한다]가 되겠습니다. (1) 먼저 환경변수에 __COMPAT_LAYER가 지정되어 있으므로 호환성 처리 엔진이 해당 레이어(이 경우엔 AlLayer.DLL)를 불러서 어떤 상황인지 물어봅니다. 이 경우엔 어떤 언어로 사용하는지가 되겠네요. (2) 로드된 기본 호환성 레이어 DLL(AcGenral.dll, AcLayers, 이 경우엔 ALRes412도!) 이 작업을 시작합니다. 이 녀석들은 호환성 엔진에게 '이러이러한 함수를 우리가 가로채도록 해주세요!'라고 부탁합니다. 가령 위에 설명했던 각종 A 함수들이 해당합니다. (3) 이제부터 AppLocale이 지정해둔 WinAPI 함수를 사용할 때에는 무조건 AppLocale의 호환성 레이어를 지나치게 됩니다. 일반적인 A 함수들은 CP949대신 Shift-JIS가 기본값인 것으로 처리하고, 글꼴 관련 처리인 경우 새로 기본값을 지정해줍니다.(가령 굴림 -> MS Gothic 처럼) 즉, AppLocale은 프로그램의 내부 코드를 고치지는 않습니다. 단지 WinAPI 함수들을 가로챌 뿐이죠. 3. 이게 왜 의미가 있나? 이게 가능한 이유는 대부분의 프로그램에서 자신이 사용하는 WinAPI 함수의 주소를 '확인하지 않고 사용'하기 때문입니다. 보안 용도로 WinAPI 함수가 원래 프로그래머가 의도한 주소와 동일한지, 아니면 다른 DLL으로 우회되었는지를 확인하는 작업은 분명 사용할 수 있는 방법이긴 하지만 윈도우즈 새 버전이 나올때마다! 아니면 서비스팩이 새로 나오거나 심지어는 보안 패치라도 있으면 얼마든지 주소가 바뀔 수 있기 때문에 별로 좋은 방법이 아닙니다. 즉, 한글패치 작업을 위해 프로그램 코드를 고쳐서 프로그램 내부의 감지 루틴과 싸우는 것 보다도 WinAPI 함수를 가로채서 돌리는 작업을 먼저 시도해 볼 수 있다는 뜻입니다. 이게 의미가 있는 몇가지 예를 들어봅시다. (1) 파일 가로채기 디버거로 조작에 들어가기 전에 미리 CreateFile, ReadFile 등의 함수를 가로채는 것으로 아카이브의 구조를 대략적이나마 알 수 있도록 해줍니다. 로더에서는 Data.pak 대신 Data_kor.pak을 열도록 시도해줄 수도 있으며, Graphics.pak의 0x1000 부터 0x2000사이의 읽기 시도는 그냥 Graphics_kor.pak의 0x0000부터 0x1000사이의 값으로 바꿔서 보내줄 수도 있습니다. (2) 글꼴 바꾸기 CreateFont를 가로채면 자신이 원하는 글꼴을 마음대로 불러올 수 있습니다. 프로그램 내부 코드를 볼 필요없이 글꼴을 정해줄 수 있다는건 확실한 매리트입니다. 적어도 ( http://www.team-uml.com/1648280 ) 이런 질문을 할 필요는 없어지죠. (3) 기타! Visual C++ 6.0으로 만들어진듯한 프로그램들이라면 wsprintf 함수를 후킹해보세요. 생각보다 많은 정보가 나옵니다 :) 이상으로 AppLocale과 관련된 내용으로 시작했다가 한패 이야기로 끝나는 내용이 되겠습니다. 뱀발 : 어쩌다보니 제가 만든 로더들(발표된건 '하나'밖에 없지만!!!!)은 전부다 WinAPI 가로챈것만으로도 잘 돌아갑니다. 프로그램 코드 내부를 들여다 볼때는 언팩/리팩할때 뿐인거죠! 넵! |
vector<char> buff(strText.length()*2+1); //Fuc**** Legacy
WideCharToMultiByte(CP_ACP,0,strText.c_str(),-1,buff.data(),buff.size(),NULL,NULL);
printf("%s\n",buff.data());
제목
엮인글 주소
t3RRa #
|
|
|
2012.01.24 16:08
|
|
|
Hide_D #
|
|
|
그걸 회피하기 위해!! 아랄트랜스와 제 로더에서는 GetGlyphOutline를 후킹하는 방법을 쓰고 있습니다. 일본어 상용한자 범위 내에서 그 스크립트에 사용하는 모든 한글 + 완성형 한글을 모두 1:1 매핑해서 때려박고 GetGlyphOutline함수에서 출력할 때 원형을 받아서 돌려주는 거죠. 자체폰트를 사용하는 경우에는 폰트 파일을 위의 맵 대로 만들어주면 되고, 일반 게임에서도 동작 가능합니다. 이 맵을 만드는데 수행했던 뻘짓이 이 링크 ( http://lab.aralgood.com/35448 )에 담겨있습니다. 반각 글자를 출력하는 루틴이 '아무것도 없는' 경우만이 이 방식의 단점입니다 넵
2012.01.24 20:38
+
|
|
|
Hide_D #
|
|
|
이 내용에 대해서는 따로 글을 써보도록 하겠습니다!
2012.01.25 00:58
|
|
|
t3RRa #
|
|
|
;;; 스크립 수정시에 다시 매핑해줘야하겠네요...
2012.01.25 18:43
|
|
|
Hide_D #
|
|
|
그래서 사실 사용하는 글자 테이블이 세종류에요. 0. 히라가나, 가타카나, 및 Shift-JIS와 CP949에서 사용하는 전각 문자 -> 혹시 모르니까요 1. 한글 완성형 코드 ->는 일단 ㅇㅇ 2. 2010년 언젠가를 기준으로 아랄연구소 + 폴라리스 + 달빛아래의 게시물에 담긴 모든 글자 ->통신체와 흔히 틀리는 오타 확인을 위해 3. 초벌 번역된 스크립트 ->이건 한패 작업을 할때마다 계속 덧붙이고 있습니다. 여태까지 추가된 글자가 한 2글자정도? 상용한자 구역에 현재 저 위의 세가지 나온 모든 글자를 매핑해두었는데, 대충 30자리쯤 남은 상황이고 현재까진 문제가 없더라구요. 더 필요하면 상용한자 말고 남은 한자 구역들이 많긴 한데 이쪽은 혹시 전용폰트같은걸 사용하는 게임일 때 매핑하는데 문제가 생길 수도 있어서 보류해 두었구요. 어차피 한국어 -> 일본어 매핑할때 매핑 실수하면 '뷁' 에 해당하는 글자로 매핑이 되도록 해둔지라 티가 나게 되어있슴다
2012.01.26 01:27
+
|
|
|
t3RRa #
|
|
|
으.... 제 성격은 걍 코드 고치자... 이런거 -ㅁ-;;; 한 단계를 더 거쳐야하는건 왠지 게으른 저에겐...
2012.01.26 16:09
|
|
  #
|
|
 몇몇 프로텍터의 경우에서는 Applocale을 씹어잡수는 것을 확인할 수 있어요. 그 경우는 해당 프로텍터가 자기자신의 Import Address Table을 PE헤더에서 참조하는 것이 아니라 프로텍터의 초기화 과정에서 독자적인 Import Table을 작성하기 때문에 발생하는 문제인데 이 경우를 볼 때 Applocale은 Import Address Table의 ANSI 관련 함수의 주소를 고쳐주는 방식으로 구동하는 게 아닐까 싶습니다. 이 경우 API함수를 후킹하려면 API함수 내부의 시작부분에 후킹코드를 때려박는 게 제일이겠죠 역시 ㅇㅇㅋ
2012.01.25 08:50
+
|
|
|
Hide_D #
|
|
|
그래서 지금 로더에선 API 함수 내부에 후킹코드를 때려박고 있지요 ㅇㅇ
2012.01.25 13:44
|
|
|
프시쵸 #
|
|
|
좋은 글이군요! 좋은 정보 감사합니다~
2012.01.26 11:47
|
|
하지만.. 스크립트 파일에서 문자열을 가져와 출력할때 바로 전에 일본어 코드인지 검사하는 코드가 있다면, 결국 메모리상에서든 파일상으로든 실행파일을 고칠 수 밖에 없죠..