Newsgroup: it.comp.programmare.win32
Titolo: Individuazione memoria allocata

Sto scrivendo un programma di crittografia che gira sotto Win9x. Devo fare
in modo che alcune variabili allocate dal prg non siano rintracciabili
dall'utente o da un hacker che abbia ottenuto l'accesso al computer.
Possedendo soltanto l'eseguibile senza simboli per il debug č possibile
leggere un preciso indirizzo allocato dal programma alla ricerca di dati
"sensibili" (password, chiavi private, ecc.)? Se sě, esiste qualche sistema
in grado almeno di complicare la vita ad un eventuale "curiosone"?
Grazie
Cristiano

in grado almeno di complicare la vita ad un eventuale "curiosone"?
penso che già una sola API possa farti danni.... ReadProcessMemory
conoscendo l'indirizzo dove i tuoi dati stanno memorizzati ed avendo
l'id del tuo processo si può tranquillamente fare ciò che non vuoi...
ma chi ama il reverse engineering troverà 1000 e uno modi per superare
l'ostacolo, strumenti di debugging quali TRW2K, SOFTICE permettono
oggigiorno di fare qualsiasi cosa... di complicare la vita ad un
eventuale curiosone ne esistono migliaia, ma quell'eventuale curiosone
di turno troverà sempre il modo di fregarti.
un suggerimento ? usa tutto ciò che ti sembra opportuno, e magari
escogita altre soluzioni (password crittografate ulteriormente? chiavi
non riferite da nessun puntatore ? a tuo piacimento.....)
cod

 non riferite da nessun puntatore ? a tuo piacimento.....)
In che senso "chiavi non riferite da nessun puntatore"? Non è obbligatorio
allocare in ogni caso la memoria necessaria per le chiavi?
Ciao e grazie
Cristiano

allocare in ogni caso la memoria necessaria per le chiavi?
si é obbligatorio, però se tu consideri che la prima cosa che un
reverser tenta di fare é carpire il funzionamento del programma!
Ora se tu hai una tabella di puntatori, e stabilisci in modo random
qual é l'elemento che deve contenere l'indirizzo reale dell'oggetto
il compilatore genera del codice molto diverso dal solito!
esempio:
char *heap[32];
int i=random(32);
heap[i]=indirizzo_virtuale_della_memoria;
meglio sempre che char *heap=indirizzo_virtuale_della_memoria;
il compilatore deve generare del codice in +, e scendendo a livello
di linguaggio assembly la cosa diventa leggermente differente, a volte
se non si sta attenti il reverser impazzisce...+ accessi inutili, +
manipolazioni delle chiavi lo faranno innervosire... e se si
innervosisce so 2 le possibilità:
1) che é un pivello, e ci rinuncia (ce ne stanno un botto di ragazzini
che vogliono fare i fighetti facendo i cracker, ma davanti alle
difficoltà mollano!)
2) che é un tizio coi contro*..............* e troverà + divertente
smontare il tuo programma :)
considera inoltre che oramai i compilatori tendono a generare
codice + o - ripetitivo, e quindi il tuo codice dovrà rinunciare allo
stile, usare forme non facilmente tollerabili per il linguaggio in cui
programmi......
cod

 computer.
In generale e` un errore mantenere in memoria delle chiavi di accesso per
piu` del tempo necessario. Quando hai usato le chiavi, azzera la memoria che
le conteneva e poi deallocala.
---
Bye! Lorenzo Lutti
http://antani.virtualave.net/

 [...]
L'esempio è interessante ma la sicurezza di un programma di crittografia
deve essere valutata supponendo che il nostro avversario sappia esattamente
cosa fa il programma perché come tu stesso dici "quell'eventuale curiosone
di turno troverà sempre il modo di fregarti.", per cui ha poco senso
escogitare tanti stratagemmi. Bisogna considerare anche il fatto che io non
userei mai un programma fatto da un altro senza sapere per filo e per segno
come fa a cifrare un file (chi mi assicura che viene tutto fatto a regola
d'arte?), un tipico esempio sono le API crittografiche di windows: chiunque
s'interessa anche solo un po' di crittografia nemmeno si sogna di usarle
visto che la documentazione riguardante gli algoritmi sembrerebbe
inesistente.
Speravo solo di poter disporre di memoria inaccessibile ad altri programmi;
comunque farò delle prove per verificare l'effettiva accessibilità della
memoria.
Grazie per l'aiuto
Cristiano

"Lorenzo Lutti" <lorenz...@DOHtiscalinet.it> ha scritto nel messaggio
news:7%uR6.33$ZZ....@news.infostrada.it...

Sě, questa č la prassi ma la chiave di sessione (o i suoi derivati) deve
essere tenuta in memoria per tutta la durata della cifratura o decifratura,
per cui avendo a che fare con file di alcuni mega "il curiosone" avrebbe
tutto il tempo di trovare la chiave.
Cristiano

 memoria.
Ho fatto le prove che dicevo; purtroppo la memoria è sempre accessibile,
indipendentemente dalla funzione usata per allocarla :-((
Però non ho capito come si fa ad enumerare i processi.
Cristiano

memoria.
a mio avviso e' tempo perso: non e' possibile. e' sufficiente iniettare una dll
all'interno del tuo codice e aggirare eventuali protezioni da processi esterni
(cmq non attuabili anche li')... il tutto supponendo che l'acero (^^) abbia i
tuoi stessi privilegi sulla macchina... anche PGP, per citare un esempio, ha dei
seri problemi a difendere la memoria che mantiene le chiavi di sessione: magari
prova a dare uno sguardo al codice dei pgp open source per vedere come
affrontano il problema.
di sicuro qualche "trappolina" scoraggia curiosoni va inserita, ma devi essere
al corrente che non serve a molto, in quanto aggirabile (prima o poi).
saluti,
Francesco Picasso
http://francesco.netsigners.com

Però non ho capito come si fa ad enumerare i processi.
immagino che l'indisponibilità della memoria ad altri processi
si riferisse al fatto che il memory manager bloccasse le pagine
rendendole indisponibili ad altri processi, ma cmq dall'interno
del tuo processo o da altri processi l'accesso é sempre garantito,
tanto tu giri a ring3, gli altri processi a ring3, risultato quel che
sai
auguri
cod