segunda-feira, 16 de julho de 2012

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. 

6 comentários:

  1. Já encontrei vários jogos multiload, que foram convertidos por vc, FMM :-)
    Como vc obtinha informação naquela época? Ou, além da dificuldade de ferramentas (sem emulador), vc levantou tudo no 'braço'?

    ResponderExcluir
    Respostas
    1. Muito dessa história se perdeu pois acabei jogando muita coisa fora. Mas fora alguns livros (T. Baker, R.J.Simpson&J.Terrell e I.Logan&F.O'Hara), eu só me baseava no manual da IDS-91 e um texto (provavelmente do Otto) sobre rotinas da Beta. Também teve uma série da Your Sinclair que me ajudou muito, disponível agora em: http://www.worldofspectrum.org/showwrap.cgi?page=index.html.

      O resto era 'na unha', com ajuda valiosa da Multiface 1 com o Genie. Pena que não me lembro mais dos detalhes. Quem sabe se eu disassemblar as antigas adaptações, eu possa recuperar parte das memórias.

      Excluir
  2. Ow taí um comentário que iria fazer também, você pode contar um pouco sobre aquela época, conta um pouco da sua história Flávio, pq escolheu a química etc etc?! :)

    ResponderExcluir
    Respostas
    1. Uma parte desta história escrevi no site: http://garrettimus.org/CantinhoSpeccy/save/MeuRelato.html.

      Eu comecei a fuçar com eletrônica criança ainda, desmontando aparelhos quebrados com um ferro de solda que era aquecido na boca de fogão. Aos poucos, fui me instruindo graças a revistas de bancas, especialmente o Saber Eletrônica e o DCE. Mais tarde surgiu o boom da computação da década de 1980, que acabou me fisgando também. Já existia na mesma época um grande interesse por Química também, mas este ficava praticamente na teoria (eu só via através de livros), enquanto a Eletrônica e Computação eu tinha como brincar. Talvez isto tenha sido um dos motivos que me levaram a este ofício.

      Excluir
  3. Vc citou o Otto (rotinas da beta)...eu tenho essa curiosidade. Será que a rotina para os multiload, nasceu na CBI?
    Pois quando eu comprei a CBI, não se falava dessas adaptações. Com o passar do tempo apareceram os primeiros jogos. No R-Type, foi onde eu ví o nome do Otto. Infelizmente o próprio Otto já disse na lista, que não lembra muita coisa desse tempo.

    ResponderExcluir
    Respostas
    1. Boa pergunta, não me lembro qual foi o primeiro multiload adaptado para Beta que eu vi. Só sei que graças ao R-Type e outros que acabei me animando a fazer as minhas próprias adaptações.

      Excluir

Seu comentário é bem vindo, mas peço que use este espaço adequadamente.