Pointer scan does not work

[Samg381]

I am using the latest AppImage on my Ubuntu 22.04 system.

Clicking 'pointer scan for this address' and clicking 'ok' on the scan configuration screen results in a blank pointer scan output.

Screenshots below.

After clicking 'scan' ...

[brkzlr]

Pointer scan won't auto-open your file. You're supposed to press on File -> Open and then open the scandata. If it's still empty, then it found nothing.

Instructions on how to use this are posted on our Discord server but we didn't had the time to fill the wiki with stuff like this. Regardless, Pointer Scan does work as intended but the design will change in the near future.

[brkzlr]

Drafted a lite version for you and other non-Discord users: https://github.com/korcankaraokcu/PINCE/wiki/Pointer-Scanner

[Samg381]

Thank you very much! This was helpful, and corrected some of my misunderstandings about the feature and it's uses.

Unfortunately, I am still scratching my head with a simple issue I am trying to work through. Perhaps you could give it a quick test on your end?

I have written a very simple C++ application called 'samMemTest' that asks for the user to input a number, and then prompts the user to save that number to a global variable. This sequence runs in a loop, and allows for easy location of both the input buffer address, and the address of the storage variable. I have attached the binary to the program, as well as a screenshot.

samMemTest.zip

Here is the source code to samMemTest:

bool memTest() {

    int x;

    printf("Memory test initialized.\n---\n");

    while(true) {

        printf("\n---\nEnter a number: \n");
        std::cin >> x;

        printf("Press P to write. \n");
        char key;
        std::cin >> key;

        if (key == 'p') {
            printf("Number is now %d\n", x);
        }

    }
    return true;
}

My objective is to find the offset to the global variable, such that I can immediately find the global variable after samMemTest has been re-launched. I am using the mapfile (/proc/PID/maps) and the stack address as the base address, but I am also not sure if this is correct.

I have tried simply subtracting the address of the global variable (as found by PINCE) from the base address (found in mapfile), however this offset changes slightly between runs. See below screenshot:

I know this is not your job (nor the proper place to ask), but after reading your thorough write-up I felt compelled to ask here. Any assistance would be greatly appreciated.. I am almost certainly doing something wrong..

Thank you!

[brkzlr]

That's not a global variable though. Global variables have static addresses (which means you don't need to pointer scan them) as they're stored in the .BSS section of a binary.

It is a local variable inside main() that is stored on the stack like the rest.

I'll take a look after work.

[Samg381]

Ah, interesting.. appreciate that insight! So it seems my 'x' variable was not global (my oversight), and was being stored in the stack instead of the initialized/uninitialized data segment. So, if I'm understanding properly- there is no such thing as an offset to a value only in the stack.

Let me make a new dummy application with a proper global variable and I'll try again and report back. Thank you again.

---

Edit:

Okay, here is the new application:

#include <stdio.h>
#include <iostream>

int GlobalVariable;

int main() {

    printf("Memory test initialized.\n---\n");

    while(true) {

        printf("\n---\nEnter a number: \n");
        std::cin >> GlobalVariable;

        printf("Press P to write. \n");
        char key;
        std::cin >> key;

        if (key == 'p') {
            printf("Number is now %d\n", GlobalVariable);
        }

    }

    return 0;

}

And here is the result of the pointer scan!

memTest[4]+13C memTest[4]+8->134 memTest[4]+8->0->134 memTest[4]+8->0->0->134 libc.so.6[5]+838->168->0->134 libc.so.6[5]+838->168->134 memTest[4]+F8->CC memTest[4]+8->F0->CC memTest[4]+8->0->F0->CC libc.so.6[5]+838->168->F0->CC memTest[4]+F8->88->CC memTest[4]+8->F0->88->CC memTest[4]+F8->88->88->CC

[brkzlr]

there is no such thing as an offset to a value only in the stack.

Nope, there is. I was just saying that your application had a local variable not a global one. If it was indeed global, you could just find its address and that would be static, same every app boot (with ASLR and other randomizers disabled ofc).

I've tested your code and ran a pointer scan, pointer chains persist after restart, so everything is working fine. If you have Discord, I strongly suggest going into our server as GitHub is not really fit for these kind of discussions.

[Samg381]

Thanks a ton. One final, quick question regarding the syntax of the pointer scan- then I will close this thread! (and move to discord for future non-ticket items)

I entered memTest[4]+0x13C into a new manual address, which reads the value of our variable perfectly, and persists between instantiations of the dummy program, as expected.

I am wondering what the significance of the [4] is in this case. I poured over cheat engine documentation and couldn't find any reference to this syntax is with respect to pointer scans. Is it a byte offset of some sort? Are we resolving a pointer at memTest[4] before adding the 0x13C offset? Or is it some sort of shifting operation being done to the memTest base address prior to adding the offset?

Apologies for my neophyte questions.. it is embarrassingly bad.

[brkzlr]

If you go into Memory Viewer while attached to a program, then go to View -> Memory Regions you'll see that your program memTest has 5 entries, which are indexed from 0 to 4.

memTest[4] is the base address of the last entry there, which is the only region that is writable, where most variables would be stored.

[Samg381]

Tremendously helpful. Thank you.