| Age | Commit message (Collapse) | Author |
|---|
|
Cont. 02e67da266d21e106d0b9900a2a98dbf8d045ad2
We don't really need to do the same check for the non-utf8 variant since it uses the ReadCString function.
|
|
Fixes 912465b5cf1d0442443d9584e15111361f27751c regression that broke cfstring parsing
|
|
Fixes https://github.com/Vector35/binaryninja/issues/1470
|
|
|
|
|
|
view
This can cause functions to be reanalyzed unnecessarily when the view is
loaded from a bndb. Fixes
https://github.com/Vector35/binaryninja-api/issues/8051.
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7666.
Correctly managing the state of bulk symbol modifications via
`BeginBulkModifySymbols` / `EndBulkModifySymbols` is error-prone in the
face of exceptions and early returns. Leaking a bulk symbol modification
can leave the view in a state where no further changes to symbols will
be applied.
All users of the C++ API are encouraged to move from
`BeginBulkModifySymbols` / `EndBulkModifySymbols` to the new
`BulkSymbolModification` class.
|
|
The symbol creation code in `ObjCProcessor` was updated to avoid
creating undo actions some time ago, but removing these calls was missed
due to the timing of when the PR that introduced them was merged.
|
|
Incorrect parsing of method type encoding strings was causing incorrect
function types to be applied to Objective-C method implementations. In
some cases this would result in confusion about which stack locations
specific parameters resided at.
`q`, `Q` and `d` were being mapped to `NSInteger`, `NSUInteger` and
`CGFloat` respectively. While this works for 64-bit platforms, the type
aliases refer to 32-bit types on 32-bit platforms. These type encodings
are explicitly for 64-bit types. To address this `q`, `Q` and `d` are
now mapped to `int64_t`, `uint64_t` and `double` respectively.
`l` and `L` were incorrectly being interpreted as `int64_t` and
`uint64_t`. While `long` is a 64-bit type on 64-bit Apple platforms, the
`l` / `L` type encodings always refer to a 32-bit type.
`S` was mistakenly being mapped to `uint8_t`. It is now `uint16_t` as
intended.
|
|
The compiler represents block parameters as `@?` in the method type
encoding string. We had been parsing this as two separate parameters
(one `id` and one unknown type that was mapped to `void*`), resulting in
some Objective-C method implementations incorrectly having an extra
parameter.
We cannot represent a Clang block (e.g., `void (^)()`) in the type
system at present. Since these are Objective-C compatible types the
simplest solution for now is to represent them as `id`.
|
|
This eliminates a significant amount of wasted work when loading
multiple images containing Objective-C from a shared cache. The time
taken to load 400 images from an iOS shared cache (with an analysis hold
enabled) drops from eight minutes to around six minutes.
|
|
|
|
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.
|
|
The `__objc_ivar` section contains [values of type `long` for all
architectures except arm64, where it contains `int`][1].
This fixes problems with resolving non-fragile ivar accesses to struct
field accesses on arm64 and 32-bit architectures.
[1]: https://github.com/llvm/llvm-project/blob/535d6917ec3308ade866f205644b740666312342/clang/lib/CodeGen/CGObjCMac.cpp#L5628-L5629
|
|
This would leak if parsing of CFStrings was enabled while parsing of
Objective-C metadata was disabled.
It would also leak if exceptions were thrown or early returns were taken
in the ~500 lines between where the object was allocated and it was
deleted.
|
|
`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.
|
|
The order that the operands to `+` are evaluated in is unspecified. Clang
happens to evaluate them left to right and gives the expected answer.
MSVC picks the opposite order and so the value it computes is off by 4.
This was resulting in missing method names when arm64 binaries
containing Objective-C are analyzed on Windows.
|
|
of the _user_ variant
|
|
|
|
cause bugs and also issues with C++20
|
|
backed by a database
|
|
This makes it easier to see the possible message send targets when
looking at a call to `objc_msgSend`.
|
|
Detect and remove common prefixes used on selectors so that their
argument names are more natural. For instance, a selector of
`initWithURL:withStagedURL`: now ends up with arguments named `URL` and
`stagedURL`, rather than `initWithURL` and `withStagedURL`.
|
|
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 also updates the symbol names that are generated when the name
cannot be found to include the address in hex rather than decimal so
it's easier to navigate to.
|
|
objc-runtime-new.mm mentions an offset of 0 is used for anonymous
bitfields.
Previously this would throw an exception when attempting to read from
offset 0 and the types would not be applied.
|
|
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
|
|
More informative than a warning
|
|
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
|
|
See: https://github.com/Vector35/binaryninja-api/pull/6540/files#r2020882071
|
|
|
|
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.
|
