Newsgroup: it.comp.programmare.win32
Titolo: Eseguire programma ...

Come posso avviare del codice eseguibile nei seguenti  due casi senza
passare da file?
1)Lanciare un eseguibile dove il codice si trova all'interno di un
vettore
esempio:
........
fp=fopen("helloworld.exe","r");
fread(&vettore ,sizeof(unsigned char), 3413,fp);
lancia(vettore);//?????????
2)Lanciare un eseguibile inglobato in un file txt a partire dalla
posizione  24.
Spero di essere stato sufficientemente chiaro, mi date qualche dritta?
Un saluto a tutto il newsgroup.

 vettore
se vuoi caricare il file in memoria ed eseguirlo da lě senza il supporto
del sistema operativo allora non č facile: devi caricare anche tutte le
DLL da cui dipende, bindarlo, ed infine rilocarlo. devi studiare il
formato PE/COFF (specifiche scaricabili in formato doc da MSDN).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 del sistema operativo allora non è facile: devi caricare anche tutte le


 senza passare da file?
[...]
Entrambe le cose che chiedi vanno dall'abbastanza complicato (se si 
tratta di poche istruzioni macchina senza dipendenze esterne) al 
terribilmente incasinato (se si tratta di caricare codice che non 
conosci a priori e che potrebbe avere dipendenze da DLL e altro).
Probabilmente se ci spieghi il problema che pensi di risolvere in quel 
modo qualcuno ti darà una soluzione più semplice.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

Ok, però non mettetevi a ridere :)
Il primo motivo è la curiosità, il secondo è impedire il
"disassembaggio" degli eseguibili creati con .net.
Sono rimasto abbstanza stupito  quando ho provato reflector: dandogli
in pasto un exe creato con .net restituisce il sorgente leggibile e nel
linguaggio voluto!!!
Vorrei quindi creare un exe in c, a questo gli accodo  e codifico l'exe
creato con .net.
Cliccando sull'exe volevo decodificare l'exe .net al volo ed
eseguirlo....cattiva come idea?
Valter Minute ha scritto:


 eseguirlo....cattiva come idea?
Esistono software fatti apposta per oscurare gli eseguibili .net (o 
java, che ha lo stesso "problema"), anche se credo che la pezza sia 
peggio del buco, in quanto, modificando il binario, potrebbero 
introdurre a loro volta errori.
I programmi .net non sono eseguibili nativi e quindi non puoi 
"caricare in memoria il codice ed eseguirlo".
Il codice IL viene tradotto in codice nativo in fase di esecuzione 
(non interpretato) oppure in fase di installazione e fare questo 
dentro un tuo programma vorrebbe dire ricreare il CLR di NET.
Puoi vedere se il CLR consente di "pluggare" dei loader che carichino 
il codice IL da file diversi da .exe e .dll, anche se credo che 
questo sia un potenziale grosso problema di sicurezza (con programmi 
che si scaricano codice da chissà dove).
E, comunque, un "malintenzionato" potrebbe debuggare il CLR e 
scoprire dove viene memorizzato il codice in chiaro e quindi riuscire 
a recuperarlo per poi "disassemblarlo".
Tieni presente che gli offuscatori o il tuo ipotetico "loader" 
complicano il lavoro di chi vuole fare il reverse engineering della 
tua applicazione, ma non lo rendono impossibile e il tempo che spendi 
a implementare queste protezioni è tempo in meno che potrai dedicare 
ad aggiungere funzioni o sistemare bug del tuo software.


 nel linguaggio voluto!!!
Se guardi bene come funziona reflector, bisogna fare i complimenti al suo 
autore che ha reso semplice qualcosa che cosě banale non č. Certamente il 
codice IL lo vedresti comunque senza problemi con ildasm, ma tornare a c# o 
vb.net
  č tutt'altra cosa.
Inoltre tieni conto che anche il codice C e C++sono tutt'altro che a prova 
di bomba. Ci sono disassemblatori che ti riportano un pseudo-listato. Il 
codice C++ č particolarmente intuibile perché i compilatori scrivono codice 
nativo a "pattern" ben riconoscibili e per esempio il "this" viene sempre 
messo dentro lo stesso registro x86.
Quindi concordo che fare il reverse di un assembly sia piů semplice e che 
dia maggiore aderenza all'originale di un compilato nativo, ma non pensare 
neppure che il codice nativo sia tutta sta certezza.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 certezza. 
Inoltre (IMVHO) proteggere il codice dal reverse engineering nella 
gran parte dei casi non ha molto senso. Può aver senso solo se il 
nostro amico ha implementato un algoritmo super complesso e mai 
concepito da altri che rende le prestazioni del suo software diversi 
ordini di grandezza migliori di quelle dei concorrenti (ma allora 
perchè farlo in .NET?).


 "disassembaggio" degli eseguibili creati con .net.
La resitenza è inutile, io citerei... 
-- 
Luc

Alcibiade wrote:
Premesso che non esiste protezione software che possa funzionare al 100%.
|| Come posso avviare del codice eseguibile nei seguenti  due casi senza
|| passare da file?
||
|| 1)Lanciare un eseguibile dove il codice si trova all'interno di un
|| vettore
|| esempio:
||
|| ........
|| fp=fopen("helloworld.exe","r");
|| fread(&vettore ,sizeof(unsigned char), 3413,fp);
|| lancia(vettore);//?????????
Cosi', come ti e' stato detto, risulta essere abbastanza problematico.
Potresti pero' scrivere il tuo vettore in un file temporaneo (con nome e 
estensione di fantasia) e poi eseguirlo con la normale shell.
Terminata l'esecuzione cancelli il file temporaneo e non ne rimane traccia.
|| 2)Lanciare un eseguibile inglobato in un file txt a partire dalla
|| posizione  24.
In modo analogo a prima carichi il tuo file .txt, estrai quello che ti 
interessa, lo scrivi in un file e lo mandi in esecuzione.
Tieni presente che mantenendo il tuo programma in memoria anziche' 
memorizzarlo su un file temporaneo non complica assolutamente la vita a chi 
vuole decompilare il tuo codice, invece di lavorare su un file lavorera' 
direttamente in memoria.
-- 
Guglielmo

 cosa puoi dirmi?
non ho capito che intendi... come fa un file di testo a contenere un
eseguibile nativo di Windows? se lo contiene non è un file di testo...


Guglielmo Calligaro ha scritto:

In effetti questa è stata la prima soluzione semplice che mi è venuta
in mente, però mi sembra un poco sporca: creare l'eseguibile, metterlo
in esecuzione per poi cancellarlo...inoltre alcuni antivirus potrebbero
negare la creazione dell'exe .... comunque da quanto ho capito questa
è l'unica strada(se la volessi intraprendere) .
Sono d'accordo che comunque è possibile risalire al codice , però con
la tecnologia .net mi sembra troppo facile. Ho letto su un sito la
recensione dei vari obfuscator ed il risultato è stato che comunque il
codice era abbstanza leggibile, direi senza paragone rispetto
all'assembler.
Non voglio nascondere un algoritmo prezioso(magari ;) ) però
sinceramente mi scoccia dare il sorgente completo.
Grazie a tutti lo stesso per risposte,
Marco.

Alcibiade wrote:
| Non voglio nascondere un algoritmo prezioso(magari ;) ) però
| sinceramente mi scoccia dare il sorgente completo.
| Grazie a tutti lo stesso per risposte,
Questa e' fonte di perplessita' per moltissimi programmatori che sviluppano 
applicazioni desktop e condividono il tuo fastidio.
Se quello che fai ha poco valore "intellettuale" sara' ben difficile trovare 
qualcuno che abbia voglia di mettersi a decompilare i tuoi programmi, 
cercare di capire come funzionano per poi magari modificarli e ricompilarli.
Forse la concorrenza? O magari il cliente perche' il tuo programma ha delle 
opzioni a pagamento o delle scadenze che se "crakkate" rappresentano un 
danno economico per il tuo lavoro?
Insomma valuta tu quali siano gli effettivi pericoli, le possibilita' sono 
molte e quindi calibra il grado e il tipo di protezione piu' adatto, pur 
essendo pienamente consapevole che sistemi sicuri al 100% non esistono, 
framework o non framework.
-- 
Guglielmo

 perchè farlo in .NET?).
quoto assolutamente.
Se poi hai un algoritmo così prezioso, non regge neppure se scritto in 
codice nativo come i più popolari crack hanno dimostrato negli anni.
Mi sembra che il software stia progressivamente andando verso il servizio. 
Chi ti può dare il miglior servizio e il resto del valore aggiunto se non 
chi l'ha scritto? Quindi pur riuscendo a copiarlo sei sempre azzoppato 
rispetto all'autore originale.
Per i gestionali poi questo discorso è ancora più calzante. Lì conta quasi 
solo il servizio.
