Board Thread:Game Discussion/@comment-31526827-20180615024459/@comment-120.20.83.107-20180617235903

DrestinBlack wrote: Sirebel wrote: If only it was that simple but ultimately the numbers you recognise on the screen have to be stored in memory somewhere in order to display them. A decent hacker will just work back from there to find the multiplier and the stored location of the multiplied number. This would only reduce the number of hackers until one of the hackers made the multiplier and locations public.

There are easy ways to protect in memory data (or your banking app would be too easy to hack) but that would probably require a rewrite of large amounts of the RR3 code base. With all due respect, you must not be a programmer. I have written games before. The way the hack works is very blunt, actually. It searches ALL of the programs variable space for an exact match to some number the use types in and allows a bulk replacement. It has to be a search because that location changes every time the game is run. My new solution is unhackable because it’s hidden in code and can can change at any time/as often as necessary. If hackers found the multiplier somehow, the Monmeys would simply change it’s vdlue and location.

You moght be thinking, this is too easy. It is easy and that’s why it’s even more obvious the Monkeys don’t care about anti-cheating. Why don’t they fix this bouncing through walls BS, or ability to drive off track without penalty.

The stat hacking affects WTTT to, not just OMP. In my opinion, anyone in the top 100 using an android device is Likely to be cheating. It’s so easy, why not. Oh, but so and so has a video showing it being done. Sure, and why would you assume that that isn’t using a hacked vehicle? @dib,

You are better off using a primitive Modulus-N Checksum "algorithm" rather than a hidden multiplier because once you have mapped out the games memory space which is always based on relative memory addresses (not absolute addresses ones), you can simply INC, DEC, ADD or SUB the contents of said location and see how it impacts on the game without having the foggiest idea of any multiplier etc. Even using cheap XOR encryption methods would make no difference to my ability to ++ or -- the value of any memory address at runtime...

@sirebel,

IMO, most banking apps that run on mobile platforms simply make https requests to server. They are no more/less safer than logging into your FB account. I would be surprised if any real vulnerable stuff would be stored on the client, just pretty backgrounds, buttons, slash screens, fart noises other non-critical components. And of course, usernames and passwords have to be cached somewhere and how?

@my point: In a utopian universe, you could use X,Y parity matrixes where altered values could be restored back to their original non-tampered states, but the performance hit would be huge. As an example, ECC RAM traditionally used in servers is much slower than non-ECC, and that's before the CPU has even got it's hands dirty! Memory Latency is the biggest enemy of any game dev...

Finally, the SDK and proprietary API's can severely restrict your ability to do anything really useful even if you wanted too...