| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These files are present alongside iOS 26 shared caches. Explicitly
ignoring them avoids an error being logged to the console.
|
|
In some iOS 15 caches, the .symbols file's mapping has an address of 0.
This would cause it to be returned by `SharedCache::GetEntryContaining`
and loaded into the view.
The .symbols file contains the local symbol tables for images in the
shared cache. It is not intended to be mapped into the same address
space as the rest of the shared cache.
`SharedCache` now tracks the symbols cache entry separately from other
entries. A dedicated `VirtualMemory` region is used when accessing the
data it contains. This could be a `FileAccessor`, but that would require
additional changes within `SharedCacheMachOHeader`.
`SharedCacheMachOProcessor` now directly accesses the local symbols
cache entry rather than needing to search for it.
|
|
Prior to macOS 13 / iOS 16, the base offset to use for relative direct
selector references within Objective-C message lists was stored within
the `__TEXT,__objc_opt_ro` section of /usr/lib/libobjc.A.dylib.
|
|
A mapping from imported symbol names to libraries is added to metadata.
This is used to populate external links for files within projects,
following the lead of `PEView`.
|
|
implementations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adjustments of the same confidence
A call type adjustment set via `SetAutoCallTypeAdjustment` will only
take effect if any existing call type adjustment, automatic or
user-defined, is of a lower confidence level. This ensures that user
call type adjustments with full confidence will not be overridden by
a workflow.
Similar changes have been made to `SetAutoCallStackAdjustment`,
`SetAutoInlinedDuringAnalysis` and the overload of
`SetAutoCallRegisterStackAdjustment` that adjusts a single register
stack.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7354.
|
|
|
|
|
|
|
|
|
|
|
|
Improves the speed by moving chunks of functions into worker threads, because of how the functions and possible functions are gathered we have many locations to insert fast fails, which is also partially addressed by this commit (see `maximum_possible_functions`).
|
|
of all the functions
This was caused by the internal flatbuffer verifier reaching the max number of tables, this is fine and the solution is to split the large chunk into smaller ones, effectively creating more flatbuffer "views" of tables.
This is fine from a performance perspective because we already have optimized for many small chunks (e.g. we have a lookup table stored next to each chunk).
I left some comments for future improvements but this should be good now.
Also alongside this change we improved generating performance by 2x on some pathological binaries.
|
|
It will just end up freezing the UI for an unreasonable time, just open the generated report in a real web browser or text editor, QTextBrowser falls over and fixing it would be more effort than its worth.
|
|
given
Fixes the case where we are generating many smaller chunks for a given view and then unintentionally merging
them back together, throwing away all data.
|
|
It is important that we only retrieve the medium-level IL if the function has
any user-defined variables, otherwise, we will possibly be generating MLIL for no reason.
For the above reason, we do a filter on user-defined variables first.
|
|
We do not need to consult the lifted IL if we have already cached the function GUID in the function metadata
|
|
These calls set the rpaths used for release builds of the dylibs using a
macro that isn't available in the API repository. They are not necessary
when building the shared cache plug-in outside of the context of the
app.
|
|
Defining `_DEBUG` changes which MSVC runtime library needs to be linked
which breaks clients attempting to use the C++ API with `RelWithDebInfo`.
To fix this we define a new private `BN_ENABLE_LOG_TRACE` macro and use
that within log.cpp where it was previously using `_DEBUG`.
Fixes https://github.com/Vector35/binaryninja-api/issues/7288.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is functionally equivalent to the previous workflow_objc, with the
following changes:
1. It mutates the `core.function.metaAnalysis` workflow rather than
registering a new named workflow. The activities now all check for
the presence of the Objective-C metadata added by `ObjCProcessor` to
determine whether they should do work, rather than relying on
`MachoView` to override the function workflow when Objective-C
metadata is present. This fixes
https://github.com/Vector35/binaryninja-api/issues/6779.
2. The auto-inlining of `objc_msgSend` selector stub functions is
performed in a separate activity from the processing of
`objc_msgSend` call sites. The selector stub inlining activity is
configured so that it does not run in `DSCView` as the shared cache
needs different behavior for stub functions more generally that
`SharedCacheWorkflow` already provides.
3. The way that types like `id` and `SEL` are referenced is fixed so
that they show up as `id` rather than `objc_struct*`.
This also replaces the Objective-C portion of the shared cache's
workflow, and incorporates several bug fixes that had been applied to it
but not the standalone Objective-C workflow.
|
|
1. Some SSA-specific functions are now implemented on
`LowLevelILFunction<M, SSA>` rather than `Ref<LowLevelILFunction<M, SSA>>`.
2. A lifting helper for `LLIL_TAILCALL` is added to `LowLevelILFunction`.
3. `PossibleValueSet::ImportedAddressValue` now holds the value.
|
|
These are available on `LowLevelILFunction<M, SSA>`.
|
|
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`.
|
|
To avoid non-determinism and provide consistent behavior in all cases,
now only confidence, symbol type, and name are considered when
disambiguating multiple symbols at the same address.
The previously documented behavior was not what was implemented. While
recency was considered in some cases for disambiguating symbols at the
same address, respecting it consistetly results in non-deterministic
behavior when symbols are being added concurrently by multiple sources.
|
|
address are handled"
This reverts commit 6293afcb4e10997838f94c38430feba9742bea75.
|
