Eftersom det här är riktigt svårt att göra.

För att utarbeta:

Du måste också extrahera saker som inte är kodade. Tänk på importtabeller, exporttabeller, strängar och annan data.

När du skriver kod är det bara en del av programmet. Den andra delen är Compiler Optimization and data-avsnittet. Detta gör det nästan omöjligt att skapa omskapbar montering. Om du vill redigera ett program på monteringsnivå rekommenderar jag att du använder windbg och LordPE.

Det här är från IDA Pro-boken, men även IDA, så bra som det är, är fortfarande i slutändan gissningar. Svaren här är från "The IDA Pro Book" av Chris Eagle.

1. "Varför finns det inga demonterare som kan generera ommonterbar ASM-kodinriktning på godartat program (en utan fördunkling)? "

Kompileringsprocessen är förlorad.

På maskinspråknivån finns det inga variabel- eller funktionsnamn, och information av variabel typ kan endast bestämmas av hur data används snarare än uttryckliga typdeklarationer. När du observerar 32 bitar av data som överförs måste du göra en del undersökningsarbete för att avgöra om dessa 32 bitar representerar ett heltal, ett 32-bitars flytpunktsvärde eller en 32-bitars pekare.

Kompilering är en många-till-många-operation.

Detta innebär att ett källprogram kan översättas till monteringsspråk på många olika sätt, och maskinspråk kan översättas tillbaka till källan på många olika sätt. Som ett resultat är det ganska vanligt att kompilera en fil och omedelbart dekompilera den kan ge en helt annan källfil än den som matades in. Dekompilatorer är mycket språk- och biblioteksberoende. Bearbetning av en binärproducerad av en Delphi-kompilator med en dekompilator som är utformad för att generera C-kod kan ge mycket konstiga resultat. På samma sätt kan matning av en kompilerad Windows-binär genom en dekompilator som inte har kunskap om Windows-programmerings-API: t kanske inte ge något användbart.

I grund och botten kräver det fortfarande mänskligt omdöme. Den bästa analogin jag har hört är att kompilera en binär från källan är som att beräkna en Hash.

1. "Om jag vill implementera ett sådant verktyg (utan hjälp av IDA Pro, skissar från början), är det möjligt?"

Detta låter för mig som en intressant teoretisk forskningsfråga: Kan sammanställning verkligen ses som genererande en hash-signatur? Min tarm säger "Ja." Matematiken skulle vara väldigt invecklad och skulle antagligen behöva göras med ett bevisbart språk. Vi använder vanligtvis hashes eftersom de inte är lätta att omvandla. Men du kan fortfarande attackera hash med saker som regnbågsbord, så det finns ett megaprojekt att tänka på. Min instinkt berättar att regnbågsbord på alla möjliga binärer är NP-Complete.

Tänk också på att bestämma datatyper kräver ganska mänskligt omdöme, och vi är fortfarande inte så bra på att automatisera den typen av intelligens. Är det möjligt? Kanske. Det finns en anledning till att smarta människor fortfarande gör verktyg som IDA.

1. "Finns det några andra bekymmer relaterade till detta som jag kanske har missat?"

Jag är ny när det gäller demontering till de stora pojkarna, men förhoppningsvis svarade jag åtminstone på frågan om varför det är så svårt att göra vad du frågar.

Eagle, Chris (2011-06-16). IDA Pro Book: Den inofficiella guiden till världens mest populära demonterare (Kindle Locations 151-152). Ingen stärkelsepress. Kindle Edition.

Din fråga är dock väldigt intressant, inte riktigt ny.

Många använder redan det vi kallar binär omskrivning för profileringsändamål. Till exempel DynInst & MAQAO gör det för att profilera applikationer för att hitta flaskhalsar i grundläggande block. Nu är frågan du förmodligen ställer dig själv hur det görs? Enkel. Mest tillgängliga demonterare som objdump , objconv , IDA etc. fungerar i fristående läge och skriver vanligtvis ut en instruktion om demontering, men andra gillar udis86 & distorm erbjuder ett API för att få åtkomst till den demonterade koden förutom att vara tillgänglig i fristående läge. Men vad DynInst , MAQAO stark>, och de flesta binära omskrivningsverktyg gör är att ta isär en binär fil och infoga sonder varhelst det är lämpligt i datastrukturen innan du återmonterar binärfilen. Således hanteras alla nödvändiga ändringar relaterade till adresser, filialer, sammanhangsbesparing och så vidare innan de monteras om.

Vad du måste veta är att det är extremt svårt att skriva sådana verktyg. Den första utmaningen är att skriva en pålitlig demonterare. Detta innebär naturligtvis att man väljer en demonteringsalgoritm (linjär svep kontra rekursiv traversal), separerar instruktionerna från data (de kan blandas - skalkoder till exempel), och så vidare. Sedan kommer den andra utmaningen, lappa den demonterade koden. Detta är extremt knepigt och jag kommer att påpeka det här dokumentet som bör vara till stor hjälp: http://www.maqao.org/publications/techreports/madras_techreport.pdf. Den har skrivits av författaren till demonteraren som används i MAQAO ( MADRAS - Multi Architecture Disassembler Rewriter and Assembler ). Den intressanta delen av dessa dokument är referenserna (över 50 och extremt hjälpsamma) och bilagorna som beskriver algoritmerna som används.

Även om jag inte riktigt känner till varken MAQAO eller DynInst skulle jag rekommendera att du tittar på publikationer (dokumentation, vetenskapliga artiklar, ...). Jag skulle också rekommendera att du kontrollerar PEBIL (PMaCs Efficient Binary Instrumentation Toolkit), Intels PIN , Valgrind , PLTO , Elfsh / ERESI och Etch .

De flesta av dessa verktyg utför binär omskrivning & lapp i stor utsträckning och jag tror är bra exempel på hur binär omskrivning kan närma sig.

Jag hoppas att mitt svar hjälper dig att hitta det du letade efter.

Vissa system använder ett enkelt körbart format som länkas genom att kombinera instruktionerna och definierade data som finns i de bearbetade monteringsfilerna, i en specificerad sekvens. länkaren kommer att tillämpa adressfixar, men annars kommer innehållet i den körbara körningen att vara exakt vad programmeraren angav - inget mer; inget mindre. Det gamla MS-DOS .COM-filformatet var så, och så är det möjligt för en demonterare att ta en COM-fil och producera en fil som, när den är monterad och länkad, kommer att ge en bit-identisk fil (demonteringen kan behöva använda datadirektiv för allt det inte förstår, eller för instruktioner som kan kompileras till något annat än bitmönstret än som visas i filen, men alla körbara filbyte kan skapas med definition-byte-direktiv om inget annat.

Andra system använder dock länkar som är mer sofistikerade och måste generera ytterligare information som lagras i filen. Det är möjligt att bygga samma källfil med olika versioner av verktygen kan ge olika binära filer. allmänt, när man gör en sekvens för demontering-lapp-återmontering, skulle man sträva efter att minimera mängden kod vars adress ändras. Om koden lagrar adressen för en funktion någonstans men demonteraren inte inser att det är en funktionsadress snarare än en konstant är det enda sättet att koden fungerar om funktionen förblir på samma adress. Tyvärr finns det inget sätt för en objektfil som är kompatibel med MS-DOS- eller Windows-byggverktyg för att ange var saker ska placeras. När koden ursprungligen kompilerades eller sattes samman, skulle länken vara fri att placera funktionen var som helst och uppdatera den "konstanta" funktionsadressen på lämpligt sätt. När du bearbetar demonterad kod finns det inget sätt att säkerställa att funktionen förblir på den gamla adressen, och inte heller att alla adresser som beror på den uppdateras om den rör sig.

Överlägset är den etablerade metoden för binär omskrivning dynamisk omskrivning där den binära skrivs om medan den körs på riktiga ingångar. Tänk på instrumentverktyg som PIN , DynamoRIO och Dyninst och även binära översättare som qemu .

Statiska omskrivningsverktyg har en grundläggande utmaning jämfört med dynamisk omskrivning, vilket är exakt återställning av Control Flow Graph. Det vill säga, för varje grundblock i binären behöver vi veta uppsättningen av möjliga mål för dess hoppinstruktion. Svårigheten är att binärfiler har många indirekta ​​strong> hoppinstruktioner. Till exempel, om vi möter ett grundläggande block som slutar med bx r3 måste vi ha en exakt och pålitlig Value Set Analysis (VSA) som kan berätta de möjliga värden som r3 kan ta vid körning. Tyvärr är sådan analys i allmänhet obeslutbar. Men välskötta kompilatorer producerar binärer som är strukturerade på något sätt vilket är ett faktum som kan vara användbart i stor utsträckning.

Observera att problemet med att lösa CFG-återställning skulle göra det möjligt för oss att lösa kod / dataseparationsproblemet som en biprodukt. Det vill säga att demontering av rekursiv härkomst skulle göra det möjligt för oss att i så fall perfekt separera kod från data i kodbyteflödet.

Jag kan hänvisa till följande artikel som introducerades i förra årets USENIX Security:

Shuai Wang, Pei Wang, Dinghao Wu: Återmonterbar demontering . USENIX Security 2015: 627-642

Deras verktyg Uroboros är inte öppen källkod. Den är baserad på iterativ linjär sopmontering med hjälp av objdump . Demonteringstekniken i sig diskuteras i en tidigare uppsats. Ändå ger det intressanta tekniker för statisk binär omskrivning som faktiskt fungerar (eller åtminstone det är deras påstående). De skriver till och med samma binära flera gånger utan att bryta den. Slutligen notera att statisk binär omskrivning till stor del inte är tillämplig på binärer med generering av körningskod.

Uppdatering :

Det verkar som många av bristerna i Uroboros har adresserats i Ramblr som diskuteras här:

Wang et. al. " Ramblr: Making Reassemble Great Again ", Proceedings of the Network and Distributed System Security Symposium (NDSS'17). 2017

Särskilt nämner de att deras återmonterade binära filer inte har någon exekveringskostnad eller storleksutvidgning.