R5Reloaded/r5sdk
1
0
Fork 0
mirror of https://github.com/Mauler125/r5sdk.git synced 2025-02-09 19:15:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Fix desync in CUtlbuffer::ParseToken in assembled code

Browse Source 
See commit 4969a840300bbafbc5a47f06fef41751a5620fc9, the same fix has been applied to the game executable.
This commit is contained in:
Kawe Mazidjatari 2023-06-07 22:15:28 +02:00
parent 4969a84030
commit 4290b08fd0
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
r5dev/resource/patch/r5apex.patch
View File

@ -71,6 +71,16 @@
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 ////