| Age | Commit message (Collapse) | Author |
|---|
|
- Removed last use of user object creation in objective-c
- Fixed function type info being omitted from certain images loaded automatically
- Add TODO about undo action in view init. This is not critical, just a non-actionable warning because of a design flaw
I will restate this again for anyone in the future, until the undo action system is thread-safe avoid calling it from any thread other than the main thread, it is very easy to deadlock or cause other issues. That goes for basically all user analysis object creation.
|
|
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.
|
|
This disables the filter for already added images, there is another check when we go to apply so that it fails early but the real issue is the fact this happened at all.
Within the Objective-C processor there is a call to `BeginUndoActions` which calls `ExecuteOnMainThreadAndWait`, while the objective-c processor is holding the lock to the controller.
To fix this we really need to make the undo action system not call `ExecuteOnMainThreadAndWait` which is deadlock city, to do that really the only solution is to make the `UndoBuffer` thread-safe and remove the calls to execute undo related stuff on the main thread, this will make it so that when a call to `BeginUndoActions` there is no requirement to wait on pending undo actions as they are all submitted immediately.
|
|
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
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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!
|
