Spørgsmål:
Henter Objective-C kontrolflow?
baordog
2015-10-09 23:56:51 UTC
view on stackexchange narkive permalink

Jeg lærer at adskille og analysere objektiv-c-binære filer. En af mine frustrationer er, at i Hopper og IDA ser det ud til, at de korrekte krydsreferencer og kontrolflow ikke bevares. Jeg tror, ​​det er på grund af Objective-C's meddelelsesoverførselsteknik.

For eksempel er her et nøglegenme, jeg arbejder på: enter image description here

Som du kan se, at det er meget svært at følge. Alt ser ud til at falde sammen ved afsendelse af meddelelser med meget lidt indikation af, hvor kontrolflowet faktisk begynder. For eksempel prøver jeg at bestemme, hvad der kalder mk. Det sendes tydeligvis via afsendelse af beskeder, men hvor kommer opkaldet fra? Selvfølgelig synes krydsreferencer, som IDA giver, at stoppe ved enhver Objective-C-funktion - hvilket gør det svært at bestemme, hvem der kalder det.

Jeg har prøvet dette plugin: https://github.com/zynamics/objc-helper-plugin-ida

Men det resulterer i "intet at lappe. "

Har IDA en funktion til at hjælpe med dette? Hvordan kan jeg spore dette i hånden, hvis det er nødvendigt?

Nogle har allerede foreslået, at jeg bare løser dette gennem dynamisk analyse, men jeg foretrækker at forstå den rette måde at analysere det statisk på.

Jeg har arbejdet på et projekt med det specifikke mål at rekonstruere objekt-C kontrolflow. Fejlfinding er en helt anden opgave end genopbygning, fordi fejlretning altid kun følger en mulig eksekveringsvej.
Har du noget offentligt?
@Div er det ikke altid muligt at gå igennem kode med en debugger, for eksempel når man analyserer systemrammer til en iOS-version, der ikke har en jailbreak tilgængelig.
En svar:
Nordwald
2016-09-12 11:36:47 UTC
view on stackexchange narkive permalink

Der er desværre ingen løsning, der er uden for kassen. Selv inden for akademisk forskning er de fleste projekter, der tackler dette emne, stærkt begrænset.

For at være i stand til at rekonstruere kontrolflowdiagrammet skal du have information om alle mulige værdier til argumenterne for objc_msgSend for at finde ud af, hvilken funktion der påberåbes på hvilket objekt. Dette problem er potentielt uløseligt, men kan tilnærmes, f.eks. Ved hjælp af bagudskæring og plettet analyse.

Når det er sagt, skal du være i stand til at rekonstruere de fleste opkald i godartet software ved hjælp af denne metode. Baseret på de gendannede parametre kan du indsætte funktionsstubber og omdirigere opkaldet for at generere en mere ekspressiv CFG.

Fra min anekodale oplevelse at se på adskilt objc-kode: 99,99% af tiden er selv- og _cmd-argumenterne til et bestemt objc_msgSend-opkald altid de samme og afhænger ikke af kontrolstrømmen op til det punkt. Faktisk er vælgeren for det meste indlæst i x1 lige før objc_msgSend-opkaldet. Jeg kan ikke se, hvorfor det ikke ville være let at få det rigtigt i det mindste meget af tiden, hvis ikke alt.
Bare spil nogle tankespil, og jeg er ret sikker på, at du finder et dusin eksempler, hvorfor det under alle omstændigheder ikke er muligt. Bare spørg dig selv, hvad ville du gøre, hvis du forsøger at tilsløre disse opkald. der er ingen magi ... pointeranalysering og tilsløring var der før Object-C. En stor del af reverse engineering vedrører ikke godartet software.


Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...