| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Allow users to easily create, diff, dump and validate type libraries
Supports the following formats:
- C header files (via core type parsers)
- Binary files (collects exported and imported functions)
- WinMD files (via `windows-metadata` crate)
- Existing type library files (for easy fixups)
- Apiset files (to resolve through forwarded windows dlls)
Can be invoked as a regular plugin via UI commands or via CLI.
Processing of type libraries inherently requires external linking, processing will automatically merge and deduplicate colliding type libraries so prefer to use inside a project or a directory and process all information (for a given platform) at once, rather than smaller invocations.
|
|
|
|
- Rename and retype `FileMetadata::filename` and make the assignment required to happen at time of construction.
- Add `FileMetadata::display_name` which is only to be used for presentation purposes.
- Add `FileMetadata::virtual_path` for containers.
- Rename `FileMetadata::modified` to `FileMetadata::is_modified` to be more consistent across codebase.
- Add some missing documentation.
- Add `BinaryView::from_metadata` with accompanying documentation.
|
|
|
|
|
|
|
|
|
|
|
|
inlining during analysis
Previously the address of the instruction in the function being inlined
was used as the new instruction's address when copying it during
inlining. Now there is an additional option: use the address of the
call instruction that is being replaced as the new instruction's
address.
This new mode is useful when inlining thunks or stub functions, but care
must be taken if using it beyond that.
The benefit is that it ensures that when a function contains multiple
calls to the same stub function, each inlined copy ends up with distinct
addresses. This ensures that call type adjustments and other overrides
that are stored on the function and keyed by address can be applied
independently to each callsite that was inlined.
The trade-off is that if the function being inlined contains non-trivial
logic, all of the inlined instructions sharing an address will limit
what type of adjustments can be applied to them.
The Objective-C and shared cache workflows are updated to take advantage
of this new mode when they enable inlining of stub functions. This will
make it possible for multiple calls to the same runtime function within
a single function to have separate call type adjustments applied in the
future.
|
|
- Allow extern functions to show up in a MSVC vtable
- Fix https://github.com/Vector35/binaryninja-api/issues/7871
- Share code between itanium and msvc vft analysis, it is the same logic basically
|
|
|
|
|
|
view callbacks
|
|
- Added more documentation
- Replaced global named logger for plugins, fixing the issue when the CU has multiple (e.g. statically linked demo)
- Simplified some misc code
This is a breaking change, but I believe there is no better time to make it, we cannot continue to use the `log` crate, it is too limited for our needs.
|
|
DW_AT_location variants for a DW_TAG_variable
|
|
|
|
|
|
Apart of fixes for https://github.com/Vector35/binaryninja-api/issues/7827
This also makes vtable type names refer to base class vtable type name, this was the original behavior, but it should be revisited later.
|
|
|
|
|
|
|
|
Fixes some possible nondeterminism due to parallelized matching
|
|
|
|
Reduces the size of constraints, reducing the size of chunks.
|
|
function symbol is not warranted
|
|
Avoids having to coalesce function objects from multiple sources when enumerating for matched functions.
|
|
Would result in binaryninjacore not being loaded:
```
dyld[19068]: Library not loaded: @rpath/libbinaryninjacore.1.dylib
```
Simply forgot to add build.rs to direct cargo at where to find the lib.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7770.
|
|
To keep backwards compatibility for commonly referenced code we re-export them within the architecture module.
Also does some light refactoring of some newly added APIs to keep them more consistent with other parts of the codebase.
|
|
|
|
|
|
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.
|
|
We already do this for a number of plugins / crates, this commit goes over the rest to make sure that they all do this.
We keep cleaning binaryninjacore-sys as we want to generate the core bindings immediately on changes to binaryninjacore.h
|
|
These are introduced after changing to Rust 1.91.1
|
|
|
|
shared cache
Dataflow is now used to determine call targets when detecting calls to
reference counting runtime functions. The previous approach of matching
on specific instructions missed some patterns that are common in the
shared cache.
|
|
explicit type
Helps with windows functions where we had previously defined the signature
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7705
RTTI processing with malformed sections can still cause prolonged analysis, in extreme cases like the binary in the issue needing the user to stop the RTTI processing once it gets to the Itanium RTTI pass. More work to be done, I would like to solve this with some section heuristics using the sections/segments entropy.
|
|
the previous pass
|
|
|
|
Should have the same behavior as doing it on a directory
|
|
Can be triggered by trying to run the processor on a file with no functions.
Found this while doing misc performance testing on windows.
|
|
|
|
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7646
Also cleaned up and added some more context to the `NamedTypeReference::target` function.
|
|
|