프린세스메이커5 실행파일을 3년만에 다시 조사한다.

윈도우10에서 프린세스메이커5를 돌리기 위해 각고의 노력을 기울였던 시간도, 벌써 3년이 지났다...

(3년 전 게시물을 보려면 여기를 클릭)

그러다가 최근, 다시 프메5 생각이 나서 한번 더 실행파일을 살펴보게 되었다.

이하 내용은 실행파일을 재조사하면서 느낀 점을 기록한 것이다.

1. 한글판 실행파일은 Settec으로 패킹이 된 건가?

Exeinfo로 한글판 실행파일(1.06 패치 이후)을 분석하면, EP Section에 settec이라는 문구를 볼 수 있다.

settec은 Alpharom(알파롬)이라는 복사 방지 기술을 만든 회사다. 이로써 한글판 실행파일은 패킹이 된 것으로 추정이 가능하다. 패킹이 되면 실행파일 내부의 텍스트도 볼 수 없고, 올리디버거로 불러와도 분석따위는 되지 않는다.

UPX같이 유명한 패킹 기술이라면 언패킹툴도 많이 나왔겠지만, 이건 언패킹툴도 없다.

2. XP에서는 디스크를 넣어달라는 메시지 박스가 나오는데, 왜 윈도우10에서는 나오지 않는가?

윈도우XP에서는 그냥 pm5.exe를 실행하면 '[1502] 원본 Disc를 넣어주세요!' 라는 메시지박스가 뜨면서 실행이 되지 않는다. 그래도 이건 사용자에게 디스크 문제라고 알려주니까 좀 낫다.

윈도우10에서는 아무 메시지도 출력하지 않는다. 아마 RAM에 정상적으로 올라가지도 못하고 강제종료되는 걸로 보인다. 그런데 어쩌면 인터넷에서 흔히 돌아다니는 pm5_loader가 'Time out.Bytes not found' 문구를 출력하는 것도 이와 관련이 있을지도 모른다. 패킹된 파일도 RAM에 올릴때는 복호화해서 올라가게 된다. 그러나 pm5.exe의 settec 패킹 방식이 윈도우XP · 윈도우7까지만 정상작동하는 구닥다리 방식이라서 윈도우10에서는 복호화를 못하고 강제종료되는 것이 아닐까? 강제종료가 된 걸 모르는 pm5_loader는 실행파일이 열리기만을 기다리다가 안 열리니까 Time out 오류를 내뱉게 되는거라고 감히 추측해본다.

3. 'pm5.001'의 정체는 무엇일까?

XP 환경에서 프린세스메이커5를 실행하면, 프로세스 탭에 pm5.exe와 pm5.000이라는 두 개의 프로세스를 볼 수 있다.

보통 게임을 실행하면 *.exe 파일 하나만 프로세스가 되는데 *.000이라는 프로세스까지 들어간다니 특이한 경우다.

여기서 나는 LordPE라는 프로그램을 통해서 pm5.exe와 pm5.000이라는 프로세스를 파일로 추출해보았다. (dump full) 그러자 놀라운 사실을 확인할 수 있었는데, 'pm5.000'은 pm5.exe의 복호화된 데이터였다. pm5.000 파일 내에는 게임 안에서 사용되는 한국어 단어들이 포함되어 있었다. 그러나 안타깝게도 exe 없이 단독실행을 하는 건 불가능하였다. 추출된 pm5.exe는 패킹된 상태 그대로였다.

위의 스샷처럼 추출된 pm5.000을 Crystaltile2로 열면 한국어 데이터를 바로 확인할 수가 있다.

좋다. 비록 한글판 실행파일은 구닥다리 패킹으로 인해 살릴 수 없게 되었지만, 적어도 실행파일 내 한국어 데이터는 확보했으니 이걸 일판 실행파일에 이식하기만 하면 된다.

4. 다이렉트8 사용 및 또다른 노시디 방식 실험

프린세스메이커5 실행파일 내에 d3d8.dll이라는 문구가 있다. 아마 다이렉트8을 사용하는 게임인가 보다. 어쩌면 다이렉트8의 호환성 문제가 아닐까하고 의심도 해봤지만, 그게 문제였다면 일판 및 중문판 실행파일도 정상작동하지 못했을 것이다. (이번 조사때 중문판도 구해서 확인해봤다.)

그리고 pm5_loader의 바이러스 오진으로 인해 사용을 꺼리는 사람들에게 다른 방법이 있다. 'AlphaROM 2.1～3.1汎用 起動用iso作成tool rev3.exe' 라는 파일을 구해서 실행한뒤 프메5 이미지 파일(.iso)을 지정하면 boot.iso가 나오는데 이게 pm5_loader와 같은 역할을 한다. boot.iso를 마운트하면 원본 Disc 타령없이 게임이 실행된다. 그러나 이 방법도 윈도우10에서는 전혀 효과가 없다.

5. 실행파일 수정 - 이름 입력 처리

나는 3년전에 작업해놓았던 파일을 다시 꺼냈다. 이번에는 이름 입력 처리부터 확실히 하고자 한다.

일판 실행파일은 이름 입력 구역이 총 4구역이 있다. 나는 실행파일을 한글화하면서 1~3구역에는 주로 쓰이는 한글 낱자들을 넣어두었다. 4번 구역인 뷁어 구역은 방치하고 있었는데, 이번 기회에 구조 방식을 파악하여 4번 구역에서 뷁어들을 몰아내고 한글 가나다순으로 리스트 출력이 가능하도록 만들려고 한다.

우선 あ그룹의 시작은 '닟' , い그룹의 시작은 '댥' 이라는 점에 주목해보았다.

한글 인코딩(EUC-KR, CP949) 기준으로, '닟'의 헥스코드는 889F, '댥'의 헥스코드는 88C8이다. 

889F... 88 9F...? 

이 헥스코드는 워낙 많이 봐서 이젠 외워지기까지 한다. 889F는 바로 일본어 인코딩(Shift-JIS) '亜'의 헥스코드다.

어쩌면 실행파일내에 889F를 지정한 부분이 있을까 하고 조사해봤더니, 옳거니... 바이트 플립되어서 9F 88로 들어가있었다. 3년전에는 알아차리지 못했는데, 이제는 눈에 보인다.

그 옆을 보니 88 C8도 마찬가지로 바이트 플립되어 C8 88로 들어가있는 모습을 확인할 수 있었다.

시험삼아 あ그룹에 초성 'ㄱ'에 해당되는 글자들이 나오도록 헥스값을 수정해보았다. 

88 9F는 B0 A1(가)로, 88 C8은 B1 EE(까)로 수정해본다. 이렇게 하면 '까'의 바로 앞 글자인 B1 ED(깊)까지는 あ그룹에서 출력될 거라는게 나의 예상이다. 과연 결과는 어떻게 나올까?

성공이다! 이로써 あ그룹에서 '가'(B0 A1) 부터 '깊'(B1 ED) 까지의 한글을 지원하게 되었다.

같은 방식으로 い그룹은 'ㄲ', う그룹은 'ㄴ'... 이렇게 그룹별로 초성을 지정하여 초성에 맞는 한글 낱자가 출력되도록 수정해보자!

표로 정리하면 다음과 같다.

그룹명	한글 첫글자와 헥스값	바이트 플립
あ	가 (B0 A1)	A1 B0
い	까 (B1 EE)	EE B1
う	나 (B3 AA)	AA B3
え	다 (B4 D9)	D9 B4
お	따 (B5 FB)	FB B5
か	라 (B6 F3)	F3 B6
き	마 (B8 B6)	B6 B8
く	바 (B9 D9)	D9 B9
け	빠 (BA FC)	FC BA
こ	사 (BB E7)	E7 BB
さ	싸 (BD CE)	CE BD
し	아 (BE C6)	C6 BE
す	자 (C0 DA)	DA C0
せ	짜 (C2 A5)	A5 C2
そ	차 (C2 F7)	F7 C2
た	카 (C4 AB)	AB C4
ち	타 (C5 B8)	B8 C5
つ	파 (C6 C4)	C4 C6
て	하 (C7 CF)	CF C7
と	- (C8 FF)	FF C8 '힝' (C8 FE)까지 て그룹에 출력하기 위해 일부러 다음 바이트를 지정.

이렇게 해서 한글 낱자 2350자를 리스트에 출력되도록 하는데 성공...했다고 생각하나?

(갑자기 폰트가 바뀌었는데 나중에 스샷을 찍어서 그런 거다.)

위 스샷을 보면, '힝' 까지 출력되야 하는데 '힙' 까지만 출력되고 있다. '힙'의 헥스코드는 C8 FC, '힝'의 헥스코드는 C8 FE다. 즉, 두번째 바이트가 FD, FE로 끝나는 한글 낱자들은 리스트에 출력되지 않는 문제가 발생한 것이다.

위 스크린샷은 내가 예전에 삼국지4, 삼국지5 일판 실행파일을 조사하면서 만든 자료다.

스샷의 표를 보면, CP949는 두번째 바이트가 FD, FE로 끝나는 자리에도 글자를 배당해놓았다. 그러나 Shift-JIS는 FD와 FE로 끝나는 자리에 글자를 배당하지 않았다.

따라서 일본어 로케일을 기반으로 만들어진 프로그램들은 굳이 FD, FE에 글자가 있는지 파악하지 않고 바로 다음으로 이동하게 된다. Ollydbg로 해당 어셈블리를 수정하면 되겠지만, 그건 쉽게 찾을 수 있는게 아니다.

결론은 일본어 인코딩(Shift-JIS)과 한글 인코딩(EUC-KR, CP949)의 코드 구조 차이때문에 벌어지는 문제라는 것이다. 문제가 있는 글자들은 다음과 같다. (B0~C8 구역만 분석)

앞 바이트	~FD	~FE
B0~	괄	괆
B1~	깰	깸
B2~	끗	끙
B3~	뇜	뇝
B4~	덤	덥
B5~	딴	딸
B6~	랖	랗
B7~	륨	륩
B8~	뫙	뫼
B9~	법	벗
BA~	빡	빤
BB~	생	샤
BC~	숫	숭
BD~	쐬	쐰
BE~	엌	엎
BF~	웡	웨
C0~	절	젊
C1~	집	짓
C2~	찹	찻
C3~	츳	층
C4~	퀸	퀼
C5~	퉈	퉜
C6~	폿	퐁
C7~	혜	혠
C8~	힛	힝

몇몇 글자들은 자주 쓰이는 글자들이다. 따라서 이 글자들도 반드시 실행파일에서 지원해야 할 필요가 있다. 어떻게 해야 될까?

그냥 일본어 50음도처럼 수동으로 리스트에 들어가도록 실행파일을 수정해주니까 잘 나온다.

이것으로 기존 한글판에서 지원했던 한글 2350자(EUC-KR)는 모두 지원하게 되었다.

참고로, '한글/영수' 라는 버튼 이미지는 in02.bm 파일에서 담당한다는 걸 발견했다. (중문판 파일과 바꿔치기하면서 확인) 4번 구역의 히라가나 그룹표도 이 파일에서 취급하고 있는 걸로 추정된다.

그러나 포토샵이든 그림판이든 이 파일을 불러올 방법이 없어서 수정이 불가능하다...라고 생각하고 있었는데 중문판 게임 폴더에서 결정적인 힌트를 얻을 수 있었다. 자세한 내용은 7번 단락에서 작성.

6. 실행파일 수정 - 데이터 불러오기/저장 시의 '년째' 연도 수정.

이름 입력 처리도 끝났고, 실행파일에 잔존한 뷁어들도 한글판 데이터를 보면서 거의 다 고쳤다. 이제 실행파일에 남아있는 뷁어는 한글판에서도 뷁어로 남은(미한글화된) 데이터들 뿐이다. 고치는 동안 폰트도 원래 한글판 폰트인 궁서체로 바꾸게 되었다.

그러나 최종보스마냥 어떤 뷁어 하나가 눈에 잘 띄는 곳에 틀어박혀 있어서 신경을 거슬리게 한다. 바로 데이터 불러오기/저장시에 보이는 '년째' 연도였다.

'１년째' 라고 표시돼야 정상이다. 그런데 왜 '괦년째' 라고 표시되는 걸까?

정답은 '괦'자의 헥스코드 속에 숨어있다. '괦'의 헥스코드는 82 50인데, 이 헥스코드는 일본어 인코딩(Shift-JIS)에서 전각 숫자 '１'이다.

그럼 한글 인코딩에서 전각 숫자 '１' 헥스코드 값은? A3 B1이다. 이 값으로 바꾸면 숫자가 제대로 출력될것이다.

그러나 Crystaltile2만으로는 고칠 수가 없었다. 전각 숫자와 관련된 바이트를 찾을 수가 없다. 아무래도 '년째' 주변에 있는 글자들을 힌트 삼아서 Ollydbg에서 찾아야 할 것 같다.

Ollydbg로 실행파일을 열고 모든 Text String을 조회하여 겨우 힌트 글자들을 찾아냈다. 이곳 주변에 전각 숫자와 관련된 어셈블리어가 존재할 것이다.

나는 힌트 주변에 있는 여러가지 어셈블리어를 조작해가면서 '괦' 자에 조금이라도 변화가 있는지 살펴보았다.

그렇게 어셈블리어 조작... 저장... 게임 실행... 변화 없음 확인... 게임 종료... 다시 어셈블리어 조작... 이런 식의 삽질이 시작되었다...

여러 어셈블리어를 조작하던 도중, '괦' 자가 '?'로 출력되는 현상이 벌어졌다. ADD AL, 0x4F라는 어셈블리어에서 4F를 3F로 수정하니까 그런 일이 발생하였다.

찾았다... 여기가 바로 전각 숫자와 관련이 있는 부분이었다. 

바로 몇 줄 위로 올라가보니까 MOV BYTE PTR SS:[ESP+0x34],0x82 라는 어셈블리어도 보인다. 0x82... 82 4F라... 

82 4F는 일본어 인코딩(Shift-JIS) 기준으로 전각 숫자 '０'인데... 매우 의심스럽다. 한번 이곳을 이렇게 수정해보자.

MOV BYTE PTR SS:[ESP+0x34],0x82 → MOV BYTE PTR SS:[ESP+0x34],0xA3

ADD AL,0x4F → ADD AL,0xB0

A3 B0은 한글 인코딩 기준으로 전각 숫자 '０'이다.

내 예상이 맞다면, 이곳을 수정하면 '괦'자는 사라지고 전각 숫자 '１'이 출력될 것이다.

과연 실행결과는 어떻게 나올까?

만세!!!!!!

드디어 괦이라는 뷁어가 사라지고 숫자가 제대로 출력되고 있다. 참으로 뿌듯하기만 하다.

7. 그래픽 파일 수정 - in02.bm의 버튼 이미지 변경.

5번 단락 끝부분에서 잠깐 언급한 사항이다. 나는 이번에 재조사를 진행하면서 중문판 파일까지 구했는데, 중문판의 EV 폴더내에 흥미로운 파일이 하나 있었다. 바로 EC270S.TGA라는 파일이었다. 해당 파일은 포토샵에서도 바로 열어볼 수 있었다.

EC270S.TGA 파일과 EC270S.BM 파일은 바이트 단위까지 용량이 동일하였다. 그렇다는건 .BM 파일은 원래 .TGA 파일이었다는 추정이 가능하다.

헥스 에디터로 두 파일의 헥스를 비교해보니, 헤더 16바이트를 제외하고는 파일 헥스까지도 모두 동일하였다.

TGA 파일의 헤더 바이트는 아래와 같다.

00 00 0A 00 00 00 00 00 00 00 00 00 00 01 00 01

3번째 바이트의 0A는 공통.

14번째 바이트는 가로 길이. (256의 등차수열이다. 01=256, 02=512...)

16번째 바이트는 세로 길이. (마찬가지로 256의 등차수열이다. 01=256, 02=512...)

이 방법을 in02.bm 파일에도 응용해보면 되지 않을까? 나는 in02.bm의 파일 확장자를 .tga로 바꾸고 파일을 헥스 에디터로 열어서 헤더값을 수정해보기로 결심했다.

포토샵에서 그래픽이 제대로 나올때까지 가로 길이 · 세로 길이를 담당하는 바이트를 계속 수정했다. 01... 02...

그리고 마침내...

00 00 0A 00 00 00 00 00 00 00 00 00 00 04 00 04 (1024x1024 픽셀) 로 헤더값을 수정하니 드디어 포토샵에서 제대로 나온다. 위에 올려놓은 파일이 바로 in02.bm의 그래픽 도면이다.

포토샵에서 일부 버튼 이미지를 수정했다. 알파 채널까지 있어서 좀 더 신경써줘야 한다.

수정이 완료되었으면 '배경으로 이미지 병합' 한 다음 TGA 파일로 저장한다. 이때 해상도는 32비트/픽셀에 압축(RLE)이 체크되어야 게임에서 정상출력된다.

그리고 저장한 TGA 파일을 헥스 에디터로 열어서 헤더값을 원본 파일의 값으로 고친다음 확장자도 .bm으로 변경하면 끝이다.

과연 결과는 어떻게 나올까?

수정한 in02.bm이 정상적으로 출력되고 있다.

이제 이름 입력 시에도 불편함이 사라졌다. 

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

이상으로 프린세스메이커5 실행파일에 대한 재조사 기록을 마친다.

재조사의 결과물은 https://k66google.tistory.com/507 에 게시하였고, 관련 설명도 함께 업데이트하였다.

이 글이 다른 게임의 한글화 작업을 하는 사람들에게도 참고가 되기를 바란다.

그럼 이만...