| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
address for the file offset
This would result in the virtual memory trying to access an unmapped region, failing to apply slide info
|
|
expression operation
|
|
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
|
|
|
|
rows
Before this we would load all images between the end and beginning because the model is does not have a filter proxy, but just hides the rows instead, we should move to a proxy
|
|
Stopped some stub calls resolving the target
|
|
removing it
|
|
|
|
oops!
|
|
|
|
Still have the issue with newer IOS stubs not having their direct function address taken
|
|
Any update to the model should only happen on the UI thread now. This also fixes the other issue here: https://github.com/Vector35/binaryninja-api/issues/6300
|
|
See: https://github.com/Vector35/binaryninja-api/pull/6540/files#r2020882071
|
|
|
|
|
|
In absence of a better name, this commit refactors the shared cache code.
|
|
This makes it so that we persist the symbols within the regular symbol list in storage
|
|
gracefully now
|
|
|
|
Slide info is parsed and applied on the main thread, below the
`SharedCache` constructor, when a shared cache is opened. Time spent
applying the slide is time that the main thread is blocked.
These changes eliminate some unnecessary overhead so what work remains
is dominated by kernel work (paging in data, copying pages when the
first modification is made).
The changes are:
1. Read slide pointers via `ReadULong` rather than the variable-length
`Read` method. The compiler isn't able to eliminate the call to
`memcpy` in the variable-length `Read` function, and the function
call overhead is noticeable given the small size of the read and
number of times it is called.
2. Remove the file member from `MappingInfo`. Slide info is applied for
a single file at a time so there's no reason to track the file it
belongs to. This removes unnecesssary reference counting on the
`std::shared_ptr` that holds the `MMappedFileAccessor`.
|
|
Still need to decide on how we want handle this, because we need multiple files we probably just want to prompt the user for a directory?
|
|
This warning will happen anytime you load an image with already processed regions.
|
|
Both the Macho and DSC views need to process Objective-C but have separate processor classes. It would appear that the DSC version was largely a copy and paste of the Macho view one, with some modifications. The majority of code overlaps between the 2 so it doesn't make sense to maintain 2 and copy and paste improvements/fixes between them.
This commit fixes that by creating a base Objective-C processor that contains the shared code. View specific code is implemented in the respective subclasses for the views. Although there is very little view specific code for each.
|
