 |
- Spaghetti Hacker : questo è un blog personale di studio e approfondimento di tematiche acare; una spaghettata acara, aglio, olio, pepperoncino e tanto reverse engineering, memory corruption, binary exploitation, malware analysis, digital forensics, sintesi del suono e tutto ciò che riguarda il mondo low level.
- bz, hcf, akira basho, radical edward, peperu, dr. akira pepper, yt rabbz, bpa : hacker artist, reverse engineer, battle programmer, malware & cybersecurity analyst
-
PTRACE ELF INFECTOR - Dr. Pepper
log.02e
;black box reverse engineering di un eseguibile ELF che attraverso la syscall ptrace va ad attaccarsi ad un processo in esecuzione per iniettare nello spazio di memoria di quest'ultimo una shellcode e poi eseguirla.
;la chiamata di sistema ptrace consente a un processo di eseguire il debug di un altro processo. utilizzando ptrace saremo in grado di interrompere l'esecuzione di un processo target ed esaminare i valori dei suoi registri e della memoria, nonché modificarli in qualsiasi valore desideriamo.
;il codice va ad iniettare la shellcode nella posizione dell'instruction pointer (registro rip le architetture x86_64) del processo a cui si è attaccato e di cui ottiene il controllo. la shellcode avvia una sessione di shell, e non restituire il controllo al processo originale.
;in linux esiste una protezione: per utilizzare questo eseguibile su un processo in running bisogna prima settare:
;echo 0 > /proc/sys/kernel/yama/ptrace_scope
;0 permessi ptrace classici. nessuna restrizione aggiuntiva sulle operazioni eseguite. l'utilizzo di PTRACE_TRACEME è invariato.
;1 ptrace limitato [valore predefinito]. quando si esegue un'operazione che richiede un ATTACH, il processo chiamante deve avere una relazione predefinita con il processo target. la relazione predefinita è che il processo target deve essere figlio del chiamante.;arg uint32_t argc @ rdi
;arg char **argv @ rsi
;var int64_t canary @ rbp-0x8
;var void *var_60h @ rbp-0x60
;var void*data @ rbp-0xe0
;var pid_t pid @ rbp-0xe4
;var uint32_t var_f4h @ rbp-0xf4
;var char **str @ rbp-0x100
0x000012cf endbr64
0x000012d3 push rbp
0x000012d4 mov rbp, rsp
0x000012d7 sub rsp, 0x100
0x000012de mov dword [var_f4h], edi ;argc
0x000012e4 mov qword [str], rsi ;argv
0x000012eb mov rax, qword fs:[0x28]
0x000012f4 mov qword [canary], rax
0x000012f8 xor eax, eax
0x000012fa cmp dword [var_f4h], 2
0x00001301 je 0x1332
;prologo della main, alloca spazio sullo stack e setta il canarino, poi controlla se sono stati passati due parametri, in caso continua, altrimenti stampa una stringa di Usage e poi esce. -
KEYGEN ME - Dr. Pepper
log.02d
0x00400186 push rbp
0x00400187 mov rbp, rsp
0x0040018a mov eax, 1
0x0040018f mov edi, 1
0x00400194 movabs rsi, str.____x64_NASM_Keygen_Me_n_A__root_me____n____Login_:_____Key_:__n_o___Yeah__good_jwrite_a_keygen_:__n_n_...__THE_GAME_n.m.key ; section..data:
; 0x4000b0 ; "[!] x64 NASM Keygen-Me\n[A] root-me \n[?] Login : [\o/] Yeah, good job bro, now write a keygen \n\n[.|..] THE GAME\n.m.key"
0x0040019e mov edx, 0x32 ; '2' ; 50
0x004001a3 syscall
;eax uguale a 1, la syscall chiamata è la write che stampa la stringa
;"[!] x64 NASM Keygen-Me\n[A] root-me \n[?] Login : [\o/] Yeah, good job bro, now write a keygen \n\n[.|..] THE GAME\n.m.key".0x004001a5 mov eax, 0
0x004001aa mov edi, 0
0x004001af movabs rsi, segment.LOAD1 ; 0x600260
0x004001b9 mov edx, 0x20 ; 32
0x004001be syscall
;in questo caso la syscall chiamata è la read, che legge dallo standard input 32 caratteri e li va a memorizzare nel segmento di memoria puntato da rsi, segment.LOAD1 che si trova all'indirizzo 0x600260; movabs carica una costante arbitraria a 64 bit nel registro. -
FLOODER ELF - Dr. Pepper
log.02c
;md5 86ef3c8d5eda4ababf2c8961d1e7d27d
;sha1 f04ccfd5b73fe03c23c7625a2a67cbc1f277ac3a
;sha256 d16e852f979d3c7f97e74b39c8901a64b40647504ff1e9cd41f88f0405c0d3e0
;os linux
;format ELF
;arch amd64
;path d16e852f979d3c7f97e74b39c8901a64b40647504ff1e9cd41f88f0405c0d3e0
;black box reverse engineering di un malware ELF.
;il malware ELF in esame, come scopriremo, è un flooder, che prende 4 parametri in ingresso, ossia l'IP del server vittima, la porta UDP, il throttle che determina quanti thread simultanei di flooding creare, e il time, che va a determinare il tempo delle fasi di sleep dei singoli thread. -
radare2, Analisi Statica - dr. pepper
log.02bAnalisi Statica e Comandi Generici?: mostra l'help, può essere usato dopo un comando qualsiasi, esempio : dc?
?*...: tutti i comandi
s: stampa l'indirizzo corrente
s addr/funzione: si posiziona all'indirizzo o alla funzione specificati
pdf: disassembla la funzione corrente
pdfs: disassembla la funzione corrente e produce un sommario
ie: mostra gli entry point possibili
iS: lista delle sezioni
aa/aaa/aaaa: analizza le funzioni con diversi livelli di dettaglio
afl: lista le funzioni (ha bisogno che venga prima eseguito il comando aa)
iz/izz: lista delle stringhe nelle sezioni dati (la sezione .rodata per esempio) e nell'intero binario rispettivamente (izz produce molto rumore)
ii: lista delle funzioni importate dalle librerie
is: lista dei simboli
/, /w, /w, /a: cerca una stringa specifica, una wide string, stringa esadecimale, espressione regolare, assembly opcode, rispettivamente
dr: mostra i registri e il loro contenuto o lo modifica
px o pd: stampa hexdump o disassembla, rispettivamente, per esempio pd 5 @eip stampa 5 linee di disassemblato a partire dal program counter corrente
Visula Mode?: help
V: entra in modalità visuale
!: Panel mode
p/P: passa avanti e indietro tra i diversi print mode (hex, disasm, debug..)
/: evidenzia visivamente uno specifico valore
:: permette di inserire uno specifico comando
1-9: segue le call o le jmp con i corrispondenti shortcut number in un commento
.: si posiziona sul program counter corrente (istruzione corrente)
c: abilita e disabilita il cursor mode, che permette una navigazione più dettagliata. Nel debug print mode è possibile muovere il cursore tra le finestre usando il tasto Tab
o: cambia la visualizzazione dell'assembler
g: cerca per uno specifico offset
u/U: cancella la ricerca o cerca di nuovo
b: mostra un menù con tutta una serie di entries tipo funzioni, simboli, commenti, xrefs, flags e ti permette di visualizzare le informazioni in base all'entry scelta
Edited by AKIRA BASHO - 29/12/2023, 19:29 -
SPAGHETTI HACKER - Bz Akira Santjago
log.02a
mashup: bz akira santjago
music: fitz & the tantrums
Edited by AKIRA BASHO - 2/1/2024, 21:15 -
LAZY BINDING - bash
log.019
;il lazy binding nei binari ELF di Linux è implementato con l'aiuto di due sezioni speciali, chiamate Procedure Linkage Table (.plt) e Global Offset Table (.got).
;i binari linkati staticamente sono indipendenti (autonomi), poiché portano in sé tutte le funzioni richieste. Per essere più precisi, quando un codice sorgente viene compilato, impacchetta al suo interno qualsiasi funzione di libreria richiesta dall'eseguibile, durante la fase di linking. Ciò significa anche che il binario è ben consapevole di dove sono memorizzate le funzioni (indirizzi e offset).
;un binario linkato dinamicamente è l'opposto, in quanto non impacchetta la libreria condivisa al suo interno; quando viene eseguito un binario linkato dinamicamente, nella memoria viene caricato anche un linker/loader dinamico, che aiuta a risolvere la funzione della libreria linkata; ciò è necessario in quanto l'indirizzo della libreria condivisa è sconosciuto e può variare a causa di vari fattori; uno dei fattori può essere che, se il codice della libreria viene aggiornato, ci sia una modifica dell'indirizzo; un altro esempio può essere un meccanismo di protezione come l'ASLR, che randomizza l'indirizzo delle librerie condivise, senza lasciare al binario alcun indizio sulla loro posizione; GOT e PLT entrano in gioco quando si esegue un binario linkato dinamicamente.
;Il lazy binding è abilitato/disabilitato dall'opzione -z del linker, ld.
;lazy
;dice al linker dinamico di posticipare la risoluzione dell'indirizzo della funzione al momento in cui la funzione viene chiamata (lazy binding), anziché al momento del loading.
;now
;dice al linker dinamico di risolvere tutti i simboli all'avvio del programma o quando la libreria condivisa è linkata all'utilizzo di dlopen(), invece di rimandare la risoluzione dell'indirizzo della funzione nel momento in cui la funzione viene chiamata la prima volta.
;il now binding è l'impostazione predefinita per ragioni di sicurezza; si usa l'opzione -W del gcc per passare l'opzione -z al linker ld.gcc -Wl,-zlazy -o plt1 plt1.c
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
puts("Hello world");
puts("Hello world");
exit(0);
} -
MOVAPS ISSUE - bash
log.018
;movaps attiva un errore di protezione generale quando opera su dati non allineati
;in questa CTF andiamo a sovrascrivere, con un buffer overflow, dopo una gets, l'indirizzo di ritorno della funzione main, con l'indirizzo della funzione easy al cui interno troviamo una system che stampa la flag contenuta nel file flag.txt[0x0040061d]> pdf
;var char *s @ rbp-0x40
;var char *ptr @ rbp-0x800x0040061d push rbp
0x0040061e mov rbp, rsp
0x00400621 add rsp, 0xffffffffffffff80
0x00400625 mov edx, 0xa ;size_t nbytes
0x0040062a mov esi, str._Warm_Up__n ;0x400741 ; "-Warm Up-\n" ; const char *ptr
0x0040062f mov edi, 1 ;int fd
0x00400634 call sym.imp.write ;ssize_t write(int fd, const char *ptr, size_t nbytes) -
BPA ELF Infector - bash
log.017
;BPAinfector.asm
;fasm BPAinfector.asm
;il BPA ELF infector si basa sulla ben nota tecnica di infezione PT_NOTE -> PT_LOAD e funziona sia sui binari regolari che sui PIE; questo metodo ha un alto tasso di successo ed è facile da implementare (e rilevare).
;il BPA ELF infector è una rielaborazione del virus Midrashim; ho reversato e modificato il virus Midrashim unicamente per imparare come funziona questa tecnica, essendo interessato a tutto quello che concerne il Reverse Engineering e la Malware Analysis -
WE BELEAF - bash
log.016
Arch: amd64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled[0x000008a1]> pdf
;arg int argc @ rdi
;arg char **argv @ rsi
;var int64_t canary @ rbp-0x8
;var char *s @ rbp-0x90
;var uint32_t var_98h @ rbp-0x98
;var size_t var_a0h @ rbp-0xa0
;var int64_t var_a8h @ rbp-0xa8
;var int64_t var_b4h @ rbp-0xb4
;var char **var_c0h @ rbp-0xc0
0x000008a1 push rbp
0x000008a2 mov rbp, rsp
0x000008a5 sub rsp, 0xc0
0x000008ac mov dword [var_b4h], edi ;argc
0x000008b2 mov qword [var_c0h], rsi ;argv
0x000008b9 mov rax, qword fs:[0x28]
0x000008c2 mov qword [canary], rax
;inizializzazione stack frame e stack canary
-
ELF MALWARE3 - BASH
0x00400078 mov edi, 0x6e301cbd
0x0040007d fcmovnu st(0), st(4)
0x0040007f fnstenv [rsp - 0xc]
0x00400083 pop rdx
0x00400084 sub ecx, ecx ; arg4
0x00400086 mov cl, 0x21 ; '!' ; 33
0x00400088 sub edx, 0xfffffffc
0x0040008b xor dword [rdx + 0x10], edi
0x00400091 pop rdi
0x00400092 jmp 0x78a0600f
;il malware si comporta in maniera del tutto simile all'elf malware2 analizzato nel post procedente; la cosa particolare di questo malware risiede nel fatto che staticamente non può essere analizzato; abbiamo solo un piccolo pezzettino di codice dopo il quale sia radare2 sia ghidra vedono badcode senza alcun significato; ma analizzando con il debugger di radare2, passo dopo passo, si può notare come il malware va a riscriversi partendo dall'indirizzo di memoria 0x00400091;
Reply
Create your blog! · Create your forum! · Top Blog · Categories · Help ·
Status · Contacts · Powered by BlogFree
