| Age | Commit message (Collapse) | Author |
|---|
|
The processed Objective-C metadata is not saved to the .bdnb. It must be
recomputed when the view is loaded.
Fixes https://github.com/Vector35/binaryninja-api/issues/8030.
|
|
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 adds support for the `__objc_arrayobj`, `_objc_dictobj`,
`__objc_intobj`, `__objc_floatobj`, `__objc_doubleobj` and
`__objc_dateobj` sections that contain Objective-C constants. These are
emitted by Apple's versions of Clang for `const` literals, amongst other
things.
|
|
backed by a database
|
|
|
|
We will have 2 live references in the DeleteController function, this warning does not need to be shown.
|
|
file metadata destruction
Previously we would just let them continue to exist after view destruction, this is fine assuming we expect the user to be re-opening the same cache over and over, but
if a user wants to load a bunch of different caches they might want to evict the old file accessors so that COW pages are known to be evicted, along with other paged in memory.
|
|
- Make `SharedCache::m_entries` a simple std::vector we never lookup based off the entry ID
- Remove some old comments
- Rename some old variables so that they are accurate
- Fix compiler warnings
- Remove some unneeded copying
|
|
This improves symbol recovery drastically on newer shared caches
Related PR: https://github.com/Vector35/binaryninja-api/pull/6210
|
|
And also removed unneeded VMReader construction in ApplyRegion
|
|
This made the macho objective-c processor aware of images and was passed around everywhere, instead we have an overridable section getter that gives the control over the section retrieval to the derived processor.
In the case of shared cache this means we can store the image to be processed and then use the header to locate the relevant sections.
Fixes: https://github.com/Vector35/binaryninja-api/issues/6594
|
|
adding new images and regions
Within the user section creation we will assume that because a non-default section was added, we should mark all functions for reanalysis. From initial testing
this isn't an extreme slowdown, but with the addition of more images the number of queued up functions becomes much greater, even if those are unmarked immediately
and processing of those functions isn't slow it is unneeded and might lead to other non-obvious slowdowns.
To be clear, we do not need to queue up functions from already analyzed images to be analyzed again, there is no benefit, our workflow handles cross images calls already,
so those places will already be queued up, and if they aren't, that is the issue to solve, not this.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6561
- Also tightens the SharedCache class to move only, to prevent accidental copies.
- Also removes some extra copies in FFI when should pass by ref
- Also adds `get_symbol_with_name` to python API
The current named symbol map is populated in a worker thread spawned in the view init. This is because populating the map can take about 1 second.
If we are fine with another 1 second added to the view init time then we can add it serially but I don't think this way is _that_ bad, no analysis consults
this, however a user might add a workflow that would be racing this. So we need to add a mutex.
|
|
|
|
Apparently the view metadata is not available until after view init
|
|
|
|
|
|
In absence of a better name, this commit refactors the shared cache code.
|
