Как Apple знает, что вы используете частный API?

Я отправил двоичный файл в Apple без какого-либо исходного кода.

Помимо ручной проверки исходного кода, как Apple знает, что было использовано и какие API-адреса вы вызывали?

ОТВЕТЫ

Ответ 1

Есть три способа узнать. Это всего лишь некоторые предположения, так как я не работаю в команде Apple по обзору.

1. otool -L

Здесь будут перечислены все библиотеки, к которым было привязано приложение. Что-то явно не следует использовать, так как IOKit и WebKit могут быть обнаружены этим.

2. nm -u

Здесь перечислены все связанные символы. Это может обнаружить

  • Недокументированные функции C, такие как _UIImageWithName;
  • Objective-C классы, такие как UIProgressHUD
  • Ivars, например UITouch._phase (что может стать причиной отклонения приложений на основе Three20 в течение нескольких месяцев.)

3. Список селекторов Objective-C или strings

Селекторы

Objective-C сохраняются в специальной области двоичного файла, поэтому Apple может извлечь из него контент и проверить, были ли вы использованы недокументированные методы Objective-C, такие как -[UIDevice setOrientation:].

Поскольку селектор не зависит от класса, который вы передаете, даже если ваш пользовательский класс определяет -setOrientation: не относящийся к UIDevice, будет возможность отклонения.

Вы можете использовать Erica Sadun APIKit, чтобы обнаружить потенциальное отклонение из-за (ложных срабатываний) частных API.

(Если вы действительно действительно очень хотите обходить эти проверки, вы можете использовать функции времени выполнения, такие как

  • dlopen, dlsym
  • objc_getClass, sel_registerName, objc_msgSend
  • -valueForKey:; object_getInstanceVariable, object_getIvar и т.д.

чтобы получить те частные библиотеки, классы, методы и ivars. )

Ответ 2

Вы можете перечислить селектора в программе 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/,$_))))))'

Ответ 3

Предположим, вы хотите использовать частный API; объект C позволяет вам построить любой SEL из строки:

   SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
    [UIDevice performSelector:my_sel ...];

Как сканировать робот или библиотеку? Им придется поймать это с помощью некоторого инструмента, который контролирует частные обращения во время выполнения. Даже если они построили такой инструмент времени выполнения, его трудно поймать, потому что этот вызов может быть скрыт в некотором редко реализуемом пути.

Ответ 4

Я предполагаю, что они смотрят на все символы, которые ваш двоичный файл пытается импортировать (информация, без сомнения, легко доступна для них в таблице символов) и ding you, если какой-либо из этих символов найден в их "приватном списке API". На самом деле довольно легко автоматизировать.

Ответ 5

Исполняемый файл не является черным ящиком. Если вы обратитесь в библиотеку, это легко найти. Вот почему я жалуюсь на потерю языков ассемблера в современных образованиях CS. =] Инструменты, такие как ldd, расскажут вам, с чем вы связались, хотя я не помню, какое воплощение ldd сделал это в комплекте iPhone для iPhone.

Ответ 6

otool -L somebinary

Ответ 7

кроме исследования символов...

Apple может очень легко иметь версию sdk, которая проверяет каждый из стеков частных методов при вызове, чтобы убедиться, что она введена из одного из указанных методов.

Ответ 8

Даже если вы статически связываетесь, в худшем случае они могут брать образцы кода из частных API в свой список и искать в них свои двоичные файлы (также относительно легко автоматизировать).

Зная Apple, я бы поспорил, что у них есть комплексная автоматизированная система, и любая неопределенность, вероятно, либо лишена, либо рассмотрена вручную.

Конец дня, я думаю, это, вероятно, не стоило усилий, чтобы попытаться обмануть Apple.

Ответ 9

Это настольное приложение App Scanner позволяет сканировать файлы .app для частного использования api, вытаскивая двоичный файл Mach-O. Если это возможно, то Apple тоже может!

Ответ 10

Существует множество инструментов для обратного инжиниринга, позволяющих проверять код

  • nm - перечисляет символы из объектных файлов
  • objdump - отображать информацию из объектных файлов.
  • otool - просматривать содержимое Mach-O[About] исполняемых файлов
  • strings - это даст вам все строки.

Вы можете найти примеры/представление использования этих команд в гистах для Objective-C и Swift