Odpowiedzi:
Znam 3 sposoby. To tylko spekulacje, ponieważ nie pracuję w zespole recenzentów Apple.
otool -LSpowoduje to wyświetlenie wszystkich bibliotek, z którymi aplikacja jest połączona. Coś, czego wyraźnie nie powinieneś używać, jak IOKit i WebKit, może zostać przez to wykryte.
nm -uSpowoduje to wyświetlenie wszystkich połączonych symboli. To może wykryć
UITouch._phase(co może być przyczyną odrzucenia aplikacji opartych na Three20 w ciągu ostatnich kilku miesięcy).stringsSelektory celu-C są przechowywane w specjalnym regionie pliku binarnego, dlatego Apple może wyodrębnić stamtąd zawartość i sprawdzić, czy użyłeś nieudokumentowanych metod Objective-C, takich jak -[UIDevice setOrientation:].
Ponieważ selektory są niezależne od klasy, którą wysyłasz, nawet jeśli Twoja niestandardowa klasa definiuje -setOrientation:nieistotną dla UIDevice, istnieje możliwość odrzucenia.
Możesz użyć APIKit Erica Sadun, aby wykryć potencjalne odrzucenie z powodu (fałszywych alarmów) prywatnych interfejsów API.
(Jeśli naprawdę naprawdę chcesz obejść te sprawdzenia, możesz użyć funkcji środowiska wykonawczego, takich jak
-valueForKey:; object_getInstanceVariable, object_getIvar itp.aby zdobyć te prywatne biblioteki, klasy, metody i ivary. )
Możesz wyświetlić selektory w programie Mach-O, używając następującego jednoliniowego w Terminalu:
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/,$_))))))'Powiedzmy, że chcesz użyć prywatnego API; cel C pozwala na skonstruowanie dowolnego SEL z łańcucha:
SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
[UIDevice performSelector:my_sel ...];
Jak skan robota lub biblioteki może to wykryć? Musieliby to złapać za pomocą narzędzia, które monitoruje prywatne dostępy w czasie wykonywania. Nawet jeśli skonstruowali takie narzędzie uruchomieniowe, trudno je złapać, ponieważ to wywołanie może być ukryte w jakiejś rzadko ćwiczonej ścieżce.
Wyobrażam sobie, że patrzą na wszystkie symbole, które twój plik binarny próbuje zaimportować (informacje bez wątpienia są łatwo dostępne dla nich w tabeli symboli) i dadzą ci znać, jeśli którykolwiek z tych symboli znajduje się na ich „prywatnej liście API”. W rzeczywistości dość łatwe do zautomatyzowania.
Plik wykonywalny nie jest dokładnie czarną skrzynką. Jeśli zadzwonisz do biblioteki, łatwo ją znajdziesz. Dlatego lamentuję nad utratą języków asemblera we współczesnej edukacji CS. =] Narzędzia takie jak ldd powiedzą ci, do czego się podłączyłeś, chociaż nie pamiętam, jakie wcielenie ldd znalazło się w zestawie deweloperskim Mac iPhone.
oprócz badania symboli ...
Apple może bardzo łatwo mieć wersję sdk, która sprawdza każdą ze stosów metod prywatnych po wywołaniu, aby upewnić się, że została wprowadzona z jednej z wyznaczonych metod.
Nawet jeśli łączysz statycznie, w najgorszym przypadku mogą pobrać próbki kodu z prywatnych interfejsów API na swojej liście i przeszukać je w Twoim pliku binarnym (również stosunkowo łatwe do zautomatyzowania).
Znając Apple, założę się, że mają wszechstronny, zautomatyzowany system, a wszelka niepewność jest prawdopodobnie odrzucana lub weryfikowana ręcznie.
Koniec końców, myślę, że prawdopodobnie nie warto próbować oszukać Apple.
Ta aplikacja komputerowa, App Scanner , może skanować pliki .app w celu prywatnego użytku przez api, rozłączając plik binarny Mach-O. Jeśli tak, to Apple też!
Istnieje wiele narzędzi do inżynierii wstecznej, które umożliwiają wgląd w kod
nm - wyświetla symbole z plików obiektowych objdump - wyświetla informacje z plików obiektowych.otool- widok zawartości Macha-O [O] wykonywalnestrings - to dostaniesz wszystkie struny.Przykłady / reprezentacje użycia tych poleceń można znaleźć w streszczeniach dla Objective-C i Swift