| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
implementations
|
|
|
|
|
|
|
|
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>`.
|
|
|
|
|
|
Calls to `Workflow::Instance` that were looking up a built-in workflow
name are updated to use `Workflow::Get`. Others use `Workflow::GetOrCreate`.
|
|
C++ plug-ins now consistently use the `plugin_rpath` or
`ui_plugin_rpath` macros to ensure they have `SKIP_BUILD_RPATH` set when
building on Mac (i.e., no `LC_RPATH` is added).
Rust plug-ins have their build.rs updated to only specify `-Wl,-rpath`
when building for Linux. It is not needed on macOS. On macOS we instead
explicitly specify an `@rpath`-relative install name. This doesn't
change any behavior, but avoids leaving an absolute path as the
library's install name and is consistent with CMake's behavior for C++
plug-ins.
|
|
`Workflow::new` is replaced by `Workflow::build` that returns a
`Builder` type that supports the operations that mutate a workflow, such
as registering activities.
`Workflow::instance` is replaced by `Workflow::get` to make clear that
it is intended to look up an existing workflow.
`Workflow::cloned` is introduced to wrap the common pattern of
retrieving an existing workflow and cloning it with the same name in
order to modify it.
`Builder::activity_before` / `Builder::activity_after` are introduced to
wrap the common pattern of registering an activity then inserting it
before or after a given activity.
|
|
This makes it possible to see what structure the configuration takes and
eliminates errors due to typos in JSON string literals.
|
|
The names can simply be omitted since they are only mentioned in the
declaration of a function pointer.
|
|
The `$<TARGET_FILE:binaryninjaapi>` syntax does not do what is intended
for Unix Makefiles.
In practice there's no reason for this custom command to depend on the
`binaryninjaapi` target. The Rust API uses core's C APIs directly rather
than via the C++ API, and it already depends on binaryninjacore.h via
`RUST_API_SOURCES`. Since it's running `cargo check` and not doing a
full compilation this header-only dependency is sufficient.
|
|
|
|
|
|
message
|
|
|
|
path arguments
|
|
|
|
|
|
|
|
"progress" like callbacks
Still need to add more, consider changing the boolean to an enum that describes it better, so we do not need to copy paste docs around.
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7139
|
|
- Fix cmake clean not cleaning target docs
- Fix not prioritizing enterprise remote in collab tests
- Some misc formatting
- Fix incorrect assert in binary loading
|
|
|
|
|
|
|
|
|
|
The python API was kept the same seeing as we are close to the release, will likely start deprecating some of those API's soon.
|
|
Need this for WARP, see next commit
|
|
To allow for creating reports outside the context of a view
|
|
|
|
Discovered when poking at variable values in WARP
|
|
|
|
appended for a given instruction
|
|
The clippy complaint was a real issue: the doc comment intended for
the commented-out `unresolved_indirect_branches` was being interpreted as
the start of the doc comment for the following function.
|
|
|
|
low level IL expressions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
