Newsgroup: it.comp.aiuto
Titolo: Come si crakka???

Vorrei sapere come si fa a crakkare un gioco.
Vi prego č importante!
Grazie per chiunque risponda
Leo

 ha scritto nel messaggio
news:886egn$45l$1...@nslave2.tin.it...

WWW.astalavista.com

Vorrei sapere come si fa a crakkare un gioco.
Si studia come matti e si imparano i linguaggi di programmazione.
--
Saluti.
Fabrizio

 Si studia come matti e si imparano i linguaggi di programmazione.
Non esageriamo! si studia come matti e si impara un linguaggio di
programmazione: l'Assembly!
--
Marco "DUFF" Palermo
Marc...@Hotmail.com
http://web.tiscalinet.it/THE_DUFF/index.html

programmazione: l'Assembly!
Poi ci si procura la struttura degli eseguibili dos e windows e si
impara a usare un buon debugger ;)
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

Ma non costa meno rogna, tempo e soldi comperarselo originale il programma?
Davide

Ma non costa meno rogna, tempo e soldi comperarselo originale il programma?
Certo ;)


programmazione: l'Assembly!
Non credo che sapere l'assembly basti per crackare, anzi sarebbe piu'
produttivo conoscere poco l'assembly, ma meglio un altro linguaggio di
alto livello.
 再  见
Zai Jian
        Sephiroth
___________________________________
E-Mail: 
seph...@libero.it
IGZ: Sephiroth_88, WHD_SEPHIROTH
IRC: Sephiroth, Gotenks
ICQ: 20857755
===================================
                 === No War  No Cry ===
                 ===================

Certo ;)
Si, ma....
1) Una volta imparato a crackare puoi crackare tanti programmi e ti
sei imparato un sacco di nozioni sul pc.
2) Ma vuoi mettere la soddisfazione nel riuscire a crackare un
programma?!!?


 Davide
Ah, ma quello è ovvio!
P.S.
Sono d'accordo che costa meno rogna e tempo, ma con i soldi...


 alto livello.
Sicuramente è più produttivo conoscere un linguaggio di alto livello, ma per
craccare bisogna conoscere SOLO l'assembly!
Anche perché i compilatori (C++, Pascal, Visual Basic, ecc...) non fanno
altro che "tradurre" quello che scrivi in Assembly!
Vuoi craccare qualche cosa? O assembly o ti cerchi la crack via internet!
--
Marco "DUFF" Palermo
Marc...@Hotmail.com
http://www.marcoduff.cjb.net/

Vuoi craccare qualche cosa? O assembly o ti cerchi la crack via internet!
Imparare SOLO l'assembly per crackare i programmi e' come andare da
milano a roma in bicicletta......prima o poi ci arrivi ma mi sembra
una pazzia!
S'intende IMHO
 ÔÙ  ¼û


 S'intende IMHO
Programmare in Assembly sarebbe come fare Milano Roma in bici ma non
craccare.
Ok, accetto il tuo punto di vista, ma quello che ancora non capisco e dove
vuoi mettere la conoscenza di un linguaggio di alto livello. Una fatto un
programma il codice del compilatore si perde, o meglio, si trasforma in
assembly e si stacca totalmente dal compilatore.
Se io ti presento un programma e ti chiedo come l'ho fatto, nessuno
scienziato di questa terra me lo potrà dire: il modo di compilare del Turbo
Pascal e del Basic (ti sto facendo un esempio banalissimo) è totalmente
diverso, ma una volta che si fa il make del file exe il programma potrebbe
uscire totalmente identico!
Per craccare serve soltanto: un debugger, un disassembler e un editor
esadecimale.
Con il debugger monitoriamo cosa fa il programma (vediamo il codice
Assembly)
Con il disassembler vediamo le varie procedure e funzioni scritte con un
linguaggio di alto livello ma adesso visibili soltanto in Assembly)
Con l'editor patchamo il programma.


 registrazione o ti fa partire il controllo del CD.


programma?!!?
Discutibile !, parlo dal punto di vista del programmatore... ;)


altro che "tradurre" quello che scrivi in Assembly!
In codice macchina per la precisione (l'Assembly e' un linguaggio di
astrazione simbolica). Ed e' abbastanza difficile districarsi tra il
codice macchina visto che i compilatori compiono delle ottimizzazioni
non indifferenti ! ;)


"punti deboli".
La differenza di cui non tieni conto e' che quando si scrive un
programma si compie il processo contrario a quello del cracking.
Cioe' si parte da un algoritmo e si codifica in linguaggio ad alto
livello, poi si compila e si ottiene il codice macchina.
Nel caso del cracking, non ha molta utilita' conoscere un linguaggio
ad alto livello, se non quello implementato con un particolare
compilatore e del quale si conosce il modo in cui traduce il codice
simbolico in codice macchina. In questo caso si potrebbe ricostruire
una funzione ad alto livello, partendo dalle microistruzioni a basso
livello, ma e' quasi sempre impossibile. Il cracker, di solito, ha
solo bisogno di individuare la porzione di codice del programma che
esegue i controlli necessari ad autenticare l'uso del programma,
sostituendo tutta quella porzione con un bel salto incondizionato.
Per questo scopo gli basta conoscere solo l'assembly e studiare il
codice passo per passo.
Esempio pratico :
se l'algoritmo che esegue il programma e' il seguente :
1. chiedi inserimento password
2. password corretta ? si' : salta a 3.
3. esci.
4. ok, continua esecuzione.
5. ...
6. ...
Il cracker si limita a modificare il programma nel modo seguente :
1. salta a 4.
2. password corretta ? si' : salta a 3 altrimenti continua.
3. esci.
4. ok, continua esecuzione.
5. ...
6. ...
In questo modo, tutta la parte di verifica e autenticazione viene
scavalcata.


linguaggio di alto livello ma adesso visibili soltanto in Assembly)
Aspetta, pero', i disassemblatori restituiscono quasi sempre il codice
Assembly dal compilato. Incorporano cioe' una funzione dei debugger.
E' impossibile ottenere il codice sorgente da un programma compilato,
in quanto la trasformazione e' irreversibile.
E anche nel caso in cui si riuscisse a compiere un disassemblaggio a
livello di codice sorgente, le informazioni ottenute sarebbero
talmente prive di significato, da vanificare questa operazione.


facilmente a distinguere un eseguibile VB da uno TP o C o Delphi.
Non e' detto.



http://web.tiscalinet.it/THE_DUFF/index.html
	Caro Marco
Finche' se ne parla al bar ,come di calcio, si puo' 
raccontare  tutto,ma ...hai mai provato a capire
un programma debuggando l'eseguibile ???
Di programmi in assembly ne ho fatti tanti, ma
quando ho provato a modificare programmi fatti
da altri....... !!!!
Se tieni poi conto che l'assembly che trovi e'
in effetti la traduzione di linguaggi ad alto livello,
con tutte le istruzioni in piu' che si portano dietro,
se non sei un hacher finito, meglio perdere ore
cercando in rete il crack giusto.
		Ciao Giorgio
 
miosito    
http://www.infinito.it/utenti/gmontag/miahome.html

 talmente prive di significato, da vanificare questa operazione.
In più c'è da aggiungere che gli stessi programmatori dopo aver finito il
codice, al contrario di ogni buon studente, ricopiano l'elaborato in una
brutta copia tale da rendere il codice difficile da interpretare anche da
altri programmatori che in qualche modo riescano a mettere le mani sul
codice sorgente.
--
Marco "DUFF" Palermo
Marc...@Hotmail.com
http://www.marcoduff.cjb.net/

 6. ...
In questo caso l'haker non deve fare nulla: se la password è giusta esci,
mentre se è sbagliata il programma va avanti! : )


codice sorgente.
;) diciamo che quasi sempre il programmatore crede di potersi
ricordare tutto cio' che il suo programma fa. Non e' quasi mai cosi' !
;) La manutenzione del codice occupa piu' del 70% del lifetime di un
programma ed e' la cosa piu' pallosa in assoluto ! ;) 


mentre se č sbagliata il programma va avanti! : )
Temo d'aver sbagliato l'algoritmo, il punto 2 e' 
2. password corretta ? si' : salta a 4.


uscire totalmente identico!
Si ma la stragrande maggioranza dei casi non e' cosi!!
Quello che hai detto vale per programmi veramente minuscoli


Discutibile !, parlo dal punto di vista del programmatore... ;)
Haha, dal punto di vista del programmatore del software?
Sarebbe una frustrazione....
 再  见


facilmente a distinguere un eseguibile VB da uno TP o C o Delphi.
Si, anche se non facilmente, bensi' con un esame approfondito, e'
possibile risalire al compilatore e in certi pochi casi anche alla
versione del compilatore.


 2. password corretta ? si' : salta a 4.
Ora è tutto ok! : )


scavalcata.
Come detto sopra: il sistema e' piu' complesso.


 Quello che hai detto vale per programmi veramente minuscoli
Hai pienamente ragione, infatti io mi stavo riferendo a programmi minuscoli.
Era ovvio che chi ha originariamente scritto questo messaggio non conosceva
ne i metodi di cracking ne compilatori, quindi non sono voluto entrare
troppo nel dettaglio tentando di fargli capire la sostanza!
E' ovvio che un programmatore fa molti controlli prima  di accettare una
password, quindi devono essere molte le modifiche da fare nel codice del
programma.
Per quando riguarda la compilazione che poi fa il compilatore non sono molto
d'accordo con te.
Ok, guardando un programma (si codice assembly che il programma in se) si
può intuire quale è stato il compilatore che lo ha generato, ma se io ti
presento due programmi, uno fatto con il Turbo Pascal e uno fatto in Basic,
sei sicuro al 100% che riesci a risalire al compilatore?


codice creato da un altro compilatore.
Aspetta, pero'. Bisogna distinguere tra codice creato dal compilatore
e codice "linkato" dalle librerie. Non credo sia possibile distinguere
il codice creato da un compilatore basic o C, mentre e' possibile
distinguere il codice appartenente alle loro librerie. 
Ovviamente tutto questo e' mooolto difficile da farsi.


quanto riguarda le limitazioni.
Ovvio che il mio era solo un esempio di possibile applicazione.
Lo so anche io che nella realta' le cose sono differenti, ma il
concetto era esemplificato volutamente, per far capire che non e'
necessario andarsi a scorgere tutte le istruzioni del programma, basta
individuare il punto giusto.


 sei sicuro al 100% che riesci a risalire al compilatore?
Penso proprio di si e ti faccio un esempio riportando una parte dei messaggi
che si trovano in fondo ad un eseguibile compilato in QuickBasic e visibili
con un editor esadecimale:
Errore di sintassi   RETURN senza GOSUB   Istruzioni DATA esaurite
  Chiamata di funzione non lecita .
Penso che non ci siano dubbi che si tratta di basic.
Editando invece un exe compilato in VB 1.0 si trova dopo pochi byte la
scritta :
VBRUN100 .
Editando ancora un prog. compilato in Delphi di può leggere dopo qualche
migliaio di byte la scritta: SOFTWARE\Borland\Delphi
Editando infine un prog. di cui non conosco la provenienza trovo:
fclose  ö fopen û fread   fwrite  - malloc  : printf  . Penso di non
sbagliare di molto se affermo che si tratta di C (con quanti + non lo so).
Qundi se non dalla struttura del programma (cosa che richiede un
disassemblatore e tanta esperienza) mi sembra abbastanza facile distinguere
certe categorie di compilatori.
--
AndreaP

sbagliare di molto se affermo che si tratta di C (con quanti + non lo so).
Infatti, tra l'altro il C non e' molto difficile da riconoscere, in
quanto spesso i messaggi del programma, ad esempio "Impossibile
trovare il file ..." compaiono nel codice eseguibile con gli
specificatori, ad esempio "Impossibile trovare il file %s".


con le patatine crik-crok

 certe categorie di compilatori.
Hai ragione, non ci avevo mai provato!
Caspiterina, questi programmatori devono lasciare la loro firma ovunque!!!
: )
