Mentre guardo un sacco di tutorial, leggi le risposte e, in generale, interagisco con la comunità di sicurezza IT, trovo che un'alta percentuale di loro conosce l'assemblaggio. Mi chiedo perché questa percentuale è molto più alta che altrove e perché è così importante saperlo?
* Nota a margine - Immagino che sia molto difficile capire cosa sta succedendo durante la lettura di questi. Spostare la variabile intorno e tale non sembra dare un'idea di cosa sta succedendo.
Ti consente di capire cosa sta accadendo al livello più basso possibile del sistema operativo. In secondo luogo ti permette di cambiare codice a livello di byte, il che significa che hai molto controllo sul codice. Questo è, ad esempio, necessario quando si sfruttano buffer o overflow dello stack. Quando si effettuano entrambi gli attacchi, si inietta essenzialmente il codice byte direttamente nella memoria e lo si esegue. Mentre è possibile generarlo tecnicamente con un'altra lingua, spesso non è ottimale e molto più voluminoso di quando lo si scrive in un'altra lingua. Spesso ciò che accade è che prima scrivi l'exploit in c e poi generi l'assembly dal tuo programma c. Questo è chiamato prototipazione. Da qui puoi ottimizzare il codice e rimuovere caratteri indesiderati come 0x00 byte (spesso usati come delimitatori).
Inoltre, se hai un programma che devi analizzare ma non hai il codice sorgente, dovrai spesso decompilarlo. Il risultato della de compilation è il montaggio.
Penso che la maggior parte dei professionisti della sicurezza abbia una mentalità perché mentre altri professionisti IT a volte non si preoccupano finché funziona. Assemblea ti consente di esplorare il perché al livello più basso possibile. Questo è anche un motivo per cui molti professionisti della sicurezza amano conoscere l'assembly.
Si noti inoltre che ci sono programmi per aiutarti a capire l'assembly decompilato identificando e visualizzandone le chiamate di sistema (dai un'occhiata al mio blog c'è un passaggio attraverso l'analisi del codice shell).
È il livello successivo tra 1 e 0 e più in basso puoi andare, più software puoi sovvertire. La maggior parte degli exploit sono scritti in assembly.
Per favore qualcuno mi corregga se sbaglio su questo, ma da quello che capisco. Hai linguaggi di scripting (javascript, python) al livello più alto che sono facili da scrivere ed eseguire ma non hanno accesso diretto al sistema operativo, quindi ci sono linguaggi intermedi (Java, .NET) che compilano il codice in una lingua intermedia quando quel codice viene eseguito è appena in tempo compilato per la macchina, quindi hai le lingue che compilano per la macchina su cui sono in esecuzione come C / C ++. Con C / C ++ è possibile eseguire molte più operazioni "Bare Metal", quindi in C / C ++ l'assemblaggio è così semplice quanto altro che scrivere 1 e 0. HTH
Tutti i linguaggi del computer sono essenzialmente istruzioni per una (o più di una) CPU, sotto forma di "fai questo. Ora fai così". Quindi sempre "scendere all'assemblaggio" prima o poi. I linguaggi di alto livello sono framework (scaffold?) Per evitare lunghe ripetizioni del codice assembly e consentire la programmazione in un modo più intuitivo; questo guadagno in termini di comprensibilità, flessibilità e manutenibilità ha un prezzo - in termini di dimensioni, prestazioni e requisiti.
Quando riesci a ottenere il controllo del processo di applicazione, qualunque sia il mezzo (overflow del buffer, ecc.), in pratica hai solo un'area di memoria in cui puoi inserire ciò che vuoi, e questo è per lo più indipendente su come hai ottenuto a questo punto.
Ora, per uno, l'assembly ha la più alta "densità" di istruzioni sulla dimensione del codice, almeno per le piccole dimensioni del codice, quindi è naturalmente la tua prima scelta se vuoi stipare il massimo nell'area che hai appena "conquistato" .
In secondo luogo, e probabilmente più importante, quando irrompi in un'area di memoria, conosci poco o nulla del "contesto" - non hai hai una configurazione del contesto . Ad esempio, in linguaggio C, la tua funzione main() è in effetti una funzione - ottiene chiamato dal runtime C, che ha già preparato un ambiente per l'esecuzione del programma in, una sorta di sistema di supporto vitale per il tuo codice. Con uno shellcode, non hai questo tipo di supporto e devi essere in grado di fare a meno (cioè assemblare) o crearne uno nuovo (di nuovo in assembly, dal momento che il codice di costruzione del supporto vitale non può aver bisogno di un supporto vitale stesso) .
Quindi in teoria, potresti preparare uno "stub runtime di shellcode" inizializzando un ambiente e "collegando" il tuo codice C al sistema. Una volta ottenuto ciò, è possibile semplicemente allegare un codice shell C al runtime ed essere in grado di riferire le funzioni del sistema operativo per nome. Diversi shellcode hanno uno stub per farlo, ma di solito è scritto in Assembly perché la ragione numero uno continua a essere valida: lo spazio è prezioso.
Gli exploit che consentono l'esecuzione di un binario indipendente (nella forma più elementare e banale, un allegato eseguibile a un'e-mail su cui la vittima farà clic) hanno restrizioni di dimensioni ridotte e (solitamente) nessun requisito di runtime, quindi hanno bisogno di no, e per scopi di manutenzione non lo sono quasi mai, scritti in linguaggi di basso livello.
Leggi altre domande sui tag assembly