.gif)
아하하 ㅡㅗㅡ;;; 역시 테스트 안하고 버그 없기를 바라는 것은 무리였습니다;
변경점
1. LEN 루틴을 만들어놓고 실제 프로그램과 연결 안 했던 문제 수정.....;;;;
- LEN 루틴 자체는 로그를 보니 제대로 작동하는 듯 합니다.
2. 옵션에서 LEN 옵션을 꺼도 삭제되지 않던 문제 수정.
3. SMSTR 에서 LEN 옵션이 m_pArgText 기준으로 돌아가도록 수정.
문제점
1. SMSTR(IGNORE) 와 SMSTR(MATCH) 아직 테스트해보지 못했음.
- 이 기능을 써야 하는 게임이 뭐가 있는지 모르기 때문에 테스트할 환경이 안돼서...
2. 생각해보니 LEN(-4) 같은 경우 SOW 같은 방식인 경우 앞을 다 잡아먹기 때문에
문제가 생길 가능성이 높군요. SOW 시의 LEN 처리를 개선해야 할 듯.
FrigateBird
- 2012.03.02
- 12:29:17
SMSTR(IGNORE) 동작할때도
ZeroMemory(pMain, sizeof(DWORD) * 4);
이녀석이 동작해서 기존 포인터를 날려먹어버리네요.
SMSTR(IGNORE) 와 SMSTR(MATCH) 가 동작할때는..
즉,
if(sLen >= 0x10){ 혹은 if(sLen >= 0x8){
// 긴 문자열
....
...
..
// 기존 내용 삭제
ZeroMemory(pMain, sizeof(DWORD) * 4); <--제거
버그 하나 잡.
FrigateBird
- 2012.03.02
- 12:50:31
if(sLen >= 0x8){
// 긴 문자열
NOTIFY_DEBUG_MESSAGE(_T("SMSTR: ApplySmartString: Unicode long\n"));
// 기존 내용 삭제
//ZeroMemory(pMain, sizeof(DWORD) * 4); <--여기랑
if(sLen >= 0x10){
// 긴 문자열
NOTIFY_DEBUG_MESSAGE(_T("SMSTR: ApplySmartString: ANSI long\n"));
// 기존 내용 삭제
//ZeroMemory(pMain, sizeof(DWORD) * 4); <--여기랑
2군데 수정하고 SMSTR(IGNORE) 와 SMSTR(MATCH) 테스트 결과.
이상없음.
^-^
FrigateBird
- 2012.03.02
- 13:23:11
LEN 쪽도 이상하네요.
포인터 변경이 되면 이상한 값으로 변경되서 나오네요.
정확히 사용법이
+0x4, 0x4, 4
어떤값을 집어넣어야 되나요?
FrigateBird
- 2012.03.02
- 13:35:28
+0x4 로 잘 동작하는군요.
그런데..
해당 지점의 밖에 위치에서 LEN이 있을 경우에 까지는 동작하지 않네요?
완전히 대사의 위치로부터 이격한 위치값만 참조하는데;;
FrigateBird
- 2012.03.02
- 13:41:14
ex)
0x0042064D 위치 후킹
[[eax+ebx*0x4]] 장소에 대사가 있으며, 포인터로 후킹한 인자는 [eax+ebx*0x4] 이며 이 장소의 포인터를 교체할 예정.
+0x4 위치에 길이가 있다. (포인터로 부터 떨어진 LEN 값.)
정확한 위치는 [eax+ebx*0x4]+0x4이며 이 부분이 바꿔지거나 비교할 참조값.
이상 증상1. LEN 값은 정상이나.. 더하는 대상이 대사 장소로부터 이격함...
[[eax+ebx*0x4]]+0x4 장소에 값(원문의 +0x4 위치의 글자)을 가져와서 원문 길이측정한것과 비교하고 있음.
글자이므로 당연히 에러. [eax+ebx*0x4]+0x4 위치를 참조가 제대로 되지않음.
whoami
- 2012.03.02
- 17:42:49
1. 아 그렇군요. 일반적인 경우 포인터를 바꿔넣으므로 상관이 없는데
IGNORE 나 MATCH에서는 지우면 안되는군요; 빼버리거나 옵션에 따라 결정하도록 해야겠군요.
2. LEN(숫자) 의 경우 무조건 16진수로 계산됩니다. 맨 앞의 + 나 0, 0x 등은 무시하도록 만들어져 있습니다.
따라서 4 = +4 = +04 = +0x4 가 되어야 정상입니다.
3. LEN(수식) 이 버그는 제가 직접 테스트하면서 잡아야 할 것 같은데요.
게임 이름하고 ATCode 옵션, 기타 필터세팅 등을 좀 알려주세요.
공개 곤란하시다면 비밀글로라도..
whoami
- 2012.03.03
- 01:26:32
자기 전에 잠시 테스트해봤습니다.
아. 그 전에 잠시 알려드릴 사항이 있는데, OVERWRITE 에서 왜 LEN(4) 가 잘 동작하지 않는가.. 를 적습니다.
일단 OVERWRITE 에서 상대위치로 할 경우 저는 다음과 같은 경우를 상정해서 만들었습니다.
(예) 4ABCD
앞의 4 는 ABCD 의 길이이고, pArgText 는 A 를 가리키고 있을 겁니다. 이 때 LEN(-4) 를 넣어주면 보정이 되겠죠.
거꾸로 말해서 OVERWRITE 시에는 LEN 옵션이 + 가 되는 경우는 거의 없을 겁니다. 문자를 가리키게 되니까요.
또 OVERWRITE 에서 번역인자에서 번역인자를 가리키는 포인터를 뽑아내기가 힘들다는 문제도 있습니다.
C로 말씀드리자면 char str[]="ABCD", *pstr=str; 에서 str 의 주소를 안다고 해도 pstr 의 주소를
찾기는 힘들다는 것이죠.. (더 헷갈리려나)
따라서 이럴 때에는 LEN(수식) 을 써 주시기 바랍니다. LEN([EAX+EBX*0x4]+0x4) 처럼 말이죠.
그럼 이제 넘어와서... 말씀하신 게임을 테스트해봤는데요. 일단 제 컴퓨터 (Win7 x64 SP1) 에서는
PTRCHEAT 방식으로 하면 에러가 나면서 종료됩니다. LEN 세팅이 없더라도 말이죠.
그래서 그냥 OVERWRITE 방식으로 했는데도 제대로 작동이 되지 않더군요.. 그래서 로그를 좀 늘려봤는데
다음과 같이 나왔습니다.
옵션 - TRANS([[EAX+EBX*0x4]],OVERWRITE,LEN([EAX+EBX*0x4]+0x4))
GetTextPoint: called
GetTextPoint: pArgText=077C3478
IsValidTextPoint: called
IsValidTextPoint: return TRUE
IsDuplicateText: called
IsDuplicateText: return FALSE
ChangeLength: called
ChangeLength: pnLen=06B5CB0C, *pnLen=19(0x00000013), pnLen-4=06B5CB08, *(pnLen-4)=077C3478
ChangeLength: nOrigLen = 18
*(pnLen-4) 와 pArgText 가 동일하므로 확실히 pnLen 은 문자길이를 가리키고 있습니다.
그런데 *pnLen = 19 이고 nOrigLen = 18 입니다.. 1이 달라서 덮어쓰기가 되지 않고 있습니다;;
아마 이 위치에는 문자열 + \0 을 포함한 문자길이+1 의 값이 들어가게 되어 있는 듯 합니다..
이걸 어쩔까요? 문자열 길이 비교할 때 (*pnLen==nTempLen || *pnLen==nTempLen+1 ) 로 해야 할까요?
FrigateBird
- 2012.03.03
- 02:14:41
1. 아 이렇게도 LEN([EAX+EBX*0x4]+0x4) 되는거였군요?
2. 또한 OVERWRITE 에서 LEN(-4) 동작도 제대로 되는걸 확인했습니다.
ex)七つのふしぎの終わるとき QLIE 엔진에서 동작 확인
3. 지금 생각해보니 특정 엔진에서는 널 문자 포함한 길이를 사용할때도 있던데..
거기까지 생각을 깜빡했네요;;
안전하지는 않지만, 길이 값과 널 값과의 차이로 자동 인식하게 하는것도 나쁘지 않을 것 같네요.
FrigateBird
- 2012.03.03
- 02:38:44
OVERWRITE 에서 LEN 이 잘 작동하는걸 확인했는데
TRANS([ebp-0x4],LEN(-4),OVERWRITE(IGNORE))
좀 튕기길래 PTRCHEAT 방식으로 하려고 하니.. 제대로 되지 않네요?
TRANS([ebp-0x4],LEN([EBP-0X4]-0X4),PTRCHEAT)
수식으로 했는데 말이지요;
FrigateBird
- 2012.03.03
- 03:07:28
확인 보고.
PTRCHEAT 로 할시 해당 포인터는 제대로 변경되나...
변경된 지점의 LEN 위치에 길이가 없음.
변경되기 전 포인터의 원문 길이 지점 LEN(-4) 라고 할때 이곳에는 변경된 길이가 제대로 들어갔지만
(사실상 저기가 바뀌면 안됩니다. 가리키는 메모리 내에 원문길이가 변동되지 않았으니 길이만 수정해버리면
나중에 재 로드시 문제가 생기게 됩니다.)
포인터로 갈아치운(즉 아랄 버퍼로 번역된 포인터 내에 번역문의 이격 지점 LEN(-4) 에는 아무것도 안들어감. 오로지 번역문만 존재...) 게 뭔가 의미 없어졌네요;;
고로 아랄 버퍼 포인터로 변경 후 그 지점내 LEN 이격 지점에도 길이 복사 하나 더 집어넣으시면 될것같네요.
FrigateBird
- 2012.03.03
- 03:28:41
간단히 버그를 토끼(?)가 이해하게 말하자면
메모리가 아닌
포인터일 경우
// 이제 번역문의 길이로 바꿔넣는다.
nTempLen = (m_bUnicode ? lstrlenW((LPCWSTR)m_pTransTextBuf) : lstrlenA((LPCSTR)m_pTransTextBuf));
if (nBytes == 1)
*(BYTE *)pnLen = nTempLen & 0x0FF;
else if (nBytes == 2)
*(WORD *)pnLen = nTempLen & 0x0FFFF;
else
{
*pnLen = nTempLen;
pnLen = (int *)((DWORD)m_pTransTextBuf + m_nLenPos);
*pnLen = nTempLen;
}
이렇게 마지막 추가하면 되려나요.
FrigateBird
- 2012.03.03
- 03:34:04
OK 저 2줄 추가로 포인터에서 되는걸 확인.
허나. 그 위에 부분인 *pnLen = nTempLen; 가 움직여서
포인터가 바뀐 원 장소에 길이가 바뀌어 버렸음.
(고정 위치 원문일 경우 리로드 시 길이 오류가 생길 가능성이 있음)
아무래도 구분해서
메모리일때는
*pnLen = nTempLen;
포인터일때는
pnLen = (int *)((DWORD)m_pTransTextBuf + m_nLenPos);
*pnLen = nTempLen;
로 따로 분리해서 놓는게 가장 이상적이네요. (차후 버그를 생각했을때)
당장 분리해야되네요 ㅡㅡ 백로그에서 벌써 버그 튀어나옴.
걍 포인터 바꾸고 왔는지 메모리 덮어썻는지 확인 처리해버림.
FrigateBird
- 2012.03.03
- 04:12:03
대~충
else
{
if ( bPos == TRUE)
*pnLen = nTempLen;
else
{
pnLen = (int *)((DWORD)m_pTransTextBuf + m_nLenPos);
*pnLen = nTempLen;
}
}
갈기고 끝
스마트 쪽은 모르겠다 아우...
저긴 변수가 너무 많아서 생각하기 골치아프네요.
일단 SOW, PTRCHEAT, OVERWRITE 쪽만 구분해놓았습니다.
OTL SOW 는 테스트 안해봐서 모르겠지만 맞을거고..
PTRCHEAT, OVERWRITE 는 LEN이 이상없이 돌아가는걸 확인.
FrigateBird
- 2012.03.03
- 05:03:04
해당 것으로 내놓은 코드 2개.
첫번째는 LEN 을 사용한 형태(포인터)
(메모리 형식도 되는걸 확인, 하지만 버퍼가 정해진 것보다 넘어가버릴 때 운없으면 튕김. 그래서 포인터 방식으로 취함)
두번째는 SMSTR(IGNORE), SMSTR(기본) 의 적절한 코드 위치에 병행사용 으로 인한 오류 제거
문제없는 코드가 이렇게 2개가 나오니 기쁘군요.
고생하셨습니다.
FrigateBird
- 2012.03.03
- 15:30:05
真剣で私に恋しなさい！Ｓ
하는 중....
SMSTR(기본) 적용시 튕기는 현상..
확인결과 대사 이외의 위치에서 값이 없어서 그러는 모양.
(이건 뭐 어쩔 수가 없네요. +,- 어느 정도 버퍼 범위를 복사해올 수 도 없는 노릇이고..)
다른 위치에서 후킹하면 되지만 위치 찾기도 귀찮네요.
문제점 1 은 제가 테스트 해보도록 하겠습니다.
겸사겸사 LEN도 확인해보겠습니다.