Я придумываю этот грубый обходной путь, но в некоторой степени выполняю работу.
Я сильно помог мне с реверс-инжинирингом двоичного файла специфичного для симулятора WebKit (для этого достаточно демо-приложения Hopper), найденного (начиная с XCode 10.1) здесь:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks
чтобы иметь представление о том, как организован бинарный файл и что находится внутри (в каком порядке).
Также был полезен исходный код WebKit здесь
Так что, по сути, обходной путь сводится к настройке некоторых точек останова на некоторых существующих публичных или частных методах objc. Во время работы вашего приложения используйте, например:
br s -F "-[WKWebView _isPlayingAudio]"
Это даст вам адрес этого метода в WebKit:
Breakpoint 11: where = WebKit`-[WKWebView(WKPrivate) _isPlayingAudio], address = 0x00000001e7ed3f3c
Теперь прибывает грубый трюк:
di -s 0x00000001e7ed3f3c -c 1000000
Здесь используется очень агрессивная настройка -c, чтобы глубоко проникнуть в память WebKit (это займет некоторое время!). Это даст вам хорошую разборку, включая символы C ++, например ::1010 *
WebKit`WebKit::WebPageProxy::activityStateDidChange:
-> 0x1e7f5dbe4 <+0>: stp x20, x19, [sp, #-0x20]!
Получите вывод отладчика в ваш любимый текстовый редактор для поиска вашего символа. Если вам повезет, вы знаете адрес сейчас. Если это так, вы можете использовать:
di s -a 0x1e7f5dbe4
На самом деле установить точку останова.
Вступление в работу также может ускорить процесс, так как разборка полезно прокомментирована такими вещами, как:
0x1e7f5dc78 <+148>: b 0x1e23543ac ; WebCore::RunLoopObserver::schedule(__CFRunLoop*, unsigned long)
0x1e7f5dc88 <+164>: b 0x1e7f5dc8c ; WebKit::WebPageProxy::dispatchActivityStateChange()