I have a code unit that looks like this:
MOV byte ptr [ESP + 0x24], 0xcc
If I select that code unit and do a scalar search on my selection, looking for the _Specific Scalar_ 0xcc, it doesn't find it. However, if I look for the _Specific Scalar_ -52, it finds it.
If you right-click on that instruction and select "Instruction Info", does the type of that operand say "SCAL"? If not, it won't be found in a scalar search. Another way to check: if you select that instruction and open the instruction search dialog (Search->For Instruction Patterns), then filter out all scalars (select the blue 'S' on the toolbar), I bet that operand stays the same, because it's not seen as a scalar.
I suppose this is a bit of a semantic issue. Internally that item isn't stored as a SCAL type but obviously as a user you don't care; if it looks like a duck and quacks like a duck, it's a scalar (I think that's how that saying goes).
If you right-click on that instruction and select "Instruction Info", does the type of that operand say "SCAL"? If not, it won't be found in a scalar search. Another way to check: if you select that instruction and open the instruction search dialog (Search->For Instruction Patterns), then filter out all scalars (select the blue 'S' on the toolbar), I bet that operand stays the same, because it's not seen as a scalar.
I suppose this is a bit of a semantic issue. Internally that item isn't stored as a SCAL type but obviously as a user you don't care; if it looks like a duck and quacks like a duck, it's a scalar (I think that's how that saying goes).
That would only make sense if it didn't find it when searching for -52. Additionally it also finds it when searching for -0x34. I'm only speculating, but I'm wondering if it is ruling it out when searching for 0xcc because its unsigned value requires 2 bytes to fit in a signed value which is obviously larger than a byte. Pure speculation though, I haven't actually looked into the cause only reproduced it.
I confirmed it's a SCAL. This is more of an issue of it being an unsigned byte, but the scalar search is searching for signed bytes, or something like that.
Here is a simpler example:
OR EDX, 0xffffffff
Searching for 0xffffffff results in no matches, but searching for -1 finds it.
Got a fix for this - we'll be rolling it out soon
Most helpful comment
Here is a simpler example:
OR EDX, 0xffffffffSearching for
0xffffffffresults in no matches, but searching for-1finds it.