Implement a Pseudo Objective-C language representation #6807
Conversation
bdash
force-pushed
the
objc-pseudo-language
branch
from
7240294 to
487602f
Compare
…ementations The setting is on by default to preserve the current experience. It should likely be revisited as related changes are merged. I find this to be confusing as often as it is helpful since it picks the first implementation of the selector it sees without consideration for the type of the receiver. This is particularly annoying if the binary being analyzed implements a method with the same name as a commonly-used method on a system type (`-description` or `-path`, for instance), or has methods with generic names (`-initWithURL:`) on many types. Explicit cross-references from selectors to method implementations make it possible to see the potential implementations without rewriting the call, and an Objective-C pseudo-language (Vector35/binaryninja-api#6807) provides an even more natural representation of Objective-C message sends without these downsides.
bdash
force-pushed
the
objc-pseudo-language
branch
3 times, most recently
from
a20a8b8 to
dabc917
Compare
bdash
force-pushed
the
objc-pseudo-language
branch
2 times, most recently
from
60cf7f2 to
526f46f
Compare
|
This is very cool. We will look into merging this but I have some questions we need to discuss internally before. I think we probably would have preferred this to be in its own set of files rather than mixed in with the pseudo-c. Its understandable why as they share a lot of code but maybe it would have been best to copy the code. |
|
I'm not clear why you'd prefer that this copy the ~2,500 lines of code from the pseudo-c plug-in, rather than sharing the common code. Objective-C is very much a superset of the C language so sharing the code seems like the best solution. Based on what I've seen with other cases in binaryninja-api where code has been copied rather than shared (Objective-C metadata and Mach-O parsing), the "shared" code will very quickly get out of sync as people will either not know or not want to take the time to make the same change in multiple places. |
|
Yeah you're right after looking at your changes a bit more what you did makes more sense than copying the existing code. |
This is implemented in the Pseudo C plug-in as it shares 99% of the logic. The Objective-C support is implemented in a subclass of `PseudoCFunction`. The handling of instruction types that the Objective-C representation needs to customize is extracted into virtual functions that the Objective-C subclass overrides. This currently supports: * Rewriting `objc_msgSend` / `objc_msgSendSuper2` with constant selectors to `[receiver message]` notation. * Rewriting calls to `objc_alloc` / `objc_alloc_init` / `objc_new` to the equivalent message send notation. * Rewriting `objc_retain` / `objc_release` and friends to the equivalent message send notation. * Displaying Objective-C class references as their class names rather than `_OBJC_CLASS_$_` symbol names. * Displaying Objective-C string literals as `@"..."`. This works best when used in conjunction with https://github.com/bdash/bn-objc-extras as the reference counting runtime calls add so much clutter.
…an implementation These are detected by their function names having the characteristic `-[ClassName methodName:]` format. Calls to functions with this naming pattern that accept a selector as a second argument are assumed to be `objc_msgSend` calls that the Objective-C workflow rewrote. These calls are formatted identically to other `objc_msgSend` calls with the exception that the selector tokens reference the address of the call target rather than the selector string, so double-clicking on them takes you to the fixed destination of the rewritten call.
0cyn
force-pushed
the
objc-pseudo-language
branch
from
526f46f to
40a395b
Compare
|
Thank you so much for this PR, this has been a desired feature for a very long time! We've merged this PR with |
This is implemented in the Pseudo C plug-in as it shares 99% of the logic. The Objective-C support is implemented in a subclass of
PseudoCFunction. The handling of instruction types that the Objective-C representation needs to customize is extracted into virtual functions that the Objective-C subclass overrides.This currently supports:
objc_msgSend/objc_msgSendSuper2with constant selectors to[receiver message]notation.objc_alloc/objc_alloc_init/objc_newto the equivalent message send notation.objc_retain/objc_releaseand friends to the equivalent message send notation._OBJC_CLASS_$_symbol names.@"...".This works best when used in conjunction with bdash/bn-objc-extras as it supports eliminating the reference counting runtime calls that add so, so much clutter.