클로저스 일본판 후기

원래 클로저스 일본판은 세가가 서비스를 하고 있었지만, 올해 1월에 그만두고 HappyTuk 이라는 회사가 이어하게 되었다.

아마 칸코레 비타급의 게임을 팔아먹으려니 장사가 안 되었던 듯하다. 유명 성우도 잔뜩 쓰고 세가로서는 열심히 투자했지만 워낙 원본이 똥겜이라…

아무튼 원본이 워낙 똥겜인데다 일본판은 지역제한으로 시작 자체를 못했으므로 잊어버리고 살다가 이전 자체도 한참 지나서 알았는데, 며칠전에 원본을 한번 들어가본 김에 바뀐 일본판도 시험해보기로 했다.

일단 바뀐 HappyTuk(이하 HT) 이라는 회사가 무슨 회사인지부터 찾아봤는데, 요약에는 대만 회사라고 나오지만 채용정보를 보니 한국 회사같다. 아마 한국이 본거지고 요약에 나온 주소지는 지부인 것으로 생각된다.

채용정보에는 여러가지 한다고 나와있는데 검색결과에 클로저스 일본판이 제일 먼저 나와있는 걸 보면 거의 이거 말고는 되는 게 없는 거 아닌가 싶다. 아무튼 방문해보면…

한글과 일본어가 섞여있는게 만들다 만 것처럼 생겼다. 설명에 의하면 브라우저의 언어에 따라 다르게 보인다라고 설명하고 있는데 음… 이것도 나왔다 안나왔다 하는게 아무래도 물건너에서도 한글이 튀어나올 것 같다.

아무튼 일단 설치부터 하기로 하고 다운로드나 설치 메뉴를 찾아본다. 그렇데 첫 단계부터 웃긴다.

런처와 게임 다운로드가 따로 존재한다. 여기까지는 특이할 게 없지만 보통은 둘 중에 하나만 선택해서 진행하게 된다. (런처 설치로 진행하면 게임 설치보다 스텝이 늘어나는 정도의 차이만 있는 정도) 하지만 여기는 둘 다 모두 설치해야 진행된다. 벌써 수상하다.

아무튼 런처와 게임(?)을 모두 설치하고 홈페이지에서 게임 실행을 누르면 런처가 실행된다.

가입까지는 문제가 없지만 패치부터 지역제한이 걸렸던 세가와 달리 HT판은 이러한 제한이 없다. (원칙적으로 허용되는 것은 아니고 이용약관에는 일본 외부에서의 접속을 금지한다는 조항이 있다. 다만 서버 자체도 미국에 있고 별로 규제할 생각이 없는 듯하다.) 그런데… 다운로드 속도와 예상 시간이 가관이다. 0.05MB/s(=50KB/s) 에 예상 시간이 30시간이다.

진행하는 모습을 지켜보면 이유를 알 수 있는데, 수십kb 가량의 6만개에 가까운 파일을 순차적으로, 하나씩만 다운로드 하기 때문이다. 세상에, 지금 쓰고도 미친 소리 같지만 사실이다.

참고로 원본도 동일한 방식으로 패치한다. 이러니 세가가 그만둘수밖에…

일단 시작한 것, 오기가 생겼다. 다운로드할 파일의 리스트를 추출한 후 직접 다운로드하면 훨신 더 시간이 절약될 것으로 생각하여 작업을 시작하기로 했다.

먼저 다운로드할 파일의 리스트를 추출하는 작업부터. 처음에는 웹 서버에 접속해서 다운로드 받으므로 해당 웹 서버가 파일 리스팅을 지원하면 쉽게 목록을 얻을 수 있지 않을까 생각했지만 애석하게도 지원하지 않았다.

그 다음에는 .lua 파일 디컴파일을 시도해봤다. 추측해보건데 런처는 내부적으로 CLIENT_CODE.lua 라는 컴파일된 lua 스크립트를 실행하고 여기서 문제의 업데이트 작업을 실행하는 것으로 보였으므로 디컴파일을 시도해보았다. hex 값을 보니 컴파일된 lua 5.1 스크립트 헤더까지는 확인되었지만 검색해서 나온 몇 개의 디컴파일러를 시도했지만 성공하지 못했다.

마지막으로 Cheat Engine을 사용해보기로 했다. 처음에는 텍스트 후킹을 시도했으나 생각해보니 스크립트 파일의 5MB라는 크기로 보아하니 다운로드할 파일 목록을 하드코딩했을 것으로 생각되므로 프로그램이 실행 중이면 메모리상에서 문자열(string) 이 검색될 것이라는 생각이 들었다.

메모리 뷰를 열고

string map 을 디스크에 저장한다.

현재는 다운로드를 마친 상태라 StringCount 가 적지만 해당 작업이 진행중일 때에는 6만개 이상의 문자열이 추출된다.

그렇게 추출한 문자열들을 열면 다음과 같다.

00260C10 – Patch Speed 0.04 MB/sec Remaining Time 31:24:55
01020C8C – Patch Speed
01020FC8 – PATCH/PATCH_%04d_%u/
01021530 – Patch m_mapScrutinyCRC Not Find : %s
014CFAE0 – Patch Speed 0.04 MB/sec Remaining Time 31:24:55
02EB9D68 – PATCH/PATCH_0117_1449625937/DAT/DAT4/DAT2298.CMF
02EB9DE0 – PATCH/PATCH_0117_1449625937/DAT/DAT4/DAT2298.CMF
02EB9E58 – PATCH/PATCH_0117_1449625937/DAT/DAT45/DAT22980.CMF
02EB9ED0 – PATCH/PATCH_0117_1449625937/DAT/DAT45/DAT22980.CMF
02EB9F48 – PATCH/PATCH_0117_1449625937/DAT/DAT45/DAT22981.CMF

관계없는 문자열들도 있지만 필요한 문자열들이 잘 추출된 것을 확인할 수 있다.

다음으로, 목록이 준비되었으니 파일들을 다운로드 하는 일이 남았다.

처음에는 Task 를 대량으로 만들고 Task에서 HttpWebRequest 를 써서 다운로드하려고 햇으나 이렇게 하면 4개 Task 만이 실행되고 나머지는 waiting 상태로 대기만 하는 것으로 나타났다. 직접 스레드를 실행하거나 아니면 스케줄러를 조정해야 하나… 잘 모르겠다.

그러던 중 검색을 해보니 WebClient 클래스를 사용하면 파일 다운로드를 더 간단히 백그라운드로 처리할 수 있길래 적용했다. 하지만 이것만으로는 실제 접속 수가 늘어나는 것은 아니고 ServicePointManager.DefaultConnectionLimit 값도 변경해야 했다. 처음에는 10000 으로 했더니 OotOfMemoryException 이 일어나더라. 지금은 100 으로 변경했다.

아무튼 이렇게 해서 다운로드 받으니 1시간이 걸리지 않았다.

마지막으로, 시작할 때마다 웹페이지를 찾아가서 실행하고 권한 상승 프롬프트도 뜨길래 직접 바로가기를 쓸 수 있지 않을까 해서 찾아봤다.

로그인까지 문제없이 되는 것을 확인했다. 아마 플레이도 문제 없을 듯.

타겟은 다음과 같다.

“{installation path}\CW.EXE” “{installation path}\LAUNCHER.EXE” _LC 1 _L http://closerspatch.mangot5.com/closerspatch/live/

 

한 줄 요약: 역시 백수가 되니까 시간을 너무 낭비하는 것 같다.


결과를 저장하는 차원에서 짠 프로그램과 추출한 string map 을 첨부한다.

CLJP_DOWNLOAD