아트록스의 파라미터 파일은 SPM에서 LHA 압축을 풀면 나오는 맵데이터(MAPDATA) 파일에서 얻을 수 있다. 원래 아트록스에서 파라미터는 유닛의 능력치를 의미하지만, 아트록스의 맵에디터에서 보이듯 능력치, 업그레이드, 특수능력의 한 쌍으로 이루어졌다고도 볼 수 있다. 그래서 이 포스트에서도 업그레이드와 특수능력의 분석까지 다루게 되었다. 먼저, 맵데이터 파일에서 파라미터 구조는 다음과 같다. 플레이어1 유닛 능력치플레이어1 업그레이드플레이어1 특수능력...플레이어8 유닛 능력치플레이어8 업그레이드플레이어8 특수능력 파라미터로 가기 위해서는 플레이어1 유닛 능력치의 주소를 알아내야 하는데, 아직 그것까지는 분석하지 않았고(이것을 얻기 위해서는 모든 맵데이터의 정보를 알아내야 할 것 같은 느낌이라서 포..

이번 휴가가 군 생활에서 3번째 휴가인데 아무 계획도 없이 무작정 나와서 정말로 아무것도 하지 않았다. 저번 휴가 때도 아무 계획 없이 나오기는 했지만 그래도 아트록스 해상도 패치라는 나름 만족할만한 성과를 내고 갔었는데 이번 휴가 때는 에이스사가의 스타포스락을 뚫으려고 하다가 덤프 뜨고 IAT를 복구 못 해서 시간만 낭비하는 결과를 내고 말았고, 그 후에는 롤만 하다가 프로그래밍 책 몇 권을 산 게 이번 휴가의 끝이었다. 나는 참 교만했던 게 프로그래밍 언어를 대부분 거의 마스터하고 나서 '이제 더 배울 것도 없겠지, 부대 나가면 게임이나 제작해야지.' 하는 막연한 생각을 하고 있었는데 우연히 dot_product라는 벡터함수 하나를 본 뒤 나의 부족함을 깨달았다. 수학과 물리 함수 하나 짜지 못하고 ..

HQ 파일은 천년의신화, 임진록2, 임진록2+ 조선의반격에 존재하는 파일이며, Data/Data.hq, Hq/Hq.hq 이렇게 두 개의 쌍으로 존재합니다. 여기서 *.hq는 헤더파일, *은 패킹 된 파일로 분류되지요. 아울러 쌍으로 된 이 파일들은 기본적으로 "(var & 16) ? var-16 : var+16" 암호화가 되어있어 먼저 복호화를 해줘야 합니다. 복호화된 천년의신화의 Data.hq 모습. 총라인수 : [파일 개수]->파일 명\t[파일 크기]\t[파일 오프셋]->파일 명\t[파일 크기]\t[파일 오프셋]…. 헤더는 이처럼 먼저 파일명이 명시된 뒤 크기와 오프셋이 뒤따르는 구조입니다.

임진록2+ 조선의반격 밸런스 수정기를 만들려고 노가다 중. HQ팀은 왜 능력치를 EXE 안에 둬서 어떤 게 어떤 능력인지도 구별하기 힘들게 하는지 모르겠다. 능력치를 하나하나 바꿔가면서 능력에 주석을 다는 중이다. 이런데에 HEX-RAY를 써보니까 분석이 훨씬 쉬워졌다. 올리디버거로 대충 예상은 가능하긴 한데, IDA에서는 임시변수 이름을 숫자로 직접 변환해준다. HEX-RAY는 리버싱이 막혔을 때 사용하면 정말 좋은 도구인 것 같다. 항상 많은 도움을 받는다. 위 사진은 조반에서 특정 파일이 "(var & 16) ? var-16 : var+16" 암호화를 쓰길래 만들어본 프로그램(UnZip.exe)으로 뽑아낸 자료. 심심해서 만들어 본 건데 정말로 쓸모가 없었다. (막상 만들어놓고 보니 암호화된 파일이..

문득 어렸을 때 했던 고전게임이 하고 싶어지는 때가 있다. 갑자기 고전게임이 생각나며 "그때 그 게임… 그래픽은 구졌어도 재밌게 즐겼었지…" 라던가 "그땐 참 재밌었어…" 라는 그런 생각이 우러나올 때, 바로 그때이다. 그때에 우리는 추억을 회상하거나 그 게임을 직접 찾아보게 된다. 하지만 그렇게 찾은 것이 예전보다 재미없어 바로 삭제하게 되는 이 상황은 과거가 지나치게 미화됐던 것일까 아니면 현대의 게임에 너무 물든 것일까 그것조차 아니라면 함께하던 이의 부재 때문일까…. 어떤 이유에서든 그때의 감정을 다시금 느끼지 못한다는 것이 아쉽다. 그럼에도 먼 훗날 다시금 그때를 회상할 수 있는 것은 우리에겐 아직도 그것들로 인하여 즐거웠고, 그것과 함께 어린 시절을 보냈던 좋은 기억만은 남아 숨 쉬고 있기 때..

아마게돈(Armageddon)의 데이터 파일은 헤더 파일인 Armageddon.HED와 본체 파일인 Armageddon.MFP로 나뉘어 있습니다. HED 파일의 구조를 위 사진을 통해 설명하자면, 맨 앞의 C20F 0000은 압축된 파일의 개수를 나타내며 그 뒤부터는 0x48byte마다 파일의 헤더를 나타냅니다. 이러한 파일의 헤더에서는 맨 앞의 0x04byte는 파일의 오프셋을 나타내고 맨 뒤의 0x04byte는 파일의 사이즈를 나타냅니다. 원래 초기 버전의 아마게돈은 파일이 전부 노출되어 있었지만, 업데이트하면서 HED와 MFP 파일로 아카이브 방식으로 따로 저장해둔 것으로 보입니다.

아트록스의 PAK 파일구조를 그림으로 제시하자면 대충 위 그림과 같습니다. 'Joy Max File Manager!'는 아트록스 파일인지 아닌지를 판별하는 역할을 하며 크기는 0x203으로 추측됩니다. Directory header 부분은(0x204~0x7D1FF) 특정 오프셋을 통하여 그다음 파일헤더 가 어느 위치에 속하는지를 구할 수 있게 도와줍니다. File header에는 파일과 헤더가 공존합니다. 파일의 헤더가 선 제시된 후 파일이 나오고 다음에 또 파일의 헤더와 파일이 제시됩니다. 이처럼 PAK는 마치 디스크의 파일 시스템처럼 체계적인 구조를 지니고 있습니다. 판별자 부분 중간에 나타나는 00E8 0300은 무엇을 하는 역할인지 아직 확실히 연구되지 않았습니다. 파일의 크기도 아니고 PAK의 ..

쥬라기원시전2 더랭커 SPZ 파일의 헤더는 0x20byte이며, 그다음으로는 PNT 파일 불러오기가 시작됩니다. SPZ 파일의 특이한 점은 투명색을 0번 압축 알고리즘을 이용하여 압축한다는 것인데, 아무래도 SPZ가 유닛이미지 파일이다 보니 투명색이 많아 이러한 알고리즘을 사용한 것으로 보입니다. [ 헤더 분석 ] 0x04 | 가로 픽셀0x04 | 세로 픽셀0x04 | 가로 중심점0x04 | 세로 중심점0x04 | 가로 충돌점 (추정)0x04 | 세로 충돌점 (추정)0x04 | 앞머리를 제외한 이미지의 크기0x04 | ? 팔레트를 불러오는 부분에서 바로 시작되는 0x02byte는 구간의 크기를 나타냅니다. 이러한 구간의 크기가 끝난 뒤에는 새로운 구간의 크기가 나타나는 구조로 되어있습니다. 사진에서처럼 ..

쥬라기원시전2 더랭커의 유닛 이동속도는 CEI 파일에 적혀있으며, 오프셋은 다음과 같다. 0x3CC | 상0x5CC | 우상0x7CC | 우0x9CC | 우하0xBCC | 하0xDCC | 좌하0xFCC | 좌0x11CC | 좌상//각 오프셋마다 0x200byte의 크기를 가짐 위 사진과 같이 이동속도는 4byte로 쓰여있으며, {좌우속도, 상하속도}의 8byte 쌍으로 되어있다. 눈으로 판별하기 힘들다면 홀수 번째와 짝수 번째로 판별하면 보기 쉬울 것이다. 이동속도는 CHR파일에 존재하는 m#.spz 이동그림을 토대로 움직이는데, 즉 8byte마다 이동그림 1개의 속도를 의미한다. 총 이동속도의 정보는 0x200byte이므로, 이동그림 64장만 속도를 기입할 수 있다.

쥬라기원시전2 더랭커의 PNT 파일은 위 사진처럼 4byte씩 한 조를 이루며, PNT 파일의 총 크기가 1024byte이므로 총 256개의 색상을 정의할 수 있다. 이렇게 만들어진 팔레트를 더랭커의 그림 파일이 1byte를 사용하여 불러다 쓰는 방식이다. 사진에서 살펴보자면 아래와 같이 RGB와 NULL의 조합으로 반복된다. 0x2C | R0x05 | G0x06 | B0x00 | NULL//4byte를 사용하여 색상 한 개를 표현 덧붙여, PNT 파일 중 유닛의 색상을 나타내는 팔레트는, 다음과 같이 특정 위치에서 특별한 정보를 나타낸다. 0x00~0x04 | 투명 색0x04~0x08 | 그림자 색0x3D4~0x3FC | 각 플레이어 색