HTML

Hackstock

Hack the planet! Hackers unite!

Címkék

Címkefelhő

Lokalizált erőforrások iTunes-ban

2007.12.09. 20:36 :: theshadow

Ezúttal evezzünk más vizekre.
Egyszer iTunes-t debug-oltam és a felugró ablak helyét akartam elkapni a programkódban, de nem találtam rá, mert nem MessageBox metódust használt, hanem egy teljesen egyedi megoldást.
Mielőtt munkához látnánk hatástalanítsuk a debugger detektálást a programban, mert jelen állapotában az OllyDbg-t valamint társait észreveszi és nem hajlandó elindulni megfigyelt környezetben. Szerencsére előttünk már megtalálták a megfelelő helyet, ahol valamit kell tennünk. Leírások szerint a 84 C0 74 08 6A 00 byte sorozatot kell megkeresnünk az iTunes.exe-ben, amit a 7.5.0.20-as verzió .004F4B1C offszetén találtam meg. Itt egy függvényhívás található.

.text:004F4B17                 call    debuggerCheck
.text:004F4B1C                 test    al, al
.text:004F4B1E                 jz      short loc_4F4B28
.text:004F4B20                 push    0               ; uExitCode
.text:004F4B22                 call    ds:ExitProcess

Láthatjuk, hogy ha a visszatérési érték nem nulla értékű, akkor a futás befejeződik. Ennek megfelelően módosítottam a rutint, hogy minden esetben nulla értéket adjon vissza.

.text:00418D30 ; int __cdecl debuggerCheck()
.text:00418D30 debuggerCheck   proc near               ; CODE XREF: sub_4F4B00+17p
.text:00418D30                 call    sub_418B00
.text:00418D35                 test    al, al
.text:00418D37                 jz      short loc_418D3C
.text:00418D39
.text:00418D39 loc_418D39:                             ; CODE XREF: debuggerCheck+13j
.text:00418D39                 jmp     short loc_418D4B
.text:00418D39 ; ---------------------------------------------------------------------------
.text:00418D3B                 db 0C3h ; +
.text:00418D3C ; ---------------------------------------------------------------------------
.text:00418D3C
.text:00418D3C loc_418D3C:                             ; CODE XREF: debuggerCheck+7j
.text:00418D3C                 call    sub_418B80
.text:00418D41                 test    al, al
.text:00418D43                 jnz     short loc_418D39
.text:00418D45                 call    ds:IsDebuggerPresent
.text:00418D4B
.text:00418D4B loc_418D4B:                      ; CODE XREF: debuggerCheck:loc_418D39j
.text:00418D4B                 xor     eax, eax
.text:00418D4D                 nop
.text:00418D4E                 nop
.text:00418D4F                 nop
.text:00418D50                 retn
.text:00418D50 debuggerCheck   endp

Keresgélés és file-ok nézegetése után megtaláltam, hogy a regionalizált üzenetek egy sajátos erőforrásfile-ban találhatók a iTunes\iTunes.Resources\en.lproj\Localizable.strings file-ban. A könyvtárban még található egy iTunesLocalized.dll is, ami az előbb említett file-t tölti be. Tehát azt a pontot kell megtalálnunk, hogy mely ponton töltődik be a DLL.
A nyomkövetés kalandjait nem említem meg, hanem csak az eredményeket mutatom meg. Az "iTunesLocalized" szöveget unicode formátumban a .00FBE7F0 offszeten találtam meg, amire .01099AB0 címet találhatunk hivatkozást. Ezt a mutatót a .004F87A6 címen levő kód olvassa be.

.text:004F87A0                 mov     edx, module4    ; iTunesRegistry
.text:004F87A6                 mov     eax, module3    ; iTunesLocalized
.text:004F87AB                 mov     ecx, module2    ; iTunes
.text:004F87B1                 push    edx             ; module4
.text:004F87B2                 mov     edx, iTunesModuleName ; iTunes
.text:004F87B8                 push    eax             ; module3
.text:004F87B9                 push    ecx             ; module2
.text:004F87BA                 push    edx             ; module1
.text:004F87BB                 call    initResourceModules

Némi alakítgatás ereményeként látható, hogy egy erőforrás inicializáló eljárás kapja meg néhány másik modul neve társaságában (iTunesRegistry, iTunesLocalized, iTunes).

.text:0047BAB8                 call    getResourceDLLName ; EDI: DLL name
.text:0047BABD                 mov     ebp, ds:LoadLibraryW
.text:0047BAC3                 mov     eax, esi
.text:0047BAC5                 push    eax             ; lpLibFileName
.text:0047BAC6                 call    ebp ; LoadLibraryW
.text:0047BAC8                 test    eax, eax
.text:0047BACA                 mov     addrITunesRegistry, eax
.text:0047BACF                 jz      short failedInitialization

Az iTunesRegistry.dll-t az iTunes.Resources könyvtárban keresi és próbálja betölteni.

.text:0047BAD1                 movzx   ecx, defaultLocalization
.text:0047BAD8                 mov     edi, [esp+224h+var_210]
.text:0047BADC                 push    ecx
.text:0047BADD                 xor     ecx, ecx        ; int
.text:0047BADF                 mov     eax, ebx
.text:0047BAE1                 call    getLocalizedDLLName
.text:0047BAE6                 add     esp, 4
.text:0047BAE9                 mov     edx, esi
.text:0047BAEB                 push    edx             ; lpLibFileName
.text:0047BAEC                 call    ebp ; LoadLibraryW
.text:0047BAEE                 test    eax, eax
.text:0047BAF0                 mov     addrITunesLocalized, eax
.text:0047BAF5                 jz      short failedInitialization

Lokalizált erőforrás-könyvtárból próbálja meg betölteni az iTunesLocalized.dll-t (iTunes.Resources\en.lproj).

.text:0047BAFD                 call    getResourceDLLName ; EDI: DLL name
.text:0047BB02                 mov     eax, esi
.text:0047BB04                 push    eax             ; lpLibFileName
.text:0047BB05                 call    ebp ; LoadLibraryW
.text:0047BB07                 test    eax, eax
.text:0047BB09                 mov     addrITunesDLL, eax
.text:0047BB0E                 jnz     short loc_47BB2E

Szintén az iTunes.Resources könyvtárból próbálja meg betölteni az iTunes.dll file-t. Emlékezzünk vissza, hogy a betöltött modulok címét hova töltöttük be.

.data:013B2720 addrITunesLocalized dd ?  ; DATA XREF: getResourceModulAddress+14
.data:013B2720                                         ; sub_47B370+9r ...
.data:013B2724 addrITunesDLL   dd ?       ; DATA XREF: initResourceModules+C9
.data:013B2728 addrITunesEXE   dd ?       ; DATA XREF: initResourceModules+F6
.data:013B272C dword_13B272C   dd ?     ; DATA XREF: initResourceModules+FB

Az első elem keresztreferenciái között egy kis függvény érdekes a számunka.

.text:0047B370 ; int __cdecl getITunesLocalizedModuleBase()
.text:0047B370 getITunesLocalizedModuleBase proc near  ; CODE XREF: sub_41E930+CCp
.text:0047B370                                         ; sub_41EAD0+14p ...
.text:0047B370 mov     al, byte_13B271D
.text:0047B375 neg     al
.text:0047B377 sbb     eax, eax
.text:0047B379 and     eax, addrITunesLocalized
.text:0047B37F retn
.text:0047B37F getITunesLocalizedModuleBase endp

Az eljárás jól láthatóan az iTunesLocalized.dll báziscímét adja vissza abban az esetben, ha megtörtént már az inicializáció ezelőtt. Ezt az eljárást több másik is hívjak, amelyek lokalizált erőforrásokat akarnak elérni. A báziscímet handlerként használják fel olyan rendszerhívásokhoz, amelyek dialógusokat vagy bármi mást próbálnak betölteni.
Ez a rutin mellett egy másikra is érdemes odafigyelni, amit ugyancsak az addrITunesLocalized referenciái között találhatunk meg.

.text:0047B350 ; int __cdecl getResourceModulAddress(byte counter)
.text:0047B350 getResourceModulAddress proc near       ; CODE XREF: LoadStringWLocalized+4Fp
.text:0047B350                                         ; LoadStringALocalized+3Cp ...
.text:0047B350
.text:0047B350 counter= byte ptr  4
.text:0047B350
.text:0047B350 cmp     byte_13B271D, 0
.text:0047B357 jz      short loc_47B36C
.text:0047B359 mov     al, [esp+counter]
.text:0047B35D cmp     al, 4
.text:0047B35F jnb     short loc_47B36C
.text:0047B361 movzx   eax, al
.text:0047B364 mov     eax, addrITunesLocalized[eax*4]
.text:0047B36B retn
.text:0047B36C ; ---------------------------------------------------------------------------
.text:0047B36C
.text:0047B36C loc_47B36C:                   ; CODE XREF: getResourceModulAddress+7
.text:0047B36C                                         ; getResourceModulAddress+Fj
.text:0047B36C xor     eax, eax
.text:0047B36E retn
.text:0047B36E getResourceModulAddress endp

Annyival tud többet, hogy a tábla paraméter által meghatározott elemének báziscímét adja vissza. A kép akkor áll össze, ha tovább lépünk a hivatkozó eljárásokra, ahol azt látjuk, hogy LoadStringA, LoadStringW, LoadMenuA, LoadIconA, LoadCursor, LoadImage és még hasonló eljárások segítségével keres egy erőforrást és amint sikerül betöltetni, megszakítja a keresést.
Megpróbáltatásaink itt koránt sem érnek véget. Vizsgáljuk tovább a getITunesLocalizedModuleBase függvényt hívó eljárásokat. Találni fogunk egy .0041E9FC hivatkozást, ami dialógus ablak megjelenítésének a programja. Mivel ez a függvény generikusnak néz ki (paraméterei: template név, dialógus callback függvény, üzenet), ezért az ő hívói között kell kutatnunk, amig rá nem találunk a .004A1306 címre, ami már sokkal szimpatikusabb, de még mindig nem az igazi. Ugyan látható, hogy paraméterezéshez fix callback függvény címet és sablonnevet ad át (GenericUserMessageDlg), de az üzenet konkretizálása még mindig nincs meg. Hol kapja akkor meg ezt a paramétert, mert a jelent eljárás paraméterei között nem. Figyelmesen vizsgálva ráakadhatunk az EDI regiszterre, amit egy buffer átalakító eljárásnak ad át és előzőleg nem inicializálta sehol sem. Nézzük meg, honnan kerül ide a vezérlés.

.text:004A1370 ; int __cdecl showGenericUserMessageDlg(int message, int)
.text:004A1370 showGenericUserMessageDlg proc near     ; CODE XREF: sub_49EF60+3Dp
.text:004A1370                                         ; sub_4AD0C0+45p ...
.text:004A1370
.text:004A1370 message= dword ptr  4
.text:004A1370 arg_4= dword ptr  8
.text:004A1370
.text:004A1370 push    esi
.text:004A1371 mov     esi, [esp+4+arg_4]
.text:004A1375 push    edi
.text:004A1376 mov     edi, [esp+8+message]
.text:004A137A push    7F04h
.text:004A137F push    0
.text:004A1381 call    innerGenericUserMessageDlg
.text:004A1386 add     esp, 8
.text:004A1389 pop     edi
.text:004A138A pop     esi
.text:004A138B retn
.text:004A138B showGenericUserMessageDlg endp

így már érthetőbb, azonban még ez sem legyen elég. Sok helyről hívják, de minden referencia környezetében egyvalami közös; mindenütt egy függvényhívás szerepel előtte, aminek a címe .00490720 és furcsa módon két konstans értéket ad át.

.text:00490720 ; void __cdecl getLocalizedMessageByResourceID(int returnBuffer, __int16 majorResourceID, int minorResourceID)
.text:00490720 getLocalizedMessageByResourceID proc near ; CODE XREF: sub_4116D0+122p
.text:00490720                                         ; sub_4116D0+143p ...
.text:00490720
.text:00490720 returnBuffer= dword ptr  4
.text:00490720 majorResourceID= word ptr  8
.text:00490720 minorResourceID= dword ptr  0Ch

Ez a függvény felelős az erőforrás azonosítók alapján történő szövegek kifejtéséért.
Most játszunk egy kicsit. Tegyünk le ennek a függvénynek az elejére egy megszakítást és adjuk meg a következő feltételt:
Word(esp+8) == 0xA3 && Word(esp+0xC) == 0x58
Most válasszunk ki a listából egy dalt, jobb katt és "Create ringtone...". A futásnak meg kell állni a .00490720 címen, ha mindent jól csináltunk. A Localizable.string file-ban pedig keressük meg az alábbi sort.

"163.088" = "You can create iPhone ringtones from many songs purchased from the iTunes Store.";

Igen, ez fog megjelenni és ez az eljárás kereste elő (163 = 0xA3, 088 = 0x58).

Hadd jegyezzem még itt meg, hogy nagyon sok függvény és változónév nem adott a visszafejtés során. Nagy segítségemre volt az IDA Pro 5.2 abban, hogy én adjam meg a neveket, illetve a már értelmezett eljárásoknak C szintakszisú szignaturákat definiáljak és ezek szerte a kódban úgy jelenjenek meg.

Szólj hozzá!

Címkék: itunes x86

A bejegyzés trackback címe:

https://hackstock.blog.hu/api/trackback/id/tr39258329

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.