| Age | Commit message (Collapse) | Author |
|---|
|
When not in RTM, the xabort intrinsic instruction is a NOP. When in RTM,
the only way to resolve the branch destination is to resolve the
fallback address computed by a seperate xbegin instruction
|
|
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
|
|
|
|
(skip-ci)
|
|
Return None instead of raising an ILException in Python Function.llil,
mlil, etc to allow these properties to play nice with map and filter
|
|
|
|
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.
|
|
|
|
|
|
|
|
Slight reimplementation of PR #6517 since the PR was from before our
refactor.
|
|
Closes #6563.
|
|
More informative than a warning
|
|
- Fix the inconsistent column sizing
- Stop trying to show cross reference at 0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6550
|
|
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
|
|
|
|
|
|
Only override the default platform based on the entry point architecture
in cases where the user didn't explicitly set loader.platform
|
|
Also addresses some lints that I thought were possibly worth it.
|
|
|
|
|
|
|
|
|
