2021-03-13This is part 6 on the Writing our own Cheat Engine series:
- Part 1: Introduction (start here if you're new to the series!)
- Part 2: Exact Value scanning
- Part 3: Unknown initial value
- Part 4: Floating points
- Part 5: Code finder
- Part 6: Pointers
- Part 7: Code Injection
- Part 8: Multilevel pointers
In part 5 we wrote our very own debugger. We learnt that Cheat Engine is using hardware breakpoints to watch memory change, and how to do the same ourselves. We also learnt that hardware points are not the only way to achieve the effect of watchpoints, although they certainly are the fastest and cleanest approach.In this post, we will be reusing some of that knowledge to find out a closely related value, the pointer that points to the real value1. As a quick reminder, a pointer is nothing but an usize2 representing the address of another portion of memory, in this case, the actual value we will be scanning for. A pointer is a value that, well, points elsewhere. In Rust we normally use reference instead, which are safer (typed and their lifetime is tracked) than pointers, but in the end we can achieve the same with both.Why care about pointers? It turns out that things, such as your current health in-game, are very unlikely to end up in the same memory position when you restart the game (or even change to another level, or even during gameplay). So, if you perform a scan and find that the address where your health is stored is 0x73AABABE, you might be tempted to save it and reuse it next time you launch the game. Now you don't need to scan for it again! Alas, as soon as you restart the game, the health is now stored at 0x5AADBEEF.Not all hope is lost! The game must somehow have a way to reliably find this value, and the way it's done is with pointers. There will always be some base address that holds a pointer, and the game code knows where to find this pointer. If we are also able to find the pointer at said base address, and follow it ourselves ("dereferencing" it), we can perform the same steps the game is doing, and reliably find the health no matter how much we restart the game3.PointersCheat Engine Tutorial: Step 6 In the previous step I explained how to use the Code finder to handle changing locations. But that method alone makes it difficult to find the address to set the values you want. That's why there are pointers:At the bottom you'll find 2 buttons. One will change the value, and the other changes the value AND the location of the value. For this step you don't really need to know assembler, but it helps a lot if you do.First find the address of the value. When you've found it use the function to find out what accesses this address.Change the value again, and a item will show in the list. Double click that item. (or select and click on more info) and a new window will open with detailed information on what happened when the instruction ran.If the assembler instruction doesn't have anything between a '[' and ']' then use another item in the list. If it does it will say what it think will be the value of the pointer you need.Go back to the main cheat engine window (you can keep this extra info window open if you want, but if you close it, remember what is between the [ and ]) and do a 4 byte scan in hexadecimal for the value the extra info told you. When done scanning it may return 1 or a few hundred addresses. Most of the time the address you need will be the smallest one. Now click on manually add and select the pointer checkbox.The window will change and allow you to type in the address of a pointer and a offset. Fill in as address the address you just found. If the assembler instruction has a calculation (e.g: [esi+12]) at the end then type the value in that's at the end. else leave it 0. If it was a more complicated instruction look at the calculation.Example of a more complicated instruction:[EAX*2+EDX+00000310] eax=4C and edx=00801234.In this case EDX would be the value the pointer has, and EAX*2+00000310 the offset, so the offset you'd fill in would be 2*4C+00000310=3A8. (this is all in hex, use calc.exe from windows in scientific mode to calculate).Back to the tutorial, click OK and the address will be added, If all went right the address will show P->xxxxxxx, with xxxxxxx being the address of the value you found. If thats not right, you've done something wrong. Now, change the value using the pointer you added in 5000 and freeze it. Then click Change pointer, and if all went right the next button will become visible.extra: And you could also use the pointer scanner to find the pointer to this address.On-access watchpointsLast time we managed to learn how hardware breakpoints were being set by observing Cheat Engine's behaviour. I think it's now time to handle this properly instead. We'll check out the CPU Registers x86 page on OSDev to learn about it:
- DR0, DR1, DR2 and DR3 can hold a memory address each. This address will be used by the breakpoint.
- DR4 is actually an obsolete synonym for DR6.
- DR5 is another obsolete synonym, this time for DR7.
- DR6 is debug status. The four lowest bits indicate which breakpoint was hit, and the four highest bits contain additional information. We should make sure to clear this ourselves when a breakpoint is hit.
- DR7 is debug control, which we need to study more carefully.
Each debug register DR0 through DR3 has two corresponding bits in DR7, starting from the lowest-order bit, to indicate whether the corresponding register is a
Local or
Global breakpoint. So it looks like this: Meaning: [ .. .. G3 L3 G2 L2 G1 L1 G0 L0 ]Bit-index: 31-08 07 06 05 04 03 02 01 00Cheat Engine was using local breakpoints, because the zeroth bit was set. Probably because we don't want these breakpoints to infect other programs! Because we were using only one breakpoint, only the lowermost bit was being set. The local 1st, 2nd and 3rd bits were unset.Now, each debug register DR0 through DR4 has four additional bits in DR7, two for the
Condition and another two for the
Size: Meaning: [ S3 C3 S2 C2 S1 C1 S0 C0 .. .. ]Bit-index: 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15-00The two bits of the condition mean the following:
- 00 execution breakpoint.
- 01 write watchpoint.
- 11 read/write watchpoint.
- 10 unsupported I/O read/write.
When we were using Cheat Engine to add write watchpoints, the bits 17 and 16 were indeed set to 01, and the bits 19 and 18 were set to 11. Hm, but 112 = 310 , and yet, we were watching writes to 4 bytes. So what's up with this? Is there a different mapping for the size which isn't documented at the time of writing? Seems we need to learn from Cheat Engine's behaviour one more time.For reference, this is what DR7 looked like when we added a single write watchpoint:hex: 000d_0001bin: 00000000_00001101_00000000_00000001And this is the code I will be using to check the breakpoints of different sizes:thread::enum_threads(pid) .unwrap() .into_iter() .for_each(tid let thread = thread::Thread::open(tid).unwrap(); let ctx = thread.get_context().unwrap(); eprintln!("hex: :08x", ctx.Dr7); eprintln!("bin: :032b", ctx.Dr7); );Let's compare this to watchpoints for sizes 1, 2, 4 and 8 bytes:1 bytehex: 0001_0401bin: 00000000_00000001_00000100_000000012 byteshex: 0005_0401bin: 00000000_00000101_00000100_000000014 byteshex: 000d_0401bin: 00000000_00001101_00000100_000000018 byteshex: 0009_0401bin: 00000000_00001001_00000100_00000001 ^ wut?I have no idea what's up with that stray tenth bit. Its use does not seem documented, and things worked fine without it, so we'll ignore it. The lowest bit is set to indicate we're using DR0, bits 17 and 16 represent the write watchpoint, and the size seems to be as follows:
- 00 for a single byte.
- 01 for two bytes (a "word").
- 11 for four bytes (a "double word").
- 10 for eight bytes (a "quadruple word").
Doesn't make much sense if you ask me, but we'll roll with it. Just to confirm, this is what the "on-access" breakpoint looks like according to Cheat Engine:hex: 000f_0401bin: 00000000_00001111_00000100_00000001So it all checks out! The bit pattern is 11 for read/write (technically, a write is also an access). Let's implement this!Proper breakpoint handlingThe first thing we need to do is represent the possible breakpoint conditions:#[repr(u8)]pub enum Condition Execute = 0b00, Write = 0b01, Access = 0b11,And also the legal breakpoint sizes:#[repr(u8)]pub enum Size Byte = 0b00, Word = 0b01, DoubleWord = 0b11, QuadWord = 0b10,We are using #[repr(u8)] so that we can convert a given variant into the corresponding bit pattern. With the right types defined in order to set a breakpoint, we can start implementing the method that will set them (inside impl Thread):pub fn add_breakpoint(&self, addr: usize, cond: Condition, size: Size) -> io::Result<Breakpoint> let mut context = self.get_context()?; todo!()First, let's try finding an "open spot" where we could set our breakpoint. We will "slide" a the 0b11 bitmask over the lowest eight bits, and if and only if both the local and global bits are unset, then we're free to set a breakpoint at this index4:let index = (0..4) .find_map(i ((context.Dr7 & (0b11 context.Dr0 = addr, 1 => context.Dr1 = addr, 2 => context.Dr2 = addr, 3 => context.Dr3 = addr, _ => unreachable!(),}let clear_mask = !((0b1111 dd2b598166
