Type resolution can give surprisingly different results for local variables in similar code

オープン
#7,367 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
objective-c

調査の方向性

Reproduce the discrepancy using the attached good and bad binaries, switch to HLIL at 0x100000890, and apply the shown _objc_msgSendSuper2 call type override. Compare how obj_3 is resolved, including the objc_retain call at 0x100000918. Done means both cases resolve obj_3 as MyClass* after the override, rather than leaving bad at id.

索引モデルが issue の本文から書いたものです。

説明

Core: Type Propagation Effort: Medium Impact: Low

Version and Platform (required):

  • Binary Ninja Version: 5.2.8236-dev Ultimate, d8af0ff0
  • OS: macos
  • OS Version: 26.0
  • CPU Architecture: arm64

Bug Description:
While working on applying more type information from Objective-C binaries I noticed that the type resolution algorithm gives different results in code that is very similar. Specifically, in cases when the return type of a function that is used to initialize a variable and a function to which the variable is passed have a) different types and b) the same confidence, the function parameter type can end up taking precedence over the return type. This can give the effect of a call type adjustment not being applied.

Whether the return type or later parameter type ends up being selected for the local variable's type depends on the order the algorithm traverses the basic blocks and their edges.

Steps To Reproduce:

  1. Open both good and bad. Switch to HLIL and go to 0x100000890.
  2. Right-click on the call to _objc_msgSendSuper2 and add a call type override to:
    MyClass* _objc_msgSendSuper2(struct objc_super* super, SEL sel)
    

Expected Behavior:
The type of the local variable obj_3 should update to MyClass* to reflect the new type information.

good behaves as expected.

In bad it stays at id as the type information from the objc_retain call at 0x100000918 is seen first. Since it has the same full confidence as the return type of the call type override, it ends up being used.

Workaround:

Apply a type to the local variable.

Binaries:

bad.zip
good.zip

These can be built from this source file (call-type-override.m by doing:

cc -DBAD -o bad -fobjc-arc -framework Foundation -Os call-type-override.m
cc -UBAD -o good -fobjc-arc -framework Foundation -Os call-type-override.m

The only difference between them is if (!a || !b || !c) becomes if (!a && !b && !c)

主要言語
C++
スター
1.3k
フォーク
298
平均マージ
5日 5時間
マージ済み PR(30日)
19

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Vector35/binaryninja-api のほかの issue

Vector35/binaryninja-api の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。