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.

***

Ha tisztességes betörési tesztet akarunk végezni egy iOS-es alkalmazáson, akkor sajnos nem lehet megúszni a sz@rral való kézi megküzdést, azaz azt, hogy belemásszunk az alkalmazás bináris analízisébe.

Ez a rész egyébként eléggé fájdalmas bír lenni a magamfajta linuxbubusoknak, ugyanis ergyamód szopni lehet azon, hogy a vonatkozó eszközöket két ízben lehet elérni/letölteni: (a.) OSX-re, (b.) iOS-re fordítva. Ezeket meg ugye se a Virtualbox, se a linux nem viszi. Egy-egy eszközt ki lehet túrni és krosszkompájlolni linuxra, de ez tényleg nagyon-nagyon fájdalmas. Bele kell törődni: az Apple-ös termékeken futó binárisok buzgatásához Apple termék kell. Pont. (Jó, most hazudtam: az IDA Pro hatos verziója tök jól dekompilálni tudja a Mach-O formátumot, de sok esetben ez az ágyúval verébre lövés minősített esete és sajnos csak nézegetni lehet a visszafejtett ARM assembly-t, debuggerben bökdösni sajna nem. Ez van.)

Némi könnyebséget jelent, hogy nem kell beruházni csillió forintért egy MacBook Pro-ra, hanem ha jailbreakeled a teszt iPhone-odat/iPadedet, akkor be lehet rá ssh-zni és az itt következő toolok mind-mind elérhetőek a Cydia repóiból, azaz ha felraktad rá jailbreak után a Cydia nevű eszközt, akkor tudsz rá az OpenSSH mellett egy csomó bináris analízisre jó toolt is gyógyítani.

Szóval, valahogy lett egy shelled egy iOS/OSX gépen és megvan az alkalmazásod, amit meg szeretnél b tesztelned kell. Legelőször is néhány alap dolog: linuxon ugye az ELF32 a leggyakoribb bináris formátum, vindózon a PE, iOS-en meg a Mach-O. A Mach-O minden architektúrán értelmezett, ami az Apple portfoliójában szerepel: i386, Sparc, ARM. Ami minket az iOS analízis kapcsán érdekel, az az ARM.

ARM-ból rögtön kétfajta is van – ugye ezek a procik megtalálhatóak mindenben a hordozható játékkonzolon át az okostelefonokig, és bár ugyanúgy hívják őket, ARM és ARM proci között is óriási különbségek lehetnek utasításkészlet tekintetében (is). A fejlesztők dolgát megkönnyítendő a procikat generációkba/családokba sorolják és az ugyanabba a családba tartozó procikon ugyanaz a kód futhat. Az első generációs iPhone-okban az ARMv6-os utasításkészletet beszélő procik ketyegtek, míg 3GS-től kezdve ARMv7-esek. Mivel a kompatibilitás biztosítása szükséges a lefordított alkalmazások tekintetében, sok esetben mindkét architektúrához tartozó kódot belefordítják ugyanabba a binárisba – ezeket hívják fat binary-nak. Amikor ilyen appot boncolsz fel IDA Pro-val, feldobja az ablakot, hogy achtung, több szegmens is van, melyiket akarod beparszolni.

Mutatok egy példát IDA Pro nélkül – legyen ez a PhotoVault nevű, Appstore-ból letölthető app binárisa.

white-iPhone:/User/Applications/33347AFA-B579-441D-9A04-8B7DF6A15831/PhotoVault.app root# otool -f PhotoVault

Fat headers
fat_magic 0xcafebabe
nfat_arch 2

architecture 0
cputype 12
cpusubtype 9
capabilities 0x0
offset 4096
size 2465232
align 2^12 (4096)

architecture 1
cputype 12
cpusubtype 6
capabilities 0x0
offset 24698880
size 2442336
align 2^12 (4096)

A 12-es cputype az ARM procikat jelenti, a 9-es subtype a v6-ot, a 12-es meg a v7-et, gyakorlatilag kétszer van meg ebben a binárisban ugyanaz a kód, másra fordítva. Az otool egyébként zseniális kis cucc, a Mach-O binárisok matatásának non plus ultrája. Tud pl. disassemblerként is működni, de erről kicsit később. Meg lehet vele nézni pl. a binárisunk függőségeit.

white-iPhone:/tmp root# otool -L PhotoVault
PhotoVault:
/System/Library/Frameworks/ImageIO.framework/ImageIO (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreMedia.framework/CoreMedia (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreVideo.framework/CoreVideo (compatibility version 1.2.0, current version 1.7.0) […]

A binárisunk által berántott rendszerkönyvtárak is segíthetnek abban, hogy kitaláljuk, milyen funkciókat is pakoltak bele a fejlesztők.

white-iPhone:/tmp root# otool -l PhotoVault
[…]
Load command 25
cmd LC_LOAD_DYLIB
cmdsize 88
name /System/Library/Frameworks/AddressBook.framework/AddressBook (offset 24)
time stamp 2 Thu Jan 1 01:00:02 1970
current version 30.0.0
compatibility version 1.0.0
[…]

Az App Store-ból letöltött binárisok sajnos alapból titkosítva jönnek, ezért ha simán beküldöd őket egy disassemblerbe, akkor nem fog működni a dolog. Természetesen ez nem lehet akadály, ugyanis ha jailbreakelt az eszközünk, akkor debuggerben elindítva az alkalmazást és a megfelelő részeket kidumpolva, majd visszamásolva a binárisba “megtörjük” (vagy inkább megkerüljük) a pofonegyszerű titkosítást.

Hogy lehet tudni, hogy titkosított-e a binárisod? Innét.

white-iPhone:/tmp # otool -l PhotoVault | grep crypt
cryptoff 8192
cryptsize 1970176
cryptid 1

Hogy lehet megkerülni a dolgot? Pofonegyszerű, némi gdb varázslat kell hozzá – erről lesz szó még később (egy későbbi részben, márminthogy. Stay tuned.) Ha már dekriptált a bináris, akkor a stringek kilistázását mindenképp érdemes megtenni. IDA Próban Shift + F12, parancssorból:

white-iPhone:/User/Applications/33347AFA-B579-441D-9A04-8B7DF6A15831/PhotoVault.app root# cat PhotoVault | strings | grep -i Password
@_kCFHTTPAuthenticationPassword
@_CFHTTPAuthenticationRequiresUserNameAndPassword
_CFHTTPAuthenticationRequiresUserNameAndPassword
_kCFHTTPAuthenticationPassword
@_kCFHTTPAuthenticationPassword
@_CFHTTPAuthenticationRequiresUserNameAndPassword
_CFHTTPAuthenticationRequiresUserNameAndPassword
_kCFHTTPAuthenticationPassword

A dekriptált binárisok vizsgálatakor elkerülhetetlen, hogy felrajzoljuk az alkalmazás Objective C-ben megírt forrásának alapvető térképét, az interfészek és objektumok definícióját és a függvények fejlécét. A dekriptált iOS binárisok szerencsére nagyon jól és könnyen dekompilálhatóak és még ARM assembly nélkül is elég érdekes dolgokat lehet találni bennük. Csináljuk meg ezt a térképet pl. a dekriptált PhotoVault binárisra!

white-iPhone:/tmp root# class-dump -s PhotoVault
[…]
struct CGAffineTransform {
float a;
float b;
float c;
float d;
}
[…]
@protocol TTPhoto <NSObject, TTURLObject>
– (void)setCaption:(id)fp8;
– (id)caption;
– (void)setIndex:(int)fp8;
– (int)index;
– (void)setSize:(struct CGSize)fp8;
– (struct CGSize)size;
– (void)setPhotoSource:(id)fp8;
– (id)photoSource;
– (id)URLForVersion:(int)fp8;
@end

Ebből a térképből már elég jól lehet tippelgetni, hogy melyik komponens mit csinálhat az alkalmazásban. Igen, tudom, az IDA Pro is megmondja mindezt, azonban ez szerintem áttekinthetőbb formátumú térkép egy nagyobb alkalmazás esetében. Akit érdekel a dolog mélyebben, annak ajánlom ezt a könyvet és az otool manualját.

A következő részben arról lesz szó, hogy hogyan lehet megkerülni az AppStore-ból jövő binárisok titkosítását sok-sok gdb-vel.