| Age | Commit message (Collapse) | Author |
|---|
|
Rather than introducing duplicate definitions of these types, use a
NamedTypeReference that will be resolved to the type from the libobjc
type library when it is loaded.
This prevents these types from showing up as id_1 / SEL_1 in some places
rather than as their expected names.
|
|
`SymbolQueue`'s lifetime was being managed via `new` / `delete`. This
was error-prone in the face of code that can a) throw exceptions, or b)
return early. Typically the solution would be to move to
`std::unique_ptr` and call it a day, but nothing is ever easy.
The `SymbolQueue`s created by `ObjCProcessor` are intended to live for
the duration of `ProcessObjCData` and `ProcessCFStrings` methods. Since
they are used multiple levels down the call tree, the active
`SymbolQueue` is stored as a member variable on `ObjCProcessor`.
Switching to `std::unique_ptr` would ensure that the `SymbolQueue` is
destroyed, but would leave a dangling pointer in the member variable.
To address this I'm introducing a `ScopedSingleton` class that provides
a thread-local singleton whose lifetime is controlled by a guard object.
`ProcessObjCData` / `ProcessCFStrings` call `ScopedSymbolQueue::Make`
and store the returned guard object in a local. Code that accesses the
symbol queue uses `ScopedSymbolQueue::Get` to retrieve the current
instance. The guard object ensures the `SymbolQueue` is deleted and the
`current` pointer is cleared no matter how the scope is exited.
A better longer-term design is to introduce a class for processing the
Objective-C runtime metadata and a class for processing constants such
as `CFString`s. These could directly own the symbol queue so it would be
accessible to any member functions that define symbols. This is a more
involved refactoring than I have time for right now.
|
|
This adds support for the `__objc_arrayobj`, `_objc_dictobj`,
`__objc_intobj`, `__objc_floatobj`, `__objc_doubleobj` and
`__objc_dateobj` sections that contain Objective-C constants. These are
emitted by Apple's versions of Clang for `const` literals, amongst other
things.
|
|
backed by a database
|
|
Handle the case where the `class` field of the category is a direct
reference to an external symbol via a bind fixup. In that case, the
pointer's value when read from the view is 0. To determine the class
name it is necessary to look up the relocation for the pointer's address
and parse the class name from the symbol's name.
|
|
- Removed last use of user object creation in objective-c
- Fixed function type info being omitted from certain images loaded automatically
- Add TODO about undo action in view init. This is not critical, just a non-actionable warning because of a design flaw
I will restate this again for anyone in the future, until the undo action system is thread-safe avoid calling it from any thread other than the main thread, it is very easy to deadlock or cause other issues. That goes for basically all user analysis object creation.
|
|
They were previously relying on the Objective-C workflow to render the
`rptr_t` typedef. Relative pointer types are now a first class citizen
and are rendered correctly without any additional work.
|
|
This made the macho objective-c processor aware of images and was passed around everywhere, instead we have an overridable section getter that gives the control over the section retrieval to the derived processor.
In the case of shared cache this means we can store the image to be processed and then use the header to locate the relevant sections.
Fixes: https://github.com/Vector35/binaryninja-api/issues/6594
|
|
The logic for determining the class name of a category did not correctly
handle classes defined in other images in the shared cache. There were
two problems:
1. If the class is defined in another image that is already loaded,
`ObjCProcessor` has already renamed the symbol from `_OBJC_CLASS_$_`
to `cls_`. Both forms of symbol name are now handled.
2. If the class is defined in an image that is not yet loaded, no symbol
name is available. The category's class is now looked up in the
shared cache symbol table, and the symbol's name is parsed as if it
were an import symbol.
This fixes almost all cases of "Failed to determine base classname for
category" that I have come across.
Mason Reed: Fixed up to make objective-c processor always consult GetSymbol
|
|
In absence of a better name, this commit refactors the shared cache code.
|
|
Both the Macho and DSC views need to process Objective-C but have separate processor classes. It would appear that the DSC version was largely a copy and paste of the Macho view one, with some modifications. The majority of code overlaps between the 2 so it doesn't make sense to maintain 2 and copy and paste improvements/fixes between them.
This commit fixes that by creating a base Objective-C processor that contains the shared code. View specific code is implemented in the respective subclasses for the views. Although there is very little view specific code for each.
|
