| Age | Commit message (Collapse) | Author |
|
Container Browser
Add the ui.files.universal.dedicatedPicker setting, allowing users to choose
between the dedicated architecture picker dialog and the standard container
browser for opening Universal (fat) Mach-O binaries. Previously the dedicated
picker was always used with no way to opt out.
Implementing this required restructuring how Universal binaries are handled
during file open. The previous approach intercepted Universal binaries during
container processing, bypassing the container browser's normal pipeline with
dedicated routing logic. This tightly coupled Universal-specific behavior into
the container system, prevented the container browser from handling Universal
binaries natively, and introduced several bugs around exclusion settings,
nested containers, and multi-child container hierarchies.
Bug fixes:
- The previous implementation always intercepted Universal binaries during
container processing with its own routing logic, bypassing the container
browser entirely. There was no way for the container browser to handle
Universal binaries natively, even when that was the desired behavior.
- Universal binaries inside multi-child containers were not detected. The
previous implementation only traversed single-child paths in the container
hierarchy, silently ignoring Universal binaries that appeared as siblings
among multiple children.
- Nested containers (e.g., archives) inside Universal slices were not
handled. The previous implementation intercepted Universal binaries at the
transform routing level before the container browser could perform
recursive delayering. When the dedicated picker is disabled, the container
browser now processes the full hierarchy including Universal slices and any
containers within them.
- Reverted incorrect IsInteractive to IsUIEnabled change in
UniversalTransform. The previous change conflated headless mode with
non-interactive processing. The UI can be enabled while still performing a
non-interactive auto-open (e.g., container browser auto-resolving with a
preferred architecture). The IsInteractive() flag captures the actual
intent and enables the transform to produce only the preferred
architecture child for non-interactive sessions, avoiding unnecessary
BinaryView construction for all slices.
|
|
Structure{,Builder}::{GetMemberByName,GetMemberByOffset}
Failing to check the return value is almost always a bug.
|
|
|
|
|
|
|
|
The iterators now store an offset into the operand storage, rather than
a pointer. Deferencing the iterator retrieves the value at that offset
from the IL function.
This issue existed prior to the operand list storage refactor, but
became easier to hit after that change. The separate operand list vector
is smaller and thus more likely to reallocate when a new instruction is
appended.
|
|
|
|
|
|
|
|
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).
|
|
Rather than using chains of `UNDEF` instructions, the contents of these
lists are in a vector alongside the instructions. The instruction itself
stores the entry count and offset into this second vector at which the
associated items can be found.
This improves analysis performance by around 2% and decreases memory
usage by around 5%.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the UI.
|
|
|
|
|
|
Finally closes #5463.
|
|
|
|
On Apple platforms these wrap `os_unfair_lock`. On other platforms
they're aliases for the std equivalents.
|
|
context menu.
|
|
https://github.com/Vector35/binaryninja-api/issues/4052, fix https://github.com/Vector35/binaryninja-api/issues/5607
|
|
|
|
|
|
|
|
|
|
The addends were correctly stored in the relocation info and displayed
as offsets in linear view, but the relocation handlers never applied
them. Reading from an address containing such a relocation would give an
incorrect value.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wrong time
|
|
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`.
|
|
Co-authored-by: Mason Reed <mason@vector35.com>
|
|
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.
|