Undo CUtlBuffer::ParseToken patch

The bug was only reproduced on the compiled implementation in the game executable. The CUtlBuffer::ParseToken implementation in the SDK did not bug on the same input string. More research is required, and a possible good fix would be to just hook and replace the game's implementation with that of the SDK.
This commit is contained in:
Kawe Mazidjatari 2023-06-23 00:27:24 +02:00
parent a93824b2db
commit cfa2172322
2 changed files with 3 additions and 10 deletions

View File

@ -71,16 +71,6 @@
0x6FD0EE: "nop (x4)" // Nop 'minss xmm0, xmm6' (extraneous clamp).
0x6FD114: "nop (x3)" // Nop 'movaps xmm6, xmm0' (extraneous move operation).
// This fixes a bug where the control member 'CUtlBuffer::m_Get' is out of sync with the text buffer in 'CUtlBuffer::ParseToken'.
// When we iterate over each character in the token buffer, we perform an equality test between the read len and buf len to prevent
// a buffer overflow. Before this test happens, the read len always gets incremented by 1.
// When the test fails, the code continues to where it checks if the control character is a break character (delimiter), if so,
// the code breaks out of the loop, decrements the 'm_Get' member variable by 1, null-terminates the token buffer and returns the
// read len. The issue is that read len has been incremented by 1 during the equality test, but the m_Get member variable by -1,
// causing a desync. The next time 'ParseToken' is getting called, the control character will be off by one as 'm_Get' is off by one.
// The fix is to just nop the decrement operation in assembled code (see commit '4969a84' for the source code fix).
0x47E03A: "nop (x4)"
/////////////////////////////
/////////////////////////////
//// Exploitable defects ////

View File

@ -1429,7 +1429,10 @@ int64 CUtlBuffer::ParseToken(characterset_t* pBreaks, char* pTokenBuf, int64 nMa
break;
if (IN_CHARACTERSET(*pBreaks, c) || c == '\"' || c <= ' ')
{
SeekGet(SEEK_CURRENT, -1);
break;
}
}
pTokenBuf[nLen] = 0;