Spørsmål:
Kontroller flytegrafrekonstruksjonsprosjekter
Nordwald
2016-09-02 11:46:08 UTC
view on stackexchange narkive permalink

Jeg ser etter prosjekter som gir rekonstruerte kontrollflytgrafer fra binærfiler mens jeg støtter mer enn én plattform (f.eks. x86, x64, arm). For eksempel med tanke på dette korte monteringsprogrammet: 

  .global main.intel_syntax noprefix.extern getchar.extern printf.section .datajmpTable: .long _stub0 .long _stub1 .long _stub2fmt: .asciz "% x \ n ".seksjon .textmain: call getchar mov dl, 4 imul dl add eax, offset jmpTable jmp [eax] .long 3851_stub0: mov eax, 0 jmp end .long 3851_stub1: mov eax, 1 jmp end .long 3851_stub2: mov eax, 2 jmp end .long 3851end: push eax push offset fmt call printf add esp, 8 ret

Prosjekter jeg har vurdert:

  • IDA (best hittil, ekstraksjon smertefull)
  • BARF (naiv, begrenset tilnærming)
  • Angr (går lett i stykker eller beregner for alltid)
  • Radare2 (er det noe api å eksportere cfg-data?)
  • JakStab (begrenset til x86)

ganske opplagt valg, fortsatt er det fortsatt en smerte å eksportere en interprosedural CFG. Også, selv om den er i stand til å finne alle grunnleggende blokker i dette eksemplet, savner den alle indirekte kanter.

Prosjektene bør tilby slags API for å gi cfg. Jeg vet at det å løse dette problemet med statisk analyse alene kan være gjennomførbart. Jeg ser etter en best mulig tilnærming.

Hvilken del av å hente ut informasjonen fra IDA er spesielt smertefull? for meg ser det ut som å skrive et IDAPython-skript for det er ganske enkelt. Deretter kan du strukturere ditt eget grensesnitt hvis IDAs rå API er tungvint for deg.
IDA avslører mange interne strukturer og har en egen forståelse av kontrollflytgrafer. Hovedkritikken er fokus på funksjoner og behandling (og merking) av kanter.
[McSema] (https://github.com/trailofbits/mcsema) og [CMU BAP] (https://github.com/BinaryAnalysisPlatform/bap) virker lovende.
Tre svar:
Maijin
2016-09-04 21:52:46 UTC
view on stackexchange narkive permalink

Utpakking av kontrollflytdiagram i JSON med radare2: 

  $ > pythonimport r2piper2 = r2pipe.open ("/ bin / ls") r2.cmd ("aaa") # Se radare. i dag / innlegg / standard-analyse / cfg = r2.cmdj ("agj")

https://github.com/radare/radare2-bindings/tree/ master / r2pipe / python

har ikke radare noen slags 'ekte' api?
Det gjør det og ikke bare en: https://github.com/radare/radare2-bindings. r2pipe er bare en innpakning for r_core_cmd (), den gyter eller kobles til en R2-økt og kjører kommandoer og returnerer utdataene. Så lenge mange kommandoer har json-utgang, kan du bruke cmdj () som vil returnere et opprinnelig objekt for det språket du bruker. fra testene mine er dette mye raskere enn å bruke swig-bindingene fordi dataserialisering og ffi er veldig dyre. og json-parsere er MÅTT raskere. r2pipe krever ingen vedlikehold, og det vil hjelpe deg i de fleste av de brukene du vil ha.
perror
2016-09-02 12:28:25 UTC
view on stackexchange narkive permalink

For nå ser de mest effektive tilnærmingene i praksis ut til å følge prinsippet om symbolsk utførelse. Denne teknikken, opprinnelig utviklet for automatisk å bygge opp et sett med testtilfeller basert på en gitt kildekode, har nylig blitt brukt i binær analyse for å oppdage og (delvis) gjenopprette CFG i det analyserte binære programmet.

Mesteparten av tiden, hvis du vil håndtere flere forsamlingsspråk, må du bruke en mellomrepresentasjon for programmene. For nå har det vært mange av disse generiske modellene, og ingen fikk virkelig overlegenhet over de andre. Likevel ser de fleste populærene ut til å være den mellomliggende representasjonen av LLVM (mange verktøy bruker den), den nest mest populære ser ut til å være VEX, den mellomliggende representasjonen som brukes i Valgrind (som brukt i Angr). Den fra QEMU eller språket RREIL kan også være et alternativ, men de brukes mindre ofte. Men de fleste prosjektene kommer med sin egen mellomrepresentasjon.

Så, det du trenger for å bygge opp et CFG-gjenopprettingsprogram basert på symbolsk utførelse, er følgende moduler:

  • Loader : Denne modulen har ansvaret for å ta ditt binære program (det kan være en kjørbar eller et bibliotek) og simulere arbeidet til den opprinnelige lasteren for å bygge et realistisk minnebilde av hva du får etter at lasteprosessen er oppnådd.

  • Dekoder : Denne modulen har ansvaret for å oversette den innfødte forsamlingen som ble funnet mens den symbolsk utførte programmet til din egen mellomrepresentasjon. Det er en ganske lang (og smertefull) kode å implementere! Så vær forberedt på å lide mens du gjør dette.

  • Symbolisk utførelsesmotor : Vanligvis basert på en SMT-løser som bruker logikken QF_AUFBV (Quantifier Free / Arrays / Uninterpreted Function / Bitvectors), kan den symbolske utførelsesmotoren virkelig være en ytelsesflaskehals hvis du koder det naivt fordi gjenoppretting av CFG vil bruke det mye. Her er det virkelig viktig å ha en god formelforenklingsmodul (eller kutting).

Bortsett fra disse tre modulene, kan du også forbedre verktøyene dine ved å legge til mer avansert analyse og begynne å kode et abstrakt tolkningsrammeverk som kan legges til på toppen av den mellomliggende representasjonen din, bare for å få sjansen til å avdekke noen deler av CFG som ikke kan oppdages bare gjennom kraften til SMT-løsere.

Også ytelse er virkelig nøkkelen til å gjøre verktøyene dine virkelig brukbare. Så, å kunne fange det nøyaktige omfanget av en variabel eller muligheten til å oppdage en funksjon eller en modul / et objekt i binærkoden, hjelper mye å redusere størrelsen på koden du må vurdere på en gang.

Nå kan jeg gi deg mange tips og artikler om dette emnet, men jeg mangler litt tid. Jeg kan komme tilbake for å fullføre skrivingen av en omfattende liste senere, men den generelle ideen har forhåpentligvis blitt gitt ovenfor. Håper dette kan hjelpe deg.

Takk for forklaringen din. Jeg håpet dette har blitt gjort før på en mer pålitelig måte enn _hacky_ implementeringen i angr. Kjenner du noen andre prosjekter som tilbyr denne typen funksjonalitet?
For en tid siden skrev jeg denne [listen over verktøy] (http://reverseengineering.stackexchange.com/questions/4678/code-coverage-fuzzing/4679#4679) som utfører symbolsk utførelse (eller som kan brukes som en modul hjelper til med å gjøre det). Kanskje du kan finne noen hint der.
Fish
2017-08-16 14:15:06 UTC
view on stackexchange narkive permalink

Angr (går lett i stykker eller beregner for alltid)

Hvis du fremdeles er interessert i å finne en løsning, kan det være lurt å gi en ny prøve. Du bør hoppe på den slakke kanalen vår (angr.slack.com, vennligst få en invitasjon fra http://angr.io) slik at vi kan løse eventuelle CFG-gjenopprettingsproblemer sammen.

Jeg tror angr gir deg best fleksibilitet ut av alle løsningene du har nevnt, uten å gå inn i det symbolske kjøringshelvete.

Ansvarsfraskrivelse: Jeg er en kjerne-angr-utvikler.



ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...