View Issue Details
|Summary||0000265: Anti cheating check => Hook function for variable monitoring|
|Description||When there are some complex numerical systems in ghost, some users will use some memory modification tools to modify the values (such as money or intimacy)|
In some mature games, the "Canary value" is often used to detect memory modification: the Canary value has the same value as the protected variable, and the protected variable will deviate from the real value by a specific value to prevent it from being detected by the memory modifier. When you detect that the Canary value is different from the real value of the protected value, You know something has moved your memory. At this time, you can enable some plots or punishments specially provided for cheaters
I try to provide this method in my ghost, but it's too troublesome: every time I update the corresponding value, I need to add a large series of more complex operations to the code
So I wonder if this function can be used as the built-in function of yaya: one function is used to declare that the variable needs Canary value, and the other function detects whether the value has been modified
|Tags||No tags attached.|
SSP and YAYA are not so good protective environment.
Users can boot any other ghosts, add any other plugins.
This means users can load any other unmanaged DLLs in same memory space, and modify any environment freely.
So, it's completely meaningless trying to implement memory data protection such as canary value.
If you want more protective environment, you should need more extensive system.
Aren't you too nervous? I think it's okay to trust users a little more.
Yes, I know that anti cheating doesn't make much sense, but I still want to make ghost detect and handle possible memory modifications through operations such as Canary value: some users only use CE, and I can detect this through the Canary value mechanism and prepare some additional scenarios or penalties
If I really want to deal with cheating, I can detect the list of programs running in the background, but I just want to surprise these guys who modify memory
I don't think this is within the scope of yaya's functions, although it can do it
Your problem is that you want to do something else when modifying a variable, but you don't want to write the code that modifies the variable too long and ugly, right?
Unfortunately, yaya cannot overload operator= like C++.
But I think you can write modifications to special variables as functions and use function calls to modify them
My problem is not when storing values: it's ugly to use function calls to encapsulate the storage of values, but it's in an acceptable range
The problem is when you take it out: each time you have to do additional calculations to offset the offset
All in all, yes, it's ugly, so I wonder if I can make this mechanism an optional feature of yaya to keep my DIC files dry
You know, this mechanism is only used for variables declared by a specific function. In this way, it will not bring too much burden to ordinary variables, except virtual function table lookup or flag detection
How about this?
Three functions are designed to declare several processing functions for variables:
The processing function when the variable is changed: parameter: the name of the changed variable, the original variable value and the existing variable value
The processing function when the variable is destroyed: parameter: the name of the destroyed variable and the original variable value
The processing function when the variable is accessed: parameter: the variable name and variable content, and take the return value of this function as the value of the variable
I think this is much better than only anti cheating: it even allows yaya to be more object-oriented
The processing function when a variable is changed: parameters: the name of the unchanged variable, the original variable value, the variable value being assigned
the return value of the function as the content of variable modification
This will be better
So maybe it's better to rename this issue?
Now the problem becomes the implementation of the new "Object-Oriented" function, isn't it?
|2021-09-07 10:33||guest||New Issue|
|2021-09-08 16:51||ponapalt||Assigned To||=> ponapalt|
|2021-09-08 16:51||ponapalt||Status||new => closed|
|2021-09-08 16:51||ponapalt||Resolution||open => not fixable|
|2021-09-08 16:51||ponapalt||Note Added: 0000644|
|2021-09-08 22:43||guest||Status||closed => feedback|
|2021-09-08 22:43||guest||Resolution||not fixable => reopened|
|2021-09-08 22:43||guest||Note Added: 0000648|
|2021-09-08 23:48||guest||Note Added: 0000649|
|2021-09-08 23:48||guest||Status||feedback => assigned|
|2021-09-09 10:41||guest||Note Added: 0000660|
|2021-09-09 10:55||guest||Note Added: 0000661|
|2021-09-09 11:03||guest||Note Added: 0000662|
|2021-09-09 11:08||guest||Note Added: 0000663|
|2021-09-10 10:09||guest||Note Added: 0000666|
|2021-11-14 21:58||guest||Note Added: 0000928|
|2021-11-15 10:51||ponapalt||Summary||Anti cheating check => Anti cheating check => Hook function for variable monitoring|
|2021-11-21 05:04||ponapalt||Status||assigned => closed|
|2021-11-21 05:04||ponapalt||Note Added: 0000942|