1. twindtrout9783

    OP twindtrout9783 Advanced Member
    Newcomer

    Joined:
    Nov 5, 2019
    Messages:
    92
    Country:
    United States
    I want to make a few cheat tables for Cheat Engine 7.0, but first I need to know how to make pointers.
    Can anyone give me an explaination as to how?
     
  2. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    30,545
    Country:
    United Kingdom
    "make pointers"?
    What an odd term.

    Anyway pointers are a concept in programming that allow you to note where something else is in a program/memory. The pointer literally pointing the way to said data or part of the code.
    You can have a pointer to a pointer to a pointer.... indeed stacking 20 of them up with a few other things is a common question when they teach new programmers to make sure they truly get the idea but I will hold off there for a moment. I will note it is a valid thing to do in programming to have multiple pointers nested, not that it really matters for the would be cheat maker if it is a valid coding reason, the dev having a good time or just a frustration to would be cheat makers/cheat users as it is still the same problem to solve.

    In old school games (anything that ran in REAL mode on X86 or anything 16 bit or older, though it took a long time for it to get phased out -- 95% of the time this works just fine on the DS for example) you might have encountered a pointer mainly only in dealing with text and the like, or as a jump in the code. For memory based stuff, at least as far as cheats were concerned, they were rare and everything would be in the same place boot after boot after boot with no scope for any change.

    In newer code/languages you have the option to run all sorts of bits of code in different orders, and have the code handle noting where things are in memory rather than typically having them baked into the code.
    You also have the option to have tables increase infinitely (or until you run out of memory) which also necessitates pointers. Or if you prefer a game might have said you only have 50 inventory slots because it had assigned only the space necessary for it, today a game can save effectively infinite slots by just adding more on to the end. If there is more on the end then if the next bit of code is directed to be stored after it then having addition items means it might be shuffled forward between boots or that part of the game being loaded. Likewise if a piece of code fails to release memory after it is done, or continues to add and add and add to the memory it sections off you get a memory leak but that is not really necessary to contemplate too much right now other than to say a game might release code from memory it is not using at that point in time and thus mean your cheat does nothing as it is literally not there in memory to do anything with (you get a minor variation with older consoles as well where a cheat might work in game but crash when it is booting up because the cheat engine does not care but the game does).

    There is also something called ASLR, address space layout randomisation. It is a fairly weak security feature but is a thing to tackle. Here it was noted that a lot of exploits (and cheats but nobody really cares about that) relied upon having things land in predictable locations in memory. If you jumble this up (easy enough to do if you build your program with it in mind) randomly then the exploits work less of the time if they can't rely on something being somewhere in memory. It can also mean your data you wish to cheat with is not in the same place, that your injected code might not be in the same place and more besides.

    To find a pointer you do much like you would to find a cheat, indeed you will probably have to find a cheat several times.
    Do a classic infinite ammo one, and we will assume it has no fancy mirrors, encryption, checksums, duplicates, multi location, register held values or other anti cheat/cheat prevention/code based frustration you might encounter.
    So you fire a bullet, do a search for anything that reduced/changed in value, fire a bullet, do a search, maybe leave it alone and then only search for things that are the same, fire a bullet,..... until you find where the bullet value is housed for that run. This is the classic cheat finding method that any cheat finding guide will tell you ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial being my usual link for cheat finding for console games and old PC games for that matter, https://doc.kodewerx.org/index.html being a nice list of the various cheat types for many old consoles).

    Note the location of the ammo and take a copy of the game's memory.
    New boot of the game, repeat.
    Can do it a few more times if you want, three is usually the minimum for a decent automated search, though theoretically you can get away with two (or one if you are really bored and fancy playing with assembly, which nobody does for that sort of thing).
    Old school consoles, some newer consoles and modern operating systems will tend to have their code load in the same place in memory (modern operating systems it will be virtual memory addresses but that matters little) but you might also have to note the layout used.

    You will then get a program to feed a few of the game's memory, the locations for the ammo for each of those (make sure you get the right values associated with the right memory dump else it is not going to do much). It will then take the locations of the ammo for each boot and try to see what might be pointing at that location in memory in each of those. If it finds a commonality between each boot you have your pointer. Again you can have a pointer to a pointer to a pointer to a... so you might get to repeat the process to ascend up the list of pointers. Eventually a pointer will be in a fixed location between boots, even if the location it points to is radically different each time.
    The cheat program will take this pointer value, read it every time/every boot and then where it says go hold that value or set a value or do whatever your cheat is set to do.
     
  3. twindtrout9783

    OP twindtrout9783 Advanced Member
    Newcomer

    Joined:
    Nov 5, 2019
    Messages:
    92
    Country:
    United States
    Thank you for typing all of this up for me.

    During the process of finding the (static?) pointer, do I need to find what writes my address, or what access the address?
     
  4. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    30,545
    Country:
    United Kingdom
    I can think of valid reasons to do both in cheat making, especially if you are going to edit the program instead (why have infinite lives via a RAM cheaty if every death gives you an extra life by changing the sub to an add sort of thing), though most of the time you will not be doing any kind of read/write breakpoints/watchpoints/logging as they would be known and instead it is all about the search.
    Likewise if you do want do breakpoints then both will probably yield you what you want -- something will probably read something to make sure you have enough ammo say to fire a gun, and it will probably subtract however many (which is to say write it) after you fired it. Both of those will yield something of interest if you are either chasing down a pointer or figuring out what a given bit of code does.
     
  5. twindtrout9783

    OP twindtrout9783 Advanced Member
    Newcomer

    Joined:
    Nov 5, 2019
    Messages:
    92
    Country:
    United States
    Well, as of right now, I'm messing around with my Health in Terraria.
    I went with trying to see what accessed it, and this is what I found:
    [​IMG]
    EDIT: I also searched for any opcodes that will write to my address, but I didn't find anything.
    [​IMG]
     
    Last edited by twindtrout9783, May 23, 2020 at 8:30 PM
  6. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    30,545
    Country:
    United Kingdom
    Are we messing with assembly already? That is rather advanced to be playing with if you are only just starting on pointers before now.
    How much do you know of assembly for either another system or X86? You can do stuff in it but generally it is considered the hardest form of coding there is that is still somewhat usable to do real work in.

    I normally mainly have to get people used to the types of assembly seen in consoles these days when having discussions so I don't know what I have for X86 for those new to it.
    https://stuff.pypt.lt/ggt80x86a/asm1.htm
    https://www.plantation-productions.com/Webster/www.artofasm.com/index.html
    They are my two chosen comprehensive guides but I am not sure what is a gentle introduction other than sending you off for hours to watch this lecture series, though it will also cover pointers, data types and a bunch of other cool stuff that if you can learn it will help making cheats so so much.

    Anyway
    https://www.felixcloutier.com/x86/fst:fstp
    FSTP — Store Floating Point Value
    Curious that they would do health as a float. Floating point if you were unaware is a way of doing fractional numbers on computers, most of which would rather be doing nice positive natural numbers if given half the chance. Modern computers and a game like Terraria is not so bad though I guess.
    That is something that stashes a floating point value into memory and then POPs it afterwards, sort of two for one instruction really.

    PUSH (usually also associated with POP which you just met above) is a program flow and CPU management control operation (usually associated with things like compares, jumps and flag fiddling stuff)

    A CPU will usually have registers (little sections of very fast memory to use in operations) but only a very few of them. To that end a program may choose to put the current contents somewhere else (PUSH it away) and then when it is done it will POP it back onto where it came from. Such things are also why you are generally not advised to call a function within a function as you then might end up pushing too many things away and bad news/slowdown.
    In this case I wonder if you found the memory you were looking for, or instead it might be a register value (the memory is just the memory and while registers are few in number if something can live on it and be operated on it then it will, such a thing had caused many a head scratch by cheat makers over the years).

    If you know assembly or are willing to muddle through looking up them all then the 20 or so instructions that precede those you just found are of interest. Hopefully it will be a nice bit of maths and some comparisons and branches (probably IF ELSE in more general programming loop discussions or you are familiar with that sort of thing). Edit one of those instructions to skip the is dead part, or change it to set a health value to full and you have your infinite health cheat (though anti piracy protection/anti hack protection might object in a modern PC game, older console games seldom will or will have the protections defeated in other patches you can get).
     
  7. twindtrout9783

    OP twindtrout9783 Advanced Member
    Newcomer

    Joined:
    Nov 5, 2019
    Messages:
    92
    Country:
    United States
    I don't know if I was getting into assembly or not, but thank you anyways.

    So far, I've seen the health as Byte, 2 Bytes, and 4 Bytes (all on the same address)

    I don't know assembly, but I am willing to learn.
     
  8. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    30,545
    Country:
    United Kingdom
    Some might deem that running before you can walk, especially if we also have to consider counter anti piracy*/anti cheat stuff. That said the basics are not that complicated and you will be able to do useful things in fairly short order using them.

    *anti piracy often detects changes to the game binary. Even if your cheat patch does not touch anything there it can trip it anyway. Anti cheat also often does similar.

    Anyway there are two main areas to consider in memory of any given program

    1) The memory itself aka data section
    2) The code that runs the game aka executable section
    Save hacking is another thing but I will skip that in this. Note that savestate hacking is basically just a version of 1).

    Most basic cheats you have dealt with on consoles before that are not save cheats will be 1). Here the data the game generates to store variables like how much health, ammo, mana, strength, item durability, items in inventory, possibly stuff like speed in game, how many steps before the next "random" battle and so on and so on. Find where a variable is located and you can alter it.
    Various cheat devices will have more and more functionality beyond just hold this item at this value until either I turn off or the game turns off. You will also gain basic loop options as well so you can do things like check this value, if it is less than, equal to, greater than, between this range....

    Finding variables can be hard. The basic stuff you can constantly change, manipulate or otherwise handle in very quick succession (it is easy to fire a bullet or stand there being hit by a weak enemy, if the game puts nice numbers on screen you can even search for them, or search for them once you convert it to hexadecimal number types) tends to be found quite easily by just constantly searching until the list gets small enough that you can watch it all at once, or try things out and see what happens. Things that are on or off, or take 10 minutes to reset to try for another search take more effort. Savestates can help here as you can load and test things, load and try something else, load and test until such a time as you find what you want.
    Also worth noting is once you find one item the one next door to it might also be of interest, or the value up from it can be something rarer. This can be especially useful when doing infinite items. This is how people usually do things like have 99 end game weapons -- find a cheat for say iron daggers you can buy in the starting town and it is of the form that this value followed by this number means, note that 2 might be say a steel dagger, and the super gold obsidian fancy end game sword with a 30 hour game + 5 hour sidequest to get it is hopefully then just a matter of trying 3, 4, 5,... until you get there. Can also be useful if you are helping someone fill in a FAQ and want all the details.

    Two main subjects to discuss now would be data types (you already met floats, and I mentioned in passing other number types, this would be expanded to include things like linked lists, and all the other stuff on things like https://www.tutorialspoint.com/cprogramming/c_data_types.htm ) and cheat prevention methods, however I will put a pin in that for the moment.

    2) You might have met in old school games as a game genie, though not all game genie codes deal with the executable. Likewise on the DS as the executable binary was in memory you could edit that, and people did.

    Anyway here you change how the program works, or maybe data it brings along for the ride within the binary. The scope for changes available here is dramatically more but so does the difficulty.
    The CPU is the beating heart of the system, or subsystem, in most cases. There are parts that might never be touched in a given game but everything usually comes back to the CPU.
    They are at their heart actually quite simple devices, even the decades of stuff built on stuff built on stuff that is the modern X86/X64 Intel/AMD style processor (by comparison the ARM of just about everything else nowadays, along with the Z80, 68K, 6502, PowerPC, 8080, MIPS and other things you will have seen if you looked at specs sheets for game consoles and microcomputers are usually even more tame but also a bit more limited).
    You might have looked at something like https://www.felixcloutier.com/x86/ and seen the 1000+ instructions (never mind one of Intel's own datasheets covering timings, caches and multiple cores), some of which do very weird and wonderful things like smoosh arrays together and thought oh dear. Don't worry as nobody really memorises all of that in an effort to do useful things, and most of it is slightly more advanced or tweaked ways of doing basic things. Some might memorise all of say the 6502 processor (around here most would note its use in the NES) and they might have some odd ways of looking at things if you speak to them after you got this X86 stuff on lock but it should all be pretty familiar (learn one type of assembly and you can do two, learn two and they are start being reasonably familiar).

    Anyway instructions can be categorised in various ways but I usually find it helpful to split the basic maths from the system/processor manipulation/housekeeping and the program flow stuff.
    Maths is maths. Processors excel at doing very basic maths operations. Indeed they are so basic it can be hard for people to imagine how anything useful gets done. Some also like going to look at adding machines as everything is adding in the end (adding is adding, multiplication is adding, subtraction is just a type of adding and if you remember logarithms from school division is a type of subtraction which as just mentioned is also adding), and if you don't know Boolean logic (gates from electronics) then do that too. X86 can reach out and touch memory from instructions, some older systems might need dedicated instructions for that one (or use something called DMA, direct memory access, to do other things)
    System manipulation and processor housekeeping is just that. Things that manipulate memory, other registers and the like. PUSH and POP are some of the most important here, and you met those already.
    Program flow is when stuff starts getting useful. If you learn basic programming you will be introduced to loops (FOR, While, IF ELSE...). These are things that allow you to do things like add things up and only when something happens do something else. In the processor these will be things like compare (CMP), jump (JMP) and branch in some other systems (BRA) with most things just be variations on that (Jcc being jump if condition met and has a nice long list of things it can check and jump accordingly https://www.felixcloutier.com/x86/jcc ). Programmers will also usually bunch up a group of instructions that perform a common task and then jump to it (this would be calling a function), and calling a function might first mean you do some housekeeping (the push and pop stuff) so it does not overwrite your useful data or trouble itself.

    I should mention the NOP at this stage. Short for No-Operation. When playing cheat hacker this is going to be your friend where in normal assembly programming it has very limited uses (mostly just a means of making something wait if you have a complicated instruction you need to wait to complete). If you start pressing delete in code already compiled bad things start happening as something that jumps to somewhere else might encounter something it does not expect (or miss an important step). A NOP essentially causes no change in the state of things but a cycle to skip. Some systems will have a dedicated NOP, some programs you are viewing/editing assembly with will give you one it made up and other times you get to make your own (MOV EDX, EDX being a nice choice as it merely copies the data from one register to itself and does not change anything, indeed most programmers on most systems will copy a register to a register).
    The main reason it is your friend is you can edit out instructions you don't want. Die in a game and lose a life, oh no the thing that reaches out, grabs the lives value, subs one and then returns it no longer subs one because the sub part is a NOP. Come to a shop and it wants all the gold to buy an item, oh no the the thing that checks your wallet balance suddenly does not care and will proceed to the allowing you to buy it (possibly sending you to negative money, though that will probably only be a few instructions later down the line) regardless of whether you have sufficient funds.
    I should note that we normally use the die in a game part as an example where this gets tedious. Think basic mario. Time running out, hit enemies, hit hazards, fall in a pit, poison mushroom, possibly get crushed... all of these can lead to a sub from the lives value where a simple cheat holding the single lives value is a nice bit easier. At the same time holding a life value once every frame to max might not keep you invincible if the game keeps the life value in the CPU during all its calculations, or you get more than the max value/your current max during that frame, in which case the hack that does the compare life and checks if greater than 0 bit is far nicer to go and fiddle with.

    So yeah 1000+ instructions, even more if you account for sub types, many doing weird and exotic things that few would be able to explain in depth. If however you can get an understanding of the flow of operations and what it is doing, and change critical parts of it, most of which will be fairly simple, you can do some wonderful cheats, and also write documents like https://www.dragonflycave.com/mechanics/gen-i-capturing for everybody to read and design in game builds to handle. The https://stuff.pypt.lt/ggt80x86a/asm1.htm link from earlier is quite old but in later chapters does a good job in building up instructions into something you might consider useful to do in programming, the art of assembly one ( https://www.plantation-productions.com/Webster/ ) will eventually get there as well but will teach you computer science first, which you can also learn from that UNSW computing playlist if you want something a bit more passive.

    Naturally it gets a lot lot lot more complicated (I barely mentioned timing for instance -- not all instructions take the same time to perform), program flow skipped out stacks, did not mention the program counter (the program will note where it is presently at), status flags (if you check if something is negative you might want to note that somewhere, it is but one thing a flag might handle), and the registers for X86 are weird compared to a lot of other ones in that they stack on top of each other for the smaller values (AH and AL both go next to each other to form AX which in turn is a chunk of EAX so be careful sticking something in AH if you have some good data you want to keep in EAX. This is not common in other systems where most registers are an island undo themselves).

    Anyway pointers and data types.
    As there are limited amounts of registers you have plain old memory to stash data in when it is not being operated upon. It pays then to note where you stored this data, something to point the way as it were. As mentioned though modern programming can dynamically allocate memory as it is needed rather than have one programmer attempt to account for everything in the game all at once (or two+ programmers work closely together to make sure they did not step on the toes of another, which gets about as annoying as you imagine). At some point will be a hardcoded value (give or take ASLR) for which the path to the value you want that run/that instant can be started at, you might have to go through a bunch of pointers to get there (and possibly do some maths on the values contained) but you will get there.

    Data types.
    Computers started off doing simple addition of positive whole numbers. Negatives are useful to have so you have those next (though there are a few variations -- the first obvious choice of use the top bit in the value to indicate negative works well until you get negative 0 and have to account for that when you are checking to see if something is less than or at 0), fractional values are also useful if you start dividing things so you have those as well (in PCs these days floating point numbers of various precisions are pretty much what is used, however there are others used in older systems or more specialised calculations where the inaccuracies of floating point become troublesome*).
    *10 divided by 3 is 3.33333.... however say it only stores 3.33 then multiplying by 3 I have 9.99. Now imagine that is money and all of a sudden I have 0.01 left over, multiply that by a few million transactions and then all of a sudden the morally unscrupulous programmer gets to retire. If you have ever heard of a penny rounding scheme then this is that. There are other problems with floating point (beyond it being slower) but they are usually variations on that theme.
    Stacks of related numbers became useful so now we have arrays**, and they also bring their own area of maths (I don't know if you have suffered matrix and vector maths at school yet but yeah it does have actual uses in the real world, even more so if you find yourself playing with 3d graphics and calculations for it)
    **level up happens. + 5 to all stats. Easy to have an array add 5, more tedious (and longer) to add 5 to each and every aspect of it. Have to do something complicated on top of that like +10% to primary stats and +5% to others... even more tedious but less so with arrays as you can multiply by another array. This is why C family tutorials will spend hours going over arrays and getting their usage down. https://www.tutorialspoint.com/cprogramming/c_unions.htm is another. Linked lists (and doubly linked lists and all the rest) more still.
    Again this is all skipping over things that various computer education courses will spend months on but hopefully it is enough for you to start making sense of things.

    Tools
    Cheat searchers like you started this thread off wanted to use are little more than slightly specialised debugging tools for programs.
    https://www.hex-rays.com/products/ida/ is paid for for the current version but older ones are available for free.

    https://ghidra-sre.org/ is free and positioned as something of a competitor to IDA. It is good though (it is something of the NSA's baby and they know how to hack)

    http://www.ollydbg.de/ is a bit old school but still used by a lot of people, and in some ways a bit more gentle on newcomers.

    https://rada.re/n/ is the last of the big ones used by hackers on the PC. Before the rise of ghidra it was probably the big open source competitor to IDA. Still has some great stuff in it though.

    There are a thousand other tools handling executable packing (EXE and DLL files are not always just plain and in the open -- compression, encryption, protection... can all feature and game devs are some of the biggest users of it), DLL export and plenty more besides.
     
    0x3000027E likes this.
  9. twindtrout9783

    OP twindtrout9783 Advanced Member
    Newcomer

    Joined:
    Nov 5, 2019
    Messages:
    92
    Country:
    United States
    Thank you for helping me and giving me all of this information.
     
  10. 0x3000027E

    0x3000027E GBAtemp Regular
    Member

    Joined:
    Mar 14, 2018
    Messages:
    147
    Country:
    United States
    Great read, thanks.
     
  11. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    30,545
    Country:
    United Kingdom
    Glad you enjoyed my witterings. The ROM hacking documentation from my signature https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ has a few more things with pictures and workflow, though it is more ROM hacking than cheat making. Likewise while I do know some X86 (all those tutorial links I have read and learned from myself) and Windows/PC code bothering I am not half as versed in it as I am the likes of the GBA and DS, we have a ways to go before I get to the limits of my knowledge here for PC stuff but it will hit far sooner than it would for said handhelds (especially if you start quizzing me on the intricacies of C, and especially C++, coding and how it trickles down).

    Seems I forgot to mention anti cheat, after promising to cover it too. Better sort that.

    Some devs for various reasons, or just the way something is coded, will do things to prevent cheats from happening.

    The cheat making guide I linked in an earlier post ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) has a few examples on later "days" but we will cover it a bit.

    Two main approaches.

    1) Encryption, hashing and mirrors, mirrors also including false positives and display values.
    2) Fun with pointers

    Encryption is just that and the value will be combined with another value to have it as legit. Usually it is not going to be full bore asymmetric cryptography like you use to secure a bank transaction, website or something, however some online games might go there.
    Hashing is more or less just that. All the data will be hashed and if it does not match the hash then something has been twiddled that should not have. You will more commonly meet hashes in save hacking where most save games have some kind of hash/checksum (rarely a signature but it is space year 2020 as I write this and and running a HMAC or something is no big deal so things can change)
    Mirrors. The basic thing, beyond simply having multiple copies all over memory, here is having say the inverse of the number somewhere else, or have it taken away from the maximum number. If you are doing the is higher than/is lower than then inversion will soon lose something from what search as it will decrease when the main value increases.
    There are plenty of further options with maths, boolean logic (though the XOR stuff is arguably a form of crypto), shifts, rotates and whatever other operations might want to be done.
    False positives and display numbers are a fun one. People often want to search for numbers themselves as they appear on display, and many times it will speed up a search (the main exception being timers which are frequently not as nice, and often also provide an example of how freezing a number with a cheat might stop the game from working if something depends upon a timer working. If it is only going to be a minute or two to search then do that). Sometimes devs will use that to trick people.
    Display numbers might also be if the stats are a calculation (I am sure we have all had games with things like HP = level*5 for this class + constitution * 2 + ...) and the results of it displayed rather than being a straight number.

    2) Pointers, as we started out discussing, point the way to data. It is entirely possible to shuffle data around the RAM the whole time the game is working (can be every frame/vblank, or every hblank, can be some other cycle, can be a far longer time, can be after every interaction with it). It does also rather handily defeat a basic search, change number, search, change number... cheat finding routine. In such cases you probably do want to be working backwards from the display number in assembly to get to the good stuff.


    I mentioned problem cheats above. All sorts of things can change what goes here -- games can have low health behaviours, timers being stopped is often a bad thing if the rest of the game depends upon the time, if you set a value to a start game value it might be a low value by the time you end a game (say in Zelda if you have some kind of audio cue saying you have low health and you say if greater than three set it to three for your hearts for some kind of challenge run the sound will probably drive you nuts),
    Sometimes you will have to work around it with assembly but do also not discount simpler means, or things like resetting to full rather than holding it. If infinite health is a problem for a must lose battle (and you don't want to recode it) then maybe infinite invincibility potions instead.

    Back in general cheats there is some more advanced stuff to contemplate. There are also things like text speed changes that some like to do (if the speed slider in a game is just setting values but is way below max value then maybe set it to max value with a cheat), I mentioned on-off flags in passing and they can be annoying to find, no random fights cheats are usually things like there is an item/equip/cutscene type mode in a game that sets such a flag so find it and trip it without the item or whatever, moon jump is either a jump/gravity stat set to silliness or if there is a double jump then the "has jumped a second time" flag is always set to 0. Or if you prefer always be asking yourself "if I were the dev what would I have done?", sometimes it will not get you far but often enough it gets you good places that might have taken longer.
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - pointers, Engine, Cheat