Finding HEX pattern (and its global address) in process memory

Templates/Scripts
1

I’m trying to find specific set of bytes/pattern in a process memory. Manual search finds it relatively fast in 800Mb working set, but I can’t do it from BT template:

Printf("Running test1\n");
Printf("%Ld\n",  FindFirst("FFDDCCAACC,h", false, false, 1));
local TFindResults r = FindAll("FFDDCCAACC,h", false, false, 1);
Printf("Tfindall\n");
Printf("%d\n", r.count);

I always receive weirdest results. I know about “AddressLocalToFile” but it returns even more weird results.
What I want is the address where pattern starts I can work with - Use FSkip/FSeek/Ftell, ReadUInt at global address, etc.

For the sake of it I tried to leverage CursorPos:

local int64 pattern = GetCursorPos();
Printf("Pattern: %Ld\n", pattern);
Printf("Data %u\n", ReadUInt(pattern));
local uint32 rOffset = ReadUInt(pattern+14);
Printf("%u\n", rOffset);

It returns completely invalid data

2

Hello Digika. The FindFirst/GetCursorPos/ReadUInt functions all work with local coordinates which are 0…FileSize-1. Any time you want to print an address you have to use the AddressLocalToFile function when working with processes. You also have to make sure that everything is 64-bit and you need to use %LX or %Ld with Printf. We tried this code:

int i;
Printf("Running test1\n");
local TFindResults r = FindAll("FFDDCCAACC,h", false, false, 0);
Printf("Tfindall\n");
for( i = 0; i < r.count; i++ )
    Printf( "%LX\n", AddressLocalToFile(r.start[i]) ); 
Printf("%d\n", r.count);

This should print addresses that match the Ctrl+F tool. If you are using GetCursorPos and ReadUint, this will print the uint at the current position, but the read may be done in little-endian mode. It’s easier to tell what’s going on when using %X for printf:

local int64 pattern = GetCursorPos();
Printf("Pattern: %LX\n", AddressLocalToFile(pattern));
Printf("Data %X\n", ReadUInt(pattern));

Let us know if you can’t get either of these to work. Cheers!

Graeme
SweetScape Software

3

Thank you for the reply. The code you’ve provided does not work as expected.

//------------------------------------------------
//--- 010 Editor v14.0 Binary Template
//
//      File: 
//   Authors: 
//   Version: 
//   Purpose: 
//  Category: 
// File Mask: 
//  ID Bytes: 
//   History: 
//------------------------------------------------
local int i;
Printf("Running test1\n");
local TFindResults r = FindAll("FFDDCCAACC,h", false, false, 0);
Printf("Tfindall\n");
for( i = 0; i < r.count; i++ )
    Printf( "%LX\n", AddressLocalToFile(r.start[i]));
Printf("%d\n", r.count);

When I search for specified bytes manually I get result in 2 seconds.
When I run template I get no results. It executes normally.

No dice with cursor either.
After manual search I’m at the process memory position 5368813936. Inspector shows me uint32 with value: 1447122753 (41 57 41 56)
Running your example code:

local int64 pattern = GetCursorPos();
Printf("Pattern: %LX\n", AddressLocalToFile(pattern));
Printf("Data %X\n", ReadUInt(pattern));

I get the following output:

Pattern: 140019970
Data 41574156

The values make no sense.
Switching endianess also does not produce any relevant changes.

4

When using GetCursorPos, you said the position is 5368813936 but the script output is 140019970. Note that 140019970 is just 5368813936 in hex notation so they are the same number. If you just using decimal addresses you should use:

local int64 pattern = GetCursorPos();
Printf("Pattern: %Ld\n", AddressLocalToFile(pattern));
Printf("Data %X\n", ReadUInt(pattern));

Also the Data output of 41574156 matches the hex bytes 41 57 41 56 and this is in hex notation too. If the output of the script is not matching the results from Ctrl+F, make sure that you are running the script on the same process as you are doing Ctrl+F and not another file.

If you are sure you are running on the correct process then it’s possible the process has changed. When doing Ctrl+F, do you ever get a Read error displayed in the status bar? This can happen if the structure of the process has changed significantly since it was loaded. I believe right now the FindAll function is returning zero matches if it hits a read error but the Ctrl+F search will return some matches if it hits an error. We’ll have to look into this more.

Graeme
SweetScape Software

5

This makes a little bit more sense now, but it still does not explain why FindAll/FindFirst cannot find anything/return no results. The normal search does instanty.

6

We have tried running the script on a number of processes and get the same results as using Ctrl+F. Can you make sure you are running the script on the proper file? When you run the script, in the Output area you should see at the top 'Executing script ‘???’ on ‘???’. Make sure the file listed after ‘on’ is the file you are targeting. If you get a process that doesn’t return any results, could you try running this on a different process and see if you get the same results?

Graeme
SweetScape Software

7

Is there a difference between script and template in this context?

This is no a file, this is process memory.

8

The FindAll function should operate the same if run in a script or template. When running a script on a process you should see 'Executing script ‘???’ on ‘Process: ???’ in the Output panel. Just make sure that the process listed is correct.

Graeme
SweetScape Software

9

Yes, I can guarantee I’m running it on correct “file” (process).
My only assumptions it might have encountered read error and stopped (hence why the return was super-fast) but why is there no feedback on this?