Cheat Engine

[Nvr22]

In auto-assembly you can use AoBs to find a specific address which works wonders on things you can't find a solid pointer for,
not to mention it's much, much quicker to find a good AoB than pointer if you can isolate the AoB to a single result or the first resulting address.


So what I'm suggesting is adding in a way to input AoBs (with offsets) to the Pointer menu- so, after you've selected the process you want,
it will automagically run a background AoB scan using the AoB you typed into the Address' Pointer menu, then proceed to fill out the Address field with the first result it finds +/- the offset (as per usual).

Any changes to the value of the address found using this method won't alter the AoB in the Pointer menu.

This allows for using AoBs in the same manner as with scripts outside of them which will-
make small changes to a single dynamic address less of a hassle, since you won't have to go through your AoB script just to change the value from 05 to 0A*,
allow for patch resistant addresses in the Address List, as well as create a viable alternative to pointers.

The whole point of a script using AoB is to continue to find dynamic addresses despite restarts or patches, and that's exactly why I would like this implemented-
So every time you restart the process or it gets patched you won't have to go back and manually scan for everything in the Address List all over again, consequently having to refind its pointer on top of that, or--
be forced to create and alter scripts for the simplest of tasks merely due to frequent patching.


*Keep in mind you have to change the AoB after [DISABLE] to reflect the change from 05 to 0A as well, which quickly becomes time consuming if you have to do it 15+ times consecutively-
especially when considering this is all what would just be a double click and typed "10" if it were in the address list.

[Dark Byte]

I don't really get what you are suggesting, or the reason, but i think i may have some suggestions for your current script

You can use registersymbol in the first aa script you do to store all aob's .
The addresslist will then recognize those symbolnames and if they are combined with an offset deal with that automatically

Disable should of course also make use of the registered symbol address when restoring

If you're asking because the aob has changed and you wish to change all scripts easily, you can do that as well. Just keep ALL aob's in the initial script, and use that to store the original bytes when injected.(you can store the original bytes before overwriting)

In the secondary scripts make use of the registered addresses and when disabled restore with the stored original bytes

[Nvr22]

I believe I've used what you're talking about before, but it's quite a bit different from what I'm suggesting as well as what I'm using the script for.
It might just be easier to explain it with an image.


Just follow the arrows in the attachment - sorry if it's a bit messy.


The reason I'm suggesting this is so there can be an easily accessible alternative to pointers that's patch resistant,
so when something's updated you don't have to go through finding the Address' pointer all over again.

With applications that are patched quickly (hourly, daily, biweekly) using pointers is just a waste of time,
but if the game crashes and you don't have them then you're out of luck- unless you use AoBs,
however the usability and ease of access with AoBs isn't quite on the same level as pointers with the exception of turning to scripts which helps slightly but only improves time by a matter of merely a three or four minutes.

I'm hoping, if you decide to try it out, this will allow for pointers to no longer be the only way to automatically get an address in the Address List.
Plus finding a compatible AoB can be quite a bit quicker than going through pointers until you dig up a static one.

Edit: Using scripts speeds up my time, but it may just be a me thing so I edited it out. Irregardless the suggestion was intended as an alternative to pointers anyway so the scripts part hardly mattered.

[Nvr22]

Bump for response.
Impractical?
Already in and I just missed it?
Hard to implement?

Only you can decide! *pans*

[Dark Byte]

I'm just not sure how useful this is as aob's tend to be used with code most of the time (and don't use value changes to change code, that's just horrible practice)

I might expand the userdefined symbol list with the ability to do an aob scan when the table is loaded/process opened/referenced when not yet defined, but I don't think it's a good fit as a cheatentry element

[Jeffrey_]

This does seem quite useful for me really. Because I'm not the best in auto assembly but I like to use pointers a lot. But in some games e.g Minecraft, finding a good pointer that's works every time is practically impossible. So this would be very useful for creating easy pointers and for games like Minecraft. Plus it would save time and most likely make the pointer work in every version of the game. So I agree with Nvr22 and would like this implemented in the next beta.

[Dark Byte]

I don't see how this would help at all with pointers to data
AOB's are mainly for code (JITed for example in java). You could use it to find signatures for specific structures, but still you'd find too many to be of use then

[Nvr22]

(You can skip to the edit if you don't want to read this wall)

Simply because AoBs original intent was for use in code, doesn't mean it needs to be limited by it.

In most cases that I've needed to use AoBs I've been able to whittle it down to 1 to 4 results easily.
If it's 2 or more it's almost always the first result, which is the one an AoB in auto-assembly will pick.

However, if you can't whittle it down or it isn't the first- that's where offsets come into play.
Since the AoB you were trying won't work, you go a few lines back until you find one that's alone when searched (usually doesn't take long) then add the +6 or +B to it to lead to the exact address you want.

So in almost every case it's very possible.

Furthermore it's purpose -isn't- to replace pointers, or help them- but to provide a alternative -to- them, even if a rarely circumstantial one.

In some cases, as you've said, you may find too many resulting AoBs for it to be useful- then you'll have to go with regular pointers.
But in other cases when you can't legitimately get a solid pointer you'll now have an -option- to use AoB Pointers so you're not stuck with finding the address through manual scanning every time you restart the application, or using scripts for simplistic tasks.
With the added bonus that the AoB Pointers will be patch resistant, so you won't always have to change them when whatever you're using is updated (Pic is specifically aims at this)

If you think it would be too confusing to the random person who downloads CE to hack the latest flash game, it could always be a defaulted:off with an option for it in the settings.
Though that wouldn't really help its use in Tables or Trainers for the average user either.


Oh and I was actually using code to change values, not the other way around.
Sorry for the late response, I was a bit busy for the last few days.





EDIT: God I suck at explaining things.
Summarized AoB Pointers will be useful (or "help") by:

1. Being much quicker to find than Pointers (Saving some time- especially if it's multi-level)

2. Being Patch Resistant (Saving even -more- time* See pic)

3. Opening an alternative to Pointers
3a. Releases AoB from the awful, cruel binds of scripts

At -least- give it a shot in the beta, all this is doing is bringing aobscan(AA BB CC DD 99) to the Pointer menu.
And if you haven't already, -please- look though the pic.



*Remember that game you hacked months ago? If you used an AoB Pointer on the gold value and it's been patched since then, you won't have to go searching for it all over again the next time you play!
Alternatively, if the game you're hacking updates daily you won't have to go searching for that gold multi-level pointer with every. Single. Patch.

[Gniarf]

If I understand correctly you want to scan for a signature like 11 22 33 44 55 66 and you know that -for example- your money is always stored 20 bytes after this signature. Is that it?


If it is, rejoice, you can already do that with CE's built in LUA script engine. I'm not very experienced with CE lua scripts but the concept is:

[Nvr22]

That's actually quite close. Near the same in fact, but what you're suggesting goes against the point behind adding it to the pointer menu.

Lua isn't easily accessible, without prior knowledge the typical user won't know this type of usage even existed.

The purpose of adding it to the pointer menu is to make that option easily accessible to people that just want to hack Minecraft per se but find it impossible to get a pointer.
Quite simply, just to add another option for the people who -don't- know Lua (would that not be most of the people who use Cheat Engine?) so they -don't- have to turn to scripting for very simple tasks.

But yes, you pretty much have the -idea- down to a T. I'm just trying to get this specifically in the pointer menu for the sake of people who are like I was 11 months ago.


@Dark Byte
How wouldn't this be useful in pointing to addresses exactly? You've practically even listed it here yourself /viewtopic.php?t=531962&sid=d33b31d2c2786c9563f21903c90fc27e
Every bit of usefulness that had (in using AoBs to point to Addresses, not that script specifically) will be exactly the same with this, so how is it -not- useful?
There could even be an option for choosing if it's the 2nd or 3rd+ address.

Of course it won't be used for big things that absolutely NEED scripting, but only for simply things that merely need one address and simple value changes like gold or experience. That's its entire intention.
This could even effect trainers in the fact that since these simple single addresses will now have a method of being patch resistant, people can use input boxes instead of "Press 5 to up your gold by 50".
It's merely creating a simplified usage for AoBs where there otherwise isn't one. So how is it bad?

[Nvr22]

Bump for the hopes and dreams that drive us into tomorrow..! I meant to bump it sooner but was busy again.

It's EXACTLY what Gniarf talked about but instead in a place where regular users who don't know Lua, like me or Jeff up there, can utilize it if we need to.
If it's useful as a Lua script, why wouldn't it be just as useful here?
They operate in nearly the same manner.

Are you refusing to even try it because you thought I was using values to change code?
Which wasn't the case at all, I was using code to change values so I didn't have to search for the latest address every time it was patched (which was often).

At -least- give it a shot.

[Dark Byte]

[Nvr22]

I doubt we're even on the same page but that may just be me.

[Gniarf]

[Nvr22]