View previous topic :: View next topic |
Author |
Message |
DEVCORE Cheater Reputation: 0
Joined: 11 Aug 2018 Posts: 28
|
Posted: Tue Aug 28, 2018 9:56 pm Post subject: Freezing / Nopping Value - A newbie question |
|
|
Hey all, question relating to C++:
1) Say I wanted to freeze a ammo value or health value like in cheat engine. How would I do this in c++ code? Would I just make a while loop and increment that loop by +1 or however much I want?
Or should I nop the address?
Or both ways are correct and those are just 2 different ways of doing it but still get same result?
|
|
Back to top |
|
|
DEVCORE Cheater Reputation: 0
Joined: 11 Aug 2018 Posts: 28
|
Posted: Sat Sep 01, 2018 2:27 am Post subject: |
|
|
Bump!
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 137
Joined: 06 Jul 2014 Posts: 4250
|
Posted: Sat Sep 01, 2018 7:30 am Post subject: |
|
|
If you want to emulate CE's freeze, call WriteProcessMemory periodically.
To replace some code with NOPs, use WriteProcessMemory (and probably VirtualProtectEx).
Search for examples and documentation if needed.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
DEVCORE Cheater Reputation: 0
Joined: 11 Aug 2018 Posts: 28
|
Posted: Sat Sep 01, 2018 9:28 pm Post subject: |
|
|
ParkourPenguin wrote: | If you want to emulate CE's freeze, call WriteProcessMemory periodically.
To replace some code with NOPs, use WriteProcessMemory (and probably VirtualProtectEx).
Search for examples and documentation if needed. |
Thanks. Also to freeze ammo would putting the write function in a loop work the same? Would it be the same thing as using nop?
|
|
Back to top |
|
|
OldCheatEngineUser Whateven rank Reputation: 20
Joined: 01 Feb 2016 Posts: 1586
|
Posted: Sun Sep 02, 2018 1:59 am Post subject: |
|
|
pLearner wrote: | Thanks. Also to freeze ammo would putting the write function in a loop work the same? Would it be the same thing as using nop? |
you can make a while-loop (while true or while hotkey pressed or even while value is not equal to 100)
looping thru write process memory is what ce freeze option does, which means it will keep writing the same value over and over and over .. every couple ms.
nop is not the same, its almost similar to removing the instruction that writes to the address.
nop meaning No OPeration.
while-loop:
pros:
you can terminate it whenever you like.
cons:
if game thread have the highest priority, then most likely you while-loop is useless.
nop:
pros:
game function will never update the value. (you can also close your trainer after the temp-patch)
cons:
if the game have more than one function related to that address, then you have to patch every function can write to your address.
_________________
About Me;
I Use CE Since Version 1.X, And Still Learning How To Use It Well!
Jul 26, 2020
STN wrote: | i am a sweetheart. |
|
|
Back to top |
|
|
Csimbi I post too much Reputation: 91
Joined: 14 Jul 2007 Posts: 3093
|
Posted: Sun Sep 02, 2018 3:14 am Post subject: |
|
|
WHILE is a pretty bad choice, actually. Just think through what it would mean for the game, the CPU and the memory and how prone it is for breaking.
CE is using a timer, which is a tad bit better than WHILE, but it works well because it consumes little CPU and checks that the address is still valid.
NOP is cheap, it's the ignorant/lazy shortcut you should not be taking.
Quite often, you will miss other bits that also update the same value (for example, physical and various magic or physics-based damage are all using different code).
You will also prevent updating values with the same code (when friendly and enemy units are both damaged - they both will be invincible).
As a good practice: learn not to use NOP - redirect the code to your codecave and do your magic there for the addresses you want.
- The code will only be called when the value is actually updated.
- You can handle encryption and some cheat protection mechanisms.
- You can filter values (instead of blatantly preventing writes to any address) and better tailor the results and look at other values as well.
- You can redirect multiple calls to the same cave (reuse the code).
In the end, it's all up to you, really.
|
|
Back to top |
|
|
atom0s Moderator Reputation: 198
Joined: 25 Jan 2006 Posts: 8515 Location: 127.0.0.1
|
Posted: Sun Sep 02, 2018 10:52 am Post subject: |
|
|
Csimbi wrote: | WHILE is a pretty bad choice, actually. Just think through what it would mean for the game, the CPU and the memory and how prone it is for breaking.
CE is using a timer, which is a tad bit better than WHILE, but it works well because it consumes little CPU and checks that the address is still valid.
|
While vs. Timer is not the reason for CPU usage spikes. It also works in the same manner as each other in terms of what it means for the game. Both are going to perform the same functionality as the end result so it doesn't matter which is used if the code / pointer breaks.
If you want to emulate the timer CPU usage and such, add a sleep to the while loop. Emulate exactly what the timer does, for example if you have a timer that ticks once a second, in the while loop just sleep 1 second as well.
Code: |
while (someCondition)
{
::Sleep(1000);
}
|
A sleep as low as 10 will cause the running thread to not eat CPU cycles.
If the intention is to make something that constantly writes to a value to mimic freezing, a thread or timer works fine. For newer programmers using basic UI creation and C++, a timer would be better suited since there is less worry on cleanup properly, where-as cleaning up a thread can deadlock the application if not done properly.
Csimbi wrote: |
NOP is cheap, it's the ignorant/lazy shortcut you should not be taking.
Quite often, you will miss other bits that also update the same value (for example, physical and various magic or physics-based damage are all using different code).
You will also prevent updating values with the same code (when friendly and enemy units are both damaged - they both will be invincible).
As a good practice: learn not to use NOP - redirect the code to your codecave and do your magic there for the addresses you want.
- The code will only be called when the value is actually updated.
- You can handle encryption and some cheat protection mechanisms.
- You can filter values (instead of blatantly preventing writes to any address) and better tailor the results and look at other values as well.
- You can redirect multiple calls to the same cave (reuse the code).
In the end, it's all up to you, really. |
There is nothing wrong with nopping code. It is not lazy or something people should not do. Telling people to allocate memory to jump to a cave to do nothing and jump back is wasteful. There is 0 reason to do any of that if nopping an instruction achieves the end goal. You are adding unnecessary clock cycles to the application effectively slowing it down (granted on todays hardware you will never really notice it unless you have terrible code) for something that a few nops could have achieved with no wasted cycles.
_________________
- Retired. |
|
Back to top |
|
|
atom0s Moderator Reputation: 198
Joined: 25 Jan 2006 Posts: 8515 Location: 127.0.0.1
|
Posted: Sun Sep 02, 2018 11:03 am Post subject: Re: Freezing / Nopping Value - A newbie question |
|
|
pLearner wrote: | Hey all, question relating to C++:
1) Say I wanted to freeze a ammo value or health value like in cheat engine. How would I do this in c++ code? Would I just make a while loop and increment that loop by +1 or however much I want?
Or should I nop the address?
Or both ways are correct and those are just 2 different ways of doing it but still get same result? |
Both are correct but can yield different results depending on how you code things and how often the game uses/writes to the value.
Ideally, the best possible methods for accuracy in the value are going to be ensuing that you are altering the value before the game uses it. Code injection will perform the best, be it by nop'ing the instruction in question or writing a cave to alter the value/flow of the code.
If it is something as simple as say:
And you can just nop the code to achieve the result you want, do that.
If you need to alter the value of eax, then create a cave and write to it.
If you are fine with a delay and potential missing of a value write per-frame, you can just WriteProcessMemory externally from your trainer/app instead to the address of [ecx+12C] and go from there.
Up to you which result, you would like to end up with but all are correct ways to do things.
_________________
- Retired. |
|
Back to top |
|
|
Csimbi I post too much Reputation: 91
Joined: 14 Jul 2007 Posts: 3093
|
Posted: Mon Sep 03, 2018 12:24 am Post subject: |
|
|
atom0s wrote: | There is nothing wrong with nopping code. It is not lazy or something people should not do. Telling people to allocate memory to jump to a cave to do nothing and jump back is wasteful. There is 0 reason to do any of that if nopping an instruction achieves the end goal. You are adding unnecessary clock cycles to the application effectively slowing it down (granted on todays hardware you will never really notice it unless you have terrible code) for something that a few nops could have achieved with no wasted cycles. |
People, in general? Sure.
People on this forum posting tables? Agree to disagree.
|
|
Back to top |
|
|
|