| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was done for kernel cache in
https://github.com/Vector35/binaryninja-api/pull/7519, and is now being
extended to Mach-O images that appear to be XNU kernels (that is, they
contain `__KLD` segments). This improves the experience when opening
kernels from the macOS Kernel Debug Kit.
|
|
These binaries can be ELF64 or ELF32 format, if the user specifies
linux-x32 or linux-ilp32 platforms the BinaryView's default address size
needs to be 4, even if it's an ELF64
|
|
|
|
|
|
Closes #7851.
|
|
|
|
1. A section's `flags` are masked with `SECTION_TYPE` before being
compared. This prevents misclassifying a section when its low bits
are shared with other section types.
2. `__mod_init_func` and `__init_offsets` are identified by section type
flags, rather than by name. There's no documented reason why these
were being matched by name.
3. A fallback is added to detect `__got` sections by name. This is
necessary as some kext bundles that have their `__got` sections as
`S_REGULAR` rather than `S_NON_LAZY_SYMBOL_POINTERS`. This fixes
https://github.com/Vector35/binaryninja-api/issues/7891.
Thanks to @WHW0x455 for these fixes.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7781.
|
|
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.
|
|
EndBulkAddSegments
This defers rebuilding of the section map until after all sections for
an image have been added, rather than having the section map be rebuilt
after adding each section.
|
|
This defers rebuilding of the section map until after all sections for
an image have been added, rather than having the section map be rebuilt
after adding each section.
|
|
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.
|
|
unbacked regions
Fixes https://github.com/Vector35/binaryninja-api/issues/7724
|
|
This ensures they do not overlap with any images that may later be loaded from the shared cache.
|
|
This ensures they do not overlap with any images that may later be loaded from the kernel cache.
Fixes https://github.com/Vector35/binaryninja-api/issues/7634.
|
|
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7615.
The dependency loading for kernel cache images was copied from the
shared cache code, and looks for `LC_LOAD_DYLIB` load commands to
determine the direct dependencies of an image. Images in kernel caches
don't use `LC_LOAD_DYLIB` load commands so no dependencies were ever
loaded. It could, however, result in a crash.
|
|
correspond to
|
|
The down and enter keys now preserve an existing selection in the
associated list or table views, rather than unconditionally selecting or
activating the first item.
|
|
|
|
XNU maps kernel cache segments in with different permissions than the
load commands indicate. For instance, `__DATA_CONST` is initially mapped
as read-write before later being re-mapped as read-only. Treating it as
read-only results in analysis falsely assuming that global variables
cannot change.
To work around this we maintain a mapping from segment name to initial
permissions (i.e., most lax permissions) and favor them over permissions
derived from the segment load command. Section semantics are also
derived from the segment's permissions when the segment is present in
the mapping.
The mapping is based on the initial permissions established by
`arm_vm_prot_init` within the XNU source.
|
|
Clang, MSVC and GCC all have different opinions about what's permissible with initialization from a braced initializer list.
|
|
|
|
The parsing of fix-up chains is moved out of `MachoView` and into its
own class. It deals purely in terms of offsets into the Mach-O slice.
`MachoView` translates those offsets to mapped addresses when needed.
This is primarily aimed at fixing incorrect handling of pointer formats
that use offsets where in some cases the relocations would be applied at
incorrect addresses due to confusion between file offsets, Mach-O slice
offsets, and VM offsets.
It incidentally fixes addends from bind operations not being respected.
These show up most frequently in C++ RTTI information.
|
|
infinite loop)
|
|
|
|
|
|
See https://github.com/Vector35/binaryninja-api/issues/7247#issuecomment-3392192797 for details.
|
|
|
|
|
|
Extra noise in the CMake configure step, much of the value from these has been removed after the refactor(s), e.g. metadata version is no longer used
|
|
container transforms.
|
|
the payload.
|
|
`LC_FUNCTION_STARTS` includes both functions and jump tables. We want to
avoid calling `AddFunctionForAnalysis` on jump tables since it can
result in a function being created at the jump table's location with a
bogus body.
We already skip adding functions for entries in `LC_FUNCTION_STARTS` if
the lifting of their first few bytes end up including `LLIL_UNDEF`.
However, arm64 intentionally lifts `udf` instructions (i.e., opcodes in
the Permanently Undefined range) to `LLIL_TRAP` in order to preserve the
immediate portion of the instruction.
To address this, `MachoView::IsValidFunctionStart` now returns false if
the first lifted instruction is `LLIL_TRAP` in addition to when the
lifting contains `LLIL_UNDEF`.
|
|
|
|
|
