Infinite Ammo/Generic DLC encryption/Reverse-engineering:
The main concept is this:
__asm mov edx, BABAC8B6 // xor key
__asm mov eax, [ecx+64] // ammo1
__asm add eax, [ecx+68] // ammo2
__asm xor eax, edx // xor with key
__asm retn // return with ammo value
Imagine that ecx+64 holds the first value, Ammo1.
Let ecx+68 hold the second value, Ammo2.
The goal is that (Ammo1+Ammo2) xor Key = CurrentAmmo.
For most people it will be very obvious to solve this.
ammunition processing, obviously the value has long been obfuscated.
Simply searching for your ammo value will not work because it is stored
as not only a xored value, but half of that value.
way to find the function if needed is simply to search for an unknown
value, and then search for decreasing values every 2 shots, and you
might then find '2' unsigned long next to each other which is normal)
But the obfuscation is very simple, and most of their actual 'encryption' calls and obfuscations follow the same exact format.
easy way to solve this problem while knowing the key is that once you
have access to the weapon structure to change ammo values:
DWORD XorKey = 0xBABAC8B6;
// Note: ActualAmmo = (Ammo1 + Ammo2) ^ XorKey;, obviously this is what you want to store or maintain for infinite ammo
DWORD Ammo1 = (XorKey/2);
DWORD Ammo2 = (XorKey/2);
Ammo1++; // add one, to ensure you always have 1 bullet if ActualAmmo==0
Note what happens now is essentially this:
(5D5D645B + 5D5D645C) xor BABAC8B6 =1
BABAC8B7 xor BABAC8B6 = 1
Even if you had 0 bullets, you should now have 1 bullet.
Note that the better programmatic solution is this (the above was for understanding):
DWORD Ammo1 = (XorKey ^ 1) / 2; // ensure value of 1
same encryption is applied on most of their file-patching and DLCs (ex: https://www.youtube.com/watch?v=UvlyZpO0pCs)