Ответы:
Я знаю 3 способа. Это всего лишь предположения, так как я не работаю в группе обзора Apple.
otool -L
В нем будут перечислены все библиотеки, с которыми связано приложение. То, что вам явно не следует использовать, например, IOKit и WebKit, могут быть обнаружены этим.
nm -u
Это список всех связанных символов. Это может обнаружить
UITouch._phase
(который может быть причиной отказа от приложений на базе Three20 в последние несколько месяцев).strings
Селекторы Objective-C хранятся в специальной области двоичного файла, поэтому Apple может извлечь оттуда контент и проверить, не использовали ли вы какие-либо недокументированные методы Objective-C, например -[UIDevice setOrientation:]
.
Поскольку селекторы не зависят от класса, о котором вы сообщаете, даже если ваш собственный класс определяет -setOrientation:
не относящийся к UIDevice, существует вероятность того, что он будет отклонен.
Вы можете использовать APIKit Эрики Садун для обнаружения потенциального отказа из-за (ложных срабатываний) частных API.
(Если вы действительно действительно хотите обойти эти проверки, вы можете использовать функции времени выполнения, такие как
-valueForKey:
; object_getInstanceVariable, object_getIvar и т. д.чтобы получить эти частные библиотеки, классы, методы и ivars. )
Вы можете перечислить селекторы в программе Mach-O, используя следующую однострочную строку в Терминале:
otool -s __TEXT __objc_methname "$1" |expand -8 | cut -c17- | sed -n '3,$p' | perl -n -e 'print join("\n",split(/\x00/,scalar reverse (reverse unpack("(a4)*",pack("(H8)*",split(/\s/,$_))))))'
Допустим, вы хотите использовать частный API; цель C позволяет вам построить любой SEL из строки:
SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
[UIDevice performSelector:my_sel ...];
Как робот или сканирование библиотеки могли это обнаружить? Им придется уловить это с помощью какого-нибудь инструмента, который отслеживает частный доступ во время выполнения. Даже если они построили такой инструмент времени выполнения, его трудно поймать, потому что этот вызов может быть скрыт на каком-то редко используемом пути.
Я предполагаю, что они смотрят на все символы, которые пытается импортировать ваш двоичный файл (информация, без сомнения, легко доступна для них в соответствующей таблице символов), и предупреждают вас, если какой-либо из этих символов находится в их «частном списке API». На самом деле, довольно легко автоматизировать.
Исполняемый файл - это не совсем черный ящик. Если вы обратитесь в библиотеку, ее легко найти. Вот почему я оплакиваю потерю языков ассемблера в современном образовании CS. =] Такие инструменты, как ldd, расскажут, на что вы ссылались, хотя я не помню, какое воплощение ldd вошло в комплект разработчика Mac для iPhone.
помимо исследования символов ...
Apple может очень легко иметь версию sdk, которая проверяет каждый из стеков частных методов при вызове, чтобы убедиться, что он вводится одним из назначенных методов.
Даже если вы статически связываетесь, в худшем случае они могут взять образцы кода из частных API-интерфейсов в своем списке и выполнить поиск вашего двоичного файла по ним (также относительно легко автоматизировать).
Зная Apple, я готов поспорить, что у них есть комплексная автоматизированная система, и любая неопределенность, вероятно, либо отрицается, либо проверяется вручную.
В конце концов, я думаю, что попытки обмануть Apple не стоит.
Это настольное приложение, App Scanner , может сканировать файлы .app на предмет использования частного API, извлекая двоичный файл Mach-O. Если может, то сможет и Apple!
Существует множество инструментов для реверс-инжиниринга, позволяющих проверять код.
nm
- перечисляет символы из объектных файлов objdump
- отображать информацию из объектных файлов.otool
- просмотреть содержание Mach-O [О программе] исполняемых файловstrings
- это даст вам все ниточки.Вы можете найти примеры / представление использования этих команд в сущности для Objective-C и Swift.