En dekompiler (fra engelsk "decompiler", noen ganger Castilianized decompiler) er et dataprogram som utfører omvendt operasjon av en kompilator . [ 1 ] Det vil si å oversette kode eller informasjon med et lavt abstraksjonsnivå (kun designet for å bli lest av en datamaskin, f.eks . maskinkode ) til et språk eller medium med et høyere abstraksjonsnivå (vanligvis designet for å bli lest av en menneskelig, f.eks. et hvilket som helst programmeringsspråk på høyt nivå ).
Begrepet "dekompilere" brukes ofte på programmer hvis funksjon er å oversette kjørbar kode til kildekode , der:
Til sammenligning oversetter en disassembler en kjørbar eksklusivt til assemblerspråk , som som en forskjell fortsatt er avhengig av maskinvarestøtte og fortsatt har et minimalt abstraksjonsnivå (bare høyere enn maskinkode), men er lesbar for mennesker (og denne koden kan bli omskrevet). settes sammen til et kjørbart program).
Dekompilere er handlingen med å bruke en dekompilator, men hvis den brukes som et navn, kan den referere til utdata fra en dekompiler. Den kan brukes til å hente kildekode, og er svært nyttig i tilfeller av datasikkerhet, interoperabilitet og feilrettinger. [ 2 ] Suksessen til dekompilering avhenger av mengden informasjon som er tilstede i koden som dekompileres og sofistikeringen av analysen som utføres på den. Bytekodeformatene som brukes av mange virtuelle maskiner (som Java Virtual Machine eller .NET Framework Common Language Runtime) inkluderer noen ganger metadata på høyt nivå som gjør dekompileringen mer fleksibel. Maskinspråk har vanligvis mye mindre metadata, og er derfor mye vanskeligere å kompilere.
Noen kompilatorer og post-kompilatorverktøy produserer obfuskert kode (som betyr at de prøver å produsere utdata som er svært vanskelig å dekompilere). Dette gjør det vanskeligere å reversere koden fra den kjørbare.
Dekompilatorer kan betraktes som et sett med faser, som hver bidrar på en bestemt måte til dekompileringsprosessen.
Den første fasen av dekompileringen er lasteren, som mottar maskinkoden eller binærfilen fra et mellomspråk. Lasteren skal kunne oppdage grunnleggende data om programmet, for eksempel arkitekturen (Pentium, PowerPC, osv.), og inngangspunktet. I mange tilfeller skal du kunne finne hovedfunksjonen til et C-program, som er begynnelsen på den brukerskrevne koden. Dette ekskluderer initialiseringskoden fra kjøring, som ikke bør dekompileres hvis mulig.
Den neste logiske fasen er demontering av maskinkoden, som går til en maskinuavhengig representasjon (IR). For eksempel Pentium-instruksjonen
mov eax, [ebx+0x04]skal oversettes til IR
eax := m[ebx+4];De idiomatiske maskinkodesekvensene er et sett med kodesekvenser hvis semantikk ikke ser ut til å være semantisk individuelle instruksjoner. Enten som en del av demonteringsfasen, eller som en del av den påfølgende analysen, må disse idiomatiske sekvensene oversettes til deres ekvivalente IR-kode (maskinuavhengig representasjon). For eksempel, i x86 assemblerspråk:
cdq eax ; edx er lagret i eax utvidelsesregisteret xor eax, edx sub eax, edxkan oversettes til:
eax := abs(eax);Ulike typer analyser kan brukes på IR. Spesielt uttrykksformidling kombinerer semantikken til mange utsagn til mer komplekse uttrykk. For eksempel,
mov eax,[ebx+0x04] legg til eax,[ebx+0x08] sub[ebx+0x0C],eakskan resultere i følgende IR-kode etter uttrykksprogrammering:
m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);Det resulterende uttrykket ser ut som et språk på høyt nivå, pluss at du har fjernet bruken av registre eax. Ytterligere skanninger kan slette posten ebx.
En god dekompilator bør implementere typeparsing. Her resulterer måten registre eller minneregioner brukes i begrensninger på typen plassering. For eksempel innebærer en instruksjon andat operanden er et heltall; programmer bruker ikke slike operasjoner på flyttallverdier (unntatt i spesiell bibliotekkode) eller på pekere. En påstand andresulterer i 3 begrensninger; begge operandene kan være heltall, eller ett heltall og det andre en peker (i dette tilfellet; den tredje begrensningen oppstår på rekkefølgen av de to operandene når typene er forskjellige).
Ulike uttrykk på høyt nivå kan gjenkjennes ved å kjenne til strukturene eller matrisene. Imidlertid er det vanskelig å skille mange av mulighetene på grunn av friheten til maskinkoden eller også fordi noen høynivåspråk som C tillater casting og pekeraritmetikk.
Den forrige delen kan resultere i følgende kodeeksempel på høyt nivå:
struktur T1* ebx; struktur T1 { int v0004; int v0008; int v000C; }; ebx->v000C -= ebx->v0004 + ebx->v0008;Den nest siste fasen av dekompileringen involverer strukturering av IR-koden til høynivåkonstruksjoner som løkker whileog betingede strukturer if/then/else. For eksempel maskinkoden
xor eax, eax l0002: eller ebx, ebx jge l0003 legg til eax,[ebx] mov ebx,[ebx+0x4] jmp l0002 l0003: mov [0x10040000],ekskan oversettes som:
eax = 0; while (ebx < 0) { eax += ebx->v0000; ebx = ebx->v0004; } v10040000 = eax;Ustrukturert kode er vanskeligere å oversette til strukturert kode. Noen løsninger replikerer kode, eller legger til boolske variabler . Se kapittel 6 av. [ 3 ]
Den siste fasen er generering av kode på høyt nivå. Akkurat som en kompilator kan ha flere målspråk for å generere maskinkode for forskjellige arkitekturer, kan en dekompilator ha flere mål for å generere kode på forskjellige høynivåspråk.
Rett før kodegenerering er det ønskelig å tillate interaktiv redigering av IR-koden, kanskje ved å bruke et grafisk brukergrensesnitt. Dette kan tillate brukeren å legge til kommentarer, ikke-generiske variabler og funksjonsnavn. Likevel kan dette også legges til i post-dekompilere redigeringer. Brukeren kan endre noen strukturelle aspekter, for eksempel å konvertere en sløyfe whiletil en sløyfe for. Dette kan endres med et enkelt tekstredigeringsprogram, eller refaktoreringsverktøy på kildekoden kan også brukes. Brukeren må også legge til informasjon som ikke kunne gjenkjennes under typeanalysefasen, for eksempel å endre et minneuttrykk til en matrise eller struktur. Til slutt må du fikse dårlig IR-kode, eller gjøre endringer for å gjøre kodeutgangen mer lesbar.
De fleste dataprogrammer er omfattet av lov om opphavsrett . Selv om det er forskjellig mellom land å bestemme nøyaktig hva som er dekket av opphavsrett og hva som ikke er det. lov om opphavsrett gir vanligvis forfatteren ( programmereren (e) eller ansatte) en eksklusiv samling av rettigheter i programmet. Disse rettighetene inkluderer muligheten til å lage kopier, inkludert kopier laget på RAM -minnet til datamaskinen. Siden dekompileringsprosessen innebærer å lage flere kopier, har den generelt vært forbudt uten tillatelse fra opphavsrettseieren. Imidlertid er dekompilering noen ganger nødvendig når man ser etter interoperabilitet; opphavsrettslover i Europa og USA i dette tilfellet tillater dekompilering opp til en viss grense.
I USA har lover om rettferdig bruk av opphavsrett blitt brukt i dekompileringssaker. For eksempel var det en sak mellom Sega og Accolade , der Accolade endelig fikk lov til å dekompilere visse stykker kode så lenge de ikke kopierte spillingen som ble brukt av Segas konsoller. [ 4 ]
I Europa gir programvaredirektivet fra 1991 eksplisitt dekompileringsrettigheter så lenge det søkes om interoperabilitet mellom programmer. Resultatet av en heftig debatt mellom programvareproteksjonister og uavhengige kodeutviklere var artikkel 6, som bare tillater dekompilering hvis en rekke betingelser er oppfylt:
Videre foreskriver artikkel 6 at informasjonen som innhentes ved dekompilering ikke skal brukes til andre formål og ikke kan gis til en tredjepart.
På toppen av alt dette er retten gitt i artikkel 6 interessant, siden den spesifiserer hvor langt man kan gå i programvareindustrien med dekompilatorer. Få saker om disse dekompileringsrettighetene har blitt sett i Europa. Dette kan tolkes på to måter:
I en fersk rapport om det europeiske programvaredirektivet støttet EU-kommisjonen den andre tolkningen.