Wrong algorithm for scanning for signatures?

[mspi21]

I have been working on a freecam for Fallen Order and took some inspiration from your project (it’s been very helpful!), but in the process I noticed this piece of code, which doesn’t really make sense to me:

https://github.com/coltonon/OpenGameCamera/blob/afadceb5a877ca841c246ae58ca9440e372d888a/OpenGameCamera/SigScan/SigScan.cpp#L112

How can this ever work? It seems like a classic instance of the “finding a substring in a string” problem:

consider the following signature:

[34 56 78

and this piece of memory:

34 56 34 56 78

as I understand it, your algorithm goes through bytes 0 and 1, stops at the third (2), says “this one doesn’t check out”, but instead of going back to byte 1 and then 2, it continues with byte 3, therefore never detecting the pattern and returning a null pointer.

I do apologize if I’m missing something. It just seems strange that a linear algorithm could find a sequence of bytes in memory (without any sort of alignment tricks going on).

[Dyvinia]

I'm not sure if anyone would know actually, the main/original dev now works at EA and he was the one that likely wrote that line of code

[mspi21]

It’s not just that one line of code, it’s the whole block that follows. It’s just about the principle:

Let’s say I give you a string of characters (that’s like the program loaded in memory):
bananas and apples

and suppose you want to scan this sentence and find the offset of the characters anas (that would be the function signature):

What the code does is that it finds the first a, which is at position 1 (b is 0, a is 1, n is 2, and so forth). Then it tries to match the pattern we’re looking for, so anas. It matches ana, but the next letter is an n, not an s. What should the algorithm do now? It should go back to the second a in bananas and try again from there, right?

But what this piece of code does is that it ignores the previous as and continues searching for anas in the string as and apples. It was supposed to find the pattern at position 3, but instead the result returned by the algorithm is “not found” (nullptr).

I don’t necessarily need the author of the code to respond, I would just like a second opinion or someone to correct me if I’m wrong. If I’m not, I will gladly create a pull request with the bug fixed, still it is curious to me that this algorithm should work more than a fraction of the time if I’m right. I hope what I’m saying is clearer now.

[Dyvinia]

Yeah it makes sense, personally though I've got no clue if its something that was intended or if it was an oversight. Not sure if anyone else whos still involved with the project knows much about reverse engineering, so not sure if anyone would be able to give an answer