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.
Relying on mono data collector for tables
-
- Table Makers
- Posts: 168
- Joined: Sun Jun 13, 2021 12:01 am
- Reputation: 281
Relying on mono data collector for tables
Last edited by all_my_sins on Sun May 29, 2022 12:54 am, edited 1 time in total.
-
- Table Makers
- Posts: 168
- Joined: Sun Jun 13, 2021 12:01 am
- Reputation: 281
Re: Relying on mono data collector for tables
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
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
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!
Have a wild night baby!
-
- Expert Cheater
- Posts: 293
- Joined: Sat Mar 04, 2017 7:28 am
- Reputation: 236
Re: Relying on mono data collector for tables
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.
For Unity engine game, make a habit of anticipation for 14 bytes jump.
-
- Table Makers
- Posts: 168
- Joined: Sun Jun 13, 2021 12:01 am
- Reputation: 281
Re: Relying on mono data collector for tables
Thank you for clarifying!LeFiXER wrote: ↑Mon Nov 15, 2021 7:21 pmMono 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.
I've never tried aobScanRegion, I'll look into it! Thank you for the description as well, very helpful!VampTY wrote: ↑Mon Nov 15, 2021 8:13 pmI 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!
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!TheByteSize wrote: ↑Mon Nov 15, 2021 8:47 pmUnity 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.
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
just activating mono and looking up a method will JIT that method
Who is online
Users browsing this forum: No registered users