Az alábbi cikket Ys. írta a 0x90 blogon, és mivel a cikksorozata kapcsolódik az iPhone-hoz, mi érdekesnek gondoljuk a számotokra is, így ezeket engedelmével egymás után át is emelnénk ide, a Szifonra.

***

A múltkori részben ott hagytuk abba a binárisok dinamikus analízisének témakörét, hogy ráakaszkodtunk az objc_msgSend függvényre gdb-vel, és figyeltük, hogy melyik objektum melyik másikkal lép kapcsolatba. Ez nagyon izgis, lehet órákig scrollozgatni az üzeneteket olvasgatva, de sokkal érdekesebb, ha mi magunk is belenyúlunk az alkalmazásunk lelkivilágába.

Megmutatom, hogy hogy lehet debuggerből feloldani a PIN képernyőt a már eddig is vizsgált PhotoVault alkalmazásban. Amit a következőkben leírok, továbbra sem “hekkeli meg” az appot, hanem egyszerűen példát mutat arra, hogy hogyan lehet az alkalmazás feltérképezése után használni az alkalmazás osztályainak térképét és interakcióba lépni az alkalmazás komponenseivel futási időben. A példát bővebb magyarázatokkal ebben a könyvben is megtaláljátok.

A futási időben történő interakciót megtehetjük a mezei, egyszerű parancssori gdb-vel. Működik, lehetséges a dolog és még akár használható is üzemszerű tesztelési melók során, azonban van egy jóval kényelmesebb mód is – úgy hívják, hogy cycript. Idézet a weboldaláról:

“What is Cycript? A programming language designed to blend the barrier between Objective-C and JavaScript.”

Elég perverzül hangzik, nemdebár? Érdemesebb inkább úgy közelíteni hozzá, hogy ez a mi szempontunkból nem más, mint egy szintaktikai édesítőszerekkel felturbózott front-end a gdb-hez. Ráadásul a gdb-hez hasonlóan rá tud akaszkodni futó processzekre, beszéli az ObjC szintaktikát, plusz javascript-szerűen szkriptelhető és ezek így összességében már igen jól használható eszközt adnak a kezünkbe.

Lássuk, hogy hogy működik és hogy lehet használni – mielőtt használni kezdenénk, nem árt némi előismeret az appról.

Amikor egy ObjC-ben megírt alkalmazás fut, akkor mindenféle eseményekre tud reagálni. Ilyen esemény lehet akármi – pl. a júzer a home gombra ütött és az app lement háttérbe, kilépnek belőle, de akár az alkalmazás saját maga is tud eseményeket definiálni, amikre aztán reagálni akar. Javás világban az ilyesmikre figyelő állatot listenereknek hívják, ObjC alatt delegate a nevük. Az alkalmazás komponensei delegate-eket használnak arra, hogy értesítsék egymást különféle dolgokról – a konkrét alkalmazásban van egy komponens, ami a PIN screen állapotát figyeli és ha a júzer sikeresen feloldotta a zárat, küld egy jelzést az alkalmazás többi komponensének, akik eltüntetik a PIN screent és elintézik a tényleges interfész felépítését és kirajzolását.

Honnét tudom mindezt? Az osztályok leírásából. A statikus analízisről szóló részben megmutattam, hogy hogy lehet a binárisból kinyerni a “térképet”, amiből képet lehet kapni az alkalmazást felépítő objektumokról és a működésükről.

white-iPhone:~ root# class-dump PhotoVault

A következők megértéséhez nem árt némi ObjC-ismeret: dióhéjban annyit fogunk csinálni, hogy megkeressük a statikus analízis során előállított “osztálytérképen”, hogy pontosan mi történik, amikor a felhasználó beüti a PIN-jét.

A PIN-képernyőn a felhasználó PIN-jét egy UITextField típusú objektum kapja meg, kell legelőször is objektum, ami ennek az eseményeire reagál. Az osztálytérképet átböngészve meg is találjuk a kérdéses objektumot, ami a JSLockScreenViewController névre hallgat, ez implementálja a deklaráció alapján a UITextFieldDelagate protokollt.

@interface JSLockScreenViewController : _ADBannerContentSizeIdentifier320x50 <UITextFieldDelegate>
{
UIView *_background;
UIView *_headerView;
UIImageView *_headerImageView;
UILabel *_statusLabel;
UILabel *_tipLabel;
UIImageView *_lockView;
UITextField *_passcodeField;
UITextField *_firstField;
UITextField *_secondField;
UITextField *_thirdField;
UITextField *_fourthField;
UIButton *cancelButton;
UITapGestureRecognizer *_tap;
id <JSLockScreenDelegate> _delegate;
}
[…]
– (void)dismiss;
[…]
– (BOOL)textField:(id)fp8 shouldChangeCharactersInRange:(struct _NSRange)fp12 replacementString:(id)fp20;
[…]
@end

Az osztály nevéből az is sejthető (még egyszer, nincs forrásunk az alkalmazáshoz), hogy ez az a komponens, amelyik ellenőrzi a beütött PIN helyességét. Az elnevezésekből kitaláljuk, hogy a dismiss függvény az, amelyik triggereli a feloldási folyamat befejezését jelentő esemény világgá kürtölését. Maga az ellenőrzés akkor történik meg, amikor a felhasználó beütötte a négy számjegyét, ezt az alkalmazás atextField:shouldChangeCharactersInRange: API-hívás felhasználásával éri el, ami minden beütött számjegy után meghívódik.

Remek, remek, haladunk, viszont a kérdés továbbra is adott: hogy rakjuk össze a cycriptet, hogy a memóriában futó alkalmazáspéldányban meg tudjuk hívni ezt a függvényt?

Így.

Elindítjuk a cycriptet.

white-iPhone:~ root# cycript -p `ps aux | grep PhotoVault | awk ‘{print $2}’`
cy#

Az cycript alapszinten beszéli az ObjC szintaktikát és rá van akaszkodva a processzünkre, kérdezzük hát meg tőle az alkalmazás gyökerének címét a memóriában.

cy# [UIApplication sharedApplication]
“<UIApplication: 0x3969b0>”

Tehát az alkalmazásunk gyökere egy UIApplication nevű objektum. Nézzük meg a http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIApplication_Class/Reference/Reference.html oldalon, hogy milyen függvényei vannak egy ilyennek. Van neki elég sok, de hogy lássuk, hogy hogy működik a dolog (és hogy működik), tekintsük a networkActivityIndicatorVisible nevű property-t, ami a kis hálózati kommunikációs ikonkát rakja ki illetve szedi le a státuszbárból.

networkActivityIndicatorVisible

A Boolean value that turns an indicator of network activity on or off.

Elég egyszerű a használata, kapcsoljuk be.

cy# [UIApplication sharedApplication].networkActivityIndicatorVisible
0

Most nem látszik, de ha bekapcsoljuk, akkor fog.

cy# [UIApplication sharedApplication].networkActivityIndicatorVisible = YES
true

Ez volt a bemelegítés – lássuk most a PIN screenünket, minden megvan, ami kell hozzá.

Legelőször is, amikor a PIN screenen vagyunk, akkor a képernyőn kirajzolt vizuális elemekért felelős objektumok mellett kell lennie egy JSLockScreenViewController típusú objektumnak, ami az előző térképelemzéses vizsgálódás alapján valamelyik textField-hez fog kapcsolódni. Amit a képernyőn látunk, az elérhető a cycriptben a keyWindow hívással.

cy# [UIApplication sharedApplication].keyWindow
“<TTNavigatorWindow: 0x357200; baseClass = UIWindow; frame = (0 0; 320 480); layer = <CALayer: 0x357310>>”

Megkérdezhetjük tőle, hogy egészen pontosan mi is van a képernyőn (a végét levágtam, hogy elférjen).

cy# [UIApplication sharedApplication].keyWindow.recursiveDescription
“<TTNavigatorWindow: 0x3ba090; baseClass = UIWindow; frame = (0 0; 320 480); layer = <CALayer: 0x3ba1a0>>
| <UIView: 0x3cfd10; frame = (0 20; 320 460); layer = <CALayer: 0x3cfd40>>
|    | <UIImageView: 0x3cff90; frame = (0 0; 320 480); userInteractionEnabled = NO; layer = <CALayer: 0x3d0a70>>
|    | <UIView: 0x3d21e0; frame = (0 0; 320 96); layer = <CALayer: 0x3d1ff0>>

[…]

Némi keresgélés után megtaláljuk, hogy a keresett controller hol található a memóriában:

cy# [UIApplication sharedApplication].keyWindow.subviews [0]._viewDelegate
“<JSLockScreenViewController: 0x3b1a70>”

Beszállunk az objektumba:

cy# x=new Instance(0x3b1a70)
“<JSLockScreenViewController: 0x3b1a70>”

…meghívjuk a dismiss függvényt:

cy# [x dismiss]

És tádááám, a PIN screen eltűnik a képernyőről.

Mielőtt izgalomba jönnénk, hogy de jó, most megtörtük az alkalmazást és igazából PIN nélkül hozzá tudunk férni bármihez, jöjjön a hidegzuhany: ahhoz, hogy ezt meg tudjuk tenni egy bármilyen készüléken, egyrészt jailbreakeltnek kell lennie, másrészt tudnunk kell az SSH-jelszót, továbbá fel kell oldanunk a screen lockot az iOS-en*. Elég komoly előfeltételek… másrészt újból aláhúzom, hogy nem törtük meg az alkalmazást, hanem egy debuggerrel addig manipuláltuk a processz memóriaterületét, amíg el nem értük a kívánt eredményt. Ha játszottál már crackme-vel, akkor pontosan tudod, hogy az még, hogy egyszer meghívtad a debuggerből a sikeres ellenőrzéskor lefutó kódágat, még nem jelenti azt, hogy megoldottad a feladatot.

A fenti procedúra nem maga a támadás, hanem csak egy újabb eszköz, amit használhatunk az alkalmazás dinamikus analízise során.

* jogos a kérdés, hogy ezzel a módszerrel ki lehet-e kapcsolni az iOS szintű screen lockot. Lesz egy rész a screen lockról is, akkor foglalkozunk a témával részletesen.

Köszönet Nepusznak a poszt előzetes szakmai lektorálásáért.