Come smontare, modificare e rimontare un eseguibile Linux?

https://stackoverflow.com/questions/4309771

29-09-2019
|

Domanda

C'è qualche cosa questo può essere fatto? Ho usato objdump ma che non produce assemblaggio di uscita che sarà accettata da nessun assemblatore, che io sappia. Mi piacerebbe essere in grado di cambiare le istruzioni all'interno di un eseguibile e quindi verificare in seguito.

Soluzione

Non credo che ci sia alcun modo affidabile per fare questo. formati di codice macchina sono molto complicati, più complicato di file di assieme. In realtà non è possibile prendere un binario compilato (per esempio, in formato ELF) e produrre un programma di montaggio sorgente che compilerà allo stesso (o simile-abbastanza) binario. Per acquisire una comprensione delle differenze, confrontare l'output di GCC compilazione diretta assembler (gcc -S) contro l'uscita del objdump sul file eseguibile (objdump -D).

Ci sono due principali complicanze che posso pensare. In primo luogo, il codice macchina stessa non è una corrispondenza 1-a-1 con il codice assembly, perché di cose come offset di puntatore.

Ad esempio, si consideri il codice C per Ciao mondo:

int main()
{
    printf("Hello, world!\n");
    return 0;
}

Questo viene compilato in codice assembly x86:

.LC0:
    .string "hello"
    .text
<snip>
    movl    $.LC0, %eax
    movl    %eax, (%esp)
    call    printf

Dove .LCO è una costante di nome, e printf è un simbolo in una tabella dei simboli libreria condivisa. Confronto con l'uscita del objdump:

80483cd:       b8 b0 84 04 08          mov    $0x80484b0,%eax
80483d2:       89 04 24                mov    %eax,(%esp)
80483d5:       e8 1a ff ff ff          call   80482f4 <printf@plt>

In primo luogo, il .LC0 costante è ora compensato in qualche parte della memoria solo alcuni casuale - sarebbe difficile per creare un file sorgente assembly che contiene questa costante nel posto giusto, dal momento che l'assemblatore e il linker sono liberi di scegliere riprese per queste costanti.

In secondo luogo, io non sono del tutto sicuro di questo (e dipende da cose come la posizione del codice indipendente), ma credo che il riferimento a printf non è effettivamente codificato all'indirizzo puntatore in quel codice lì a tutti, ma l'ELF intestazioni contengono una tabella di ricerca che sostituisce in modo dinamico il suo indirizzo a tempo di esecuzione. Pertanto, il codice smontato abbastanza non corrisponde al codice assembly sorgente.

In sintesi, sorgente ha assemblaggio simboli mentre codice macchina compilato ha indirizzi che sono difficili da invertire.

La seconda complicazione principale è che un file sorgente assembly non può contenere tutte le informazioni che era presente nelle intestazioni dei file ELF originali, come le biblioteche, che a collegamento dinamico contro, e altri metadati messo lì dal compilatore originale. Sarebbe difficile ricostruire questo.

Come ho detto, è possibile che uno speciale strumento può manipolare tutte queste informazioni, ma è improbabile che si può semplicemente produrre codice assembly che possono essere riassemblati di nuovo al file eseguibile.

Se siete interessati a modificare solo una piccola sezione del file eseguibile, vi consiglio un approccio molto più sottile di ricompilare l'intera applicazione. Uso objdump per ottenere il codice assembly per la funzione (s) che ti interessa. Convertirlo in "Sintassi assieme di origine" a mano (e qui, mi piacerebbe che ci fosse uno strumento che in realtà ha prodotto lo smontaggio della stessa sintassi come ingresso) , e modificarlo come si desidera. Quando hai finito, ricompilazione solo quelle funzioni (s) e utilizzare objdump per capire il codice macchina per il programma modificato. Quindi, utilizzare un editor esadecimale per incollare manualmente il nuovo codice macchina sopra la parte superiore della parte corrispondente del programma originale, facendo attenzione che il nuovo codice è esattamente lo stesso numero di byte come il vecchio codice (o di tutti gli offset sarebbe sbagliato ). Se il nuovo codice è più breve, è possibile pad fuori utilizzando le istruzioni NOP. Se è più lungo, si può essere in difficoltà, e potrebbe essere necessario creare nuove funzioni e li chiamano invece.

Altri suggerimenti

Per modificare il codice all'interno di una binaria complesso, ci sono generalmente 3 modi per farlo.

Se si tratta solo di una cosa banale come una costante, allora basta cambiare la posizione con un editor esadecimale. Supponendo che si può trovare per cominciare.
Se è necessario il codice alter, quindi utilizzare il LD_PRELOAD per sovrascrivere qualche funzione nel vostro programma. Che non funziona se la funzione non è nelle tabelle delle funzioni però.
Hack il codice alla funzione che si desidera correzione di essere un salto diretto ad una funzione che si carica tramite LD_PRELOAD e poi tornare nella stessa posizione (Questa è una combi di quanto sopra due)

Naturalmente solo il 2 ° uno funziona, se la fa assemblaggio qualsiasi tipo di auto-controllo integrità.

Modifica:. Se non è ovvio poi giocare con assemblee binari è molto roba sviluppatore di alto livello, e si avrà un tempo difficile chiedendo qui, a meno che non è davvero cose specifiche si chiede

@mgiuca giustamente ha affrontato questa risposta da un punto di vista tecnico. Infatti, disassemblying un programma eseguibile in una sorgente assembly facile ricompilazione non è un compito facile.

Per aggiungere alcuni bit alla discussione, ci sono un paio di tecniche / strumenti che potrebbe essere interessante da esplorare, anche se sono tecnicamente complessi.

statico / dinamico strumentazione . Questa tecnica comporta che analizzano il formato eseguibile, inserimento / cancellazione / sostituire le istruzioni di montaggio specifiche per un determinato scopo, fissare tutti i riferimenti a variabili / funzioni nel file eseguibile, e l'Emit un nuovo modificato eseguibile. Alcuni strumenti, che io conosco sono: PIN , dirottatore , PEBIL , DynamoRIO . Si consideri che la configurazione di tali strumenti per un diverso scopo da quello che sono stati progettati per potrebbe essere difficile, e richiede la comprensione di entrambi i formati eseguibili e set di istruzioni.
completa eseguibile decompilazione . Questa tecnica cerca di ricostruire una fonte di assemblaggio completo da un file eseguibile. Si potrebbe voler dare un'occhiata al linea Disassembler , che cerca di fare il lavoro. Si perde in ogni caso informazioni sui moduli differenti sorgenti e, eventualmente, le funzioni / i nomi delle variabili.
reindirizzabile decompilazione . Questa tecnica tenta di estrarre più informazioni dal file eseguibile, guardando compilatore impronte digitali (vale a dire, i modelli di codice generato da compilatori noti) e altre cose deterministico. L'obiettivo principale è quello di ricostruire il codice sorgente di livello superiore, come il C fonte, da un file eseguibile. Questo a volte è in grado di recuperare le informazioni sulle funzioni / variabili nomi. Si consideri che la compilazione di fonti con -g spesso offre risultati migliori. Si potrebbe voler dare il reindirizzabile Decompiler una prova.

La maggior parte di questo viene da valutazione e analisi vulnerbility esecuzione campi di ricerca. Sono tecniche complesse e spesso gli strumenti non possono essere utilizzati immediatamente fuori dalla scatola. Tuttavia, essi forniscono un aiuto prezioso quando si cerca di decodificare alcuni software.

Lo faccio con hexdump e un editor di testo. Devi essere davvero agio con il codice macchina e il formato del file di riporlo, e flessibile, con ciò che conta come "smontare, modificare, e poi rimontare".

Se si può ottenere via con fare solo "modifiche spot" (riscrittura byte, ma non aggiungendo né la rimozione di byte), sarà facile (relativamente parlando).

davvero non si vuole spostare eventuali istruzioni esistenti, perché allora ci si deve regolare manualmente qualsiasi indirizzo all'interno del codice macchina relativo effettato, per i salti / rami / carichi / negozi relativi alla il contatore di programma, sia in immediati valori hardcoded e quelli calcolati attraverso registri .

Si dovrebbe sempre essere in grado di farla franca, non la rimozione di byte. L'aggiunta di byte può essere necessario per le modifiche più complesse, e ottiene molto più difficile.

Passo 0 (preparazione)

Dopo che hai effettivamente smontato il file in modo corretto con objdump -D o quello che normalmente si usa prima effettivamente capire e trovare i punti necessari per il cambiamento, è necessario prendere nota di quanto segue le cose per aiutarvi a individuare i byte corretti da modificare:

Il "indirizzo" (offset dall'inizio del file) dei byte è necessario modificare.
Il valore grezzo di quei byte in quanto attualmente sono (l'opzione --show-raw-insn a objdump è veramente utile qui).

Passaggio 1

Dump la rappresentazione esadecimale grezzo del file binario con hexdump -Cv.

Passaggio 2

Aprire il file hexdumped e trovare i byte all'indirizzo che stai cercando di cambiare.

corso accelerato rapido in uscita hexdump -Cv:

La colonna più a sinistra è l'indirizzo dei byte (relativo all'inizio del file binario in sé, proprio come objdump fornisce).
La colonna più a destra (circondata da personaggi |) è solo la rappresentazione "leggibile" dei byte - il carattere ASCII corrispondente ogni byte è scritto lì, con un . in piedi per tutti i byte che non mappano ad un ASCII carattere stampabile.
La roba importante è tra -. Ogni byte come due cifre esadecimali separati da spazi, 16 byte per riga

Attenzione: objdump -D differenza, che vi dà l'indirizzo di ogni istruzione e spettacoli l'esagono grezzo dell'istruzione basata su come è documentato come in fase di codifica, hexdump -Cv discariche ogni byte esattamente nell'ordine in cui appare nel file. Questo può essere un po 'di confusione come in primo luogo sulle macchine in cui i byte di istruzione sono in ordine inverso a causa delle differenze endianness, che può anche essere disorientante quando sei in attesa di una specifica byte come un indirizzo specifico.

Passaggio 3

Modifica il byte che devono cambiare -. Ovviamente necessario capire l'istruzione di codifica macchina grezzo (non i mnemonico montaggio) e manualmente scrivere nei byte corretti

Nota: non necessità di cambiare la rappresentazione leggibile nella colonna più a destra. hexdump ignorerà quando si "non-dump" di esso.

Passo 4

"Un-dump" il file hexdump modificata utilizzando hexdump -R.

Passo 5 (controllo di integrità)

objdump tuo file appena unhexdumped e verificare che lo smontaggio che si è modificato sembra corretto. diff contro il objdump dell'originale.

Scherzi a parte, non saltare questo passaggio. Faccio un errore il più delle volte quando si modifica manualmente il codice macchina e questo è come mi prendo la maggior parte di loro.

Esempio

Ecco una vita reale ha lavorato ad esempio da quando ho modificato un binario ARMv8 (little endian) di recente. (Lo so, la questione è aggiunto x86, ma non ho un esempio x86 a portata di mano, e con i principi fondamentali sono esimoe stessi, solo le istruzioni sono diverse.)

Nella mia situazione ho bisogno di disattivare uno specifico "non si dovrebbe fare questo" check-tenendo la mano: nel mio esempio binario, in uscita objdump --show-raw-insn -d la linea a cui tenevo guardato come questo (un'istruzione prima e dopo la data per contesto):

     f40:   aa1503e3    mov x3, x21
     f44:   97fffeeb    bl  af0 <error@plt>
     f48:   f94013f7    ldr x23, [sp, #32]

Come si può vedere, il nostro programma è "utilmente" uscendo dal salto in una funzione error (che termina il programma). Inaccettabile. Quindi stiamo andando a girare che l'istruzione in una no-op. Quindi stiamo cercando il byte 0x97fffeeb all'indirizzo 0xf44 / file-offset.

Questa è la linea di hexdump -Cv contenente che compensato.

00000f40  e3 03 15 aa eb fe ff 97  f7 13 40 f9 e8 02 40 39  |..........@...@9|

Si noti come i byte rilevanti sono effettivamente capovolte (codifica little endian nell'architettura applica alle istruzioni macchina come ad altro) e come questo si riferisce leggermente unintuitively di quanto byte è a quale byte offset:

00000f40  -- -- -- -- eb fe ff 97  -- -- -- -- -- -- -- --  |..........@...@9|
                      ^
                      This is offset f44, holding the least significant byte
                      So the *instruction as a whole* is at the expected offset,
                      just the bytes are flipped around. Of course, whether the
                      order matches or not will vary with the architecture.

In ogni caso, io so da cercando in altri smontaggio che smonta 0xd503201f a nop in modo che sembra un buon candidato per la mia istruzione no-op. Ho modifica la riga nel file hexdumped di conseguenza:

00000f40  e3 03 15 aa 1f 20 03 d5  f7 13 40 f9 e8 02 40 39  |..........@...@9|

torna convertito in binario con hexdump -R, smontato il nuovo binario con objdump --show-raw-insn -d e verificato che il cambiamento è stato corretto:

     f40:   aa1503e3    mov x3, x21
     f44:   d503201f    nop
     f48:   f94013f7    ldr x23, [sp, #32]

Poi ho eseguito il file binario ed ha ottenuto il comportamento che volevo -. L'assegno in questione non è più dovuta al programma di interruzione

Macchina modifica al codice di successo.

!!! Attenzione !!!

O ero io successo? Forse si macchia di quello che ho perso in questo esempio?

Sono sicuro che hai fatto - dal momento che stai chiedendo su come modificare manualmente il codice macchina di un programma, è presumibilmente sa cosa si sta facendo. Ma per il beneficio di tutti i lettori che potrebbero essere a leggere per imparare, io elaboro:

Ho solo cambiato il ultima di istruzioni nel ramo errori caso! Il salto nella funzione che esce il problema. Ma come si può vedere, il registro x3 veniva modificato dal mov appena sopra! Infatti, un totale di quattro (4) registri sono stati modificati come parte del preambolo chiamata error, e un registro era. Ecco il codice macchina completo per quel ramo, a partire dal salto condizionato sul blocco if e termina dove il salto va a se non viene presa la if condizionale:

     f2c:   350000e8    cbnz    w8, f48
     f30:   b0000002    adrp    x2, 1000
     f34:   91128442    add x2, x2, #0x4a1
     f38:   320003e0    orr w0, wzr, #0x1
     f3c:   2a1f03e1    mov w1, wzr
     f40:   aa1503e3    mov x3, x21
     f44:   97fffeeb    bl  af0 <error@plt>
     f48:   f94013f7    ldr x23, [sp, #32]

Tutto il codice dopo che il ramo è stato generato dal compilatore sul presupposto che lo Stato programma è stato come era prima del salto condizionato ! Ma basta fare il salto finale per il codice della funzione error un no-op, ho creato un percorso di codice in cui si raggiunge il codice con incoerente / errato stato del programma

Nel mio caso, questo in realtà sembrava non causa alcun problema. Così ho avuto fortuna. molto fortunati: solo dopo che ho già eseguito il mio binario modificato (che, per inciso, era un critici per la sicurezza binario : aveva la capacità di setuid, setgid, e il cambiamento contesto di SELinux !) mi sono reso conto che ho dimenticato di tracciare in realtà i percorsi di codice di registro se queste modifiche effettuate le percorsi di codice che è venuto più tardi!

Questo potrebbe essere stato catastrofico - uno di questi registri potrebbe essere stato utilizzato in codice in seguito con il presupposto che conteneva un valore precedente che ora ha sovrascritto! E io sono il tipo di persona che la gente sappia di meticolosa un'attenta riflessione sul codice e come un pedante e pignolo per essere sempre di coscienza della sicurezza informatica.

Che cosa succede se mi stava chiamando una funzione in cui gli argomenti versato dai registri nello stack (come è molto comune su, ad esempio, 86)? E se ci fosse in realtà più istruzioni condizionali nelle istruzioni di sét che ha preceduto il salto condizionato (come è comune su, per esempio, le versioni ARM anziani)? Sarei stato in uno stato ancora più incautamente incoerente dopo aver fatto questo semplice-apparente cambiamento!

Quindi questo mio cautelativa richiamo: giocherellando manualmente con i binari è letteralmente strappando via ogni Sicurezza tra voi e ciò che la macchina e il sistema operativo permesso. Letteralmente tutti i progressi che abbiamo fatto nei nostri strumenti ad errori di cattura automaticamente i nostri programmi, andati .

Quindi, come possiamo risolvere questo problema più propriamente? Continuate a leggere.

Rimozione Codice

Per efficace / logicamente "Rimuovi" più di un'istruzione, è possibile sostituire la prima istruzione che si desidera "cancellare" con un salto incondizionato alla prima istruzione a alla fine delle istruzioni "cancellati". Per questo binario ARMv8, che sembrava in questo modo:

     f2c:   14000007    b   f48
     f30:   b0000002    adrp    x2, 1000
     f34:   91128442    add x2, x2, #0x4a1
     f38:   320003e0    orr w0, wzr, #0x1
     f3c:   2a1f03e1    mov w1, wzr
     f40:   aa1503e3    mov x3, x21
     f44:   97fffeeb    bl  af0 <error@plt>
     f48:   f94013f7    ldr x23, [sp, #32]

In sostanza, si "uccidere" il codice (trasformarlo in "codice morto"). Nota a margine: Si può fare qualcosa di simile con le stringhe letterali incorporati nel binario: fino a quando si desidera sostituirlo con una stringa più piccola, è quasi sempre possibile ottenere via con sovrascrivendo la stringa (compreso il byte di terminazione null se si tratta di un "C- stringa ") ed eventualmente sovrascrivendo la dimensione hard-coded della stringa in codice macchina che l'utilizza.

Si può anche sostituire tutte le istruzioni indesiderati senza-ops. In altre parole, siamo in grado di trasformare il codice indesiderato in quello che è chiamato un "no-op SLED":

     f2c:   d503201f    nop
     f30:   d503201f    nop
     f34:   d503201f    nop
     f38:   d503201f    nop
     f3c:   d503201f    nop
     f40:   d503201f    nop
     f44:   d503201f    nop
     f48:   f94013f7    ldr x23, [sp, #32]

Mi aspetterei che che è appena sprecare cicli di CPU rispetto a saltare su di loro, ma è semplice e quindi più sicuro contro gli errori , perché non si deve capire manualmente come codificare l'istruzione di salto tra cui capire l'offset / indirizzo da utilizzare in esso - non c'è bisogno di pensare tanto per una no-op slitta.

Per chiarezza, l'errore è facile: Ho sbagliato due (2) volte quando codifichi manualmente che un'istruzione di salto incondizionato. E non è sempre colpa nostra: la prima volta è stato perché la documentazione che ho avuto è stata superata / sbagliato e ha detto un po 'è stato ignorato nella codifica, quando in realtà non lo era, così ho impostato a zero sul mio primo tentativo

L'aggiunta di codice

potrebbe teoricamente utilizzare questa tecnica per Aggiungi istruzioni macchina troppo, ma è più complesso, e non ho mai dovuto farlo, così non ho un esempio pratico in questo momento.

Dal punto di vista del codice macchina è sorta facile: scegliere un'istruzione nel punto che si desidera aggiungere il codice, e convertirlo in un'istruzione di salto per il nuovo codice che avete bisogno di aggiungere (non dimenticate di aggiungere l'istruzione (s ) si sostituisca pertanto nel nuovo codice, a meno che non hai bisogno di quella per la logica aggiunto, e per tornare indietro alle istruzioni che si desidera tornare alla fine aggiunta). In sostanza, si è "splicing", il nuovo codice in.

Ma bisogna trovare un posto per mettere effettivamente che il nuovo codice, e questa è la parte più difficile.

Se stai davvero fortunati, si può semplicemente aggiungere il nuovo codice macchina alla fine del file, e sarà "solo lavoro": il nuovo codice sarà possibile ottenere caricata insieme alla riposare nelle stesse istruzioni macchina che ci si attende, nel vostro indirizzo di spazio spazio che cade in una pagina di memoria correttamente segnata eseguibile.

Nella mia esperienza hexdump -R ignora non solo la colonna più a destra, ma il più a colonna sinistra troppo -. Così si potrebbe letteralmente appena messo a zero indirizzi per tutte le linee aggiunte manualmente e si metterà a lavorare fuori

Se si è meno fortunato, dopo aver aggiunto il codice che dovrà regolare in realtà alcuni valori di intestazione all'interno dello stesso file: se il caricatore per il sistema operativo si aspetta che il binario di contenere metadati che descrivono la dimensione della sezione eseguibile ( per ragioni storiche, spesso chiamata la sezione "testo") dovrete trovare ed adattare tale. Ai vecchi tempi binari erano solocodice macchina cruda -. al giorno d'oggi il codice macchina è avvolto in una serie di metadati (ad esempio ELF su Linux e alcuni altri)

Se siete ancora un po 'di fortuna, si potrebbe avere qualche posto "morto" nel file che venga caricato correttamente come parte del binario allo stesso offset relativi come il resto del codice che è già nel file (e quel punto morto può andare bene il tuo codice e sia correttamente allineato se la CPU richiede la parola di allineamento per le istruzioni della CPU). Poi si può sovrascrivere.

Se sei veramente sfortunato non si può basta aggiungere il codice e non c'è spazio morto si può riempire con il vostro codice macchina. A quel punto, si deve fondamentalmente essere intimamente familiare con il formato eseguibile e la speranza che si può capire qualcosa all'interno di tali vincoli che è umanamente possibile per tirare fuori manualmente all'interno di un importo ragionevole fo tempo e con una ragionevole possibilità di non scompigliare in su .

Il mio "ci assemblatore disassembler" è l'unico sistema che so è che è stato progettato attorno al principio che qualunque sia il disassemblaggio è, deve riassemblare al byte per byte stesso binario.

https://github.com/albertvanderhorst/ciasdis

Ci sono due esempi Elf-eseguibili con il loro smontaggio e rimontaggio. È stato originariamente progettato per essere in grado di modificare un sistema avvio, consiste di codice, codice interpretato, dati e caratteri grafici, con tali accuratezze come una transizione dal reale al modalità protetta. (E 'riuscito.) Gli esempi dimostrano anche l'estrazione di testo da eseguibili, che viene successivamente utilizzato per etichette. Il pacchetto Debian è destinato per Intel Pentium, ma plug sono disponibili per DEC Alpha, 6809, 8086, ecc.

La qualità del disassemblaggio dipende da quanto sforzo si inserisce in esso. Per esempio, se non hai nemmeno fornire le informazioni che si tratta di un file di elfo, lo smontaggio sono costituiti da singoli byte, e il rimontaggio è banale. Negli esempi che uso uno script che estrae le etichette, e fa per un programma Engineered inverso veramente utilizzabile che è modificabile. È possibile inserire o cancellare qualcosa e le etichette simboliche generate automaticamente otterrà ricalcolato.

No assunto a tutti è fatto circa il blob binario, ma naturalmente un processore Intel smontaggio è di scarsa utilità per un binario DEC Alpha.

miasma

https://github.com/cea-sec/miasm

Questa sembra essere la soluzione concreta più promettenti. Secondo la descrizione del progetto, la lattina libreria:

Apertura / modifica / generare PE / ELF 32/64 LE / BE utilizzando Elfesteem

Assemblaggio / Smontaggio X86 / ARM / MIPS / SH4 / MSP430

Quindi, si deve fondamentalmente:

analizzare l'ELF in una rappresentazione interna (smontaggio)
modificare ciò che si desidera
generare un nuovo ELF (montaggio)

Non credo che genera un testo di smontaggio di rappresentanza, si dovrà probabilmente camminare attraverso strutture dati Python.

TODO trovare un esempio minimo di come fare tutto questo utilizzando la libreria. Un buon punto di partenza sembra essere esempio / DISASM / pieno .py , che analizza un dato file ELF. Lo structurei chiave di livello superiore è Container, che legge il file ELF con Container.from_stream. Todo come rimontarlo dopo? In questo articolo sembra farlo: http://www.miasm.re /blog/2016/03/24/re150_rebuild.html

Questa domanda chiede se ci sono altri tali librerie: https://reverseengineering.stackexchange.com/questions/1843/what-are-the-available-libraries-to-statically-modify-elf-executables

Domande correlate:

Penso che questo problema non è automatizzabile

Credo che il problema generale non è completamente automatizzabili, e la soluzione generale è sostanzialmente equivalente a "come invertire ingegnere" un binario.

Al fine di inserire o rimuovere byte in modo significativo, si dovrebbe assicurare che tutti i possibili salti continuare a saltare nelle stesse posizioni.

In termini formali, abbiamo bisogno di estrarre il grafo di controllo del binario.

Tuttavia, con rami indiretti per esempio, https://en.wikipedia.org/wiki/Indirect_branch , non è facile stabilire che grafico, vedi anche: calcolo destinazione del salto indiretto

Un'altra cosa che potreste essere interessati a fare:

strumentazione binario - modificando il codice esistente

Se interessati, check out: Pin, Valgrind (o progetti di fare questo:. NaCl - Google Native Client, forse QEmu)

È possibile eseguire la supervisione eseguibile sotto di ptrace (in altre parole, un debugger come gdb) e che l'esecuzione modo, il controllo, come si va, senza modificare il file vero e proprio. Naturalmente, richiede i soliti capacità di editing come trovare in cui le istruzioni particolare si vuole influenzare sono nel file eseguibile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow