La guida per gli aspiranti crackers

…………………………

The Xoanon’s Guide to Cracking

…………………………

Aspirante guida per gli aspiranti crackers

……………………………………

LE INFORMAZIONI CHE TROVATE ALL’INTERNO DI QUESTO FILE SONO PER PURO SCOPO

DIDATTICO. L’AUTORE NON INCORAGGIA CHI VOLESSE SERVIRSENE PER SCOPI ILLEGALI.

INOLTRE, NON MI ASSUMO NESSUNA RESPONSABILITA’ SE VI DISTRUGGETE I PROGRAMMI.

UPDATE 10/4/97 PART 1:

CAUSA UN MONGOLOIDE CHE SI ERA SCANDALIZZATO PER IL CONTENUTO PRETTAMENTE

OFFENSIVO E PERICOLOSO DI QUESTO SIMPATICO MANUALETTO, IL PRESENTE NON

APPARIRA’ PIU’ SU SCREAM (ALMENO NELLE VERSIONI .EXE). QUINDI, SE LO

TROVATE SUL PROSSIMO NUMERO DI “SYSTEM DOWN”, VUOL DIRE CHE NON L’HO SCRITTO

PER NULLA…..

UPDATE 10/4/97 PART 2:

.DOS4GW CRACKING *REVEALED* … VEDERE A QUESTA SEZIONE

.PICCOLE AGGIUNTE ALLA PARTE WINDOWS

UPDATE 18/4/97

.DOS4GW .ALTRI TRUCCHETTI.

—————————————————————————–

INTRODUZIONE: SCREAM SUPPORTA LA PIRATERIA. SUPPORTATE SCREAM! (SCHERZO EH?!)

—————————————————————————–

Dunque dunque dunque….. era tanto che pensavo di scrivere un qualcosa del

genere, e ora finalmente (grazie a SCREAM) ne ho la possibilità.

Sinceramente, quando ho chiesto a Swan se potevo collaborare scrivendo un

manuale di cracking, pensavo che mi avrebbe immediatamente kickato fuori dal

canale (eravamo su IRC)…… ma fortunatamente ciò non è avvenuto, anzi…..

Quindi eccomi qua !!! Premetto che di tutorial come questo, su internet, se

ne trovano a bizzeffe (io si può dire che ho imparato leggendo quelli), tutti

però con un basilare difetto: sono in INGLESE! Anche se ormai quasi tutti

conoscono questa lingua, penso che una versione italiana non dispiaccia a

nessuno. Naturalmente, sempre che questa mia versione venga su decentemente..

… Speriamo bene! (sento già che scriverò una caterva di stronzate… Bah…)

Accendiamoci una sigaretta…… via, si parte!

Il manuale è strutturato in 4 parti, trattanti i seguenti argomenti:

1) NOZIONI GENERALI E USO DEL DEBUGGER

2) DOS, DOS EXTENDERS (DOS4GW e simili)

3) WINDOWS 3.1/95/NT

4) Appendice: Patchers,TSR,Trainers

In ognuna di queste, cercherò di spiegarvi le tecniche da usare nei vari tipi

di sprotezione, nei limiti delle mie possibilità. Per semplificare le cose non

sarò troppo specifico, e tenterò di rendere il tutto capibile anche da chi di

assembler non ci capisce un accidente (io stesso non è che sia una cima nel

campo!). L’importante infatti è sapere il significato di una manciata di

istruzioni, oltre alle funzioni di alcuni dei registri AX,DX,CX,ecc…

Per ogni sezione ci sarà una guida passo passo nella sprotezione di un

programma (gioco o utility) in maniera da rendere le cose più chiare.

—————————————————————————–

CAPITOLO 1: NOZIONI GENERALI E USO DEL DEBUGGER

—————————————————————————–

Dunque, innanzitutto partiamo con le 3 doti principali dell’aspirante (e anche

del provetto) cracker:

1) Conoscenza media dell’assembler, in particolare le funzioni di JMP (nelle

sue varie forme), MOV, CALL e CMP (il vostro intervento sui programmi

“vittima” si risolverà nel 99% dei casi nella disattivazione/modifica di

queste funzioni) e della funzione dei registri principali della CPU.

2) Conoscenza dell’uso delle funzioni del debugger (SOFTICE,GAMETOOLS,

WATCOM,ecc.) necessarie alla sprotezione (STEP,TRACE,come si settano e

cosa sono i BREAKPOINT; di solito queste 3 funzioni sono le principali

che userete, il resto è utile ma non indispensabile).

3) Una dose spropositata di CULO sapientemente miscelata con intuito.

Difatti, molte volte il crack avviene per caso, magari NOPPANDO (poi vi

spiego) un’istruzione che apparentemente non c’entra nulla, oppure

forzando un JMP proprio quando si pensa che non serva a niente.

Quindi, se siete iellati tipo Paperino, meglio lasciar perdere

(scherzo eh?!)

1.1……..MINI CORSO CRACKING-ORIENTED DI ASSEMBLER (ORA SI RIDE!)

Partiamo con la parte sull’assembler. Premetto che all’inizio avevo in mente

di fare solo un breve excursus (senti vi’ che paroloni!), ma ciò penso che vi

avrebbe lasciato con parecchi punti interrogativi. Quindi, per evitare di

essere sommerso da e-mail sull’argomento (che se il server-administrator me

le becca, probabilmente mi manda alle Sughere, rinomato carcere livornese) ho

pensato di farmi dare una mano da MoonShadow (lui parla in assembler!)…

quindi, se un giorno andrete in galera per aver formato un cracking-group dopo

esservi esaltati a leggere questo manualino, ringraziate anche lui!

Allora…iniziamo con il funzionamento dei registri principali:

[AX]…. registro accumulatore, utilizzato per le operazioni matematiche e di

I/O. Tutto passa da questo registro, le funzioni di COMPARE (CMP) di solito

avvengono confrontando un valore inserito da voi (es. un numero del serial

number, una lettera della password, il numero riferito ad una icona da

scegliere) con quello contenuto in AH, AL o in tutto il registro

(non è però una regola generale, voglio dire cioè che questi valori possono

essere anche contenuti in un’altro registro, es.BX, però nel 99% dei casi è

così).

Questo valore è qui precedentemente mosso dalla routine che vi trasferisce

uno ad uno i valori (naturalmente, in HEX o in DEC) della password o del

serial number.

[BX]…. Viene utilizzato di solito come base o puntatore ad una locazione.

[CX]…. Il contatore. Viene usato per i loops (cicli) e viene decrementato

o incrementato secondo le esigenze. Di solito contiene un numero (ad es. il

numero delle volte che potete provare ad inserire la password prima che il

tutto si blocchi) che viene poi decrementato (con l’istruzione DEC CX oppure

SUB CX,AX) ogni volta che sbagliate. Utile in questo caso eliminare queste

istruzioni per poter lavorare con più tranquillità.

[DX]…. Funzioni simili a BX.

Da notare che ognuno di questi registri può essere suddiviso ulteriormente in

2 parti, ossia parte alta (es. AH,BH,ecc.) e parte bassa (AL,BL,ecc.). Quindi

in questa maniera ogni “parte” del registro può contenere un valore da 00 a

FF (mentre il registro “intero” contiene valori da 0000 a FFFF). Facciamo un

esempio: se muoviamo un valore in AX (MOV AX, 01AFh), il registro AL conterrà

il valore AFh ed il registro AH conterrà invece 01h. Tutto qua!

Ora, i segment-registers:

[CS]…. Il code-segment, cioè l’area di memoria nella quale si trova il

codice del programma che state sodomizzando. L’indirizzo CS:IP serve ad

identificare proprio l’istruzione che state per eseguire.

[DS]…. Data-segment, l’area di memoria alla quale la CPU accede in lettura.

i dati.

[ES]…. Extra-segment, altra area di memoria alla quale la CPU accede, ma

questa volta in scrittura. In pratica, la CPU legge da DS:SI e và a scrivere

il byte (o la word) letta in ES:SI.

[IP]….. Istruction Pointer. Cos’è? Semplice, l’indirizzo dell’istruzione

che state per eseguire nel code segment attuale. Io di solito, durante il

crakkaggio nel debugger, modifico questo registro invece del jump, in maniera

da non danneggiare per il momento il programma. Ma è solo una mia abitudine…

[SS]…. Stack-segment, area di memoria di “parcheggio” nella quale la CPU

tiene nota di tutti i return-address dalle subroutines. Usando l’istruzione

PUSH o POP, lo stack viene riempito o svuotato (questa ci stà che sia una

stronzata, comunque se non è proprio così la funzione di queste istruzioni è

simile….. chiederò a MoonShadow!).

Altri registri, ma questi li potete anche tralasciare, sono:

[SI]….. Source-index, usato insieme all’istruzione MOV. E’ un puntatore

all’interno di un segment (di solito DS) che viene letto dalla CPU.

[DI]….. Destination-index, anche questo usato insieme a MOV. E’ un puntatore

all’interno di un segment (di solito ES) dove la CPU và a scrivere. Andando

a vedere all’indirizzo ES:DI, se vedete che ci viene mosso qualcosa, potreste

anche capitare in locazioni interessanti… (potreste trovarci addirittura la

password che cercate…. boh, voi provate!)

[BP]….. Base-pointer, usato insieme allo Stack-segment.

[SP]….. Stack-pointer, altro pointer usato insieme allo Stack-segment

Una particolare nota merita il seguente registro:

[FLAG].. Nel vostro debugger, vedrete (di solito in cima) un’insieme di

lettere maiuscole e minuscole (oppure illuminate o no, oppure con sotto dei

numeri 0 e 1). Questi sono i flag, che servono ad indicare se un particolare

jump deve avvenire o no. Logicamente, flag=0=spento flag=1=acceso.

Agevoliamo un esempio (Agevoliamo TM of Enzino Iachetti)

CMP AL,2A……… confronta il valore di AL con 2A.

Il risultato è un cambiamento dello stato del flag

Z. Cioè, se è vero il flag viene attivato (1) sennò

viene disattivato (0).

JZ 8EDF……….. salta -SE- il flag Z=1 (quindi se AL=2A)

Comunque, io di solito non li guardo mai,anche perch‚ tutti i debugger

(di solito) ti dicono con una freccetta se il jump avviene o no….. ma è

una mia abitudine.

Piaciuti i registri? Ganzi eh? (comunque non preoccupatevi, si può crakkare

bene anche senza conoscerli molto… io stesso di solito, a meno che il

programma non sia una brutta bestia, non li guardo nemmeno….. poi vi spiego)

Ora, qualcosa sulle istruzioni (altra sigaretta…. Ulp! Le ho quasi finite!)

[MOV]….. E’ un’istruzione le cui funzioni sono fondamentali nel cracking.

Difatti, molte volte vi ritroverete a dover magari muovere un valore giusto

in una locazione semplicemente cambiando un CMP in un MOV (poi vi spiego….

non temete). La sua sintassi è: MOV [destination],[source]

es 1. MOV AX,BX ———-> muove il valore di BX in AX

es 2. MOV CX,[0400] ———-> muove i due bytes contenuti all’indirizzo

specificato (DS:0400) in CX. In questo caso

se dumpate a DS:0400 trovate lo stesso

valore di CX, solo rovesciato (es. se in CX

c’è 002Ah, troverete 2A00h); non sò perchè,

(stasera non ho fame), ma è così….

es 3. MOV AL,DL ———-> muove la parte bassa di DX nella parte bassa

di AX

es 4. MOV [ES:300],AX ———> muove il valore di AX nella locazione

specificata. Notare che se ES non è

menzionato, si usa DS. Se prima di una

istruzione del genere si muove un valore

in BX (es. 03) questo viene usato come base

da aggiungere all’indirizzo specificato.

Quindi, in questo caso, il valore di AX

verrebbe mosso in ES:300+BX = ES:303.

[CMP]….. Semplicemente, confronta due valori in memoria, siano essi registri

oppure bytes, cambiando di conseguenza il flag relativo. La sintassi, secondo

i casi, può essere:

es 1. CMP AX,01 —–> confronta AX con 01

es 2. CMP AX,BX —–> confronta AX con BX

es 3. CMP AX,[0550] —–> confronta AX con i 2 bytes a DS:0550

(eccetera eccetera…)

Questa funzione funziona (bello!) come una sottrazione source-destination,

cioè:

ponendo AX=20 e BX=21, il risultato del CMP AX,BX sarà 20-21=-1. Il risultato

di questa sottrazione attiverà il flag CARRY (C), attivato quando si sottrae

un valore più grande da uno più piccolo; se invece la sottrazione non dà

risultato negativo, il flag rimane 0 (disattivato).

Dal punto di vista crakkistico, le istruzioni CMP sono usate *SEMPRE* per

verificare il vostro input, oppure per far sapere al programma se è registrato

o meno. Quindi, truffando il CMP si può benissimo far credere al tapino una

cosa per un’altra!

[JMP]…. Lo troverete *SEMPRE* dopo il CMP, nelle varie forme.

La più semplice, e ovvia, è la forma JMP <indirizzo>, che naturalmente provoca

un salto all’indirizzo desiderato, quali che siano i valori dei flags dati

dal CMP. Per quanto riguarda l’indirizzo, questo può essere nello stesso

CS (JMP 0AF4) oppure in un’altro (JMP 2000:18A0 oppure JMP DWORD PTR ES:[DI],

che vi spedirà alla locazione contenuta in ES:DI. Ma sono solo alcuni esempi).

Questa comunque è l’istruzione che userete più spesso (anzi, mi sbilancio:

nel 99% dei casi) nei vostri scopi pirateschi. Difatti, se la vostra

protezione, ad esempio, controlla una locazione e poi fà un JNZ che riporta

il programma all’inserimento della password/serialnumber, basta che

sostituiate il jump condizionale con un JMP, e….. et voilà! Comunque, se

ne riparla dopo!

Ora, vi agevolo la lista dei vari jump condizionali, spudoratamente copiata

dal Cracking Manual di The Cyborg (quindi, grazie tante, leggetelo che è

bellino, ma il mio è meglio perchè è più aggiornato!).

Dunque, supponendo un CMP AX,BX, si possono avere i seguenti casi:

(Z,O,S,C,P sono i flags che i jump vanno a controllare)

Istruzione Definizione, condizione, flag

JNZ 030A (Jump if not zero, AX diverso da BX, Z=0)

JNE 030A (Jump if not equal, identico a JNZ)

JZ 030A (Jump if zero, AX=BX, Z=1)

JE 030A (Jump if equal, identico a JNZ)

JB 030A (Jump if below, AX<BX, C=1)

JA 030A (Jump if above, AX>BX, C=0)

JL 030A (Jump if less, AX<BX, S diverso da O)

JNGE 030A (Jump if not greater or equal, AX<=BX, S diverso da O)

JGE 030A (Jump if greater or equal, AX>=BX, S=O)

JNL 030A (Jump if not less, in pratica uguale a JGE)

JLE 030A (Jump if less or equal, AX<=BX Z=1 oppure S=F)

JNG 030A (Jump if not greater, come JLE)

JG 030A (Jump if greater, AX>BX Z=0 oppure S=O)

JNLE 030A (Jump if not less or equal, AX>=BX Z=0 oppure S=O)

JS 030A (Jump if sign, /, S=1)

JNS 030A (Jump if not sign, /, S=0)

JC 030A (Jump if carry, /, C=1)

JNC 030A (Jump if not carry, /, C=0)

JO 030A (Jump if overflow, /, O=1)

JNO 030A (Jump if not overflow, /, O=0)

JP 030A (Jump if parity, /, P=1)

JPE 030A (Jump if parity even, come JP)

JNP 030A (Jump if no parity, /, P=0)

JPO 030A (Jump if no parity odd, come JNP)

(ce ne sarebbero altri, ma nella lista da cui li ho copiati non

venivano menzionati.)

Puff,Puff….. spero di non aver scritto minchiate! (tanto poi lo riguarda

MoonShadow!). E comunque, non fatevici tante seghe mentali….

il funzionamento dei jump lo imparerete strada facendo…. nemmeno io mi

ricordo a memoria il funzionamento di tutti questi jmp (anzi, a dire il vero

non vado oltre le prime 5/6 righe!).

[LOOP]….. Indica un ciclo, che si ripete per CX volte (naturalmente, CX

decrementa ogni volta che trova questa istruzione). Per quanto riguarda il

formato, è LOOP <indirizzo>, che indica appunto l’inizio del LOOP dove questo

ogni volta ritorna finchè CX non diventa 0. Istruzione piuttosto pallosa da

debuggare, utile in questo caso la funzione “Breakpoint Here” dei debugger,

che permette di settare un breakpoint all’istruzione successiva e ripartire

direttamente da lì senza sorbirsi tutto il ciclo (sempre che funzioni, sennò

ve lo dovete puppare tutto).

[REP]….. Repeat. Stesso discorso del loop per quanto riguarda la pallosità

e l’uso della funzione “Here”. Indica il ripetersi di istruzioni MOVS, LODS,

STOS (quindi si troverà nel formato REP MOVS, REP LODS, REP STOS). Le

istruzioni suddette vengono ripetute CX volte.

[MOVSB]….. Muove un byte dall’indirizzo DS:SI all’indirizzo ES:SI.

[MOVSW]….. Stesso discorso, ma per una word (4 bytes)

[LODSB/LODSW]….. Con queste istruzioni, viene letto un byte o una word

residenti in memoria all’indirizzo DS:SI. Il byte o la word in questione

viene messo in AL (o in tutto AX, naturalmente, se è una word)

[STOSB/STOSW]….. Se le istruzioni prima leggevano, questa cosa fà?

mah….. forse scrive! Difatti, scrive il byte (o la word) in AL (o AX se

word) all’indirizzo ES:SI.

[CALL]…… Richiama una subroutine, e dopo l’esecuzione di questa torna

all’indirizzo successivo alla CALL stessa (tramite un RET/RETF).

Esempio:

CALL 68AB —-> esegue la subroutine a CS:68AB

subroutine:

CS:68AB ……

68AE ……

68B0 ……

68B3 RET —-> torna all’istruzione successiva a CALL 68AB

Una call può essere anche nel formato CALL FAR (come anche il JMP),cioè viene

eseguita una subroutine ad un’indirizzo in un altro CS.

Nei vostri primi approcci crakkistici, se avete la fortuna di trovare la CALL

che salta *DIRETTAMENTE E SOLO* alla protezione, potete benissimo togliere

quella. Più in là sarà meglio che impariate a districarvi con i jump e i

compare, identificando e modificando quelli relativi al solo controllo della

protezione. Difatti, se per caso quella CALL chiamasse una subroutine che

contiene la protezione ma anche istruzioni necessarie al buon funzionamento

del programma, eliminandola siete fottuti…. (cosa che ho imparato dopo

mooooooooooooooolto tempo e moooooooooooolte figure penose distribuendo crack

che sì sproteggevano il programma, ma che avevano anche “alcuni” effetti

collaterali!)

[INT]…… Chiama un interrupt (tipo una CALL ma non relativa al programma)

, con una specifica funzione assegnata da un valore, di solito mosso in AX.

E’ utile ad esempio monitorare l’interrupt 13 con il debugger (nel caso si

voglia sproteggere un programma che accede al floppy), oppure l’interrupt 16

con funzione 10 (AX=10) nel caso il programma attenda la pressione di un

tasto…. Utile ma non indispensabile, si crakka anche senza usare questa

funzione del debugger…..

FFFFFFFFFFFFIIIIIIIIIIIIINNNNNNNNNEEEEEEEEE!!!!!!!!!!!!!

Finalmente, che palle!!! Non ne potevo più. Non vedo l’ora di cominciare la

parte sul cracking vero e proprio. Comunque, a parte gli scherzi, un mini

corsino di assembler (MOOOOOOOLTTTOOOOO MIIIIIINIIIII!) ci voleva proprio,

sennò probabilmente non capireste niente nelle parti successive. Comunque

non è detto che se capite poco in questa sezione non andrete avanti…….

anzi! Io stesso non conosco troppo bene l’assembler, ma vi assicuro che se vi

imparate ben bene le cose scritte sopra non avrete problemi. Quello che conta

è l’intuito, la perseveranza, e ancora una volta…..il CULO! Magari, se

l’argomento vi interessa, può essere una buona scusa per impararsi l’assembler

un pò più a fondo (cosa che stò cercando di fare anch’io!).

1.2…… USO DEI VARI DEBUGGERS

Vi dico subito che qui non mi dilungherò poi tanto, visto che anche se i

programmi sono diversi, le funzioni sono sempre le stesse, e ben deducibili

dal programma stesso. Comunque, in questo tutorial farò uso di:

1) GameTools 3.2 (G3X)…. MITICO e INEGUAGLIABILE debugger DOS

(purtroppo solo in modo reale) che potete usare anche per

fare dei trainers. Lo allego io, non sò se lo trovate su internet.

2) SoftICE 2.0 for Windows95 ….. Praticamente, il GameTools per

Windows, con le stesse doti di ineguagliabilità e miticità (che

discorso a culo!). A parte gli scherzi, indispensabile, anche

perchè è l’unico debugger (almeno credo) che permette di

debuggare (bel discorso,complimenti…) i programmi con

DOS4GW. Se volete potete anche usare il SoftICE x DOS al posto

del G3X.

3) Watcom Debugger….. Odiosissimo debugger indispensabile per

il cracking in DOS4GW. Fortunatamente, lo dovete usare solo

per questo….. il resto si fà con gli altri due! Dato che

questa parte l’ho aggiunta dopo, i comandi li trovate direttamente

nel paragrafo sul DOS4GW.

Beh, andiamo al dunque…..

i comandi del debugger che userete più spesso sono:

[STEP] ……. Esegue le istruzioni una alla volta, eseguendo direttamente

le CALL e i LOOP.

[TRACE] …… Come sopra, ma permette di eseguire le istruzioni all’interno

delle CALL e dei LOOP una alla volta. Utile se dovete utilizzare la famosa

tecnica “Cynar, fino al cuore del carciofo”, ossia spulciare all’interno di

una serie di CALL nidificate fino a trovare quella che chiama *SOLO* la

routine di protezione

[BREAKPOINT]….. Esegue un INT 3 al posto dell’istruzione presente all’

indirizzo da voi specificato, causando un ritorno al debugger quando questa

viene eseguita. (se però c’è la famosa trappola per il debugger…… son

cazzi! dovete individuare le istruzioni che vi impiantano il debugger e

levarle.). I breakpoint sono di vari tipi, ognuno con una funzione specifica.

Ad esempio, un breakpoint molto usato è quello che torna al debugger ogni

qualvolta si accede in lettura e/o scrittura alla locazione indicata

(utilissimo per trovare proprio le istruzioni che esaminano il vostro input).

Un altro ancora è quello che torna al debugger quando viene eseguita

l’istruzione all’indirizzo indicato (ad esempio, per stoppare il programma

in un certo punto che sappiamo essere proprio prima del controllo dell’input).

Questi sono solo 2 esempi di breakpoint…. nel G3X vi appare la lista

di quelli che potete usare, nel SoftICE dovete settarveli a mano.

La sintassi per il SoftICE non stò a scriverla,in quanto è spiegata nell’

help stesso del programma. Direte voi, dove lo trovo l’help ?

Semplice: se digitate ? <invio>, vi appare una lista di tutti i comandi

disponibili; ora, andate a vedere quelli relativi ai breakpoint, scegliete

quello che vi interessa e inserite ? <nome breakpoint (BPR,BPX,ecc.). Vi

apparirà quindi la sintassi del comando. Questo procedimento è valido anche

per tutto il resto dei comandi del SoftICE (così lo spiego una volta sola!)

[HERE]….. La funzione cui accennavo prima nel tutorial assembler, permette

di settare un breakpoint BPX (break on execution) in un punto particolare

(es. subito dopo un loop) causando il ritorno al debugger quando il programma

arriva a quel punto. In questo modo, si saltano fastidiose attese…..

Giustamente, voi mi direte: ma non è lo stesso mettere un breakpoint come

spiegato prima ? No, cioè sì (la funzione è la stessa), ma così fate prima.

Mi spiego: col G3X, ad esempio, scorrete il listato assembler, e all’indirizzo

dove volete che il programma si fermi premete “H”, in modo da mandarlo in

esecuzione fino a quando non raggiunge quel punto. Per il SoftICE stesso

discorso, ma prima dovete entrare nella CodeWindow (la finestra sopra a quella

dove inserite i comandi, quella dove vedete il disassemblato del codice)

digitando “ec”. Quindi, scorrete con alt+frecce e premete F7 dove volete il

breakpoint. L’unica differenza è che questo tipo di BP vale una volta sola,

ossia tutte le volte lo dovete risettare. Capito mi avete ?

[INTERRUPT MONITOR]….. Non è una vera e propria funzione, bensì un

breakpoint (nel SoftICE comando BPINT) ad uno specificato interrupt, che

causa il ritorno al debugger ogni qualvolta questo interrupt è chiamato.

Utile nel caso di protezioni che accedono al floppy,o alla porta parallela

(se se ne conoscono gli interrupt relativi, quello del floppy è il 13)….

ma come ho detto più indietro non indispensabile, serve solo a sveltire un

po’ la procedura. Non vi intrippate quindi troppo a mettere breakpoint

sull’interrupt 21 o 10, chiamati per funzioni dos e apertura schermo, perchè

rischiate di perdervi nei meandri del programma. Usate questa funzione solo

nei casi in cui conoscete *ESATTAMENTE* il numero dell’interrupt e la funzione

richiesta (es. per la pressione di un tasto, INT16 con funzione 10 in AX).

Dal G3X, accedendo al menu interrupt monitor, potete settare questi breakpoint

in maniera molto semplice….. nel SoftICE dovete fare a mano.

Vabbè, le funzioni che andrete maggiormente (anzi,diciamo pure esclusivamente)

a usare nei debuggers trattati sono queste. Vi faccio ora una panoramica sui

tasti da usare nel SoftICE per accedere a queste funzioni (così evitate di

battere 200 volte “p” <return>, “p” <return> mentre debuggate). Quelli del

G3X non li metto, dato che tutto è spiegato su schermo e anche un deficiente

quale ero (e sono) io lo saprebbe far funzionare…..

F10….. P (step)

F6…… EC (enter/exit code window)

F7…… H (here) [dovete prima andare nella code window con F6 (ec)]

F8…… T (trace)

Da notare che questi tasti possono anche essere cambiati, basta andare a

modificare il file WINICE.DAT nella directory del SoftICE.

——————————————————————————

CAPITOLO 2: CRACKING IN DOS / ThE FuN StUfF BeGiNs! /

——————————————————————————

Eccoci arrivati, dopo la pallosissima (anche da scrivere) prima parte, al

succo di questo tutorial…. il cracking vero e proprio.

Cominciamo dal DOS, trattando i vari tipi di protezione che potete trovare,

ognuno spiegato in maniera (spero) abbastanza dettagliata e corredato da un

esempio….. naturalmente, questi dovranno essere presi solo come tali, anche

perchè ogni protezione è diversa dall’altra e non si può generalizzare il

tutto con una precisa tecnica. Mano a mano che poi crakkerete da soli

sicuramente saprete far fronte anche a situazioni diverse, più o meno

discostanti da quelle qui illustrate.

Una cosa che tengo a puntualizzare è questa: avrete sicuramente visto che

oggi tutti i crackers tendono a fare (per i programmi che richiedono un

serial number collegato al vostro nome) dei KeyMakers, ossia dei programmi

che, una volta scoperto l’algoritmo, prendono il vostro input e ne fanno

un numero valido per il programma. Io da parte mia preferisco sempre

SRADICARE di netto la protezione, anche perchè così non devo perder tempo

a star dietro all’algoritmo, magari complicatissimo….. Quindi, i miei

esempi saranno tutti improntati sulla COMPLETA eliminazione della routine

di protezione. Se poi volete farvi i keymaker per quel tipo di programmi,

basta che seguiate l’algoritmo di protezione, facilmente trovabile mettendo

dei breakpoint R/W (read/write) o meglio R (read) alla locazione dove trovate

il vostro ECHO (ossia, l’input che avete dato es.il vostro nome). Per cercare

l’echo, basta cercare in memoria quello che avete inserito, subito dopo essere

tornati al debugger dopo l’inserimento. A questo proposito, per quanto

riguarda il dos, ricordatevi che le locazioni buone per l’echo (ne troverete

infatti diversi) sono quelle dalle parti del CS o DS, ma non sempre…

comunque, mai quelle iniziali e finali (da C000 in poi). Con un pò di pratica,

le riconoscerete a occhio, ve lo garantisco.

Quindi, fatte queste precisazioni, LET’S START!

2.1…. Protezione con controllo dell’accesso al disco (INT13)

Questo tipo di protezione è in assoluto la più facile da eliminare. Difatti,

si basa sul controllo di settori del floppy che non vengono copiati durante

un normale processo di copia, quindi presenti solo sul floppy originale.

Data la sua facilità di sradicazione, oggi questa protezione non è quasi

più usata…. comunque, mi sembra un buon esempio per iniziare.

L’esempio che vi proporrò è il gioco “Lemmings” (spero lo abbiate, di solito

lo davano con le vecchie SoundBlaster), anche perchè non sono riuscito a

trovare qualcos’altro che usa questo tipo di protezione.

Iniziamo….. Per prima cosa, caricate il G3X, buttatevi Lemmings sull’HD

e togliete il dischetto originale dal drive (oppure mettetecene uno a caso)

in maniera da simulare il caso di una copia pirata.

Ah, ricordatevi di togliere il QEMM (o l’EMM386) se lo avete installato,

perchè nel mio caso faceva impallare il tutto (forse il gioco è troppo

vecchio, non lo supporta….).

Dunque, appena caricato il file LEMMINGS.BAT vi trovate davanti ad una

schermata in modo testo che vi permette di scegliere il computer posseduto.

A questo punto, premete PRTSCR (STAMPA,per i non inglesi) ed entrate nel

G3X. Premete “V” per entrare nel debugger, dopodichè iniziate a steppare

con “P” finchè non vi trovate nel ciclo di ripetizione che aspetta l’input.

Questo è un punto fermo nel debugging crakkistico, cioè bisogna sempre

trovare questo ciclo in modo da rientrare nel debugger una volta effettuata

la scelta.

Quindi, vi troverete in questo punto (il CS lo ometto, tanto cambia sempre):

5448 CALL 9109 < Inizio ciclo attesa input

544B PUSH BX

544C XOR BX,BX

544E CALL 7583

5451 POP BX

5452 JB 5442

5454 MOV AH,01

5456 CALL 8413

5459 JNE 8461

545B MOV AH,84

545D INT 2A

545F JMP 5448 < Torna all’inizio finchè non premete il tasto giusto

5461 XOR AH,AH < Qui premete “H” per tornare al G3X dopo aver premuto <ret>

Come vedrete, continuando con “P” non fà altro che saltare a 5448 ogni volta

che arriva a 545D, ciò indica che è un ciclo. Allora, provate a mettere il

breakpoint HERE a 5461 (andateci sopra e premete H)…. hmmm, torna allo

schermo di selezione! Quindi, premete return (tanto và bene per tutti la

prima opzione) e….. magia, riecco il G3X! Era proprio il ciclo di attesa

dell’input!

Vabbè, andiamo avanti! Premete comodamente “P” fino a che non arrivate a

questa parte:

00E0 CALL 0649 < Controlla se il floppy originale è inserito,sennò esce

00E3 CALL 1591 < Fà partire il gioco

00E6 CLI

00E7 MOV CX, [1FC9]

Noterete subito che steppando la prima call, il programma esce dicendo che

il disco originale non è inserito. Primo trucchetto del cracker provetto:

quando ci sono due call una di seguito all’altra, la prima delle quali esce

se non si è azzeccato la password o simili (come in questo caso), provare

SEMPRE, una volta arrivati a questa call, a cambiare l’IP ed eseguire la

seconda….. fusse che fusse la vorta ‘bbona!

Quindi, tutto da capo, fino a riarrivare all’indirizzo 00E0 (questa volta

però, salvatevi l’indirizzo andandoci sopra e premendo “TAB”, almeno se

qualcosa và male poi potete metterci un BPX e ricominciare da qui). A questo

punto provate a farli saltare la call, cioè a non eseguirla proprio,

cambiando il valore del registro IP (premete R poi I, quindi scrivete 00E3, la

locazione successiva). Ora, incrociate le dita….. ricominciate a steppare

con “P”, anzi per un brivido maggiore consiglio di uscire direttamente dal

G3X con “ESC”. Et voilà, come dice il mago Afono del Vernacoliere, avete

fatto il vostro primo crack!!!! Naturalmente, dovete poi andare a ricercare

con un hex-editor i bytes corrispondenti alla call (quindi,segnatevi i

precedenti,quelli e i successivi) e cambiare i valori nel file (mi sembra

sia VGALEMMI.EXE) con una serie di NOP (No-Operation, in hex 90). Ma di questo

parleremo poi, nel capitolo apposta sul patcher! Intanto, godetevi la vostra

prima sprotezione!!!!

Ah,faccio notare che se provavate a monitorare l’INT13, in questo caso i

programmatori sono stati furbi implementando la cosiddetta “trappola per

debugger”, cioè una serie di INT3 dopo le istruzioni “chiave” che fanno

impiantare il povero G3X…. se non ci credete, provate (tanto come si fà

lo dovreste sapere, ve l’ho spiegato prima!)

2.2. Aiuto, il mio piratone di fiducia mi ha dato il programma senza SN!

Capita sempre, specialmente col mio fornitore, di ricevere programmi bomba

che una volta installati, chiedono il serial number. Alcuni funzionano per

un pò, poi cominciano a frantumarci le palle con nag-screens vari (del

tipo : “Bei mi budiuli, ir programma E LO DOVETE PAGA’!!!). Alcuni,addirittura

non si installano nemmeno in mancanza del magico numerino. E’ questo il caso

del crack che mo’ vi propongo: il QEMM versione 8.0 (peraltro, non distribuito

in versione shareware ma serial-dipendente anche lui).

Dunque, come al solito, G3X in spalla e via!

Si parte con l’inserimento di tutti i dati nell’installer (nome,città,cazzi

vari) e si inserisce anche un serial number a caso (può essere anche una

parola, tanto la protezione la sodomizziamo! io di solito uso “culo”, semplice

ma efficace…..). Prima di premere return, PRTSCR e entriamo nel G3X. Dato

che abbiamo inserito un input, tanto vale cercare il nostro ECHO, in modo da

settare un BP R/W (read/write) che ci farà capitombolare proprio nel bel mezzo

della routine da fottere…. Quindi si entra nel debugger, si mette in modo

testo con “U”, si mette il display della memoria a 0000:0000 con “C” (change

address, sennò non trova una mazza) e si preme “F”. A questo punto, inserite

il serial number che avete digitato e premete return, scegliendo la ricerca

in ASCII e il modo Case Sensitive OFF(non tiene conto delle maiuscole e

minuscole). Troverete un bel pò di echo, comunque vi ho già detto prima di

non considerare quelli troppo vicini all’inizio e quelli troppo lontani…..

in medio stat virtus (diceva Socrate,mi sembra….. sapete, studio Biologia e

questi sono solo ricordi del liceo!). Spulciando tra gli echo che trovate

vi salterà subito all’occhio quello situato a CS:000A, contenente il vostro

serial inserito e, guardando sopra, gli altri dati che avete messo. Quindi,

sicuramente, è quello giusto! Come al solito, salvatevi l’indirizzo andandoci

sopra e premendo TAB, dopodichè settateci un BPRW (tornate nella schermata

iniziale del G3X,scegliete il menu dei breakpoint,selezionatene uno,scegliete

BreakPoint ReadWrite,premete TAB e da qui selezionate l’indirizzo….puff,

puff, ma vi devo dire tutto io? basta,da ora in poi sarò più sintetico!).

A questo punto tornate al programma premendo ESC, e quando premerete invio

magicamente riapparirà il G3X. Bene, siete usciti proprio ora dalla routine

di attesa dell’input! Cominciate allora a steppare, usando tutti i trucchetti

che vi ho insegnato prima (ad es. all’indirizzo CS:3DA6 c’è un ciclo palloso

a bestia, saltatelo con l’HERE a 3DA8). Ad un certo punto arriverete qui:

1B90 TEST AX,AX < Parte finale della routine di protezione

1B92 JNE 1BA6 < Se il numero è giusto, và a 1BA6

1B94 MOV AL,F9

1B96 CALL 11BF < Beep, segnaccio!

1B99 CALL 1916 < Spiacente,avete cacato fuori dal vaso (SN errato)

1B9C POP SI

1B9D CALL 18E3 < Con queste istruzioni e le successive torna

1BA0 CMP AL,1B all’input e vi richiede il SN

…………..

1BA6 POP SI

1BA7 JMP 1B56

Se eseguite la CALL 11BF e successiva, vedete che il programma dà il messaggio

di errore. Bene, è dove volevamo arrivare! Ora facciamo marcia indietro.

Qual’è il jump prima della call che da l’errore? Quello a CS:1B92 !(infatti

vedete che salta avanti, cosa IMPORTANTISSIMA da notare: difatti, cercando

di saltare la protezione, i jump che saltano avanti sono SEMPRE i PRIMI da

controllare, altro trucchetto da cracker provetto…. ci và anche di rima!)

Subito, settateci un BPX (togliete quello RW, tanto nella routine giusta ci

siete), uscite dal programma e ricaricatelo (tanto gli indirizzi in memoria

dovrebbero rimanere gli stessi, sennò vi tocca tornarci a mano.)

Vedrete che dopo aver reinserito il SN e premuto return, il G3X si ferma

proprio a CS:1B92. Cambiate quindi l’IP e mandatelo a 1BA6. Ancora qualche “P”

e arriverete qui:

1B68 JZ 1B6D < Qui dovete cambiare l’istruzione in JMP 1C25

1B6A CALL 1C26

1B6D CALL 1525 < Torna al programma e attende la pressione del return

1B70 MOV BX, [5307]

1B74 CMP BX, 3F3F < Ennesimo controllo finale della correttezza del SN

1B78 JNE 1B7D < Se è sbagliato salta a 1B7D

1B7A JMP 1C25 < Se è giusto salta a 1C25 e inizia l’installazione

Osserverete ora che eseguendo le CALL riappare lo schermo del programma,

e che premendo <return> ritorna il G3X. Bene, avanti! Vedrete che facendo

il JNE 187D si ritorna daccapo, con il beep di errore eccetera. Mettiamo

dunque un BPX (disabilitando sempre il precedente,altra regolina) a 1B78,

usciamo e ricarichiamo il programma. Una volta tornati a questo punto,

cambiamo IP mettendolo a 1B7A e continuiamo a steppare. Tadà….. altra

protezione fottuta, complimenti, avete appena fatto il vostro 2ø crack!!!

Per fare le cose ammodino, sarà meglio cambiare il JZ 1B6D a CS:1B68 in un

bel JMP 1C25, in modo da garantire che, quale che sia il SN, il programma

lo prenda per giusto. Quindi, tornando sopra, dovreste inserire l’istruzione

premendo A (assemble) e inserendo i valori esadecimali E9 <ret> BF <ret> 00

<ret>. Perchè questi? Bè, sinceramente non lo sò nemmeno io. Sò solo che

dato che il G3X purtroppo non supporta l’inserimento dell’istruzione assembler

in maniera normale (es. JMP direttamente), bisogna prendere il valore hex

dell’istruzione che si vuole inserire (in questo caso, E9 A8 00 che

corrisponde al JMP 1525 all’offset 1B7A). Quindi, copiarlo nell’offset

desiderato e giocherellare un pò con gli ultimi due valori (il primo rimane

fisso) finchè non si riottiene l’indirizzo voluto, in questo caso 1525. Fatto

questo, provate il tutto rieseguendo da capo il programma e facendo la

modifica, poi segnatevi i valori dei bytes da sostituire e continuate la

lettura del manuale, perchè come fare i patches lo spiego all’ultimo!!!

Ah, dimenticavo: inutile dire che questo procedimento è analogo in caso di

programmi che vogliono una password (es. giochi che vogliono la password

a pagina x del manuale).

2.3 Variazioni sul tema: Xoanon’s Standard Cracking Algorithm (TM)

Questi due procedimenti standard sono applicabili anche ad altre situazioni,

per cui non starò a dilungarmi oltre. Un esempio è il caso della scelta di

una determinata icona per superare la protezione (come succede, ad esempio,

in molti giochi della Lucas). In questo caso, come al solito, basta riuscire

ad imbroccare il punto di entrata giusto, ossia, e non mi stancherò mai di

ripeterlo, L’ALGORITMO CHE ATTENDE IL VOSTRO INPUT. Fatto questo, in maniera

analoga a come avete fatto per Lemmings, non resta altro da fare che steppare

fino a che non succede qualcosa. Quando la routine vi butta fuori e riparte

aspettando un’altro input, segnatevi il punto (una CALL) dove il fatidico

“INCORRECT PASSWORD” appare e esaminate bene il disassemblato PRIMA di questa

istruzione. Ci sarà infatti SICURAMENTE un CMP seguito da un jump condizionale

che, in caso l’icona scelta sia quella giusta, salterà questa CALL portandovi

da un’altra parte (in genere il jump giusto da modificare vi porterà avanti,

mai indietro, ma questo mi sembra di avervelo già detto). Quindi, una volta

trovato basta modificarlo. Interessante variazione può essere quella di

non modificare il jump, ma sostituire al CMP un MOV. E’quello che si chiama

DIRTY-CRACK, e vi permette di evitare magari di ritornarci sopra se il

check viene fatto anche più avanti nel programma. Basta andare a vedere,

infatti, alla locazione di memoria dove effettua il compare (quella tra

parentesi quadre, per intendersi, oppure in AX o nel registro dove effettua

il CMP) e vedere che valore c’è. Supponiamo che la situazione sia:

……..

CS:0010 CMP AX,00 < se in AX c’è 0 setta il flag a 1, sennò a 0

CS:0013 JNZ 7641 < se il flag è 0, salta a 7641

CS:0015 CALL 4328 < vi butta fuori o simili

……..

CS:7641 Dovete saltare qui per saltare la protezione

Se quando andate a vedere nella locazione del compare, in caso sbagliaste

la password, ci trovate uno 00, vuol dire che quello è il valore che il

programma esamina per vedere se è registrato/sprotetto o no. Basta cambiare

il CMP in MOV in maniera da mettere nella locazione/registro un valore diverso

da quello, per far credere al prg di essere registrato effettivamente

(oppure per farli credere che avete indovinato la password).

Tutto quello che vi ho detto in questo paragrafo può benissimo essere

considerato “IL METODO STANDARD PER IL CRACKING DOS/WINDOWS”, quindi…….

almeno questo dovete impiantarvelo bene nel ceppione !!!!!

Anche per quanto riguarda le protezioni con chiave hardware, stesso discorso.

L’unica cosa, come vi ho detto qualche pagina fà, è se nella protezione sono

implementati particolari accorgimenti “ANTI-DEBUGGING”. In questo caso,

purtroppo, la cosa si fà complicata….. l’unica è provare ad eseguire le

istruzioni passo passo fino a quando il programma si impianta, tornare

indietro, eliminare l’istruzione dove questo accade (andando a tracciare bene

all’interno delle CALL per essere sicuri di non eliminare qualcosa di troppo)

e riprovare. Di più su questo non sò dirvi, comunque sicuramente non

troverete molti programmi di questo tipo….. lo stesso CuBase 3.0 (programma

che costa una cifra, con protezione a chiave hardware) non contiene nessuna

di queste tecniche, e la sprotezione è una vera puttanata (5 minuti) !!!

Un’ultimo cenno sulla modifica della label del floppy (o del cdrom) quando

il programma richiede un particolare nome del disco per funzionare o per

essere installato: solita zuppa! Ci sarà un punto dove troverete un CMP

con un jump condizionale seguente che vi porterà alla visualizzazione di

roba del tipo “Insert the correct disk/CD in drive”. Basta individuare questo

punto e saltarlo. Tutto qua.

2.4 Cracking in ambiente DOS4GW (*FOR EXPERTS ONLY*)

Eccoci al dunque, al punto dove si vede veramente se un cracker ha le palle

o meno (ve lo immaginate un cracker con le palle, dico di quelli da mangia’!).

Premetto che le mie palle in questo campo non sono ancora molto sviluppate,

quindi….. perdonatemi se in questa sezione sarò poco chiaro!

Non vi stò a dire nemmeno che, se prima non vi leggete bene gli altri capitoli

e non vi imparate BENE BENE a destreggiare nel debugging, sviluppando un certo

intuito “crakkistico”, potete benissimo saltare questa parte, tanto non ci

capirete quasi nulla! Ordunque, fatte queste precisazioni, cominciamo:

Innanzitutto, dovete usare lo strafottutissimoWDmaledettochilhainventatolopote

vanofàunpòpiùfaciledausanonsòtipoilsofticecheècomplicatoperòafàlecosesifàprest

oinvececonquestobisognastàagiràfralefinestreuncisicapisceunasega….. Capito,

a me piace MOOOOLTO il Watcom Debugger!

A parte questo mio odio recondito verso il programmino (in realtà,l’unico che

permette di debuggare il DOS4GW, che che ne dicano chi sostiene che si può

fare benissimo con il SoftICE per Windows95. Dimostratemelo!), vi spiego

subito qualche comandino:

F10….. Step

F8…… Trace

F5…… Go (esegue fino al BP specificato)

F9…… Setta il BP all’indirizzo specificato

Praticamente, il vostro debugging si ridurrà al pallosissimo steppare fino a

che non trovate una call che vi butta fuori. A questo punto:

1) Fate UNDO con CTRL+LEFT (rispondete YES alla finestra che appare)

2) Mettete un BP con F9 alla call incriminata

3) Tracciatela

4) Con le call successive, ripetete da 1 a 3 finchè non vi accorgete che

siete arrivati ad un punto nel quale un jump condizionale controlla

l’entrata o meno nel programma (password esatta,cd check).

5) Provate a saltarlo, cambiando l’EIP (uguale all’IP, ma questa volta a

32-Bit. Anche gli altri registri li trovate in formato E) andando nella

finestra REGISTERS da uno dei meno e clicckando sopra al registro.

6) Se funge, segnatevi i bytes da cambiare. Dato che nel WD non c’è la

funzione di assemble, a meno che non si tratti di NOPPARE qualcosa,

dovrete scazzarvi a cambiare i bytes clickando sul jump da cambiare

e giocherellando con i valori fino a che non avete ottenuto quello

giusto. Questo è uno dei principali motivi per cui odio questo debugger!

Non vi stò nemmeno a dire che nel debugging di questi programmi è quantomeno

ESSENZIALE avere a disposizione l’originale, per vedere come si comporta

debuggandolo, in modo da identificare il punto dove agire. Difatti, in questa

maniera potete prima provare a debuggare in condizione “pirata” (ossia, ad

esempio, sbagliando la password o non inserendo il CD). Quindi, segnatevi

tutti i breakpoint “buoni” che trovate;

A questo punto, debuggando l’originale inserendo la PWD giusta o il CD, usate

gli stessi BP partendo dall’ultimo, fino a che il programma non tornerà al

debugger. Segnatevi questo BP. Ora sapete che il check avviene in un punto

proprio dopo quella call.

Tracciate la call e steppate finchè non esce, seguendo esattamente quello che

succede, segnandovi tutti i jump condizionali. Ora basta riprovare a

debuggare in condizione “pirata”, settare il BP che che vi siete segnati

precedentemente e vedere cosa fanno i jump condizionali. Sicuramente ne

troverete uno che si comporta diversamente da prima, e sarà proprio quello

da cambiare.

Questa tecnica è diciamo standard per quanto riguarda i CD-CHECK, come nel

caso di Destruction Derby che ora vi propongo…..

Dunque, iniziate il debugging caricando WD /TR=RSI /SWAP DD.EXE.

Steppate, settate BP, tracciate, eseguite e cazzi vari fino a quando non

arrivate a questo punto (naturalmente, ci arriverete dopo MOOOLTE volte che

il programma vi butta fuori, quindi dovrete ricominciare tracciando e

ritracciando…..):

(naturalmente, l’EIP che troverete voi sarà diverso!!)

[ ] 003A68F5 sub esp,0000000C

[ ] 003A68FB mov eax,[004EA78A]

[ ] 003A6900 sar eax,10

[ ] 003A6903 cmp eax,00000014

= > 003A6906 je CS:003A6916 < Con il CD originale inserito, questo

[ ] 003A6908 mov eax,00000003 JE viene eseguito. Per eliminare

[ ] 003A690D push eax il cd check, basta cambiarlo in JMP.

[ ] 003A690E call CS:003A6ABF

[ ] 003A6913 add esp,00000004

Usando le tecniche sopra descritte e controllando prima come si comporta il

gioco con il CD inserito vedrete che il JE a 3A906 (nel mio caso) viene

eseguito, mentre non inserendo il CD la call a 3A690E vi butta fuori. Quindi,

basta cambiare questo je in un JMP. Dunque, provate innanzitutto a cambiare

l’EIP in modo da simulare un JMP, per vedere se funge (tante volte mi fossi

rincoglionito……). Controllato questo, segnatevi i bytes corrispondenti

all’istruzione a 3A6906 (anche qualcuno prima e dopo) clicckando sul JE

stesso. Poi, andate al capitolo sul patcher per vedere come il tutto si

mette in pratica…… Alè, il vostro primo crack in DOS4GW!!!!!

Ah, dimenticavo: dato che il WD non stoppa i programmi che hanno un proprio

keyboard handler (praticamente, tutti) l’unica soluzione per debuggarli

è fare come in questo caso, cioè eseguirli passo passo dall’inizio, tracciando

e ritracciando (cosa PALLOSISSIMA che vi porterà via ore e ore). Sennò,

potete provare a mettere un BP (dall’apposito menu) alla locazione 0xA0000

scegliendo “Byte”, il che vi riporterà al debugger ogni volta che il programma

scrive sullo schermo. Cioè, in pratica, non potete fare quello che fate col

SoftICE o col G3X, cioè magari arrivati al punto dove vi chiede la password

entrare nel debugger e fare tutto il resto. Altra ragione per cui odio il WD,

dato che il tasto per entrare nel debugger c’è (PRTSCR), ma praticamente è

inusabile per questo “cavillo”!

UPDATE:

Ho scoperto finalmente come “crakkare” il DOS4GW usando il Softice 95!!!!

Eh eh….. vi stupisco vero ?

Dunque….. premetto che è una puttanata, bastava solamente pensarci prima.

Allora, partendo dal presupposto che la parte iniziale dell’extender è sempre

la stessa (cioè, il DOS4GW che è “attaccato” all’eseguibile è sempre

il solito) basta fare in questa maniera:

1) Si carica l’EXE da crakkare con il WD

2) Ci segnamo i primi bytes (quelli iniziali, che corrispondono a quelli

subito dopo il caricamento dell’extender)

3) Usciamo dal WD, carichiamo il nostro bravo Hex-Editor e cerchiamo i

suddetti bytes nel file

4) Ai primi 2 bytes sostituiamo “CD 03”, che corrisponde a INT 3, un interrupt

riservato ai debugger per prendere il controllo della situazione

5) A questo punto, carichiamo il SoftICE 95, e eseguiamo il nostro file da

crakkare. Wow…… il Softice appare proprio nel punto dove noi abbiamo

sostituito i bytes…. ganzo!

6) Al posto dell’INT3 sostituiamo i bytes che ci siamo segnati in precedenza

7) Si continua a debuggare normalmente, avendo ora passato la parte di

startup.

UPDATE 2:

Dunque dunque…. eccovi fresco fresco un altro trucchetto (forse migliore del

primo, essendo rippato brutalmente dalla guida di +ORC). C’è di meglio che

potete evitare di cercare prima i bytes con il WD.Allora:

1) Cercate con un hex-editor nel file “vittima” la parola “WATCOM” (non mi

ricordo se è WATCOM o Watcom o watcom, mettete case-insensitive). Ne

troverete 3 o 4, quella bona è quella che immediatamente prima ha EB 76

2) Al solito, sostituite questo con CD 03 (ah già.. se il softice non “poppa”

quando eseguite, ricordatevi di attivare I3HERE ON)

3) Runnate il programma normalmente e…. tadan! Siete proprio dopo lo

startup!

4) Risostituite CD03 con EB76 e divertitevi!

——————————————————————————

CAPITOLO 3: CRACKING IN WINDOWS

——————————————————————————

* IN QUESTA PARTE SARO` PIU` SBRIGATIVO, SPECIE NEI CONCETTI DETTI E RIDETTI

NELLE PARTI PRECEDENTI. SOPRATTUTTO, VI SPIEGHERO` IL FUNZIONAMENTO DEL

DEBUGGER *

Ah, dopo il cracking in dos, passiamo a Windows….. con tutti i suoi bei

programmini shareware che funzionano a metà, funzionano per 30 gg, e cazzi

vari….. BASTA!!!! Vi salverò da questo martirio !!!

Premetto che tratterò solo Windows95 con il relativo SoftICE, ma penso che

le stesse nozioni valgano anche per Windows3.1 e NT (comunque, fatemi sapere.)

Dunque, innanzitutto installatevi il SoftICE95 (lo trovate sulla rete, basta

che andiate a cercare con AltaVista la parola “Hack” o “Crack” e vi

appariranno migliaia di siti con tutti i debuggers che volete….

Una volta installato, vi conviene farvi nella vostra AUTOEXEC.BAT un’aggiunta

del tipo:

Choice /TN,10 Carico il SoftICE (S/N) ?

If ERRORLEVEL 2 goto END

:ICE

* mettete qui il comando che vi aggiunge il programma di installazione

(es. c:\utility\sice95\sice.exe

:END

Inoltre, andate a modificare il file WINICE.DAT nella directory dove il

debugger è installato, modificando la riga con “X;” in questo modo:

WATCH ES:DI;LINES 50;X;

A questo punto assicuratevi di settare il driver della scheda grafica dal

setup del SoftICE, dopodichè siete pronti a debuggare. Su questo, faccio

una piccola aggiunta: a me,ad esempio, il driver della S3 fornito con

l’ICE non funziona, quindi tutte le volte devo settare Windows95 a 16

colori, sennò appena entro nel debugger svalvola lo schermo……

(questo per il SoftICE 2.0, con il 3.0 tutto funziona a meraviglia. Se

avete il 2.0 andatevi a beccare i nuovi drivers al sito della NuMEGA, mi

sembra www.numega.com… ma non sono sicuro!)

3.1 Nozioncine sul funzionamento di Windows95 (penso vada bene anche per 3.1)

Iniziamo con qualche delucidazione su come Windows lavora… che è meglio!

Dunque, dovete sapere che ad ogni cosa che accade sullo schermo (come ad

esempio, l’apparire di una finestra, il click di un bottone, insomma tutto!)

corrisponde una particolare API (funzione interna) del sistema operativo.

Per farvi capire meglio, se il programma vuole aprire una finestra non farà

altro che usare le funzioni del sistema, e nel disassemblato vedrete, tra le

altre, una CALL USER!OPENWINDOW (o roba del genere, non ho il debugger qui

davanti e a mente non me lo ricordo…). Quindi, per i nostri loschi scopi

basta intercettare alcune di queste chiamate, nella maggior parte dei casi

quelle relative all’inserimento di testo oppure al click di un bottone.

Per questo ci viene in aiuto il comando dell’ICE, BMSG.

Questo comando senta un particolare BP che vi riporta al beneamato debugger

ogni volta che questo intercetta una chiamata ad una specifica funzione del

sistema. La sintassi è la seguente:

BMSG window-handle funzionedelsistema

Mi spiego meglio: il Window-Handle non è altro che il primo indirizzo che

trovate nella tabella che ottenete con HWND taskname (spiegato dopo).

Notate che accanto a questo valore, tra le altre cose, c’è il nome dell’handle

stesso. Bene, questo ci serve a identificare l’handle che vogliamo allacciare.

Ad esempio, se avete un task di nome OMAR, e la finestra mostra:

3 righe per inserire il testo (ad es. dati personali e SN)

2 bottoni (es. OK, Cancel)

Dando il comando HWND omar troverete 3 handle EDIT e 2 handle BUTTON (più

altre cose). Dato che voi dovete inserire il SN (mettiamo) il vostro bersaglio

sarà uno dei 3 EDIT, giusto? Ma quale dei 3 ? Di solito il primo, perchè

quello dove inserire il SN di solito appare per ultimo (funziona così….).

Comunque, provate, tanto se beccate quello giusto non appena premete return

vi ritorna al debugger…….

Ah già, le funzioni di sistema da intercettare……. eccone qualcuna che

vi farà sicuramente comodo:

WM_GETTEXT Come nell’esempio, quando dovete inserire qualcosa

WM_COMMAND Quando dovete cliccare un bottone

GETWINDOWTEXT Sempre per il testo, applicazioni a 16-Bit *

GETWINDOWTEXTA (o W) Come sopra, ma per applicazioni a 32-Bit *

GETDLGITEMTEXT Ancora per il testo,16-Bit *

GETDLGITEMTEXTA (o W) A 32-Bit *

WM_MOVE Per tornare al debugger quando apre una nuova finestra

(da usare se i precedenti non funzionano)

* = da usare con BPX al posto di BMSG (si ferma quando trova la call che

esegue la funzione, mentre con BMSG vi ritrovate dentro la funzione

di sistema….. vabbè, è uguale. Io uso solo WM_GETTEXT e WM_MOVE,

con BMSG, poi fate voi…..)

3.2 Esempio pratico di registrazione di uno shareware

Capito bene il paragrafo precedente? Bene, cominciamo!

Dunque, i comandi principali li sapete già (andatevi a vedere il capitolo

1 paragrafo 2)…. al SoftICE si accede con CTRL-D….. cosa c’è ancora

da spiegare? Boh…… tagliamo la testa al toro e facciamo subito un

bell’esempio, così si spiega tutto senza star a fare rigirii inutili.

Dunque, prendete un bel programmino shareware di quelli che, ad esempio,

funzionano 30gg e poi non vanno più…. tipo il QuickView Plus 3.0 32-Bit.

Una volta installato, aprite un promptino del dos (infatti non vi crea l’icona

essendo un tipo-plug-in del Netscape) e caricate ORDER32.EXE. Quindi, clickate

su “Single User” poi su “Unlock by Phone”. A questo punto, inserite il vostro

unlock code (senza premere return, mi raccomando!), naturalmente scazzato,

e premete CTRL-D per entrare nell’ICE.

A questo punto, il primo passo da fare è individuare il task corrispondente

all’ORDER32. Difatti, non è detto che quando stoppate con CTRL-D andiate a

finire proprio nell’area di memoria riservata al programma…. anzi, diciamo

che non ci andrete a finire mai in questa maniera!

Bisogna fare quello che in gergo si chiama “PINPOINTING”, ossia dobbiamo

intercettare un messaggio che quella finestra di Windows manda al sistema

operativo, in modo da entrare così nel task. Ordunque, individuiamo il

task inserendo TASK <return>. Apparirà una lista con (fra gli altri):

TaskName SS:SP StackTop StackBot StackLow TaskDB hQueue Events

…….. * GLI INDIRIZZI NATURALMENTE CAMBIANO!*

Order32 0000:0000 005ED000 005F0000 306E 30D7 0000

Spool32 0000:0000 0073D000 006C0000 246E 25D7 0000

Systray 0000:0000 00415000 003F0000 156E 2561 0000

……..

A questo punto, facciamo un bel HWND Order32, per avere una lista di tutti

gli handlers del task. Otteniamo questo (sempre tra gli altri):

Window Handle hQueue SZ QOwner Name Window Procedure

…….. *GLI INDIRIZZI CAMBIANO (E VE LO RIDIO!!!!)*

01AC (2) 0E3F 32 ORDER32 Static 17DF:000052FA

01A4 (2) 0E3F 32 ORDER32 Edit 17DF:00000BF4

01B4 (2) 0E3F 32 ORDER32 Button 17DF:0000102E

0C50 (2) 0E3F 32 ORDER32 Button 17DF:0000102E

……..

In base alle cose spiegate nel paragrafo precedente, scegliamo come handle

da pinpointare quello EDIT a 01B4 (anche perchè è l’unico edit che vi appare).

A questo punto, tornate al debugger con CTRL-D e premete return per far

accettare il vostro input. Di colpo riapparirà l’ICE, e voi inizierete nello

steppaggio…..fino ad arrivare a:

…… (INDOVINATE UN PO’? COSA FANNO GLI INDIRIZZI?)

014F:004049C8 ADD ESP,04

014F:004049CB TEST EAX,EAX

014F:004049CD JNZ 00404A29 < Se il SN è sbagliato, non esegue il salto

014F:004049CF PUSH 20 e vi dà il messaggio di errore.

……

Bene, con le tecniche che ormai avrete appreso (ossia, cercare sempre il

jump condizionale precedente alla call che vi fà uscire) non avrete difficoltà

ad individuare nel JNZ indicato sopra la “chiave” per questo crack. Basta

cambiarlo in JMP (con A 004049CD <ret> JMP 00404A29 <ret>) e….. bravi!

Ora crakkate anche in Windows….. Azz, siete dei mostri!!!

Naturalmente, per il cracking in Windows valgono anche le regole generali

spiegate e rispiegate, potete settare dei BPX (con l’apposito comando) per

evitare tutte le volte di ricominciare da capo, ecc… Unica cosa, data la

possibilità di intercettare direttamente la chiamata alla routine di

accettazione dell’input con BMSG, non c’è bisogno tutte le volte di cercare

il loop che aspetta l’inserimento. Per quanto riguarda gli HERE, anche quello

l’ho già spiegato nelle funzioni del debugger….. cos’altro c’è ?

Ah,già: se siete nella merda fino al collo e volete cercare il vostro ECHO

in memoria, una volta tornati al debugger dopo il BMSG, fate questo:

1) inserite S 30:0 lffffffff ‘il vostro SN’

2) guardate gli indirizzi che trovate. Quelli buoni sono di solito quelli

a 30:80000000 e seguenti (il 30 è fisso!). Tanto per controllare,

andate a vedere a questi indirizzi con D <indirizzo> e scorrendo la

DATA WINDOW con ctrl+frecce (o alt, non me lo ricordo. Comunque, è

la finestra dove appare l’immagine della memoria). Molte volte qui

ci trovate direttamente, oltre a quello inserito da voi, il SN

giusto già calcolato!!

3) mettete un BPR (breakpoint-on-range) ai vari indirizzi che trovate

fino a trovare quello giusto. Di solito, quello giusto è quello dove

appaiono vicino al SN anche gli altri dati inseriti.

4) da qui, procedete come sempre.

Una nota sul Loader: lo potete usare, serve a farvi entrare nel debugger

dall’inizio del programma, per eseguirlo passo passo….. ma sinceramente

io non l’ho mai usato….

Beh…. non sò cos’altro dirvi…. naturalmente, applicando queste nozioni

generali, potete anche provare a crackare qualcosa di diverso dallo shareware.

Ad esempio, provate con il Cubase 3.0, che ha la chiave hardware. Vi posso

garantire che la protezione è una vera puttanata. Basta entrare nel debugger

“di rincorsa” non appena appare l’inizio del Cubase e mettere un BMSG WM_MOVE

per farlo tornare quando appare la finestra con scritto “Chiave non inserita”.

Di qui, trovate il jump condizionale ed è fatta…….

——————————————————————————

APPENDICE: PATCHERS, TSR, TRAINERS

——————————————————————————

1.1 Il PATCHER. Per distribuire i vostri crack!

Dunque, che cos’è un patcher? Semplicemente, è un programma che vi permette

di distribuire a giro il vostro crack. Cioè, contiene delle istruzioni che

vanno a scrivere sul file originale in modo da “sproteggerlo”. Dunque,

bando alle ciance, via agevolo il mio PATCHER UNIVERSALE in Turbo Pascal 7,

che potete compilare e usare voi.

Premetto che, per fare dei patch dovete avere:

1) I bytes originali e quelli cambiati (deducibili come spiegato, nel

SoftICE assemblando l’istruzione voluta e andando a vedere in memoria a

quali bytes corrisponde). Più, naturalmente, un pò di bytes prima e dopo

quelli che volete cambiare.

2) Un disk-editor (uno qualsiasi, io ho l’HEXED che si trova su internet)

3) L’ UNP, per scompattare gli eseguibili che, essendo crunchati, non vi danno

la possibilità di trovare al loro interno i bytes desiderati. Anche questo,

si trova su internet.

4) L’offset (cioè la posizione nel file) dei bytes da cambiare.

Lo vedete nel disk editor (mi raccomando,in decimale!)

5) La lunghezza del file bersaglio, per evitare che il patcher possa

modificare file con nome uguale, ma magari versione diversa.

//////////////////////////TAGLIATE QUI////////////////////////////////////////

{$I-}

(* Simply follow the comments inside the file to customize your patch *)

(* This proggy is TOTALLY free, i wrote it for myself to speed-up patching*)

(* However, if you keep the “written by XOANON” lines, i will be glad!*)

(* Hello to all crackerz/phreakerz/hackerz worldwide! *)

(* Compile with Borland Turbo Pascal 7 or higher *)

uses

dos, crt;

var

f : file of char;

c: char;

filnam: string [80];

filsiz: longint;

size: longint;

a, i, x : integer;

procedure drawscreen;

begin

writeln (‘ —————————————————————————-‘);

write (‘ – ‘);

gotoxy (69,2);

writeln (‘ -‘);

gotoxy (1,3);

writeln (‘ —————————————————————————-‘);

textcolor (8);

gotoxy (10,2);

write (‘General Purpose Patcher 1.0 – Written by [>X0aN0n<] in 1996’);

delay (140);

gotoxy (10,2);

textcolor (7);

write (‘General Purpose Patcher 1.0 – Written by [>X0aN0n<] in 1996’);

delay (140);

gotoxy (10,2);

textcolor (15);

write (‘General Purpose Patcher 1.0 – Written by [>X0aN0n<] in 1996’);

delay (140);

textcolor (7);

writeln;writeln;writeln;

write (‘ ‘);

textcolor(15);

write (‘[PrOgRaM NaMe] : ‘);

textcolor (7);

(* Write in the line below the name of the program *)

writeln (‘Cubase Score 3.0 for Windows ‘);

write (‘ ‘);

textcolor(15);

write (‘[PaTcH DoNe By] : ‘);

textcolor (7);

(* Write in the line below the author of patch *)

writeln (‘Xoanon ‘);

write (‘ ‘);

textcolor(15);

write(‘ [FiLe T0 RaPe] : ‘);

textcolor(7);

(* Write in the line below the name of the file to be patched *);

writeln (‘CUBASESC.EXE ‘);

write (‘ ‘);

textcolor (15);

write (‘ [TyPe 0f PaTcH] : ‘);

textcolor (7);

(* Write in the line below the type of the patch *)

writeln (‘Dongle Crack -100%- ‘);

write (‘ ‘);

textcolor (15);

(* Write in the line below the results obtained patching the file*)

write (‘ [ReSuLtZ] : ‘);

textcolor (7);

(* Write in the line below the results obtained patching the file*)

writeln (‘Simply, now your Cubase works! ‘);

write (‘ ‘);

textcolor (15);

write (‘ [ByTeZ ChAnGeD] : ‘);

textcolor (7);

(* Write in the line below how many bytes the patch will go to change*)

writeln (‘2 ‘);

write (‘ ‘);

textcolor (15);

write (‘ [NoTeZ] : ‘);

textcolor (7);

(* In the writeln lines below, you can add some notes (I.E. how to run the patch) *)

writeln (‘Run this patch in your Cubase directory to crack it. ‘);

write (‘ ‘);

write (‘ ‘);

writeln (‘Personally, i see my patch more stable than others, bcoz’);

write (‘ ‘);

write (‘ ‘);

writeln (‘using it there are less “General Protection Errors”. ‘);

write (‘ ‘);

write (‘ ‘);

writeln (‘But, try it yourself…….’);

writeln;

writeln;

end;

begin

clrscr;

drawscreen;

assign (f, ‘CUBASESC.EXE’); (* Write here the name of file to be patched*)

filnam := ‘CUBASESC.EXE’; (* Write here the name of file to be patched*)

filsiz := 2478080; (* This is the lenght of file to be patched*)

reset (f);

size := filesize (f);

a := IOResult;

if a <> 0 then (*Error, file not found*)

begin

sound (220);

delay(120);

nosound ;

writeln ;

textcolor (15);

write (‘Error 1:’);

textcolor (7);

write (‘ File ‘,filnam);

writeln (‘ not found. Check your directory.’);

writeln;

halt (1)

end else (* File found but filelenght doesn’t match*)

begin

if size <> filsiz then

begin

sound (220);

delay (120);

nosound;

writeln;

textcolor (15);

write (‘Error 2:’);

textcolor (7);

write(‘ File ‘,filnam);

write (‘ must be ‘,filsiz);

writeln (‘ bytes long.’);

writeln (‘ Probably you have an incorrect/packed version.’);

writeln;

halt (1);

end else

(*Everything is OK, let’s PATCH!*)

(* First, we check if the file is already patched*)

seek (f,585299); (*File offset of byte 1*)

read (f,c);

if c <> #116 then (*This is the ORIGINAL value of byte 1, decimal of course*)

begin (*Now we patch the file to its original state*)

(*The following lines depends on how many bytes you have to change*)

(*In this case, there are 3 bytes*)

(*If you have more, simply copy the first 3 lines 2,3,4,5,etc. times*)

(*The bytes must be entered in decimal format, I.E the NOP code $90 must be entered as #144*)

(*In all these line you must enter the ORIGINAL value of the bytes*)

seek (f, 585299); (* File offset of byte 1*)

c := #116; (* Byte to write *)

write (f, c);

seek (f, 585300); (* File offset of byte 2*)

c := #2; (* Byte to write*)

write (f, c);

sound (220);

delay (120);

nosound;

writeln (‘File already patched. Now, back to original state.’);

writeln;

end else

(*The following lines depends on how many bytes you have to change*)

(*In this case, there are 3 bytes*)

(*If you have more, simply copy the first 3 lines 2,3,4,5,etc. times*)

(*The bytes must be entered in decimal format, I.E the NOP code $90 must be entered as #144*)

begin

seek (f, 585299); (* File offset of byte 1*)

c := #144; (* Byte to write *)

write (f, c);

seek (f, 585300); (* File offset of byte 2*)

c := #144; (* Byte to write*)

write (f, c);

sound (220);

delay(120);

nosound ;

writeln (‘File successfully patched.’);

writeln;

end;

end;

end.

//////////////////////////TAGLIATE QUI////////////////////////////////////////

Beh, anche se i commenti sono in inglese (l’ho fatto per distribuirlo su

internet….. la traduzione mi sembra superflua….) si dovrebbe capire bene.

Basta andare a sostituire i valori indicati, se ci sono più bytes da cambiare

si deve copiare alcuni pezzi più volte…. insomma, è già tutto fatto.

L’importante è convertire i bytes in HEX in decimale, con una qualsiasi

calcolatrice…. Avete notato la funzione di unpatching? Bellina eh?

Una cosa da notare: quando non trovate i bytes nel file, può essere perchè

gli indirizzi li cambia direttamente in memoria, e quindi nel file non

trovate solo l’offset. Quindi, cercate magari qualche byte prima (magari

segnatevi i bytes delle istruzioni PUSH e POP precedenti, che quelle le

trovate sempre) e andate a occhio. Tutto qua!

1.2. I TSR. Quando il patcher non basta……

Che cos’è il TSR? è un programma che và a modificare il contenuto della

memoria in maniera dinamica, ossia mentre il programma viene eseguito.

Serve principalmente quando il file magari è compattato in una maniera

proprietaria e non potete quindi trovarvi dentro i bytes.

Premetto che un TSR non lo sò scrivere, quindi, per evitare di sbattere le

palle a Moonshadow per farmelo in assembler, vi dico come usare un programmino

che trovate insieme al G3X, il TSRCRACK.

Dunque, funziona così:

1) Create un file testo del tipo

INT numero < interrupt al quale si aggancia. Deve essere nello stesso CS

dell’istruzione. Per trovarlo, usate la funzione INT MONITOR

del G3X su un interrupt di uso comune, es. il 21

IF CS:0000:ipdell’istruzione = byte1 byte2 byte3 byte4 (….)

THEN CS:0000:ipdell’istruzione = bytenew1 bytenew2 bytenew3 bytenew4 (…)

2) Tornate al DOS e scrivete TSRCRACK nomefile.txt. Et voilà, TSR pronto.

Naturalmente, lo dovete caricare SEMPRE, prima del programma protetto.

Questo metodo vale solo per i programmi che non usano il DOS4GW, e comunque

che non usano dos-extenders. Per questi particolari programmi, bisogna creare

dei TSR ad-hoc, e io….. non sono ancora in grado. Al limite, chiedete a

Moonshadow….

Comunque, niente paura: la quasi totalità dei programmi (anzi, diciamo pure

tutti) non richiede TSR. Basta un patch!!!

1.3. Trainers, come finire i giochi senza cheat-mode!

Qui sarò sbrigativo. Il metodo descritto funziona solo con i giochi non in

protected mode (quindi niente DOS4GW o extenders vari).

1) Caricate il G3X

2) Caricate il gioco, iniziate a giocare

3) Entrate nel G3X e scegliete GLOBAL ANALYSIS, BYTE, <return>

4) Tornate al gioco e perdete una vita o fate diminuire l’energia o il tempo

5) Entrate nel G3X, GLOBAL ANALYSIS, DECREASE

6) Ripetete dal punto 4 al 5 per un pò di volte, fino a quando non trovate

una locazione giusta….. cioè, con i valori es. 04 03 02 01

7) Mettete un BP Read-Write a quella locazione

8) Tornate al gioco, riperdete una vita/energia/tempo

9) Quando torna al debugger (se la locazione è giusta) segnatevi i bytes

dell’istruzione (di solito un DEC) e da qui in poi, procedete come

se fosse un crack qualsiasi (disk editor, patcher)

Non vi allego il patcher modificato, tanto penso che la cosa sia intuitiva.

Praticamente, basta cambiare le scritte, il procedimento è lo stesso.

Considerate che quando fà il patch mette il trainer, quando fà l’unpatch

riporta il gioco in condizioni normali.

Essendo ora tutti i giochi in protected mode, comunque, questo metodo funziona

solo con i giochi vecchi….. oppure con gli emulatori tipo C64S (però in

questo caso non fate il patcher, meglio caricare il G3X in memoria ogni

volta che si vuol giocare!). Se volete fare trainer per i giochi in DOS4GW,

meglio prendere qualcosa tipo il GameWizard32 (lo trovate su internet).

——————————————————————————

CONCLUSIONI E CONSIDERAZIONI FINALI

——————————————————————————

Dunque, siamo alla fine. Spero che questo tutorial vi sia servito, io da parte

mia ho cercato di farlo nel migliore dei modi, accessibile a tutti.

Non pensate comunque di riuscire a crackare qualcosa alla prima, il tutto

richiede logicamente un pò di pratica. Man mano che proverete, comunque,

troverete tutto più facile di volta in volta.

Per trovare i programmi necessari (SoftICE x Windows95, se volete anche per

DOS, e il disk editor), basta cercare con AltaVISTA o simili la parola “Hack”

o “Crack” o “Phreak”. Troverete migliaia di siti, basta cercare un minimo

e troverete quello che cercate.

Inoltre, scarivatevi *SUBITO* la guida di +ORC (la migliore al mondo e penso

nell’universo) …. le varie parti abbastanza aggiornate le trovate a

www.dodgenet.com/~kwantam nella sezione “Hacking Textz”. Ci sarebbe anche il

sito quasi-ufficiale di +ORC, ma quello non ve lo dico…. vi rovinerei il

divertimento nel cercarlo….. sappiate solo che con i vari spiders non lo

troverete mai, quindi …. l’unica è rovistare tra i vari links nelle pagine

hackers per vedere se scovate qualcosa! Eh eh eh…..

Sicuramente ho tralasciato qualcosa (e chi non lo fà), ma d’altra parte non

potevo certo spiegarvi TUTTE le situazioni (cambiano sempre)….

Del resto, basta un pò di pratica e troverete da soli le risposte alle vostre

domande! Ah, dimenticavo: >>>>>NON MI E-MAILATE TANTO NON VI RISPONDO<<<<<<.

(O, swanne, mi raccomando eh? ir tegame di tu ma se mandi ir mi indirizzo a

giro….. un mi vorrai mia fà arrestà eh? sennò poi l’artiolini ganzi chi

te li scrive….. via swanne, ammodino eh, che se stai bono ti fo’ anche

ir crachin manua’ in livornese!)

Special Greetings to: MoonShadow (Assembler Consultor)

All the PiNNACLE Crew (Zima Man,Hyper,Blaze,Joker,

Silky,MrMox,X-con and

the others)

Trencher (For the long time spent together in

cracking….. and for helping me

in programming the first patcher i

did!)

Colonel (Moral Support)

Beppe (Moral Support)

All the rest of MeltBody Team (Moral Support)

Mamma e Babbo (Per le sigarette fornite… in tutto

penso 2 pacchetti in 1 settimana di

duro lavoro)

H A P P Y

C R A C K I N G

. . . .

*** ** * * * * * * **

*** ** . . . **

*** *** *** ****** ** ** *** ** **

*** *** ** ** ** ** *** ** ** ** *** **

*** ** ** ****** ** *** ** ** ** ***

** ** ** ** *** ** ** ** ** ** ** **

*** *** *** ** ** ** * *** ** *

*** ** ** ……………….

*** **** .PiNNACLE Industries.

** ** . Chief Cracker .

……………….

STAI CERCANDO PRODOTTI PER L’HACKING, LA SICUREZZA INFORMATICA E IL PENETRATION TESTING? HAI BISOGNO DI BONIFICARE IL TUO SMARTPHONE, IL TUO PC O IL TUO SITO DA VIRUS E MALWARE? DEVI RINTRACCIARE UNA PERSONA O RECUPERARE DELLE INFORMAZIONI URGENTI? DEVI RIPRENDERE POSSESSO DI UN ACCOUNT, UNA MAIL O DI UNA PASSWORD CHE TI HANNO SOTTRATTO? VUOI ACQUISTARE DEVICE GIÀ CONFIGURATI PER SPERIMENTARE TUTTE LE TECNICHE DI HACKING IN MODO FACILE E VELOCE? HAI ESIGENZE PARTICOLARI IN AMBITO SOFTWARE O HARDWARE?POSSIAMO AIUTARTI  ! CLICCA SUBITO SUL BOTTONE ROSSO QUI SOTTO OPPURE CONTATTACI TRAMITE WHATSAPP O COMPILANDO E INVIANDO IL MODULO SOTTOSTANTE.

chevron_left
chevron_right

Disclaimer : Tutte le tecniche, i prodotti e i servizi presenti o descritti su questo sito si intendono a scopo puramente informativo, di studio o di aggiornamento professionale e per testare esclusivamente la sicurezza e la funzionalità della propria rete informatica o degli account di cui si è legittimi proprietari o per i quali si dispone l'autorizzazione ad attività di hardening o di penetration testing da parte dei legittimi titolari in accordo alle vigenti normative sull'accesso a sistemi informatici e telematici (cfr. art. 615 ter c.p. e successive modifiche). HackerSecret declina ogni responsabilità per ogni ulteriore utilizzo al di fuori di tale ambito che è di esclusiva resposabilità individuale ai sensi delle vigenti leggi e per eventuali danni o problematiche causate dall'utilizzo delle tecniche, dei prodotti o dei servizi presenti o descritti nel sito ai propri sistemi o apparati informatici o per la perdita di dati sensibili e non conseguente all'utilizzo di tali tecniche, prodotti o servizi.