[MachoView] Fixed missing symbols in binding parsing

[mostobriv]

This MR addressing #7196

[mostobriv]

@0cyn @bdash what do you think about bindings into Self (BindSpecialDylibSelf), should MachoView handle them as before - if can't find, then ignore and log an error, or should define them as external in case if can't find (this behaviour can add some extra info to the user)?

[0cyn]

Hi, I apologize for the delay on this issue. The binary provided in #7196 ended up having exposing a sweeping set of issues with how we process binding information, handle stubs sections, etc.

I've created a draft PR containing the in-progress fixes for this branch here: #7303

Further testing needs done on this branch to ensure it doesn't break or drastically slow down any existing Mach-O processing.

I'm going to go ahead and close this PR in favor of that one, as it includes the fix contained in this PR.

We are hoping to merge this very soon after we're able to validate the changes. Thank you so much for your PR!

[mostobriv]

Sure, no problem

[mostobriv]

However, what about this?

what do you think about bindings into Self (BindSpecialDylibSelf), should MachoView handle them as before - if can't find, then ignore and log an error, or should define them as external in case if can't find (this behaviour can add some extra info to the user)?

Can you cover this as well in your MR?

[0cyn]

I decided to handle this as before in the PR, logging an error if it cannot be found, as they afaik should not be bindable at runtime.

Proving an error with the symbol information and address it attempted to bind should be sufficient enough info for the user in identifying something strange occurring, without incorrectly responding to these ordinals by trying to bind something to a symbol that is not there.

I'm very hesitant to try and infer something the binding information disagrees with.

---

I am seeing these in this libloader binary: (was this dumped from memory out of curiosity?)

In this case the intern bind itself will fail, but the la_symbol_ptr entry already encodes the value of the target function.

[mostobriv]

as they afaik should not be bindable at runtime.

they are a weak bindings, so they should actually, i mean there is no-error in the context of linking them in runtime, however i guess logging such symbols is ok as well

was this dumped from memory out of curiosity?

nope, this is enterprise protection (RASP) of an iOS apps library, this is how its shipped in IPAs

UPD: oh, wait, ye, this one is dumped actually, but not in form of you ment i guess, its dumped via old version of mremap_encrypted, so technically it wasnt loaded (?)

[mostobriv]

I can try to create such binary statically for you, if it helps, guess it will only require bit of llvm magic

[bdash]

I didn't see anything in the binary that looked like a self bind.

I think an oversight here is that bindings in the weak bindings table cannot explicitly set a library ordinal. The code as it stands treats those weak bindings as having a library ordinal of 0 (BIND_SPECIAL_DYLIB_SELF), when it should treat all weak bindings as implicitly having a library ordinal of -3 (BIND_SPECIAL_DYLIB_WEAK_LOOKUP).

Something like:

-               uint64_t ordinal = 0;
+               uint64_t ordinal = binding == WeakBinding ? BindSpecialDylibWeakLookup : 0;