Newsgroup: it.comp.programmare.win32
Titolo: Ottimizzazioni con dev-cpp e tecniche anti-disassemblaggio

Ciao a tutti, stavo iniziando a creare un programmino in C come 
passatempo dopo aver imparato i principali rudimenti del C in un corso 
dove non si è parlato di ottimizzazione del codice in fase di 
compilazione (non so nulla a riguardo).
Usando il dev-cpp come ambiente C, come devo settare le ottimizzazioni? 
Ho visto che stanno sotto "copiler options/settings" e sono:
-------------
Perform a number of minor optimizations Y/N
Further optimizations/Optimize Y/N
Further optimizations/Optimize more Y/N
Further optimizations/Best Optimization Y/N
-------------
Cosa mi consigliate di fare: metterle tutte su "Yes" o fare 
diversamente? Conviene attivarle solo nell'ultima compilazione quando si 
ha il codice definitivo o anche nelle versioni intermedie del programma?
Esiste poi un metodo per rendere più difficile da disassemblare 
l'eseguibile che si crea? Intendo dire: è possibile creare il file .exe 
(passando al compilatore appositi parametri o tramite l'uso di un 
qualche programma apposito) del mio programma in modo tale che sia molto 
più difficile, con le tecniche opportune, risalire al codice sorgente?
   grazie anticipatamente per le risposte, rz
-- 
                                   /TIDIRYUM - Ferrara - ITALY\
                                   \ICQ#    13901251   !!bye!!/
//°Orgoglioso fondatore di free.it.hobby.freccette-darts°\\

 più difficile, con le tecniche opportune, risalire al codice sorgente?
Trucchi ce ne sono, ma perlopiù sono accessibili a chi
programma in assembler, oppure son il risultato dell'uso
sugli eseguibili finali di appositi programmi che introducono
combinazioni di istruzioni tali da confondere un eventuale
debugger/disassembler. In linea generale però, un cracker
esperto riesce a venirne comunque a capo. Direi che se il
tuo programma è molto specialistico e può suscitare solo
l'interesse di una cerchia ristretta puoi stare traquillo,
se invece stai creando qualcosa di interessante per il
grande pubblico... presto o tardi te lo disassemblano,
trucchi o non trucchi :-)

 l'eseguibile che si crea? Intendo dire: è possibile creare il file .exe
Puoi utilizzare dei compressori/offuscatori di .EXE come UPX o Molebox.
Tieni presente però che per ognuno di essi esiste un decodificatore. Alcuni
permettono di assegnare una chiave di codifica.
A livello di codice in sé, intanto puoi rendere più difficoltoso studiare il
disassemblato. Inserisci del codice che non fa nulla, però fa perdere tempo.
Inizializza variabili che servono a una funzione, dentro a un'altra...
utilizza la stessa chiamata (con parametri differenti) per svolgere due
compiti completamente diversi. Dagli dentro di Goto !!! Usa un thread che
magari non fa nulla. Per un semplice controllo a=b , fai controllare bit per
bit facendo rimbalzare il codice a destra e a manca. Non scrivere mai
stringhe in chiaro. Se c'è una chiave da potreggere, mettila in posti
inusuali e poi magari crea un file RegisterKey.pak dentro Windows che però
non serve a niente. Crea una funzione con qualche ciclo for e poi riempila
di NOP con un disassemblatore (molti penseranno che lì ci andrà del codice
automodificante). Non scrivere mai e=15 , ma crea un vettore e scrivi
e=v[1]+2 con v[1]=13 . Crea codice automodificante (non facile però).
Ovviamente più il codice è "incasinato" e più difficile è da seguire in
assembly disassemblato (chiaramente questo ferma gli hacker meno bravi).
Puoi inoltre controllare quanti programmi sono lanciati quando il tuo
programma gira e verificare che non ci siano applicazioni come RegMon,
FileMon, etc... Ci sono anche sistemi per rilevare SoftIce, cerca in rete.
Ad ogni modo, la protezione al 100% non esiste, però puoi fermare una grande
fetta dei meno bravi.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 e=v[1]+2 con v[1]=13 . Crea codice automodificante (non facile però).
In un ambiente multitask non si può usare codice
automodificante. Il sistema operativo non te lo
permette, tutte le sezioni di memoria che contengono
codice sono a sola lettura. E' il motivo per cui il
vecchio DOS non poteva girare in modo protetto ma
doveva restare in modo reale: perchè conteneva
codice automodificante...
E i GOTO non offuscano un tubo, in assembler :-)

 E i GOTO non offuscano un tubo, in assembler :-)
Essere troppo categorici è sintomo di poca propensione a imparare cose
nuove. Hai mai provato a leggere un disassemblato? Seguire già 9/10 JMP
sparsi qua e là che vanno avanti e indietro e che magari escono da una
condizione o un ciclo annidato (quindi già pieno di JMP) per ritornarci in
seguito dopo aver modificato quella variabile globale del ciclo che quindi
va considerata diversamente, etc.. etc.. con tanto di considerazione delle
modifiche sullo stack (già leggere l'offeset del jump in esadecimale è super
noioso). Quindi i GOTO offuscano non solo i tubi, ma anche la voglia
dell'hacker. :-)Come dicevo, non si ha la sicurezza al 100%, ma almeno la
soddisfazione di far stare dietro al tuo codice diverse ore in più e magari
di scoraggiare i meno bravi. Del resto, è una battaglia persa in partenza..
e quello che si può fare è questo.
Ah, dimenticavo.. un'altra avvertenza è anche quella di mettere qualche
stringa che possa sembrare codice, tipo che ne so "FF105E" .. ciò potrebbe
far sbagliare qualche disassemblatore.


 più difficile, con le tecniche opportune, risalire al codice sorgente?
Se ti basta un "livello normale" di difficolta:
1) guarda la documentazione di strip.exe per capire come togliere
    dall'eseguire tutte le informazioni non necessarie (che potrebbero venir
    sfruttate in disassemblaggio per rendere piu comprensibile il
    disassemblato);
2) compila con il maggior numero di ottimizzazioni attivate
    (NON TUTTE, alcune e' meglio tenerle disattivare, ma la cosa
     varia da applicazione ad applicazione e da compilatore
     a compilatore)
    in questo modo il codice disassemblato e' meno "regolare"
    ed il valore "finale" di una variabile sta piu a lungo
    nei registri interni della cpu oppure esiste in piu copie
    (valore precedente su un registro, valore successivo in un
     altro) rendendo piu complessa la comprensione di
    cosa-fa-cosa-ed-a-che-serve;
3) dove puoi usa librerie statiche ricompilate con le stesse
    opzioni dell'applicazione (es: se usi wxWindows non usarlo
    come DLL ma compila tutto insieme all'applicazione)
    e strippa tutto (con strip.exe o con opzioni passate al
    linker) in modo tale da ottenere una mole enorme
    di roba da disassemblare e con poche informazioni "utili".
In genere comunque se l'applicazione e' "banale" uno te la puo
replicare anche senza disassemblare, se invece e' abbastanza complessa
di solito non servono particolari precauzioni, visto che
basta la complessita intrinseca del codice a proteggerti.
L. Micheletto

 contengono codice sono a sola lettura
guarda, te l'ho già spiegato: quegli articoli sui sistemi operativi che 
a te piacciono tanto parlano di *System V Release 4*, 1985 o giù di lì. 
Non funziona più così. In Windows non ha *mai* funzionato così
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 Non funziona più così. In Windows non ha *mai* funzionato così
Vuoi dire che in Winzozz è possibile scrivere nelle proprie aree di
codice? Ma allora mi sorge un dubbio: supponiamo che uno stesso programma,
che è un programma automodificante, venga avviato due volte; il SO sarà
costretto a caricare due copie diverse del codice, perché le due copie
sono separate e se una modifica se stessa non deve modificare anche
l'altra, giusto? Se sì, non sarebbe più intelligente impedire ai programmi
di automodificarsi, in modo tale da poter caricare una sola copia del
segmento CODE? Come mai Windows permette ai programmi di automodificarsi???
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Come mai Windows permette ai programmi di automodificarsi??? 
perchè sì


 Non funziona più così. In Windows non ha *mai* funzionato così
Con il service pack 2 di WinXP dovrebbero venir introdotte delle ulteriori
restrizioni riguardo l'esecuzione di codice piazzato sullo stack
e riguardo la modifica di dati nelle sezioni contenenti codice
ma se non erro saranno opzioni disabilitabili proprio perche in passato
ci si potevano prendere maggiori liberta a riguardo
[in passato persino la GDI di Windows 3.1 "compilava sullo stack"
  alcune funzioni di bitblitting quando usava schede video
  senza accelerazione hardware].
L. Micheletto

 stack e riguardo la modifica di dati nelle sezioni contenenti codice
sai dirmi qualcosa di più specifico?


 
Cerca su 
www.theinquirer.net
 l'articolo
"Windows as an incendiary device" (10 o 11 dicembre) oppure
(piu direttamente) cerca sul sito di MSDN:
"Windows XP Service Pack 2: A Developer's View
  Draft Version for PDC 2003" (ottobre 2003).
Li trovi tutti i dettagli, inclusa la "Execution protection"
(NX, ovvero "no execute") che opera a livello di pagine
di memoria virtuale ed impedisce l'esecuzione su heap e stack.
In particolare la parte che sinteticamente riassume la cosa e':
Table 1. User-Mode Execution Protection (32-bit OS)
Memory Region Type                          Is Region Executable?
                                             SP2              Windows XP
System-Wide Execution Protection Enabled?   Yes              No
Stack                                       No               Yes
Heap                                        By default, No   Yes
Se DOPO  aver installato il SP2 di WinXP non si settano correttamente
i privilegi di esecuzione delle varie applicazioni, si avranno
eccezioni STATUS_ACCESS_VIOLATION (0xC0000005) con tutta la roba
che usa codice compilato just in time oppure che
"si auto ottimizza" al caricamento.
Uhm! Sono io che sono paranoico oppure c'e' da aspettarsi
qualche problema *specialmente* con roba scritta in Java
che usa JVM non-Microsoft ?
L. Micheletto