Dev Talk

네 일단 말씀하신 내용은 가능은 해보이구요
이 내용과 지금 구조적으로 가장 비슷한게 폰트매퍼 플러그인인데
이 놈은 폰트관련함수 / 텍스트출력함수 들을 후킹하는 동시에
컨텍스트에 필터 오브젝트도 생성할 수 있습니다.
즉, 필터플러그인 이면서 후킹까지하는 꽤나 걸쳐진(?) 녀석이죠.

그런데 저도 이와 관련해서 생각해 본적이 있는데
바로 ATCode 플러그인에 스크립트를 지원하자는 것이었습니다.
지금은 라디오 버튼으로 1. 아무작업 안함 / 2. 메모리 덮어쓰기 / 3.포인터 바꾸기 등을 고르지만
스크립트 직접 작성 이란 고급 항목을 둬서 직접 동작을 프로그래밍 하는 것이죠
즉, 아래 두개는 같은 동작을 뜻하는 겁니다.

<기존 방식 사용>
0x405060 코드지점에서 [ESP+0x8] 인자 번역
번역 방식은 포인터 바꿔치기

<스크립트 직접 작성>
0x405060 코드지점에서 스크립트 직접 작성

void OnCode405060(REGISTER_ENTRY* pReg)
{
      // 여기에 코드를 작성해주세요
      char buf[1024];
      Translate(pReg->ESP + 0x8, buf);
      *(pReg->ESP + 0x8) = buf;
}

뭐 대충 이런식... 그런데 스크립트 엔진 손좀 봐야 겠네요.
ATCode 플러그인 뜯어보시면 발견하셨을 수 있겠지만 스크립트 엔진이 하나 들어있습니다.
여차하면 그걸 개조하려구요

저도 테스트후기에서 실행파일 수정하시는 것을 보면서 비슷한 생각을 했는데요..
코드 후킹지점에서 경직된 행동을 하는 것이 아니라 스크립트 같은 유연한 방법을
사용하면 실행파일 수정이라는 복잡한 과정을 거치지 않더라도 되지 않을까 하는..

그래서 생각한 대안이 3가지 있습니다.. 만 각각이 장단점이 있군요.

1. 스크립트 방식
- 장점: (C/C++ 프로그래밍에 비해 간단한) 스크립트 언어만 이해하면 되므로 익히기가 비교적 쉽다.
- 단점: 스크립트 자체가 지원하는 기능이 부실할 경우 한계가 보일 수 있다. 추가기능을 넣으려면
  플러그인을 그때그때 고쳐야 하고 무작정 기능을 부풀리다 보면 오히려 사용하기 어렵게 될 가능성이 높다.

2. ATCode 의 플러그인 (게임 전용 DLL - 게임 내의 ATData 폴더에 위치) 으로 작동하는 방식
- 장점: C/C++ 언어를 그대로 사용하므로 스크립트 엔진이 필요없다. DLL 인터페이스만 제공하므로
  구현이 쉽다.
- 단점: "플러그인의 플러그인" 이라는 또 다른 플러그인 인터페이스를 정의해야 한다.. ATCode
  플러그인과 게임 전용 플러그인과의 소통이 어렵다.

3. ATCode 플러그인 소스를 고쳐서 "게임 전용 알고리즘 DLL" (알고리즘 폴더에 위치) 로 하나로 만드는 방식
- 장점: 결국 알고리즘 플러그인이므로 추가의 플러그인 인터페이스 문제는 없다. 물론 소통 문제도 없다.
- 단점: 게임 전용 알고리즘 DLL 이 난립하게 될 우려가 있다.
  "이 모든 플러그인을 전부 자동 업데이트에 넣어야 하나?" 라는 문제가 생긴다.