Cheat Engine

[Bunny_Wabbit]

And for that matter, Lua.

As someone who enjoys IT related subjects and gaming, I've always wanted to become better at understand Cheat Engine and how it works, but I've never managed to find a good resource at learning Assembly or Lua to the point where it 'clicks' as to how Cheat Engine communicates with both languages.

I get the basics of how to use the software, like how to change someone's HP or make everything free by deleting the instruction to deduct cash, but while I understand how to do it, none of the numbers make sense to me. The most I can retain from what little tutorials I've found is that the three letters are registers. But that doesn't explain what the addresses next to them are.

My main point of confusion is that, if Assembly is used to modify a processor at the hardware level, then why is it being used to change someone's HP in a video game?

There's a YouTube series by someone who's name I forgot, who reverse engineered games all the time and has a series called Let's Hack. I'm not sure if he's still uploading but I got a decent-way through his tutorials, up until he said knowing Assembly might help with the specific lesson, and because my brain is weird, I wanted to stop there and get the full course on Assembly, so everything he did in the video would make sense to me, but the question posed in the title has stopped me in my tracks. I don't know what I should be looking for if most tutorials I find online focus on processors and hardware, when it's clearly being used for software here.

Edit: Stephen Chapman, that's it. His playlist is the best I've found on Cheat Engine and I haven't watched the videos in a long while, but as I said I think I stopped watching because I told myself I was going to learn some of the ASM stuff before carrying on, and I never did.

[ParkourPenguin]

[FreeER]

[Bunny_Wabbit]

So you guys think I should try and learn and retain C++ first?

I looked at that playlist ParkourPenguin, but I get the feeling you need to be a student of his to understand the context of what he's talking about. He kept saying stuff like "As we talked about before". I got a little beyond converting Dec to Bin to Hex in the first video and it kinda got confusing from there, and felt like a test on whether I needed to remember what he was talking about or not.

I tried learning x86 from a Udemy course and a book on Kindle, but the instructor had scarpered and wasn't answering anyone's questions, and just wasn't very easily understood. As for the book, every time he mentioned a new CPU introducing a new feature, he'd talk about it as if you already know what it is, like he was making everything twice as wordy as it needs to be. Like, for example he'd say what features the x86 introduced after its previous iteration, and he wouldn't explain what any of the features did, he'd just breeze past them.

Seems there really are no resources that break this shit down. I'm wondering if just searching stuff I don't understand in Cheat Engine will be a better idea - I've already gotten a grasp on registers and basic instructions that way. As I said, Stpehen vaguely saying "Well some Assembly might help here" had me super worried that I'd need to study an Assembly bible in order to actually use Cheat Engine, or just basic reverse engineering on software. The latter might still be true, but I still get the feeling that understanding any of the actual code in memory is much easier to understand than these people make it out to be.

[FreeER]

Understanding 10-20 lines is pretty easy yeah
Most of what you're going to see is mov, add, sub, inc, dec, lea, mul, imul, div, xor, push, pop, jmp, call, and various conditional jumps like jne,je,jg,jl etc.
and for floating point
fld, fst, fstp, fadd, fsub, fmul or (older x86 code)
movss, movsd, adds*, subs*, muls* (newer x64 but also seen on new x86)

As Kovah mentions near the start of the first video there's only about 14-30 instructions that make up the majority of code and are really worth knowing.

not too hard to nop out an instruction to make it not do something or change dec/sub to inc/add so that it increases a value instead of decreasing it, or change a mov to move an immediate/literal value (harder with the floating point since they don't accept immediate values)

Understanding entire functions and how they relate to each other, as well as writing your own, how a stack frame works and some of the more complex instructions will take more effort.

As for the OST videos, there's 11 hours of content over 2 days irl, you/they are not expected to remember everything. Just watch it through once and see how much you pick upon. Don't stress over it, just see if you can follow along with the program being discussed and do the exercises. If something sounds interesting just make a note and look it up later. Some things are nice to know about in general like risc and endianness but aren't going to come up if you're just doing regular games, however they probably will if you mess with any emulators so it's nice to be aware that those are things that exist at least vaguely. Similarly for base conversions you need to be aware that various bases exist and allow you to represent the same value in different ways, but you can just use a calculator to do the conversion.

Stephen himself didn't know asm all that well through the tutorials iirc, I remember seeing him recreate call with push and jmp in his magic bug net script for terraria. Though it's possible those were made after I don't believe so. Of course he's learned a lot since then

The more you're actually working with assembly the more it matters how well you understand things, and there's a lot of things that aren't very intuitive so aren't just going to pick up by doing the same basic techniques a noob knows about. You're probably not going to learn to trace function calls etc., especially without programming experience, if all you understand up to that point is nopping whatever comes up in the find what writes list, of course if you're still watching tutorials maybe it'll be shown and you can learn from that and trial and error but.

[predprey]