Is er nog hoop op een Decompiler dat zou converteren een uitvoerbaar programma in C / C + + code?

Deze FAQ antwoord is een fragment uit FRAGMENTEN door Bob Stout.

Niet in het bezit van uw adem. Denk er eens over na ... Voor een Decompiler om goed te werken, hetzij 1) om de compiler zou moeten genereren in wezen identiek code, zelfs met volledige optimalisatie ingeschakeld, of 2) het zou moeten erkennen dat het individuele vermogen van elke compiler de code generator.

Als het eerste geval zouden kloppen, zouden er geen meer nodig compiler benchmarks omdat iedereen zou werken hetzelfde. Voor het tweede geval om waar te zijn zou vereisen enorm complex programma dat moest veranderen bij elke nieuwe release compiler.

Dus wat over specifieke decompilers voor specifieke compilers - zeggen een Decompiler ontworpen om te werken alleen op code wordt gegenereerd door, zeg, BC + + 4.5? Dit raakt ons recht terug naar de optimalisatie probleem. Code geschreven voor de duidelijkheid en begrijpelijkheid is vaak inefficiënt. Code geschreven voor maximale prestaties (snelheid of grootte) wordt vaak cryptische (op zijn best!) Toevoegen aan dit het feit dat alle moderne compilers hebben een veelheid van optimalisatie schakelaars om die optimalisatie technieken in staat te stellen en die te vermijden. De onderste lijn is dat voor een redelijk grote, complexe bron module, kunt u de compiler om een aantal verschillende doel-modules eenvoudig door het veranderen van uw optimalisatie schakelaars, zodat uw Decompiler zal ook moeten worden een deoptimizer die automagisch herkent die optimalisatie strategieën werden ingeschakeld tijdens het compileren.

Laten we eens verder te vereenvoudigen en te specificeren dat u alleen wilt ondersteuning van een specifieke compiler en u wilt decompileren naar de meest logische broncode zonder te proberen om de optimalisatie. Wat dan? Een goede optimizer kan en zal ingrijpend herschrijven onder de motorkap van uw code, dus wat je uit je Decompiler zal worden, niet alleen cryptische, maar in veel gevallen, bezaaid met goto verklaringen en andere nee-nee's van goede codering praktijk. Op dit punt, hebt u decompiled bron, maar wat goed is het?

Merk ook op zorgvuldig mijn verwijzing naar de bron modules. Een kenmerk van C is dat het grotendeels onleesbaar tenzij opgesplitst in makkelijk onderhoudbare bron modules (. C-bestanden). Hoe zal de Decompiler omgaan met dat? Het kan ofwel proberen te decompileren het hele programma in sommige mammoet main () functie, verliest alle modulariteit, of zou kunnen proberen om elke aangeroepen functie in haar eigen bestand. De eerste manier zou onbruikbaar chaos en de tweede zou in de problemen waar de oorspronkelijke bron afwijken bestanden met meerdere functies met behulp van statische gegevens en / of een of meer functies roepen een of meer statische functies. Een Decompiler kunnen maken van statische gegevens en / of functies wereldwijd, maar alleen ten koste of leesbaarheid (dat zou al onaanvaardbaar).

Tot slot, niet vergeten dat commerciële toepassingen vaak code de moeilijkste of tijd-kritieke functies in assembler die kan bewijzen bijna onmogelijk te decompileren in een C-equivalent.

Zoals ik al zei, niet in het bezit van uw adem. Aangezien de technologie verbetert tot waar decompilers kunnen meer haalbaar is, Optimizers en talen (C + +, bijvoorbeeld, zou een veel hardere taal te decompileren dan C) ook samenzweren om hen minder waarschijnlijk.

Voor de jaren Unix aanvragen zijn verdeeld in gehuld bron vorm (maar niet de menselijke machine leesbare - alle commentaar en witruimte verwijderd, namen alle variabelen in de vorm OOIIOIOI, enz.), dat is een zeer adequate middelen voor de bescherming van de rechten van de auteur. Het is zeer onwaarschijnlijk dat Decompiler output zou zelfs zo leesbaar als gehuld bron.

Update: Decompiler technologie is nog steeds erg moeilijk, maar significante vooruitgang is geboekt sinds dit werd geschreven.

Lees Wat is een Decompiler? Voor bijgewerkte informatie over Decompiler projecten.