anti-API monitor: si può?

[71104]

non so se avete presente quei programmi tipo APIMon del PSDK di Microsoft, che servono a loggare tutte le chiamate API effettuate da un programma monitorato; quei programmi si basano sulla tecnica dei trampolines, che trovate egregiamente implementata nelle librerie Detours di Microsoft Research (una delle poche cose che zio Bill ci concede gratis), oppure su una tecnica simile ma più semplice che consiste nel piazzare/rimuovere dinamicamente il JMP incondizionato all'inizio del codice target secondo le necessità (ora scusate se non entro molto in dettaglio, ma l'ora... ); entrambe le tecniche hanno pro e contro e si possono usare a seconda delle necessità.

ora mi chiedevo se fosse possibile realizzare un sistema che impedisse il monitoraggio delle chiamate a una certa funzione, partendo dal presupposto che un ipotetico monitor abbia installato una istruzione JMP near assoluta ai primi 5 bytes del codice della funzione monitorata.

l'idea che avevo avuto io si basa sul fatto che le API di Windows, che come convenzione di chiamata usano una macro definita come __stdcall, iniziano tutte con gli stessi primi 3 bytes:

PUSH EBP
MOV EBP,ESP

di conseguenza avevo pensato di realizzare un stub contenente queste due istruzioni che poi chiamasse l'indirizzo effettivo della funzione più 3; in tal modo se è stato installato un JMP, la CPU eseguirà il codice disallineato saltando a metà del JMP: in alcuni casi semplicemente i 2 bytes rimanenti salteranno e la CPU riprenderà la normale esecuzione (il log non avverrà), mentre in altri la CPU eseguirà codice senza senso che probabilmente prima o poi manderà il processo in crash. se invece il JMP non è stato installato, la funzione viene eseguita normalmente.

esiti di questo genere a me andrebbero benissimo, potrei dire di aver ideato il mio sistema "anti - API monitor", ma ho un banale problema di implementazione C: io avevo dichiarato lo stub come segue:

typedef DWORD (WINAPI *APIFUNC)();

__declspec(naked) DWORD WINAPI Stub(APIFUNC pfn) {
	__asm {
		pop eax
		add eax,3
		push ebp
		mov ebp,esp
		jmp eax
	}
}

in tal modo basta chiamare la funzione API di turno non direttamente, bensì tramite la funzione Stub; l'indirizzo effettivo della API come vedete viene passato come argomento a Stub (quindi viene spinto nello stack, ma poi viene subito rimosso; non badate per ora al fatto che lo stub è un po' pesante, credo si possa ottimizzare, era solo una cosa temporanea).

fin qui ok, ma il problema sorge proprio quando devo chiamare lo stub; come faccio banalmente in C a fare il push dei parametri della funzione API? in un primo momento mi era venuto spontaneo di scrivere erroneamente così:

Stub(GetMessage(&msg, NULL, 0, 0));  // esempio di chiamata a GetMessage

che però ovviamente non va bene; io dovrei fare in modo che il compilatore generi nell'ordine:
- i push dei parametri della funzione API
- il push dell'indirizzo finale della API (e questo mi crea un altro problema meno banale che espongo di seguito)
- il call allo stub piuttosto che alla API

il problema meno banale di cui sopra è che l'indirizzo che il compilatore usa per generare il CALL alla funzione API non sempre corrisponde all'indirizzo effettivo dell'inizio del codice della funzione, anzi, non ci corrisponde quasi mai: nella maggior parte dei casi i compilatori (non chiedetemi perché, perché non l'ho mai capito) generano un CALL ad una entry in una tabella di JMP che a loro volta rimandano alle rispettive "funzioni target"; quindi al problema della chiamata della funzione API aggiungiamoci anche il fatto che dovrei fare questa "indirezione" per così dire...

anybody got some good idea?

buona notte

[71104]

Originariamente inviato da 71104

[...] partendo dal presupposto che un ipotetico monitor abbia installato una istruzione JMP near assoluta ai primi 5 bytes del codice della funzione monitorata. [...]

chiedo venia: qui temo di aver detto una cosa errata; riconsultando il reference mi accorgo che il JMP near assoluto esiste solo in forma indiretta... le Detours usano la versione near relative, che inizia con 0xE9 e infatti è la versione che meglio si adatta allo scopo discusso nel topic.

[71104]

up!

non dovrò mica uppare per tutta la settimana...?

[cionci]

Se stub fosse una funzione a parametri variabili (attenzione che dovresti descrivere anche i parametri)...potresti passare i parametri direttamente a Stub e fare il push dei parametri all'interno di Stub... Un po' come si fa con la printf...

[71104]

ci avevo pensato, ma mi sa che se uso l'ellissi il compilatore mi costringe a usare __cdecl come convenzione di chiamata per Stub...
a me serve necessariamente __stdcall, cioè mi serve la stessa della funzione da chiamare, altrimenti poi quando la funzione fa il suo RET mi ripulisce lo stack, dopodiché quando esco da Stub il caller tenta di fare un'altra pulizia...

[71104]

ultimi aggiornamenti: se uso l'ellissi posso anche specificare __stcall come convenzione, ma il compilatore ignora e usa __cdecl.
inoltre il codice dello stub era errato; questo sarebbe quello giusto:

__declspec(naked) DWORD WINAPI Stub(APIFUNC pfn) {
	__asm {
		pop ecx
		pop eax
		push ecx
		add eax,5
		mov eax,eax
		push ebp
		mov ebp,esp
		jmp eax
	}
}

mi ero dimenticato che quando entro in Stub la prima cosa che trovo nello stack non è il primo parametro, è l'indirizzo di ritorno...
inoltre ho scoperto che per qualche oscuro motivo le funzioni API non iniziano con il push di ebp, ma con una inutilissima mov eax,eax... di conseguenza il codice che posso skippare viene portato a 5 bytes, e questa cosa mi cade a pennello perché così salto l'intero jmp ad una ipotetica routine di intercettazione
il codice viene eseguito normalmente e il log non avviene

sarebbe bello trovare una soluzione al mio problema: avrei progettato un anti-API monitor niente male (nessuno mi sa aiutare? )

dovrei solo avere l'accortezza di usare lo stub solo per le API che effettivamente iniziano con quei 5 bytes: penso che siano la maggior parte, ma se così non fosse posso sempre creare un altro stub, o altri 2.

[71104]

hmmm... forse ci sono: si tratterebbe di una soluzione che va bene solo nel mio caso, ma che risolverebbe contemporaneamente entrambi i miei problemi.
va bene solo nel mio caso perché la soluzione va applicata prima della rilocazione del modulo su cui sto lavorando, e non sono sicuro che possa funzionare, ma proverò e tra qualche gg farò sapere.

nel frattempo se avete altre idee proponete plz thx

[71104]

niente da fare, quello che avevo pensato non si può fare.
il fatto è che una soluzione potrebbe essere quella di utilizzare lo Stub con un cast, ma vorrei evitare di fare un cast per ogni funzione API che uso
mi serve una soluzione più comoda

[71104]

ehm, ma perché in questo thread parlo solo io?
forse il primo post era troppo lungo da leggere?

comunque stavolta penso di aver realmente trovato la soluzione; prima provo ad applicarla e poi la posto, per chi interessasse (pochini vedo... )

[cdimauro]

Io ti leggo con interesse, anche se personalmente non perderei tempo su queste cose...

[71104]

Originariamente inviato da cdimauro

Io ti leggo con interesse, anche se personalmente non perderei tempo su queste cose...

O_______________________O la trovi una perdita di tempo?????????
non andiamo affatto d'accordo allora!!!
a me questa cosa piace un sacco e tante altre simili anche

[cdimauro]

Una protezione, per quanto ben congegnata, prima o poi verrà scardinata.

A meno di roba come Palladium, ma in questo caso non avresti comunque bisogno di proteggere il tuo software...

[VICIUS]

Originariamente inviato da cdimauro

Una protezione, per quanto ben congegnata, prima o poi verrà scardinata.

A meno di roba come Palladium, ma in questo caso non avresti comunque bisogno di proteggere il tuo software...

Sono d'accordo. Che senso ha cercare di nascondere ste cose? Ho ti vergogni di quello che hai scritto, oppure sei un fan della filosofia "security through obscurity".

ciao

[cdimauro]

Non vedo cosa ci sia di male in questa "filosofia": io la apprezzo particolarmente, specialmente in certi contesti.

[VICIUS]

Originariamente inviato da cdimauro

Non vedo cosa ci sia di male in questa "filosofia": io la apprezzo particolarmente, specialmente in certi contesti.

<ot>Trovo quella "filosofia" sbagliata. Non mi piace nascondere il codice tutto qui. Trovo inutile perdere tempo a criptare codice o perdere la testa per impedire ad altri di sapere quali funzioni sto usando attraverso strani macchinamenti partoriti durante una notte di luna piena con uno strano allineamento dei pianeti.</ot>

ciao

[71104]

Originariamente inviato da cdimauro

Una protezione, per quanto ben congegnata, prima o poi verrà scardinata.

ci sono protezioni estremamente difficili da "scardinare": lo puoi fare solo se sai come fare. certo, alla fine si tratta solo di un discorso relativo: lo scopo non è quello di creare una protezione "incrakkabile", ma il più possibile difficile da crakkare. e con quella che sto congegnando io ti ci voglio...

[71104]

Originariamente inviato da VICIUS

Sono d'accordo. Che senso ha cercare di nascondere ste cose? Ho ti vergogni di quello che hai scritto, oppure sei un fan della filosofia "security through obscurity".

ne' l'uno ne' l'altro: sto semplicemente programmando uno spyware
e non mi venire a dire che allora è la prima: sono fierissimo del software che sto scrivendo!!!
mi affascinano molto le problematiche che sto affrontando e sono molto appassionato al lato tecnico del mio lavoro

[71104]

Originariamente inviato da VICIUS

<ot>Trovo quella "filosofia" sbagliata. Non mi piace nascondere il codice tutto qui. Trovo inutile perdere tempo a criptare codice o perdere la testa per impedire ad altri di sapere quali funzioni sto usando attraverso strani macchinamenti partoriti durante una notte di luna piena con uno strano allineamento dei pianeti.</ot>

be', arriverà anche per te il giorno in cui gradirai di essere pagato per il lavoro che fai: se mai programmerai un tool che desidererai proteggere e rendere closed e magari shareware, avrai la necessità di creare la classica versione limitata che si blocchi dopo N giorni.

dicono che in questi casi il modo migliore di agire non sia quello di bloccare dopo N giorni, ma di togliere del tutto il codice per abilitare determinate funzionalità; non credere che questo rappresenti un problema per un vero cracker: non ci si mette nulla a creare un crack che, una volta avviato il tuo programma ed entratoci con la solita CreateRemoteThread, risponda al comando Save nel quale con una compilazione condizionale tu avevi disabilitato la finestrella "Save as...".

ancora potresti rispondermi che l'autore potrebbe togliere non semplicemente la visualizzazione della finestra, ma l'intero codice per il salvataggio, o di qualche altra funzionalità: nei casi in cui la quantità di codice che il cracker deve "reinserire" diventi eccessiva, si può fare in due modi:
1) il cracker "reinventa" il codice (nel caso del comando Save inventa un suo formato; nel caso specifico questo implica che debba essere riprogrammato anche il comando Open e simili); oppure, soluzione spesso più semplice:
2) il cracker preleva il codice mancante da una versione completa del software.

in poche parole quello che voglio dire è che un cracker si può trovare di fronte a problemi più difficili, come ad es. il non conoscere l'esistenza di un simpatico stub che impedisce il monitoraggio dele chiamate API
esistono anche cose più perfide: tempo fa mi è stata insegnata una tecnica interessante che devo ancora capire bene a fondo: la perturbazione dello stack; ti dico solo che rende semplicemente impossibile il debugging del programma in ring 3...

[VICIUS]

Originariamente inviato da 71104

be', arriverà anche per te il giorno in cui gradirai di essere pagato per il lavoro che fai: se mai programmerai un tool che desidererai proteggere e rendere closed e magari shareware, avrai la necessità di creare la classica versione limitata che si blocchi dopo N giorni.

In genere tendo a farmi pagare in base alle ore che ho impiegato per sviluppare. Ho sempre fornito anche i codici sorgenti a prodotto finito. Fino ad ora praticamente tutti hanno deciso di richiamare me ogni volta che volevano una modifica al programma. pagandomi. Se avessi venduto licenze sarei morto di fame da un bel pezzo.

ciao

[71104]

Originariamente inviato da VICIUS

In genere tendo a farmi pagare in base alle ore che ho impiegato per sviluppare. Ho sempre fornito anche i codici sorgenti a prodotto finito. Fino ad ora praticamente tutti hanno deciso di richiamare me ogni volta che volevano una modifica al programma. pagandomi. Se avessi venduto licenze sarei morto di fame da un bel pezzo.

oè! guarda che gli shareware non sono mica una mia invenzione, eh...