| Age | Commit message (Collapse) | Author |
|---|
|
Fixed branch island regions being skipped
|
|
|
|
They show up in some macOS system executables.
|
|
added in the background through the UI
We set some model data after the fact that didn't exist because the qt object was destructed on tab close.
|
|
We will have 2 live references in the DeleteController function, this warning does not need to be shown.
|
|
Simple change that means an image's dependencies can be loaded via the DSC triage view whether the primary image has already been loaded or not. Sometimes I've already loaded an image and then later on decide I want to load its dependencies. Currently there is no easy way to do that in the UI.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Required adding an API to determine if an image is loaded.
|
|
|
|
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.
|
|
1. Crash on kernel cache image load
2. Duplicate Load Image buttons in kernel cache view
3. Improper selection behavior in both views
4. Address column should no longer resize to be smaller than contents
5. Symbol tables should now be properly sortable
|
|
|
|
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.
|
|
One day, these will share more code, but today is not quite that day.
|
|
This avoids the 3 errors on view initialization for all supported kernel
caches that aren't "real".
|
|
This reverts commit 9169a13c818fc7f3b09246360c31e200b01bda23.
|
|
|
|
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
|
|
`fixObjCCallTypes` is updated to handle tail calls as well as regular
calls.
Additionally, if the selector address is not valid it now looks for the
`sel_` symbols that `DSCObjCProcessor::ReadMethodList` adds for
selectors whose names reside in regions that are not yet mapped. This
allows call type overrides to be applied even when a selector's name is
defined in a different image.
|
|
These are treated the same as `objc_msgSend` with the exception of their
first argument being an `objc_super*` rather than `id`.
|
|
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 #6586, but for this plugin as well.
|
|
|
|
Check for the core plugin setting and, if it's disabled, look in the user directory
|
|
|
|
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.
|
