Я отправил в Apple двоичный файл без исходного кода.
Помимо ручной проверки исходного кода, как Apple узнает, что использовалось и какие API вы вызывали?
Я отправил в Apple двоичный файл без исходного кода.
Помимо ручной проверки исходного кода, как Apple узнает, что использовалось и какие API вы вызывали?
Ответы:
Я знаю 3 способа. Это всего лишь предположения, так как я не работаю в группе обзора Apple.
1.
otool -L
В нем будут перечислены все библиотеки, с которыми связано приложение. То, что вам явно не следует использовать, например, IOKit и WebKit, могут быть обнаружены этим.
2.
nm -u
Это список всех связанных символов. Это может обнаружить
UITouch._phase
(который может быть причиной отказа от приложений на базе Three20 в последние несколько месяцев).3. Перечислить селекторы Objective-C, или
strings
Селекторы Objective-C хранятся в специальной области двоичного файла, поэтому Apple может извлечь оттуда контент и проверить, не использовали ли вы какие-либо недокументированные методы Objective-C, например
-[UIDevice setOrientation:]
.Поскольку селекторы не зависят от класса, о котором вы сообщаете, даже если ваш собственный класс определяет
-setOrientation:
не относящийся к UIDevice, существует вероятность того, что он будет отклонен.Вы можете использовать APIKit Эрики Садун для обнаружения потенциального отказа из-за (ложных срабатываний) частных API.
(Если вы действительно действительно хотите обойти эти проверки, вы можете использовать функции времени выполнения, такие как
-valueForKey:
; object_getInstanceVariable, object_getIvar и т. д.чтобы получить эти частные библиотеки, классы, методы и ivars. )
источник
Вы можете перечислить селекторы в программе Mach-O, используя следующую однострочную строку в Терминале:
источник
Допустим, вы хотите использовать частный API; цель C позволяет вам построить любой 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.
источник