Domanda Risolto Reversing Lottare con i Nanomites su Linux

evilddd

Utente Bronze
5 Gennaio 2014
21
4
3
43
Ciao a tutti,
scrivo su questo forum sperando che qualcuno possa darmi un suggerimento. Prima o poi quando si lotta con i Nanomites ci si fa la bua, il mio è uno di questi casi.

Per chi non conoscesse il tema, brevemente e grossolanamente, si tratta una tecnica per complicare l'analisi tramite un processo "tracciante" (consentitemi il termine) che si aggancia ad un altro processo (o ad esempio forka). Il processo sotto debug (con cattiveria) utilizza degli INT3 per sollevare eccezioni cattuare dal padre che si occupa di gestirle e, nel caso di un crackme, per esempio ricevere dei dati dal figlio ed elaborarli per complicare l'analisi.

Sto sbattendo da diversi giorni la testa su un crackme ELF64 che crea una miriade di processi figli (fork) che, gerarchicamente, si debuggano a scala fino all'ultimo figlio, che debugga, a sua volta, il primo padre della gerarchia, creando una sorta di catena. Tutto funziona tramite ptrace usando PTRACE_SEIZE.

Il Crackme è complesso, uno dei più complessi che io abbia mai cercato di risolvere. L'esecuzione è spezzattata sui diversi figli e l'algoritmo di verifica delle chiavi è complesso e ancora non sono riuscito a ricostruirlo e comprenderlo del tutto, complice il fatto che ogni maledetto figlio solleva INT3 al suo paparino, che a sua volta solleva un'eccezione al suo paparino e così via... Risultato? Ad un certo punto si perde consapevolezza di cosa stia succedendo...

Ovviamente non vi chiedo di risolverlo al posto mio, prima o poi ci devo riuscire! :)
Vi siete mai cimentati in qualcosa di simile? Se sì, ve ne siete cavati? Qualche suggerimento? Conoscete qualche tool o qualche tecnica che possa essere d'aiuto in un simile scenario? (Tenete presente che sono su Linux).

Grazie ;)
 
Non ho mai visto un crackme con questa tecnica, comunque ne avevo sentito parlare anche perche' la catena di debug su linux confonde solo le acque ma su Windows ha l'effetto di impedire l'attach da altri debugger in usermode (windows supporta 1 debugger alla volta per processo).
Quello che ti suggerirei e' vedere dove mette le informazioni da passare al parent prima dell'int3 (ad esempio l'indirizzo che usa per PTRACE_PEEKDATA), poi mettere li' un breakpoint e con uno script vedere nel tempo cosa viene passato e da chi per avere una visione piu' del complesso.
 
Grazie mille per il suggerimento. Il punto (i diversi punti in realtà) in cui vegono scambiati i dati tra i figli e i padri li ho beccati ma non riesco, nonostante i Breakpoint, a capire su quale dei maledetti processi padre arrivino i dati. Le sto provando tutte ed ho fatto un bel po' di passi avanti confronto a ieri. Ho in parte ricostruito l'algoritmo. Mi manca da capire bene le relazioni tra i diversi processi forkati e una volte capito il meccanismo potrei avrei risolto... E' dura ragazzi... E' veramente dura...
 
Vi siete mai cimentati in qualcosa di simile? Se sì, ve ne siete cavati? Qualche suggerimento? Conoscete qualche tool o qualche tecnica che possa essere d'aiuto in un simile scenario? (Tenete presente che sono su Linux).

Per chi è della vecchia scuola come me è impossibile non esserci mai incappati visto che era una tecnica usata da un packer chiamato Armadillo, che ai tempi era uno dei più utilizzati. Forse potresti trovare qualche vecchio paper che ne parla.
Se i nanomites sono molti comunque, quasi sicuramente devi mettere in piedi un "sistema" automatico di qualche tipo. Ad esempio, nel caso di armadillo si lanciava una routine di analisi che trovava tutti gli int3 nel codice, provava a gestirli e da quello salvava in una nuova sezione la porzione di codice risultante, a cui poi saltare quando il file era unpacked, per poi ovviamente risaltare e continuare il normale flusso del programma.
Si trattava di un solo figlio in quel caso, ma con molti figli il metodo è sempre lo stesso, cioè arrivare a lavorare con un solo processo.
 
Se i nanomites sono molti comunque, quasi sicuramente devi mettere in piedi un "sistema" automatico di qualche tipo. Ad esempio, nel caso di armadillo si lanciava una routine di analisi che trovava tutti gli int3 nel codice, provava a gestirli e da quello salvava in una nuova sezione la porzione di codice risultante, a cui poi saltare quando il file era unpacked, per poi ovviamente risaltare e continuare il normale flusso del programma.

Grazie per la risposta Evo. In effetti ho continuato con l'analisi e di nanomites ce ne stanno una valanga, di cui un buon 99% nella routine di Handling. L'approccio che mi dici è sicuramente uno di quelli che adotterei ma purtroppo il crackme usa i dati di ogni singolo processo forkato (Variabili globali e locali) nel calcolo del seriale corretto, complicando le cose. Ho capito bene o male il funzionamento generale e mi sento nella giusta direzione verso soluzione, ho preferito riscrivere il codice appoggiandomi a Ghidra. Devo capire bene l'algoritmo per scrivere un keygen o comunque ricavare a manella un seriale valido.

Grazie comunque ad entrambi per i suggerimenti! ;)
Spero di farcela, vi farò sapere!