| Age | Commit message (Collapse) | Author |
|---|
|
|
|
container file entries.
|
|
|
|
|
|
|
|
TypeBuilder.handle creates an immutable_type gets the handle and then deletes the object to which the handle belonged to.
This was fundamentally a UAF. immutable_copy is an error prone api as its very easy to misuse. We should consider a re-architecture of this API. `TypeBuilder.immutable_copy().<anything>` or `Type.mutable_copy().<anything>` should be considered sketchy and immutable_copy().handle is just a straight up UAF. Prior to this commit the following would cause a crash:
current_data_variable.type = PointerBuilder.create(FunctionType.create())
|
|
documentation.
|
|
This change allows architecture plugins to override the LiftFunction
callback to iterate a function's basic block list and lift entire
functions at once. This is required for architectures such as TMS320
C6x, which have non-traditional "delay slots" in that branches, loads,
and other instructions take multiple cycles to complete, and branch
instructions can reside within the delay slots of other branches.
|
|
copy_expr_to
|
|
|
|
This fixes the incorrect type hint and the other instance of the
function. It also looks like type parsing could have the same issue, so
I've updated that as well.
|
|
associated coreversion usage
|
|
|
|
|
|
Introduces a Pythonic get_metadata() method to BinaryView, Function, Project,
TypeArchive, and TypeLibrary classes. This method behaves like dict.get(),
returning a default value (None by default) when a key doesn't exist, instead
of raising a KeyError.
Additionally, updates query_metadata() in TypeArchive and TypeLibrary to raise
KeyError when a key is not found, making them consistent with BinaryView,
Function, and Project. Previously these two classes returned None on missing
keys. This breaking change is documented in the method docstrings.
This provides a more consistent and Pythonic API for querying metadata across
all metadata-supporting classes.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
|
This introduces two new dataclasses SegmentInfo and SectionInfo which hold information about their respective objects. These are used for specifying information to a BinaryView while class Segment and Section are still the objects used after registration. Additionally I've created two helper functions in Segment/Section which return the respective Info structure which could be useful if you wanted to modify existing Segments/Sections
Currently these two APIs are only used by the add_segments/add_sections APIs but maybe more useful in the future.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Made possible by the new attributes in binja's type system.
|
|
Literally only affects InvalidILViewType
|
|
Fixes Vector35/binaryninja-api#7782. Seems like these were missed in the refactor in de0b872e
|
|
This allows a few widely-used enums to be shrunk from 4 bytes to 1 byte,
improving packing when they're used as struct members.
To remain compatible with C, we follow CoreFoundation's approach and use
a macro when defining the enum:
```
#if defined(__cplusplus) || __has_extension(c_fixed_enum)
#define BN_ENUM(type, name) enum name : type
#else
#define BN_ENUM(type, name) typedef type name; enum
#endif
BN_ENUM(uint8_t, SomeEnum)
{
...
}
```
In C++ and C23 this will expand to an enum with a fixed underlying type.
In older C language versions, this will result in the enum type being a
typedef of the underlying type, with an unnamed enum providing the enum
values.
Minor changes were needed within the Python bindings to update places
that made assumptions about the underlying type of the enums.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Seems we forgot to expose this one
|
|
|
|
|
|
|
|
|
|
consistent, lock-free AnalysisContext queries.
|
|
Fixes: https://github.com/Vector35/binaryninja-api/issues/7588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
