From 4290b08fd041bc4e7eebeced15ccdedfd9556939 Mon Sep 17 00:00:00 2001
From: Kawe Mazidjatari <48657826+Mauler125@users.noreply.github.com>
Date: Wed, 7 Jun 2023 22:15:28 +0200
Subject: [PATCH] Fix desync in CUtlbuffer::ParseToken in assembled code

See commit 4969a840300bbafbc5a47f06fef41751a5620fc9, the same fix has been applied to the game executable.
---
 r5dev/resource/patch/r5apex.patch | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/r5dev/resource/patch/r5apex.patch b/r5dev/resource/patch/r5apex.patch
index 88a31424..d6eedd7d 100644
--- a/r5dev/resource/patch/r5apex.patch
+++ b/r5dev/resource/patch/r5apex.patch
@@ -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 ////