Skip to content

Regression from type slice handling in Type::TranslateTypeAccess #8097

@D0ntPanic

Description

@D0ntPanic

Version and Platform (required):

  • Binary Ninja Version: 5.4.9470
  • Edition: Ultimate
  • OS: macOS
  • OS Version: 26.4.1
  • CPU Architecture: M5

Bug Description:
In the test case binary quick3dcoreplugin.dll, in the function at 0x180003f18, there is a regression in structure field resolution that causes MLIL -> HLIL translation to lose dereferences, causing severe decompilation regressions.

Stable HLIL:

180003f2b        *arg1 = &std::exception::`vftable'
180003f34        arg1[1].q = 0
180003f37        arg1[1]:8.b.q = 0
180003f3f        __std_exception_copy(from: arg2 + 8, to: &arg1[1])
180003f4b        *arg1 = &std::bad_alloc::`vftable'{for `std::exception'}
180003f56        return arg1

Post-type-slice HLIL:

180003f2b        *arg1 = &std::exception::`vftable'
180003f34        arg1[1].q = 0
180003f3f        __std_exception_copy(from: arg2 + 8, to: nullptr)
180003f4b        *arg1 = &std::bad_alloc::`vftable'{for `std::exception'}
180003f56        return arg1

The 8 byte write 8 bytes into the structure (seen in the stable output at 180003f37) is writing a byte field and 7 bytes of padding in one write. Type::TranslateTypeAccess fails to handle this case, not issuing any callbacks, then proceeds to ignore the dereference completely. The second write resolves to zeroing out the pointer, which causes it to pass nullptr to the function call, which is completely incorrect.

I have another example binary but I'm no longer able to log into the portal to upload them. Available upon request.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions