Repository navigation
Resolve iOS debug symbol 100x faster #3422
ChiChou
started this conversation in
Show and tell
Replies: 1 comment
|
Damn I just realized that the address from this approach is without slides. you need to add this slide to the pointer function getSlide(module: string) {
const {
_dyld_image_count,
_dyld_get_image_header,
_dyld_get_image_vmaddr_slide,
} = getDyldApi();
const moduleInfo = Process.getModuleByName(module);
for (let i = 0; i < _dyld_image_count(); i++) {
// const name = _dyld_get_image_name(i).readUtf8String()!;
const header = _dyld_get_image_header(i);
if (moduleInfo.base.equals(header)) {
const slide = _dyld_get_image_vmaddr_slide(i);
return slide;
}
}
throw new Error(`module ${module} not found in current process`);
} |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
On iOS
DebugSymbol.getFunctionByName()is quite slow upon first call (afterwards it's much faster), and we can not specify module name when there are symbols with same name across different frameworks.For example,
_SSL_CTX_set_keylog_callbackcan be found in both WebCore and libboringssl.dylib.Module.enumerateSymbolsis designed for debug symbols enumeration. It parses mach_header and nlist structure to enumerate symbols. However if the module is in dyld_shared_cache it does not work.Before iOS 15, there are two fields in dsc header:
The symbols are aggregated in a location that does not relate to mach-o header.
From iOS 15, those information are moved to a seperated
.symbolscache which is not mapped by default.libdyld provides some private api for debug purposes:
https://github.com/apple-oss-distributions/dyld/blob/fba6732ffad1c798f31b2129eee4e073e6ae07dc/include/mach-o/dyld_introspection.h
They will do the work to parse dyld_shared_cache and map .symbols cache.
I don't know if it is a good idea to introduce those functions to frida-gum
So I converted them to frida js as a utility function
Here is the performance difference
Note that the results are different, because they resolve to two different functions that have same name respectively.
All reactions