| Age | Commit message (Collapse) | Author |
|---|
|
Responsibility for selecting an architecture is moved out of
`UniversalTransform` and into a new `ContainerOpenRequest` class.
`UniversalTransform` still handles architecture selection in headless
operation (for now).
|
|
Finally closes #5463.
|
|
|
|
https://github.com/Vector35/binaryninja-api/issues/4052, fix https://github.com/Vector35/binaryninja-api/issues/5607
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/7989.
Also corrects an oversight from d92b3684 in handling of library ordinals
>= 128.
|
|
These lookup modes are negative values that are encoded in the library
ordinal, an unsigned field, of an import fixup entry. Incorrect sign
extension when converting these ordinals back to signed values led
to them being misinterpreted.
|
|
The `FileAccessorCache`'s LRU eviction could discard a file's mapped
data after slide info had already been applied to it. Future accesses to
the file produced a fresh mapping, but failed to reapply the slide info.
This could result in pointers not correctly being slid, such as in
https://github.com/Vector35/binaryninja-api/issues/7689.
The LRU cache existed to stay within OS file descriptor limits, since
the old `MappedFile` held its fd open for the lifetime of the mapping.
There's no real reason for it to hold the file descriptor open like
this. Closing it after `mmap` is sufficient to avoid the file descriptor
limits.
`MappedFileRegion` replaces the combination of `FileAccessorCache`,
`WeakFileAccessor`, and `MappedFileAccessor`. It closes the fd
immediately after mmap, so all files can stay mapped without consuming
descriptors, making the cache unnecessary.
`MappedFileRegion` is owned directly by the `CacheEntry` for its full
lifetime. Slide info is applied exactly once to each `MappedFileRegion`.
|
|
This builds on the existing support for opening kernel caches directly from IM4P payload files,
and allows opening macOS kernel caches directly from
`/System/Volumes/Preboot/<apfs-uuid>/boot/<boot-manifest-hash>/System/Library/Caches/com.apple.kernelcaches/kernelcache`.
|
|
This reverts commit bcc40473b3660005e83f51150bdc17ae177768dc.
|
|
This reverts commit 4573354f23da495099983dac4b665988cd837ff5.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
