Відповіді:
Я знаю 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 тощо.отримати ті приватні бібліотеки, класи, методи та івари. )
Ви можете перерахувати селектори в програмі 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 Mac Dev Kit.
окрім розслідування символів ...
apple може дуже легко мати версію sdk, яка перевіряє кожен із стеків приватних методів, коли викликається, щоб переконатися, що він введений одним із призначених методів.
Навіть якщо ви стаціонарно зв’язуєтесь, в гіршому випадку вони можуть брати зразки коду з приватних API в їх списку та здійснювати пошук у вашому бінарному файлі (також відносно легко автоматизувати).
Знаючи Apple, я б сказав, що у них є комплексна автоматизована система, і будь-яка невизначеність, ймовірно, або заперечується, або переглядається вручну.
Кінець дня, я думаю, що, мабуть, не варто докладати зусиль, щоб спробувати обдурити Apple.
Цей настільний додаток, Сканер додатків , може сканувати .app файли для приватного користування api, відчепивши файл Mach-O Binary. Якщо це може, то і Apple може!
Існує маса інструментів зворотної інженерії, які дозволяють перевірити код
nm - перераховує символи з об’єктних файлів objdump - відображення інформації з об’єктних файлів.otool- перегляд вмісту виконуваних файлів Mach-O [About]strings - це отримає у вас всі струни.Ви можете знайти приклади / представлення використання цих команд у списках для Objective-C і Swift