UserPatchVer0.1.7z

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃
＃ ALIA’s CARNIVAL! Flowering Sky
＃ User Patch 0.1 Ver
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

[English]
■ How to install
01. Run to UserPatchInstall.exe
02. Select to ALIA’s CARNIVAL! Flowering Sky installed folder.
03. Click to Save button.

■ Version 0.1 ( for Tablet PC Users )
- Add QuickLoad Menu in main page.
- Add MENU button in system quick menu.

[Japanese]
■ どうやってインストールするか
01. UserPatchInstall.exeを起動させます。
02. ALIA’s CARNIVAL! Flowering Sky がインストールされているフォルダーを設定します。
03. 保存ボタンを押してください。

■ Version 0.1 ( タブレットユーザーのためのパッチ )
- メインページにクイックロードメニューを追加しました。
- システムクイックメニューにMENUボタンを追加しました。

[Korean]
■ 어떻게 설치하나요 ?
01. UserPatchInstall.exe 을 실행합니다
02. ALIA’s CARNIVAL! Flowering Sky 인스톨되어 있는 폴더를 설정합니다.
03. 저장 버튼을 누릅니다.

■ Version 0.1 ( 테블릿 유저를 위한 패치 )
- 메인페이지에 퀵로드 메뉴를 추가했습니다.
- 시스템 퀵 메뉴에 MENU 버튼을 추가했습니다.

[ 링크가 걸린 문자를 클릭하여 접속한 상태. ]

자주 애용하는 사이트 중 하나를 돌아다니던 중, 문자열이 깨지는 사태가 발생.

[ 링크가 걸린 문자에 마우스를 올려놓은 상태. ]

해당 링크가 걸려있는 부분에 마우스를 올려보니,

UTF-8 코딩이 되어있지 않은채 그대로 문자열이 삽입되어 있었다.

위의 경우 익플이 아닌 파폭이나 크롬의 경우 자동적으로 UTF-8 변환해주지만

익플의 경우 특별한 설정을 하지 않으면, 자동적으로 변환되지 않는다.

인터넷 옵션으로 간단하게 처리하면 되는데, '이걸 자바스크립트에서 어떻게 변환하는가 ?' 에

관심을 갖은게 문제의 발단이 되었다 -_- . . .

이의 해결책중 하나라 encodeURIComponent 함수를 쓰면 된다는 구글형님의 조언을 듣고

당장 실행에 옮기기로 했다.

[ 실험할 웹페이지 소스 ]

encodeURIComponent _Test.htm

[ 실험할 웹페이지 ]

[ 실행한 결과 ]

음 ? ? ? 뭔가 이상하다.

해당 웹페이지 소스 문자열은 UTF-8 로 적혀있고 정상적으로 출력되면

%[Hex] 로 출력될 문자열은 많아야 12개정도 나와야 한다.

( 한글 문자당 3bytes 라고 생각했을때 )

그런데, 위 화면에선 24개로 나오는거로 봐선 인코딩 상에 문제가 있다는걸 어렴풋 생각해볼 수 있다.

[ 웹 페이지 인코딩 ]

여기서 기본 인코딩(한국어)를 UTF-8로 바꾸면

[ 웹 페이지 인코딩 방식 변환 (한국어->UTF-8) ]

정상적으로 출력되는걸 확인할 수 있다.

 이 경우 페이지의 meta contents charset 을 utf-8 을 명확히 기재하지 않은 잘못이 있는데 

그렇다면, encodeURIComponent 함수 내부에선 어떻게 해석하기에 위와 같은 기묘한 결과를 내는걸까 ?

직접적으로 디버깅해보지 않아 아래의 답이 명확하다고 답하기 힘들지만 추측으로는 아래와 같다.

[ encodeURIComponent 으로 문자열을 변환 후 alert 호출까지의 추측 과정 ]

위 과정의 04,05 번의 경우엔 깨질 일이 없으니 01~03번을 기준으로

위 추측을 바탕으로 C언어로 작성해보았다.

 encodeURIComponent_01.cpp 

encodeURIComponent_01.exe

[ C언어를 통한 첫번째 실험 소스 및 실행 파일 ]

[ C언어를 통한 첫번째 실험 결과 ]

[ 이전 잘못된 인코딩(한국어)으로 인한 웹페이지 실행한 결과 ]

위 검은색 콘솔창과 잘못된 인코딩으로 출력된 메시지창의 값을 비교해보면

앞부분 3개까진 똑같이 들어간다.

여기서, 추측해볼 수 있는건, 추측과정의 01번하고 03번은 확실하게 맞다는 이야기가 된다.

그럼, 02번의 UTF-8 문자열을 유니코드로 변환시에 문제가 발생하고 있다는 이야기인데

이의 중간 과정을 알아보기 위헤 웹페이지 소스를 바꾸어보기로 했다.

[ 실험할 웹페이지 소스 ]

Alert_Test.htm

[ 실험할 웹페이지 ]

[ 실험한 결과 ]

여기서 살펴보기 전에 잠깐 한가지 짚어보자.

위 메시지 창이 추측 과정의 04~05번에 해당하듯, 유니코드가 정상적으로 변환되었으리라 라는 보장은 없다.

(직접 디버깅해보지 않았으니...)

하지만, 한가지 확인으로 신빙성을 조금은 높혀볼 수 있다.

C언어를 통한 실험을 했을 때 03번의 Hex 3개는 정확하게 맞아 들어갔고

이는 02번에 해당하는 유니코드 Hex 값의 2개는 정확하게 맞아 들어간다는 추측을 해볼 수 있다.

( 02번의 Hex 값 앞의 2개는 9B 5A, \u5A9B )

이 추측을 토대로 www.unicode.org 에서 제공하는 code charts 를 확인해보면

[ 유니코드 5A9B ]

비슷하게 생겼다. 이를 통해 신빙성은 조금은 높아졌다. 해볼만한 가치가 있다 !!! (야호!)

여기서, 조금더 분석을 해보기 위해 Alert Test 에 출력된 메시지 박스의 내용을 조금 분석해볼 필요가 있다.

위의 괴상한 문자를 추출해서 핵스로 출력하면 아래와 같은 결과가 나온다.

[ Alert Test 의 메시지 박스 내용을 추출한 문자열의 Hex 값 ]

여기서, 눈치 게임이 시작되는데, 뭔가 특정 패턴이 보인다.

Hex 문자열 사이에 'FD FF' 라는게 좀 많이 보인다.

이걸 분석해볼 가치가 있는가는 일단 추출한 Hex 문자열을 UTF-8 로 변환시켜볼 필요성이 있다.

[ 추출한 Hex 값의 내용을 UTF-8로 변환 ]

[ 이전 잘못된 인코딩(한국어)으로 인한 웹페이지 실행한 결과 ]

충분한 가치가 있다 !!!

(완전히 똑같다.)

IE 내부에선 어떤식으로 번역하고 있는가 Hex값을 분석해 볼 필요가 있다.

이를 분석하기 위해서 https://msdn.microsoft.com/en-us/goglobal/cc305154 를 참고하였다.

처음, UTF-8 페이지의 '가나다라'에 해당하는 Hex 문자열은

[ "가나다라" UTF-8 문자열 Hex ]

이와 같다. 이를 MultiByteToWideChar 을 통해 처리하게 되면

[ MultiByteToWideChar 의 유니코드 인코딩 번역 방법 ]

위와 같이 처리되어, 위 msdn 페이지의 표에 없는 문자는 그 문자 그대로 2bytes 를 출력하고

( 예를 들어, 80 같은 경우, 80 00 와 같이 2bytes 를 사용한다. )

표에는 번호가 있으나 내부에 문자가 없는 경우엔 2bytes 로 3F 00 값을 가진 '?' 를 넣게 된다.

[ C언어를 통한 첫번째 실험 결과 ]

이를 기준으로 분석해보면 얼추 맞게 들어가고 있다는 이야기가 된다.

하지만, IE은 이와 같이 해석하지 않는다.

다시, msdn 을 통해 분석해보면

[ encodeURIComponent 의 유니코드 인코딩 번역 방법 ]

이와 같이 해석하게 되는데 이렇게 보면 보기 힘드므로 아래의 표와 같이 순서를 작성했다.

[ encodeURIComponent 의 유니코드 인코딩 번역 방법 순서 ]

x 라고 표기된 부분은 해석 실패로 'FD FF' Hex 값을 갖게 되는 부분이다.

[ Alert Test 메시지 내용에서 추출한 Hex 값의 내용을 UTF-8로 변환 ]

위 내용을 분석한 바탕으로 C언어로 작성하게 되면

encodeURIComponent_Final.cpp

encodeURIComponent_Final.exe

[ C언어를 통한 마지막 실험 소스 및 실행 파일 ]

[ C언어를 통한 마지막 실험 실행 결과 ]

[ 이전 잘못된 인코딩(한국어)으로 인한 웹페이지 실행한 결과 ]

똑같이 맞아 떨어지는 것을 확인할 수 있다.

추측컨데, 이 문제는 encodeURIComponent 함수만이 아닐 것으로 보인다.

encodeURIComponent 와 같은 문자열을 다루는 함수를 사용시 조금 주의할 필요성이 있다고 본다.

불법으로 배포하는 주제에 돈까지 쳐받아먹으려 하는 등 여러가지 횡포가 있는데 . . .

어카이브 뜯어보려던중, 뭔가 수상한 코드를 발견했다 -_- ;;;

FS:[30] ~~~

대략 내가 2~3년 전쯤 삽질했던 스킬 중 하나였는데 LoadLibary 없이

PEB 를 통해 로딩되어있는 DLL 을 불러오는 방법이다.

( 기본적으로 ntdll 과 kernel32 은 기본으로 딸려있다. )

즉, 간단히 말하면 저 텍스트파일이 존재하지 않으면 게임이 실행되지 않는다.

( 뭐 이딴 쓰레기같은... )

한번, 다운받아봤으면 압축파일을 자세히 들여다보아라.

이 텍스트 파일이 괜히 존재하는게 아니다 -_- ; ; ;

( 저 텍스트파일 이름 바꾸면 실행도 안되고, 프로세스에도 그냥 남은 상태로 있음.

테스트 해 볼 의향이 있는 사람은 반드시 실행 후 프로세스를 종료하길 바람. )

진짜 저런짓까지 해야하나 더럽고 빡쳐서 . . .

dis2djpatch.exe

패치 파일 만들어버림.

사용 방법

위 스크린샷 처럼 해당 파일을 드래그해서 dis2djpatch 파일로 던지거나

커멘드 창으로 'dis2patch <파일 경로>' 해주고 Success XD 창이 뜨면 성공적으로 처리된다.

참고로, 이 놈들이 게임 파일 뿐만 아니라 크랙이나 패치파일에도 적용시켜 놓는 케이스가 있다.

결론 : 분석하기전에 검색좀 제대로 해볼껄 -_- . . .

엔스크립트의 반각처리는 불가능하다, 어렵다 라는 이야기를 이전부터 들은바가 있어

최근 모 카페에서 엔스크립트 엔진파일이 올라와있길래 생각난 김에 잠깐 분석해봄.

우선, 엔스크립트 일문 버전을 다운받고, 텍스트를 출력해보았다.

뭐.. 여기까진 예상했다. Font default charset 이 일본어로 되어있기때문이다.

이걸 좀 바꿔주면

한국어로 매우 잘 출력되는 "듯" 보인다.

(위에 있는 일어 메뉴는 리소스만 좀 바꿔주면 금방 끝날듯 싶다. )

하지만 이건 Fake !

두가지 문제가 있다.

첫번째로, 위 00.txt 보면 안녕하세요!<-- 느낌표가 짤려나갔다.

그리고, 두번째 문제의 경우 스크립트를 조금 변경해보고 출력해보았다.

안녕하세요의 안과 녕 사이에 '반각'인 A를 넣어보았다.

신나게 짤려나가신다. 왜 이런 현상이 일어나는걸까 ?

이유는 간단하다. 엔스크립트는 첫문자가 공백이 아닌 반각문자가 들어가면 1바이트씩 읽는게 아니고

일반 대화스크립트(캐릭터 대사나 자막 등)로 판단해서 무조건 2바이트씩 읽어버린다.

즉, 이런 현상이다.

A로 인해 2바이트씩 읽어버리는게 무너져버렸다.

이걸 처리할 방법이 없는가 ?

간단하지만 좀 귀찮은 작업이긴한데 가능하긴하다.

이걸 처리하면

뭐.. 출력은 잘(?)된다. ( 만족스럽지 않음. )

여기서 다시 살펴보면, 또다시 2가지 문제에 닥치게 된다.

위에서 언급한 첫번째 문제로 느낌표가 짤려나간 부분.

두번째는 반각으론 출력됐으나, 여전히 전각으로 보인다.

첫번째 문제에 대한건 나중에 이야기 하도록 하고, 먼저, 두번째 문제부터 살펴보자.

우선, 엔스크립트가 문자를 어떤식으로 출력하는가에 대해 문제가 있다.

엔스크립트는 Empty DC 에 TextOutA 을 통해 하나의 문자를 그려넣고

Bitblt 함수를 통해 하나씩 출력한다. 즉, Bitblt의 출력위치, 가로길이가 문제가 있다.

( 엄밀히, 출력위치의 간격, 가로길이의 값이 고정되어있는게 문제다. )

이걸 해결해서 출력하면

위와 같이 반각도 깔끔하게 출력된다.

( 기본 폰트를 변경할 경우 조금 귀찮아질 수 있다. )

자, 이제 느낌표가 짤려나간 첫번째 문제에 대해 이야기해보자.

일단, 엔스크립트는 기본적으로 반각에 대해선 대사가 아닌 명령 스크립트로 처리하려고 한다.

개행 후 첫문자가 반각이면, 무조건 명령스크립트로 보는 성질이 있는거 같고

( 이 부분에 대해선 정확히 분석해보지 않아서 장담해서 말할 수 없다. )

반각 스페이스라던가 반각 논리연산자(느낌표나 >,< 등)의 경우엔

단순 공백, 연산자로 인식하는건가 모르겠는데 인식되지 않는다.

( 이 부분도 조금만 컨트롤해주면 출력가능할듯 싶으나, 여기까지 할 시간은 부족했다. )

엔스크립트 분석에 대해선 여기까지 적고 위와 같은 이유로 엔스크립트 게임 한글화한다고 하면

가능하면 피하는게 정신건강적으로 매우 좋지 않을까 싶다.

( 반각 처리 안한다고하면, 매우 편할듯. )

요새 발매하는 기리기리 엔진을 사용하는 게임들 패킹이 일단 예전같지 않다.

발매당시 즉석으로 파이썬을 통해 만들었는데 . . .

파이썬, 저번 API 후킹할 때도 나에게 큰엿을 먹이더니만

이번엔 zlib 사용했더니 알 수 없는 바이너리 패턴이 나에게 큰엿을 먹였다.

( 이거때문에 4시간 가까이 해맴 -_- ;

분석했더니 파이썬 내부에서 뭔가 이상하게 돌아가는 덧, 파이썬 내부까진 분석안해봐서 모르겠음.

오프닝 추출 목적으로 만들었었는데, 오프닝에 만족할껄

이미지도 추출해보자라는 마음을 먹은 내가 잘못이지... )

편하긴한데 안심할 수 없는 언어인 듯 하다.

[1차 수정]

 이중 압축된 파일 처리.

xp3_atxr.exe

사용 방법은

xp3_atxr.exe <package_file> <main_key> <sub_key> <is_extract_psb_file>

package file : XP3 파일 경로.

main_key : 보통 hex 8자리 값.

sub_key : 보통 hex 2자리 값.

is_extract_psb_file : psb 파일을 추출할 경우 true, 아닐 경우 false

확실한건, 사노바 위치는 풀리고, 추측으론 네코파라도 풀리지 않을까 함.

( main_key 하고 sub_key 가 필요한데,

이 키값은 블로그에 올리기엔 너무 개방되어 있어서 카페같은데에 올림. )