Küsimus:
Kuidas tuvastada x86 32bit ribastatud kahendfunktsioonide funktsioone?
lllllllllllll
2014-07-10 22:44:35 UTC
view on stackexchange narkive permalink

Püüan luua jämedakoeline kõnegraafiku, mis põhineb mõnel x86 32-bitise platvormi binaarselt demonteeritud koostekoodil.

Täpset on väga raske genereerida Kõnegraafik põhineb asm-koodil, mõeldes erinevatele kaudse juhtimise voo ülekannetele, nii et praegu kaalun ainult otsese juhtimise voo ülekandmist .

Nii et kõigepealt proovin tuvastada function (alguse ja lõpu aadressid) demonteeritud koostekoodis eemaldatud binaarsest versioonist x86, 32bit.

Praegu on minu plaan kuidagi selline:

Mis puutub algusaadressidesse, siis võiksin konservatiivselt arvata, et mõni koostekood näeb välja selline: 

  push% ebp

tähistab algusaadressi funktsiooni.

ja võib-olla skannin kogu probleemi, tuvastades kogu käsu call sihtkohaga, võtke arvesse nende funktsioonikõne sihtkohti, kuna kogu funktsioon algab aadressiga

Probleemid on järgmised:

  1. s mõnda binaarselt määratletud funktsiooni ei pruugita kunagi kutsuda.

  2. osa kõne on optimeeritud kui jump kompilaatori poolt (mõeldes saba rekursiivsele kõnele)

Lõpp-aadressi osas muutuvad asjad keerulisemaks, kuna ühes funktsioonis võib olla mitu ret ...

? Kas on paremat lahendust ..?
Lihtsaim viis oleks ilmselt hankida IDA 5.0 (tasuta versioon) ja lasta sellel tööd teha.
Samuti võite kaaluda radare2 kasutamist. Vt küsimus: [Rekursiivse läbipääsu lahtivõtmine Radare2-ga?] (Http://reverseengineering.stackexchange.com/questions/4260/recursive-traversal-disassembling-with-radare2)
Kaks vastused:
yaspr
2014-07-11 04:33:03 UTC
view on stackexchange narkive permalink

Helistamisgraafiku või binaarse juhtimisvoo graafiku tühistamine pole sugugi nõrk ja on teadlaste jaoks endiselt kuum teema.

Teie lähenemine näib paljutõotav; kuid teie kahjuks komistate paljude tõketega.

Üks, järgides juhiseid call , annab binaarfaili staatilise analüüsi korral tõenäoliselt suurepäraseid tulemusi. Ainus probleem on see, et mõnikord on teil kaudseid kõnesid / hüppeid. See tähendab, et operand on register, mis sisaldab sihtaadressi. See juhtub väga sageli, kui kahendfaili sihtfaili algne lähtekood on kirjutatud näiteks C ++ (virtuaalsed funktsioonid). Üks võimalus sihtaadressi saamiseks on sellisel juhul jäljendada või käivitada seda arvutav kooditükk. Teine on hinnata selle väärtust heuristiliselt (heuristika on põrgu).

Kaks, saate käivitada binaarfaili mitme sisendandmekomplektiga ja kõnegraafikute dünaamilise eraldamise (seda saab teha instrumentide abil). Seejärel saate ristida kõik saadud kõnegraafikud ...

Kolm, soovitaksin funktsionaalset pigem põhibloki keskset lähenemist. Peamiselt seetõttu, et funktsioon on omaette põhiplokk ja teil on funktsioonide otsimisel sel viisil rohkem õnne kui proovida sobitada mustreid, mis võivad muutuda ühest kompilaatorist teise või kompilaatori versioonist teise.

Järgmised väljaanded on äärmiselt huvitavad: [1], [2], [3] ja ka mina soovitaks teil märkida DynInst ja callgrind , kui soovite selle teema kohta rohkem teada saada.

Mul on olnud mõningane edu järgides `kõnesid ja teinud (minimaalselt!) Emuleerimist registrihüpete jaoks. [Vaadake väljundilõigu näidis siit] (http://reverseengineering.stackexchange.com/questions/2895/delphi-pascal-try-except-finally-block). Soovitatav on-line lugemine: [Decompiler Design] (http://www.backerstreet.com/decompiler/introduction.htm) - esp. [Põhibloki lähenemine] (http://www.backerstreet.com/decompiler/basic_blocks.php).
Codoka
2020-05-27 12:19:56 UTC
view on stackexchange narkive permalink

Üldiselt saab selle probleemi lahendused klassifitseerida järgmisteks:

  • Mustriga vastav heuristika. Täpselt nagu see, mida te pakute. Näiteks push es otsimine kahendkoodist võib anda (üsna) ligikaudse ligikaudse funktsiooni alguse. Asjad on keerulisemad, kui soovite siiski funktsiooni lõppu leida.

  • Masinõpe. Mustrite sobitamist saab masinõppe abil automatiseerida. Kirjanduses on mitu ettepanekut, näiteks [ 1], [ 2] ja [ 3]. Kõik need üritavad õppida ja lõpetada funktsiooni baititaseme funktsioone. Kuid tänapäevased kompilaatori optimeerimised muudavad selliste lähenemisviiside jaoks keeruliseks üldistada ka binaarfailidele väljaspool koolituskomplekti. See on kõige lootustandvam lähenemisviis, mis põhineb [ 4] (avalikustamine: esimene autor siin) ja samaaegsel [ 5]. Põhimõtteliselt jätkub see (1) otsese kõne sihtanalüüsiga, (2) CFG läbimisega funktsiooni otste leidmiseks ja (3) saba kõne sihtanalüüsiga.

  • Kõneraami teave (CFI) kirjed. Enne väljamõeldava tegemist kontrollige CFI kirjeid jaotises .eh_frame . On suur tõenäosus, et funktsioonid on seal juba määratletud. CFI-kirjete tühjendamiseks võite kasutada midagi sellist nagu readelf --debug-dump = frames /bin/ls.

Olen vaatas hiljuti funktsioonide tuvastamise probleemi selles blogis postituses, kus esitan üksikasju.

Lahe. Täname probleemi kena kokkuvõtte eest. Praegu on käes 2020 ja lähen üksinda, et avaldada uurimisdokumente teemal "funktsioonide piiride tuvastamine", mis ei pruugi olla nii paljutõotav kui siis, kui ma selle küsimuse viis aastat tagasi postitasin. Aga jah, alati on tore näha, kuidas binaarsed häkkimisrühmad pidevalt selles valdkonnas pabereid uurivad ja avaldavad.


ⓘ
See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...