När kan en AI dekompilera all maskinkod till källkod?

Det kommer aldrig gå att återskapa vettig lättläst källkod från maskinkod helt automatiskt. Det finns så mkt mer information i källkod som t ex vettiga variabelnamn, kommentarer och design/struktur som går helt förlorad i maskinkod.

Man kan inte, utanför de absolut enklaste fallem få tillbaka originalprogrammet givet endast maskinkod som indata. Detta då kompilatorer gör fler transformer av programmet som ibland tappar delar av den fulla logiken då kompilatorn kan "bevisa" att transformen fortfarande ger samma observerbara påverkan på programmet tillstånd.

Bli också allt vanligare med "full program optimization", så kallad link time optimization. Detta snabbar upp programmet genom att vissa anrop till funktioner deklarerade i andra filer eller i andra bibliotek kan förenklas och ibland helt elimineras, så trots att funktion d.v.s. anrop till samma funktion F kan ta sig relativt olika uttryck beroende på hur F anropas.

Det skrivet, vad som är möjligt är att skapa någon högnivårepresentation av en program som om de kompileras med en specifik kompilator och en specifik uppsättning flaggor ger den binär man analyserade. Fast frågan är om författaren av originalprogrammet överhuvudtaget skulle inse att det är samma program...

En sak som är möjligt idag är s.k. liftning, har precis lär mig att Rosetta 2 bygger på exakt samma teknik som det jag länkar. Här går man inte tillbaka till ursprungliga källkoden, man lyfter någon maskinkod (x86_64 i fallet Rosetta 2) till något som kallas LLVM IR (LLVM Intermediate Representation).

LLVM IR är den enda "maskinkod" en front-end i LLVM behöver bry sig om. Så oavsett om du kompilera C, C++, Rust eller Swift så översätts det till LLVM IR om man kör med en LLVM front end. Vill du sedan köra ditt program på en x86_64 finns det en back-end som tar LLVM IR och skapar semantisk ekvivalent x86_64 kod. Vill du i stället köra på ARM64 tar man en backend som tar samma LLVM IR fast konverterar det till ARM64 maskinkod.

Då LLVM IR är en form av maskinkod även det är det relativt lätt att gå från "riktig" maskinkod till LLVM IR. Fördelen med LLVM IR är att det finns många och snabbt ökande antal verktyg som kan göra massa intressanta saker med LLVM IR. Om det inte redan finns lär det dyka upp verktyg som kan ta LLVM IR och skapa källkod i högre-nivå språk som har samma semantik.

Precis som de verktyg som går från assembler till säg C gäller samma även för "lifting". Man får en semantiskt ekvivalent LLVM IR representation av programmet, men med i princip 100 % säkerhet är det inte exakt den LLVM IR man hade när programmet ursprungligen skapades (om vi nu antar att det skapades med t.ex. Clang/LLVM).

I Rosetta 2 ser vi detta i form av att C->LLVM-IR->x86_64->LLVM-IR->ARM64 ger ett långsammare program än C->LLVM-IR->ARM64. Programmet gör samma sak men det senare har under kompileringsprocessen mer relevant kontext för att skapa ett optimalt program.

Det är inte olagligt att transformera en binär till ett annat format. Om så vore fallet skulle IDA Pro - Hex Rays (produkten du refererar till) vara olaglig, Rosetta 2 och McSema etc skulle också alla vara olagliga.

Vad som man måste tänka på är att författaren av programmet har upphovsskydd på sitt verk, vilket gäller även för de varianter man får fram genom att transformera verket till andra representationer. Så är olagligt att t.ex. själv använda den kod man får ut genom omvänd kompilering och vidaredistribuera det. Är däremot helt lagligt att göra en sådan transform för att undersöka vad programmet gör, huvudpoängen med Hex Rays är ju att göra det lättare att hitta säkerhetshål i program man bara har i binärformat.

Huvudpoängen med Rosetta 2 är att översätta en maskinkod till en annan, det är OK så länge den som har upphovsrätt fortfarande behåller sina rättigheter i den alternativa formen. D.v.s. om jag äger programmet som levereras som x86_64 och det inte finns ett explicit krav att enbart köra på en x86_64 CPU får jag, förutsatt att jag äger programmet, även köra det på andra CPU-arkitekturer via någon form av översättning (skulle det finnas ett krav på att det måste vara x86 går det ändå att köra genom emulering).

Att det få det till källkod i assembler är ju närmast trivialt, men inte särskilt användbart.
Få det till användbar källkod - lättläst, bra struktur, bra variabelnamn, lämpliga kommentarer, osv, det kommer antagligen aldrig att kunna göras maskinellt. Det är alldeles för mycket inormation som går förlorad vid kompilering.

Ja, det går väl inte emot något som jag sa?
"så att vidareutveckla såna program själv och skicka vidare till andra är ingen bra idé" mer specifikt.
TS mening var ju just att vidareutveckla program man inte har källkoden till.

Ah, sorry då missförstod jag vad "det är förbjudet" refererade till. Är rätt vanlig missuppfattning på forum att "reverse engineering" är otillåtet.

Om TS bara vill vidareutveckla programmet för eget bruk är det inget problem, går däremot inte att ta någon annans kod och distribuera vidare det (om man nu inte explicit har lov till det).

Sen finns ju möjligheten att komma runt copyright, man kan skapa en specifikation av programmet från t.ex. den kod man får ut från ett program som diskuteras här. Sedan kan ett funktionellt likvärdigt program skapas från den specifikationen, rätt gjort gör man där inget intrång på upphovsskydd även om man skriver ett program som utför samma uppgift eller utför den ursprungliga uppgiften plus mer än så vilket TS är ute efter.

Huvudandvändningen av omvänd kompilering verkar ändå vara för att betydligt enklare kunna undersöka eventuella säkerhetshål i binär-BLOB:ar man av olika skäl beror av. Inte helt ovanligt i äldre inbyggda system och är väl så man hittat flera säkerhetshål i Intels MCE och AMD motsvarighet.