Page 1 of 1
Relying on mono data collector for tables
Posted: Sun Nov 14, 2021 7:16 pm
by all_my_sins
What are the pitfalls to relying on the mono data collector over AOB in tables? Thanks!
EDIT:
Pitfalls
1. methods sometimes have the same name.
Re: Relying on mono data collector for tables
Posted: Mon Nov 15, 2021 7:16 pm
by all_my_sins
Maybe I can clarify: For the purposes of creating a table, are there any concerns with relying on the mono data collector for unity games vs. AOB? Are there situations where it would be inadvisable? I've seen a couple of tables now that just turn on the mono data collector and use the addresses it provides and if that was just as good as AOBs in Unity games, that would make my life easier.
Re: Relying on mono data collector for tables
Posted: Mon Nov 15, 2021 7:21 pm
by LeFiXER
Mono data collector can give narrower searches for AOBs which in turn makes activation of scripts faster at the expense of giving off more information. Anyone that downloads the table will know where to look to update should the original author fail to update. I'm certain you can do the same with normal AOBs but I think mono makes this method easier.
Re: Relying on mono data collector for tables
Posted: Mon Nov 15, 2021 8:13 pm
by VampTY
I prefer using
aobScanRegion instead of
aobscanmodule in Unity, is rather faster updating and reading the values if pointers are involved or not.Depends if the game based on unity engine has obfuscated values or not, protection or not, if is IL2CPP involved or not.Some, in Unity can be even used as normal
aobscan or
aobscanmodule, you can even add the .exe's name or not.Using "aobScanRegion" will tell you exact what's missing if you need to update.In some cases, you can add "??" instead of unused bytes or "*" for symbols with direct "readmem".I prefer scripts instead of pointers though, for working scripts add the address to the name.I'm not the best in explaing.Or, back and trace to the thingy you want to update, let's say life for one character, backtracking to it's real address, add it to "readmem", see how much is in hex, then even if is updated or not, will always read the real value or address, just like other game engines.I'm just an amateur in all these, but you get it!
Have a wild night baby!
Re: Relying on mono data collector for tables
Posted: Mon Nov 15, 2021 8:47 pm
by TheByteSize
Unity doesn't load the Method/Function into memory until that particular Method/Function is needed. By using Mono Data Collector to invoke it first would allow you to AOBscan early and initiate your script before it even needed like other game engine.
For Unity engine game, make a habit of anticipation for 14 bytes jump.
Re: Relying on mono data collector for tables
Posted: Tue Nov 16, 2021 5:29 pm
by all_my_sins
LeFiXER wrote: ↑Mon Nov 15, 2021 7:21 pm
Mono data collector can give narrower searches for AOBs which in turn makes activation of scripts faster at the expense of giving off more information. Anyone that downloads the table will know where to look to update should the original author fail to update. I'm certain you can do the same with normal AOBs but I think mono makes this method easier.
Thank you for clarifying!
VampTY wrote: ↑Mon Nov 15, 2021 8:13 pm
I prefer using
aobScanRegion instead of
aobscanmodule in Unity, is rather faster updating and reading the values if pointers are involved or not.Depends if the game based on unity engine has obfuscated values or not, protection or not, if is IL2CPP involved or not.Some, in Unity can be even used as normal
aobscan or
aobscanmodule, you can even add the .exe's name or not.Using "aobScanRegion" will tell you exact what's missing if you need to update.In some cases, you can add "??" instead of unused bytes or "*" for symbols with direct "readmem".I prefer scripts instead of pointers though, for working scripts add the address to the name.I'm not the best in explaing.Or, back and trace to the thingy you want to update, let's say life for one character, backtracking to it's real address, add it to "readmem", see how much is in hex, then even if is updated or not, will always read the real value or address, just like other game engines.I'm just an amateur in all these, but you get it!
Have a wild night baby!
I've never tried aobScanRegion, I'll look into it! Thank you for the description as well, very helpful!
TheByteSize wrote: ↑Mon Nov 15, 2021 8:47 pm
Unity doesn't load the Method/Function into memory until that particular Method/Function is needed. By using Mono Data Collector to invoke it first would allow you to AOBscan early and initiate your script before it even needed like other game engine.
For Unity engine game, make a habit of anticipation for 14 bytes jump.
Thank you! I'm not sure just invoking the mono data collector is enough to trigger JIT compilation, I think other steps are needed, but I haven't explored that yet. Very helpful, though!
I'm gathering from these replies that there is not much concern about relying on the mono data collector over AOB. I'll give it a shot with a few tables and see how it goes. Thanks, everyone!
Re: Relying on mono data collector for tables
Posted: Fri Nov 19, 2021 12:10 am
by Eric
just activating mono and looking up a method will JIT that method