Skąd Apple wie, że używasz prywatnego interfejsu API?

109

Przesłałem plik binarny do Apple bez kodu źródłowego.

Oprócz ręcznego sprawdzania kodu źródłowego, skąd Apple wie, co zostało użyte i jakie API wywołałeś?

iphone objective-c appstore-approval Tattat
źródło
zmieniony tytuł - przypuszczam, że miałeś na myśli „Skąd Apple wie…”
Anurag

Odpowiedzi:

173

Znam 3 sposoby. To tylko spekulacje, ponieważ nie pracuję w zespole recenzentów Apple.

1. otool -L

Spowoduje 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.

2. nm -u

Spowoduje to wyświetlenie wszystkich połączonych symboli. To może wykryć

3. Lista selektorów celu-C, lub strings

Selektory 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

  • dlopen, dlsym
  • objc_getClass, sel_registerName, objc_msgSend
  • -valueForKey:; object_getInstanceVariable, object_getIvar itp.

aby zdobyć te prywatne biblioteki, klasy, metody i ivary. )

kennytm
źródło
Świetna odpowiedź. Dodam tylko, że jeśli Twoja aplikacja robi coś, co jest niezwykle trudne do zrobienia bez użycia prywatnego interfejsu API, jestem pewien, że Twoja aplikacja zostanie poddana dodatkowej kontroli.
Matthew Frederick,
Jestem ciekawy obejścia wywoływania metod prywatnych. Myślę, że kompilator wygeneruje wywołanie objc_msgSend (foo, @selector (privateMethod)) dla [foo privateMethod], więc jeśli Apple może wykryć bezpośrednie wywołanie privateMethod, może również wykryć wywołanie pośrednie za pośrednictwem objc_msgSend (lub performSelector :).
an0
Zastanawiam się, dlaczego mówisz, że nie powinieneś linkować z IOKit i WebKit?
hjaltij
2
Na czym uruchamiasz otool? Plik .app?
Rob
1
@Eric, mogliby , chociaż taka oprzyrządowana wersja prawdopodobnie wpłynęłaby na wydajność. Niezależnie od tego, widząc, że prywatne interfejsy API wielokrotnie trafiają do App Store, jasne jest, że tego nie robią, a przynajmniej nie robią tego cały czas.
Nate
26

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/,$_))))))'
Robert Diamond
źródło
+1, @Robert Diamond, Czy możesz opisać więcej na to samo. Muszę sprawdzić, czy Google Analytics używa wywołania UDID, czy nie. Dzięki
Mangesh
13

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.

Chris McLuvin
źródło
user1203764 komentuje, że tego rodzaju połączenia można faktycznie wykryć
Rup
@Rup chcesz wyrazić opinię na temat mojego pytania dotyczącego używania valueForKey, proszę? stackoverflow.com/questions/11923597/…
Dan Rosenstark
1
@Yar ciekawe pytanie! Ale nie jestem wystarczającym ekspertem, by komentować przepraszam. To, co powiedział Farcaller, wydaje mi się rozsądne
Rup
Dzięki @Rup, nikt najwyraźniej nie jest wystarczającym ekspertem w tej dziedzinie :)
Dan Rosenstark
Ktoś, kogo znam, mówi, że właśnie dostał taki telefon do App Store.
bugloaf
7

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.

Alex Martelli
źródło
1
Właściwie mogę z całą pewnością powiedzieć, że tak nie jest (przynajmniej to nie wszystko, co robią), w oparciu o prywatne użycie API, o którym wiem, że przeszło. Gdyby to było wszystko, co było potrzebne, prywatne użycie API nie prześlizgnęłoby się . Z mojego doświadczenia wynika, że ​​odpowiedź Kenny'egoTM jest prawie na pewno poprawna. Jest to obszar, w którym Objective-C zasadniczo różni się od innych języków, takich jak C.
Nate
1

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.

Sniggerfardimungus
źródło
1
Często się zastanawiałem: gdybyś miał napisać swój plik binarny do samodzielnej modyfikacji, generując kod tylko do zaimportowania prywatnego interfejsu API po spełnieniu pewnych kryteriów (powiedzmy po dacie publikacji Twojej aplikacji), czy Apple go złapie. Z pewnością przekazują nam interesujące statystyki, takie jak liczba naszych gier, które są uruchamiane na telefonach z jailbreakiem.
Sniggerfardimungus
@ user30997, Uprzywilejowany kod jest prawdopodobnie dostępny tylko przez wywołanie systemowe; wątek wykonawczy przełącza się na wyższe uprawnienia i sprawdza, czy poprzednie uprawnienie ma uprawnienia do wykonania kodu, czy nie. To tylko przykład, są inne sposoby na zrobienie tego, ale bardzo wątpię, że programiści byli na tyle naiwni, aby pominąć podstawowy mechanizm sprawdzania uprawnień w czasie wykonywania, taki jak ten, z pewnością zostałby on już opublikowany.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1 
otool -L somebinary
dvenema
źródło
1

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.

Grady Player
źródło
To nie wystarczy, ponieważ program może wywołać to prywatne wywołanie tylko w dowolnym momencie w przyszłości, w zależności od innej logiki. Aby to zrobić, Apple musi w rzeczywistości całkowicie zablokować prywatne interfejsy API lub pozwolić, aby struktury automatycznie zgłaszały prywatne wywołania API do Apple - co znacznie obniża wydajność.
Motti Shneor,
0

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.

myć się
źródło
4
Znajomość procesu recenzji firmy Apple po napotkaniu jakiejkolwiek niepewności wiąże się z wyłamaniem zestawu kości, aby uzyskać maksymalny kaprys.
TYLKO MOJA poprawna OPINIA
0

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ż!

Andrzej
źródło
0

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] wykonywalne
  • strings - to dostaniesz wszystkie struny.

Przykłady / reprezentacje użycia tych poleceń można znaleźć w streszczeniach dla Objective-C i Swift

yoAlex5
źródło