Adaptação de jogos de fita para Beta 48 (parte 6)

Até a parte anterior apresentamos procedimentos como se fosse efetuados em um TK90X real, os quais valem também para qualquer emulador. Na sequência, estaremos cada vez mais explorando os programas que têm algum esquema de proteção de gravação em fita, que exige cada vez mais análise de disassembly e eventualmente criar algumas rotinas em assembly. Torna-se então necessário interromper código de máquina durante sua execução, para analisar o disassembly ou fazer outras operações. 

Nas épocas "heroicas" em que não existiam PC com emulador, eram usados monitores de código de máquina e disassemblers e a imbatível Multiface 1 com o programa Genie. Para aumentar o "heroísmo", impressora não era coisa de pobre, portanto éramos obrigados a copiar as listagens à mão numa folha de papel (eu tinha muitas listagens que, infelizmente, foram descartadas antes de me mudar para Curitiba). 

Hoje a realidade é diferente, podemos usar todo o poder de processamento e armazenagem de PC moderno. O que substitui - com vantagens - a Multiface 1 é o monitor e debugger dos emuladores. Eu estarei mostrando os exemplos no Fuse, pois é o que utilizo mais, porém existem vários outros, como o excelente SpecEmu disponível na webpage do José Roberto que emula também a interface CBI-95 e a Multiface 1. Apesar de ter tido alguns problemas em versões mais antigas, a versão 1.5.0 do Wine consegue rodar o SpecEmu no Linux. 

Como exemplo, eu mostrarei a adaptação do Sanxion 128 que fiz para a coleção AY Games de jogos para a Explorer. O seu carregador BASIC não tem nada de extraordinário:

10 PAPER 0: INK 0: BORDER 0: CLEAR 32767
20 LOAD "" CODE
30 RANDOMIZE USR 64768

Definindo a RAMTOP com CLEAR 32767 e carregando o código de máquina com LOAD "" CODE, é possível obter o seguinte disassembly:

64768   DI              ; Desabilita interrupção.
        LD HL,64896     ; Endereço inicial.
        XOR A           ; Inicializa registrador R com 0.
        LD R,A
64775   LD A,R          ; Pega valor do registrador e faz operação
        XOR (HL)        ;OU EXCLUSIVO com byte no endereço em HL e
        LD (HL),A       ;guarda o resultado na RAM.
        INC HL          ; Fazer HL apontar para próximo endereço.
        LD A,H          ; Repetir todo o laço até o endereço 65535.
        OR L
64782   JP NZ,64775     ; Se o endereço for 0 (após 65535), saltar
64785   JP 64896        ;para endereço 64896. 

Mas o que significaria tudo isto? Como é um assunto importante, eu estou interrompendo para explicar.

Decodificador

Embora o uso de linguagem de máquina tenha afugentado muitos pretensos piratas, não tardaram a surgir hackers que se sentiam confortáveis em decifrar listagens de disassembly. Para os desencorajar, surgiram programas que os código de máquinas estavam camuflados de alguma forma. Antes de rodar, havia uma ou mais rotinas de descodificação, conhecidas como decodificadores.

O decodificador pega um byte armazenado num dado endereço, aplica uma operação e o transforma em outro valor para armazenar de volta na memória, no mesmo endereço ou em outro lugar. No exemplo acima, um byte é lido da memória, feita uma operação com o registrador R e depois recolocado no mesmo lugar. Este é um registrador do Z80 que não é muito comum ter uso em programas assembly, mas que tem a característica de mudar de valor de forma reprodutível. O que torna atrativo seu uso em decodificadores é o fato de que, para tentar prever seu valor durante a execução de um programa, dispende-se muito trabalho, pois depende das instruções sendo executadas pelo Z80.

O papel da codificação é tornar o disassembly mais inacessível e ilegível possível. Resumindo, um decodificador é um programa que transforma um monte de bytes sem sentido num programa de linguagem de máquina operacional. Em esquemas de proteção como o Speedlock 7, cheguei a encontrar dezenas e dezenas de decodificadores que teriam que ser decifrados um a um. Felizmente no caso de Sanxion 128k, há somente um.

Como fazer para quebrar esta proteção? Como eu já disse, fazer manualmente é extremamente trabalhoso além de sujeito a erros humanos. Portanto a melhor forma é deixar que o próprio decodificador faça o trabalho, mas antes, uma providência deve ser tomada. No emulador, deve-se estipular um breakpoint, isto é, um endereço na qual o programa deve ser interrompido para abrir o modo de monitor/debugger. Já abordei extensivamente como funciona o breakpoint no Fuse, mas é fácil fazer algo parecido no SpecEmu e em outros emuladores, consulte a respectiva documentação.

No monitor/debugger do Fuse, use o comando:
br 64785
para definir um breakpoint em 64785. Este endereço é logo a seguir ao loop entre 64755 e 64782 que é o próprio decodificador. Agora carregue da fita no emulador e aguarde. Surgirá a janela do monitor/debugger que permitirá ter acesso ao disassembly a partir do endereço desejado 64896. Pronto, esta proteção está quebrada. Na parte 7 iremos ver a continuação da adaptação do Sanxion 128k.