내가 좋아했던 게임을 위한 파반느 (4) ~ 서바이벌 프로젝트를 내 로컬에서 ~

전편에 이어 클로드에게 윽박지르는 나의 모습..

바보 같은 나의 모습... 이지만 클로드는 더 바보같았다.

물론 저걸 진행할 때 보다 지금은 더 똑똑해져 있겠지만...

그래도 뭐 클로드가 함께있어서 좀 재밌는 삽질이 아닌가 싶다.

 

계속하겠다...

수정한 게 반영이 안 된다

UDP 쪽에 로그를 잔뜩 박았는데 하나도 안 찍혔다. 클로드는 "다시 빌드해주세요", "저장하셨나요?", "캐시 문제예요" 순으로 돌아갔다.

"아니 UDPServer.h 자체가 들어오긴 하는거야? 문구를 바꾸던지 그래야하는거아니냔말이지"

 

그래서 ----- UDP Server Started ----- 문구를 아주 아름답게(비속어) 바꿨다.
다시 빌드하고 F5. 콘솔에는 여전히 원래 문구가 떴다.

"아니면 다른쪽에 printf(“----- UDP Server Started -----\n”); 찍는거 있는게 아닐까? 아니면 실행하는 옵션이 이상하다던지....”

 

그러다 #include "UDPServer.h"를 Ctrl+클릭해 보니 다른 파일이 열렸다.

 

“include 된걸 컨트롤 누르고 들어가니까 다른 파일이 열리는데? 파일명이동일한데 왜다른거지”

 

 

솔루션 탐색기에서 PacketHandler.cpp의 실제 위치를 확인해 보니,

 

...\Desktop\서바이벌프로젝트 서버\files\sp_server-master\Channl32\PacketHandler.cpp

 

C:\workspace로 옮기기 전, 바탕화면에 처음 풀어놨던 폴더의 파일이 프로젝트에 그대로 물려 있었다. 그러니 그동안 workspace 쪽 파일을 아무리 고쳐도 빌드에 들어갈 리가 없었다.

그동안 수정한 거 다 어디 갔냐..

프로젝트에서 제거하고 지금 폴더의 파일로 다시 추가하자 드디어 바꾼 문구가 찍혔다.

 

UDP Server binding port: 9303
UDP Server bind success on port 9303
----- UDP Server Started (차마 못 쓰는 단어) -----

결국 답은 살아있는 사설서버에 있었다

이제 서버는 패킷을 다 보내는데, 클라이언트는 무한로딩에 빠져서 UDP 연결을 시도조차 안 했다.

클로드는 패킷 구조를 추측으로 고치기 시작했다. JOIN_CHANNEL_RESPONSE의 unk9에 9303을 넣어보자고 하고, 패킷 타입 번호도 바꿔보자고 했다. 그렇게 고치다 보니 두 #define이 같은 숫자를 갖게 됐다.

 

"여기 보면 17154가 2개인데 이게 맞는거야? 처음 값인 17271이 맞지 않을까?"

"아니 근데 너가 아까 0이 맞다면서?"

 

클로드도 "맞아요 제가 틀렸어요"를 연발했다. 그러다 이런 말을 했다.

 

"실제 사설 서버 클라이언트와 비교... 그때 Wireshark로 잡았다면 패킷 구조를 비교할 수 있는데, 지금은 안 돼요."

 

 

안 되긴 왜 안 돼.

 

 

 

"아니 사설서버 킬수 있는데? 켜볼까?"

 

 

맨 처음 내 서버로 안 붙고 사설서버로 붙어서 애먹였던 그 사설서버가 아직 살아 있었다. 이번엔 그게 답안지였다. 원본 클라이언트로 사설서버에 접속하고 Wireshark를 켰다. 클로드가 필터를 9303으로 걸라기에,

 

“9303이 아니지 않았어 udp 포트가..?”

 

 

사설서버는 TCP와 UDP 모두 21003 포트를 쓰고 있었다.

여기서 한 가지 더 삽질했다. Wireshark 패킷 덤프를 붙여넣으면 첨부파일로 바뀌어서 올라가는데, 클로드는 그걸 계속 "문서가 비어있어요"라고 했다.

 

결국 스크린샷이랑 짧은 hex 덤프로 하나씩 넘겼다.

 

그렇게 사설서버 패킷을 까서 비교해 보니 차이가 보이기 시작했다.

 

첫 번째 차이: JOIN_CHANNEL_RESPONSE(0x4377) 크기

• 사설서버: 0x44 (68바이트), unk 필드는 전부 0
• 우리 서버: 0x40 (64바이트)

구조체에 int 하나를 추가하고 size를 0x44로 맞췄다. First response: sent 68 bytes. 하지만 여전히 무한로딩이었다.

두 번째 차이: 0x4377을 두 번 보낸다

사설서버의 흐름은 이랬다.

1. 0x4377 (68b), 채널 입장 응답
2. 데이터가 왕창 옴
3. 0x4377 (68b), 같은 패킷 한 번 더
4. 이 직후에 클라이언트가 UDP 시작 (10000 → 21003 Len=52)

우리 서버도 RoomList 다음에 0x4377을 한 번 더 보내게 바꿨다.

 

First response: sent 68 bytes
MissionLevel sent: 28 bytes
PlayerData sent: 2432 bytes
LobbyUserInfo sent: 60 bytes
RoomList sent: 3216 bytes
Second JOIN_CHANNEL sent: 68 bytes

 

Wireshark로 확인해 보니 두 번째 0x4377도 잘 나갔다. 그런데 UDP는 여전히 조용했다.

 

세 번째 차이: 보내는 양이 다르다

두 번째 0x4377까지 보낸 TCP 데이터

우리 서버	약 5.8KB
사설서버	약 48KB

약 42KB가 비어 있다.

사설서버 쪽 PlayerData(0x4302) 크기도 0x979로, 우리(0x980)와 달랐다. 나머지 42KB가 무슨 패킷인지는 아직 모른다.

현재 상태

• 서버 빌드 O
• 클라이언트 IP 패치 (127.000.000.001) O
• 로그인 / 튜토리얼 스킵 O
• 채널 선택 O
• 채널 입장 후 로비 진입 X (UDP가 안 붙음)

다음 할 일은 사설서버 캡처에서 Follow TCP Stream으로 저 42KB를 패킷 타입별로 쪼개보는 거다.

돌아보면 이번 편은 “AI가 시키는 대로 하면 된다”가 아니었다. 클로드는 빌드 에러나 헥스 덤프 해석 같은 건 나보다 압도적으로 빨랐다.
 하지만 이놈의 클로드는 막히는 순간마다 너무 쉽게 우회로를 꺼내거나 포기하자고 했다. DxWnd, Proxifier, 가짜 체크섬, 하드코딩, 다른 에뮬레이터 찾기가 다 그랬다. 그걸 "아니 그게 아니라"로 되돌린 건 C++도 모르는 자바 웹 개발자의 상식이었다.

• 사설서버 운영자가 그렇게 어려운 걸 했을까?
• 두 exe가 다르면 포트라도 달라야 하는 거 아냐?
• 똑같은 상대경로인데 왜 하나만 못 읽어?
• 디버깅 장치부터 만드는 게 빠른 거 아냐?

5년 넘게 웹 장애를 잡으면서 몸에 밴 감은 언어가 달라도 통했다. 그게 이번 삽질에서 얻은 제일 큰 수확이다.

여튼.. 아직 로비 문턱이다. 쥐엔장...

 

 

 이전 글들이나 위 글들을 보다보면 정말 클로드한테 윽박지르는게 짜증스러운 인성파탄자 개발자 느낌이긴 한데,

동료한테는 안이런다 (진짜임).

 

 

 이후 부터는 최근 AI 관련 유튭을 보며 알게 된 REA (Reverse Engineer Anything)으로 해볼까 한다 
대단하다 리버스 엔지니어링 프로그램으로 그림판, 게임, 프로미어프로등,, 엄청난 프로그램을 역으로 분석해서

내 것으로 재조립 할 수 있다니.. 
어쩌면 내가 지금껏 꾸어오든 내가 좋아던 게임의 부활을 노려볼 수 있을지도 모르겠다.

하루 빨리 해보고 싶으나, 오늘은 여기까지....

 

혹시 모르니 github 링크를 남겨본다. 정말 화제의 라이브러리니 반드시 포크하고 로컬로 zip도 저장하길 바란다..

 

https://github.com/morluto/rea

GitHub - morluto/rea: Reverse engineer anything with agents, from app behavior down to native binaries.

 

그럼 다음 시간에 ...


마지막 짤은 요즘 푹 빠져서 보고 있는 평범한 경음부(만화책)의 한 장면으로..