Ghidra: Scalar search signed/unsigned issue

Created on 20 Feb 2020  路  5Comments  路  Source: NationalSecurityAgency/ghidra

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.

Most helpful comment

Here is a simpler example:

OR EDX, 0xffffffff

Searching for 0xffffffff results in no matches, but searching for -1 finds it.

All 5 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

0x6d696368 picture 0x6d696368  路  3Comments

forkoz picture forkoz  路  3Comments

loudinthecloud picture loudinthecloud  路  3Comments

awsaba picture awsaba  路  3Comments

gemini00 picture gemini00  路  3Comments