| Age | Commit message (Collapse) | Author |
|---|
|
This occurred because prior to the change made in build `7484` we short-circuited when the pointer pointed to a read only segment, now that we consult the section the sections semantics were incorrect and failed, this fixes the dyld data sections to have correct semantics.
|
|
|
|
named workflow
Activities are registered with a `viewType` predicate to ensure they
only run in shared cache views.
Adding activities to `core.function.metaAnalysis` lets activities
registered by plug-ins run in the shared cache without the plug-ins
having to be aware of the shared cache.
Work towards #6779.
|
|
Use mappingOffset as an upper bound for the header size, and avoid
reading any header fields from beyond that offset.
Co-authored-by: Mason Reed <mason@vector35.com>
|
|
underlying VirtualMemory
|
|
8267ab475cb2ac82fd3724c009f21e8e30143f6b introduced a logic error in
VirtualMemoryReader::ReadPointer that caused VirtualMemoryReader to
attempt to read pointers from the wrong address, breaking parsing of
Objective-C metadata.
|
|
Still need to fix branch island images not being picked up
|
|
Fixed branch island regions being skipped
|
|
|
|
We will have 2 live references in the DeleteController function, this warning does not need to be shown.
|
|
|
|
of the header
We did not truncate the buffer length when reading the header using the mappingOffset size, resulting in a buffer overflow.
|
|
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.
|
|
Following the conversation in https://github.com/Vector35/binaryninja-api/issues/6631 we are going to make the edited alerts warnings and then also fix the warning showing on certain shared caches even when all entries are present.
|
|
However the primary file will need to be selected each time you open, for that to be resolved we need to use project file UUID's or the cache entry UUID's themselves to traverse all project files
|
|
This commit addresses some of the issues regarding the retrieval of cache entries during view init, we now will try and store information in the database
about the given shared cache entries so that we can better alert the user to possible issues during the loading of saved shared cache databases. We also simplified
the logic so that the flow for retrieving the primary file cache is easier and users should be prompted when necessary to select the primary cache file if we cannot.
More errors will also be shown to provide the users with more information about the shared cache and what issues they might have. For example we will now try and warn the users
when they are opening a shared cache with less entries than what the shared cache reports having. We will also warn the users when opening a database if a previous secondary cache
file is no longer available.
In the future we can also utilize the shared cache UUID's for individual files to do a more aggressive search across directories in a project. This will make the file name lookup stuff
potentially unnecessary, at least when opening a database with all file UUID's stored.
|
|
The atlas files include section name info on images, its not helpful for us and skipping it altogether will remove an unneeded error related to parsing this other format
|
|
- 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
|
|
Prior to this we would not have meaningful errors shown to the user when we fail to construct a CacheEntry from a file.
Apart of trying to make the opening of shared caches clearer.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6629
|
|
Allows us to display the user friendly name of the cache entry in the triage view
|
|
This improves symbol recovery drastically on newer shared caches
Related PR: https://github.com/Vector35/binaryninja-api/pull/6210
|
|
Implicit std::filesystem::path conversion oops
|
|
We already had separated this part out into the `CacheProcessor` but its more like a builder than anything, so this refactors that out into a `SharedCacheBuilder`.
- Separate out the `CacheProcessor` and simplify its implementation
- Move more implementation specific stuff to the shared cache view
- Prepare for more validation of the shared cache to detect irregular or incomplete shared cache information
- Deduplicate a lot of file vs. project file lookup stuff
- Stop copying all images when getting the number of images to log
- Allow user to select another directory to scan for shared cache files, might make this a warning instead to prevent users from relying on this behavior
We will likely follow this commit up soon with better open behavior, maybe open with options can specify a list of cache entry files? Shouldn't be too much effort aside from making the UI modal for that.
|
|
And also removed unneeded VMReader construction in ApplyRegion
|
|
|
|
Fixes the case of stub functions being applied with mangled names.
|
|
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
|
|
This removes some section name collisions where a section name is in two separate image segments.
See https://github.com/Vector35/binaryninja-api/pull/6454 for more information.
Co-Authored-By: WeiN76LQh <WeiN76LQh@github.com>
|
|
Fixes: https://github.com/Vector35/binaryninja-api/issues/6571
|
|
This fixes a case where the remote file is downloaded and the shared cache view is selected, we _only_ work for file backed views, as our shared cache specific file accessors work on those. So this is not a loss in functionality.
In the future if we wanted to load shared caches without touching disk (yikes) than we would need to remove this restriction, or provide a way in the API for user to process their own cache entries (after view init).
|
|
This gives the user the ability to take a database with no original file path continue processing entries with the user supplied base file.
This also will set the original file path for future loads, we might want to make that optional. And the behavior with remote projects for that might be undesired.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6582
More considerations might need to be made for databases saved without the original file path. Likely solved through some shared cache specific metadata.
|
|
It is modified on a worker thread so if a user tries to call `GetSymbolWithName` after view init but before the processing on the worker thread finishes, there would have been issues!
|
|
Also swapped out CacheEntry::m_images to a vector as its never actually used as a lookup
|
|
slide info
This improves performance by ~10x with the only real issue being a copy of the cache entry existing for each weak ref.
Also fixes
- Some old TODO's that are no longer relevant
- Some function signatures not being const
- FileAccessorCache not evicting enough accessors to fit under an adjusted cache size
- Added a warning if we are over the global cache size in view initialization
- Logger name not having a `.` in `SlideInfoProcessor::SlideInfoProcessor`
- Re-added the accessor dirty check before applying slide info to fix https://github.com/Vector35/binaryninja-api/issues/6570
|
|
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.
|
|
|
|
The logic for determining the class name of a category did not correctly
handle classes defined in other images in the shared cache. There were
two problems:
1. If the class is defined in another image that is already loaded,
`ObjCProcessor` has already renamed the symbol from `_OBJC_CLASS_$_`
to `cls_`. Both forms of symbol name are now handled.
2. If the class is defined in an image that is not yet loaded, no symbol
name is available. The category's class is now looked up in the
shared cache symbol table, and the symbol's name is parsed as if it
were an import symbol.
This fixes almost all cases of "Failed to determine base classname for
category" that I have come across.
Mason Reed: Fixed up to make objective-c processor always consult GetSymbol
|
|
|
|
address for the file offset
This would result in the virtual memory trying to access an unmapped region, failing to apply slide info
|
|
Just use a vector. In the future we can turn off the write log if the system has given us ample descriptors, and we can also add a page based cache.
|
|
|
|
|
|
|
|
Apparently the view metadata is not available until after view init
|
|
|
|
Stopped some stub calls resolving the target
|
|
removing it
|
