Autore Topic: Unpacking And Decruncing  (Letto 1521 volte)

djwiper

  • Utente
  • **
  • Post: 197
  • Gioco Preferito: Sim City
Unpacking And Decruncing
« il: 24 Settembre 2004, 22:48:41 »
 Diversi giochi, specialmente quelli pubblicati su più dischi, vengono per così dire "zippati" in un solo disco dai crackers.

1) Se per me è semplicissimo far partire procdump32 e dumpare su disco un qualsiasi processo dalla RAM come era possibile fare altrettanto con i giochi su dischetto? Dove veniva salvato il processo "dumpato"? Qui sono abituato a "flushare" il thread di un programma sull'HD ma il buon vecchio cracker come faceva?

2) Ammettiamolo... 64Kb di ram sono un pò pochi (tenendo conto che una buona parte è comunque occupata dall'interprete BASIC ed altre locazioni sono riservate) per creare un programma in LM che decompattasse tali dati e farlo risiedere in memoria oltre al gioco. Quindi quanto doveva essere il rapporto di compressione?

3) Sicuramente mi sfugge qualcosa dal punto numero 2. Ipotizzo che in qualche maniera è possibile inserire un programmino che parte per primo edecompatta il gioco "zippato" precedentemente e lo esegue (un pò come fa l'UPX per sistemi Windows & Linux); ma con che algoritmo? Voglio dire ogni gruppo si creava una propria routine di packing/unpacking oppure c'è stato qualcosa di già pronto. :confused:

4) [OFF TOPIC] ma implementare un pò più di RAM era impossibile per questioni di costo oppure è stata una scelta di marketing? O forse in 64KB si fanno molte più cose rispetto a quante se ne farebbero nel pc che ho a casa, avente 8140,625 volte il quantitativo di RAM commodorense?

Spero di essere stato chiaro... S'è fatto tardi per me buonanotte a tutti ragazzi...

 :ciauz:  
Ho capito di odiare le firme...

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Unpacking And Decruncing
« Risposta #1 il: 24 Settembre 2004, 23:47:32 »
 Provo a spiegare, anche se e' piu' facile da fare che da dire.
Un programma compresso, sia sul c64 che su pc, deve avere per forza un entry point. Disassemblando e seguendo il flusso si arriva ad un punto in cui viene eseguita la jump all'entry point reale del programma decompresso. I prg compattati del c64, di solito, hanno la routine di decompressione che si copia in una zona di ram bassa, ad esempio $0100, e finiscono con un codice tipo
Codice: [Seleziona]
lda #$37
sta $01
cli
jmp $1000
non e' molto difficile a questo punto capire che il prg decompresso parte con una sys4096. :)
Con un c64 normale e' sufficiente patchare il codice sostituendo magari la
sequenza 85 01 con una D0 FE (sta $01 diventa una BNE *, un loop infinito a se stesso insomma) e a quel punto basta usare il monitor di una cartuccia tipo AR (o nel mio caso il monitor di CCS) e salvare la ram, magari prima settando la loc $01 a #$38, per far vedere tutta al ram anche sotto $A000-$BFFFf e $D000-$FFFF. Poi sta a te ripulire la memoria salvata da rimasugli e porcherie varie, magari confrontando il prg compresso con il decompresso, perche' spesso e volentieri rimangono parti anche del decompresso in memoria, dipende dal compattatore usato e se il file compresso e' stato o meno creato compattando un file che occupava tutta la ram o solo una parte.

Ogni compattatore e' diverso dagli altri, ognuno si faceva i propri e no, non c'e' mai stato niente di "pronto" tipo librerie sul c64, almeno non che io sappia. Il rapporto di compressione... non era nemmeno tenuto in considerazione o almeno non veniva mai citato, anche perche' varia da prg a prg. Si cercava solo di fare meno blocchi possibile.

Per quando riguarda la ram, il dubbio e' subito levato: il 6502/10 puo' indirizzare solo 64kb perche' ha un registro a 16bit per l'indirizzamento. 2^16=65536
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

djwiper

  • Utente
  • **
  • Post: 197
  • Gioco Preferito: Sim City
Unpacking And Decruncing
« Risposta #2 il: 25 Settembre 2004, 14:32:09 »
 Grazie Ian per la spiegazione.
Riguardo all'Entry point non ho capito molto. L'entry point non è la prima istruzione che un programma da alla cpu? Voglio dire:

Codice: [Seleziona]
Poke 53281,0

(perdonami se quello che segue è uno scempio, devo mettermi seriamente a studiare il LM)
Codice: [Seleziona]
LDA 0
STA 53281

L'entry point non è l'offset che contiene LDA 0? Ti dico questo perchè ci ho creduto fermamente fino a esattemente due minuti fa... Appena ho letto della JMP all'entry point ho capito che qualcosa non mi è chiaro.


Citazione
Con un c64 normale e' sufficiente patchare il codice sostituendo magari la
sequenza 85 01 con una D0 FE (sta $01 diventa una BNE *, un loop infinito a se stesso insomma) e a quel punto basta usare il monitor di una cartuccia tipo AR (o nel mio caso il monitor di CCS) e salvare la ram
Dove verrebe salvata la ram?  :confused:
E comunque perchè pubblicare il gioco in più dischetti?

 :ciauz:  
Ho capito di odiare le firme...

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Unpacking And Decruncing
« Risposta #3 il: 25 Settembre 2004, 20:15:23 »
 
Citazione
Riguardo all'Entry point non ho capito molto.[cut] devo mettermi seriamente a studiare il LM
Ecco bravo, altrimenti ogni spiegazione puo' cadere nel vuoto.

Citazione
L'entry point non è l'offset che contiene LDA 0?
Si, e' l'indirizzo (offset si usa in programmazione Dos, dove la memoria e' riferita in segmenti e offset, il 6502 non ha segmenti perche' vede tutta la memoria possibile)
Citazione
Appena ho letto della JMP all'entry point ho capito che qualcosa non mi è chiaro.
Vedo. un JMP salta ad un nuovo indirizzo, il codice di decompressione finendo con una JMP al di fuori dal proprio codice non e' altro che il salto all'entry point del programma decompresso.

Citazione
Dove verrebe salvata la ram?  :confused:
dove preferisci, disco, nastro, fogli di carta scrivendo a mano 01001010010011... etc
Citazione
E comunque perchè pubblicare il gioco in più dischetti?
errrrrr... la domanda e' malposta. Tu volevi chiedere: Che ore sono? :D
Se non ci sta su un floppy che fai?
1) non lo pubblichi
2) si mette il resto su un altro floppy
3) ti tocchi

Se vuoli levarti ogni dubbio non c'e' altro modo che disassemblare un prg o seguirlo passo passo con il monitor di Vice, ad esempio un prg che ha
10 SYS 2064
lo puoi debuggare settando un breakpoint:
break 0810
g 0810
e poi premendo Z[invio] segui le istruzioni. Magari attiva anche le window del disassemblato e dei registri cosi' segui attentamente il flusso.
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

djwiper

  • Utente
  • **
  • Post: 197
  • Gioco Preferito: Sim City
Unpacking And Decruncing
« Risposta #4 il: 26 Settembre 2004, 12:31:11 »
 
Citazione
errrrrr... la domanda e' malposta. Tu volevi chiedere: Che ore sono? biggrin.gif
Se non ci sta su un floppy che fai?
1) non lo pubblichi
2) si mette il resto su un altro floppy
3) ti tocchi

Ehm... vediamo un pò... lasciami pensare... Forse la due? ;)

Si, la domanda era malposta la riformulo:

Io ho fatto un gioco che gira in DOS. Compilato e con tutte le librerie mi va ad occupare 2 mega. Beh, in un dischetto non entra e perciò devo splittare il gioco in modo tale da farlo stare in due floppy da 1.44 (con conseguente lavoro di riprogrammazione e "insert disk n2" di conseguenza)! La storia finisce qui.
Poi un giorno scopro che pkzip *.* /e gioco.exe mi compatta tutto il gioco in 720KB, pergiunta in un file eseguibile!! WOW entra in un dischetto e mediante un file bat

Codice: [Seleziona]
pkunzip gioco.exe c:\gioco\
c:\gioco\start.exe
deltree /y c:\gioco

posso automaticamente decompattarlo nella directory gioco del disco fisso, farlo partire e addirittura cancellarlo!
Da quanto ho capito anche nel glorioso Commodore si poteva comprimere un gioco da due dischetti a uno, o da tre a due e via dicendo. Non capisco perchè, ed è qui la domanda, questo lavoro non veniva fatto "a monte" da chi pubblicava il gioco...
Ho capito di odiare le firme...

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Unpacking And Decruncing
« Risposta #5 il: 26 Settembre 2004, 17:25:17 »
 
Citazione da: "djwiper"
Non capisco perchè, ed è qui la domanda, questo lavoro non veniva fatto "a monte" da chi pubblicava il gioco...
Prova a comprimere 171K (o piu') di dati su un c64 e te ne accorgerai del solo del perche' non veniva fatto :D
Molti gruppi hanno elaborato dei level packer con turboloader e turbosave, ma cmq il tempo impiegato a comprimere e' certamente superiore, quindi era una magra consolazione. Io usando un "advancded Levelpacker" ho impiegato diverse ore a comprimere i livelli di Typhoon, da emulatore e con il CCS al 500%. Ti lascio immaginare a farlo su un c64 vero.
Oggi per fortuna esistono i cross-crunchers e non si pone il problema.
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

djwiper

  • Utente
  • **
  • Post: 197
  • Gioco Preferito: Sim City
Unpacking And Decruncing
« Risposta #6 il: 27 Settembre 2004, 09:19:05 »
  :hail: Grazie Ian, mi è tutto più chiaro adesso!
 :ciauz:  
Ho capito di odiare le firme...