O erro no disco mestre de Space Quest II
(lanceewing.github.io)- O Space Quest II 2.0D/2.0F Disk 1 de 720KB da Sierra On-Line continha código-fonte do interpretador AGI que não aparecia na lista de arquivos, um caso em que um erro na preparação do disco mestre foi copiado exatamente para os discos comerciais
- No FAT do DOS, excluir um arquivo não apaga os dados; apenas marca os setores como não utilizados, então, se um disco não formatado for usado como mestre, dados anteriores podem acompanhar todas as cópias
- Na área “free” de 402.432 bytes do Disk 1, em vez do valor de preenchimento de formatação 0xF6, restaram fontes em C/assembly, e a extração confirmou 93 arquivos, mais de 15.000 linhas e cerca de 70% do código-fonte do interpretador AGI
- Como o equipamento de duplicação FormMaster copiava todos os setores do disco byte a byte, e não no nível de arquivos, é possível que até dados excluídos que não estavam na lista real de arquivos tenham se espalhado para discos de clientes e varejistas
- Esse erro, ocorrido em março de 1988 no fim da era AGI, ficou escondido até a primeira descoberta conhecida por NewRisingSun em outubro de 2016, tornando-se 36 anos depois um material de arqueologia digital para examinar a implementação do AGI da Sierra
Rastros que não apareciam só pela lista de arquivos
- Os disquetes de 720KB do Space Quest II versão 2.0D e 2.0F não tinham nada de especial na aparência, e a lista de arquivos também parecia a de um disco comum de jogo da Sierra
- No diretório da 2.0D não havia arquivos extras suspeitos, e os principais arquivos de dados, como PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0 e VOL.1, foram criados em 14 de março de 1988
- Os arquivos
.OVLtêm timestamp de 15 de março de 1988, e o código do interpretador AGI tem timestamp de 18 de março de 1988, deixando um rastro de que a preparação do Space Quest II 2.0D no escritório da Sierra ocorreu ao longo de uma semana - O espaço usado no disco era de 302.918 bytes, e o espaço “free” aparecia como 402.432 bytes, ou seja, o espaço vazio era maior que o espaço usado
A área não utilizada revelada por um editor hexadecimal
- No DOS, os setores não utilizados de um disquete recém-formatado normalmente são preenchidos com o valor de formatação 0xF6
- No Disk 2 do Space Quest II 2.0D, os setores não utilizados estavam preenchidos com 0xF6, mas no Disk 1 não havia um único setor não utilizado preenchido com 0xF6
- No Disk 1, a maior sequência contínua de bytes 0xF6 tinha apenas 2 bytes e, embora mais da metade do espaço aparecesse como “free”, na prática os dados anteriores continuavam lá
- Na área marcada como não utilizada havia texto que parecia código-fonte em C, o que sugere fortemente que esse disco foi usado para outro fim antes de servir como mestre do Space Quest II Disk 1
- No sistema de arquivos DOS FAT, excluir um arquivo não remove os dados de fato; apenas marca os setores para reutilização, então, se arquivos novos não sobrescreverem esses setores, o conteúdo anterior permanece intacto
O código-fonte do interpretador AGI que ficou para trás
- Ao extrair o texto ASCII da área não utilizada, apareceram funções em C como
DisplayStatusLineeStatusLineOn DisplayStatusLineé o código que mostra uma linha de texto com a pontuação atual e o estado on/off do som, ligada à barra de status branca no topo da tela de Space Quest II- Esse código não pertence aos dados do jogo, mas ao próprio interpretador AGI da Sierra
- Havia uma grande quantidade de código-fonte nos setores não utilizados, e como o código estava armazenado em setores contíguos, foi relativamente fácil extraí-lo e separá-lo por arquivo
- No topo de cada arquivo havia comentários indicando o nome do arquivo-fonte, o que facilitou encontrar os pontos de divisão, e o resultado da separação foi de 93 arquivos ao todo
- 75 arquivos-fonte em C
- 16 arquivos-fonte em assembly
- 2 arquivos DOS BAT
- O código totaliza mais de 15.000 linhas, e a maioria dos arquivos estava completa
- Esse disco continha cerca de 70% do código-fonte do interpretador AGI da Sierra On-Line, incluindo comentários e histórico de mudanças
Histórico de mudanças e rastros dos desenvolvedores
- Alguns comentários de cabeçalho no topo dos arquivos-fonte incluem Change History
- O cabeçalho de
ANIMATE.Ctraz o nome do arquivo-fonte, uma descrição curta dizendo que ele “processa um ciclo de animação em um adventure game” e informações comocompile: MWC MWCparece ser o compilador C da Mark Williams, bastante usado na época- O histórico de mudanças inclui data, hora, iniciais de quem alterou e descrição da modificação
- Entre as iniciais, JAS corresponde a Jeff Stephenson, que trabalhou principalmente no código do interpretador AGI, e DCI corresponde a Chris Iden
- Robert Heitman também aparece, mas seu foco principal eram ferramentas gráficas como o Picture Editor e o View Editor, enquanto Jeff Stephenson e Chris Iden cuidavam principalmente do código do interpretador
O mapa de memória do AGI.EXE e o cálculo dos 70%
- Além dos 93 arquivos-fonte, o Space Quest II 2.0D 720KB Disk 1 também continha o mapa de memória do executável AGI.EXE com mais de 2.000 linhas
- Nos jogos AGI lançados comercialmente, o nome do executável do interpretador era simplesmente
AGIe não podia ser executado diretamente, mas durante o desenvolvimento era usado um interpretador diretamente executável com a extensão.EXE - Alguém da Sierra gerou o mapa de memória do AGI.EXE, isto é, do interpretador AGI, em 7 de outubro de 1987
- Essa data bate com o fato de que o comentário mais recente no histórico do código-fonte é de setembro de 1987
- O mapa de memória fornece, de forma relativamente completa, a lista de módulos e arquivos-fonte que compunham o interpretador AGI
- Há 98 arquivos-fonte distintos no mapa de memória, e entre eles 71 arquivos existem em forma completa no disco do SQ2
- Com base nessa proporção, calcula-se que o disco do Space Quest II continha cerca de 70% do código-fonte do interpretador AGI
- Alguns módulos incluem apenas arquivos de cabeçalho C e, por isso, não entram nesse cálculo
O AGI como propriedade intelectual da Sierra
- A Sierra On-Line passou por um período comercialmente difícil por volta do lançamento de King’s Quest em 1984, e Ken Williams teve de demitir cerca de 100 funcionários, reduzindo a equipe de aproximadamente 130 para cerca de 30 pessoas
- Depois disso, o sucesso do sistema de jogos de aventura AGI e dos jogos feitos sobre ele ajudou a mudar a situação da empresa
- No fim de 1984, King’s Quest entrou no top 20 das paradas de venda de software de jogos para computador e permaneceu lá por cerca de meio ano, até o lançamento de King’s Quest II
- O acordo com a Tandy Radio Shack, que vendeu versões Tandy dos jogos nas lojas Radio Shack, também ajudou
- De 1985 a 1988, os jogos AGI continuaram best-sellers, e o interpretador AGI era uma importante fonte de receita e uma peça central da propriedade intelectual da Sierra On-Line
- O fato de 70% do código-fonte do interpretador AGI ter sido copiado em massa e entregue a dezenas ou centenas de milhares de clientes foi um grande erro do ponto de vista da Sierra
As consequências de um disco mestre sem formatação
- Quando a Sierra preparava o lançamento de um novo jogo, criava um disco mestre de production copy para usar no equipamento de duplicação de discos FormMaster
- O FormMaster não copiava apenas os arquivos do disco mestre; ele copiava todos os setores do disco byte a byte, independentemente de estarem em uso ou não
- No Space Quest II 2.0D e 2.0F Disk 1, por causa desse método, até os 402.432 bytes que não estavam sendo usados como arquivos reais foram copiados junto
- No processo de preparação do disco mestre, o disco precisava ser completamente formatado antes de copiar os arquivos do jogo, e a Sierra executou corretamente essa etapa na maioria dos discos originais de seus jogos
- No Space Quest II 2.0D Disk 1, porém, alguém aparentemente esqueceu essa etapa de formatação, e o mesmo disco também foi usado na 2.0F
- Como resultado, é possível que dezenas ou centenas de milhares de discos de SQ2 enviados a clientes e varejistas tenham levado escondidos 70% do código-fonte do interpretador AGI
Um caso de arqueologia digital conhecido só em 2016
- Quase certamente esse caso foi um erro não intencional, e parece que nem a Sierra, nem concorrentes, nem clientes perceberam isso na época
- A primeira descoberta conhecida foi feita pelo usuário online NewRisingSun em outubro de 2016
- Também é importante que isso tenha acontecido no fim da era AGI
- Em março de 1988, a Sierra já havia desenvolvido o sistema de jogos de aventura SCI
- Ela estava prestes a lançar King’s Quest IV, o primeiro jogo a usar SCI
- Se esse vazamento acidental do código-fonte do interpretador AGI tivesse ocorrido 1 ou 2 anos antes, o problema poderia ter sido maior
- O código-fonte extraído do interpretador AGI foi enviado para o repositório no GitHub
- A implementação AGILE, um interpretador AGI baseado na web, originalmente recebeu alguma ajuda de partes desse código-fonte
1 comentários
Opiniões do Hacker News
A versão para DOS de 1989 de Double Dragon II: The Revenge foi distribuída em dois disquetes, e um deles continha todo o código-fonte na forma de um arquivo compactado apagado
Ele não aparecia no comando
DIR, mas era fácil de recuperar: https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)É engraçado que, mesmo numa época em que literalmente cada byte custava dinheiro, houve muitos casos em que entradas FAT de alguém acabaram gravadas em cartuchos
https://forums.nesdev.org/viewtopic.php?t=17324
Imagino que eles tenham finalizado o jogo, criado algum tipo de disco master e enviado para a fábrica de produção em massa; então me pergunto como o arquivo compactado apagado foi parar no master. Talvez tenham copiado por engano e apagado antes do lançamento
O primeiro também foi naquele mesmo computador: a versão DOS de Spacewar!. Se a memória não me falha, o jogo travava quando se chegava ao chefe, então nunca consegui terminar Double Dragon II, mas é uma boa lembrança
Ultimamente tenho feito bastante engenharia reversa de ROMs de sintetizadores
A ROM do Yamaha DX9 tinha fragmentos de uma tabela de símbolos do firmware em espaços vazios que sobraram no binário[0], além de um bloco grande de código 6303 que provavelmente veio do sistema de desenvolvimento. Encontrar esse tipo de coisa por acaso dá uma sensação realmente incrível. Fiquei tão imerso nisso que me senti como um arqueólogo de software dando uma espiada no passado, e acabei entrando fundo numa toca de coelho para tentar descobrir quais ferramentas de desenvolvimento a Yamaha usava. Não encontrei nada conclusivo, mas ler a documentação das ferramentas de desenvolvimento da época aumentou minha gratidão pelos fluxos de trabalho modernos
0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...
Fiz muita E/S bruta e análise de setores brutos de disco no BeBox, e o BeOS tinha boas ferramentas para hacking de sistemas de arquivos. Com isso, criei um driver de sistema de arquivos para Windows, que funcionava bem o suficiente para receber apoio da Yamaha. Se algum dia você se animar a fazer engenharia reversa da ROM da Yamaha para o A-sampler, entre em contato. Tenho muito interesse nessa área. O trabalho com o DX9/DX7 também é excelente e, como usuário dos dois sintetizadores desde o lançamento, acho realmente fascinante
Este jogo teve um peso tão forte na minha infância que, pensando nele hoje, depois de tanto tempo, ele parece quase um sonho
Imaginar que eu teria, na minha vida atual, o mesmo tipo de conexão com algum jogo parece impossível. Tudo ao meu redor parece apenas um jogo, uma série ou um objeto, mas Space Quest 2, 3 e 4 estão entrelaçados como uma parte fundamental do meu DNA
Os jogos da Sierra daquela época eram realmente especiais. Em particular, joguei muito Police Quest II, LSL III e Hero's Quest por volta do mesmo período. Havia algo mágico nos jogos EGA da Sierra baseados em texto e, para mim, eles ocupavam o ponto certo de conexão emocional e criativa entre a Infocom e as versões VGA point-and-click que vieram depois
Space Quest também está ligado a uma das minhas histórias favoritas da internet primitiva. Na época em que sites eram hospedados principalmente no Geocities e por universitários entediados, havia um fansite de Space Quest, e eu mandei um e-mail ao administrador de um dos grandes sites de SQ dizendo que gostava dos jogos e do site. Eu devia ter uns 14 anos, e ele respondeu que poderia me mandar os jogos originais por cerca de 40 dólares. Eram todos os originais, com as caixas e disquetes. Como era por volta de 1997, fiquei um pouco preocupado em mandar 40 dólares para um desconhecido do outro lado do país e esperar que ele realmente enviasse, mas ele enviou mesmo. Algumas semanas depois, todos os jogos chegaram exatamente como descritos, e eu fiquei radiante. Virei um verdadeiro crente da noite para o dia, e essa lembrança continua sendo uma espécie de núcleo solar de otimismo que ainda carrego. Jess, se você estiver em algum lugar, você era de verdade. Espero que a gente se encontre de novo algum dia
Meu pai trabalhava numa siderúrgica e era amigo do responsável pelos computadores de lá, que lhe deu uma cópia de SQ2 para eu jogar em casa. Joguei aquilo como um louco, mas eu era bem novo, então muita coisa me confundia. Quando eu realmente travava, pedia ao meu pai que perguntasse àquele responsável pelos computadores como passar de um ponto específico, e acho que ele gentilmente dava dicas em vez de entregar a resposta na hora. Já se passaram uns 35 anos, mas ainda me lembro com bastante detalhe de sonhos que tive relacionados a esse jogo. Ele teve um impacto enorme
Só joguei SQ I muito mais tarde, e SQ III não me marcou com a mesma força. Os demais nem eram mais jogos EGA com entrada de texto. SQ II desperta muitas lembranças e também aprendi um pouco de inglês com ele. Lembro da satisfação ao descobrir que dava para fazer “rub berries” com Roger Wilco
Esse foi meu primeiro jogo desse tipo, e passei semanas preso nele quando tinha uns dez anos
Não vejo que o motor AGI tivesse algum molho secreto especial a ponto de um concorrente se beneficiar com um vazamento
Pode haver outros exemplos, mas Hugo's House of Horrors foi um jogo no estilo AGI feito por uma única pessoa alguns anos depois. Para além da novidade inicial de uma aventura gráfica, os jogos da Sierra deram certo porque havia um esforço enorme em criar os gráficos e escrever o jogo em si. Não quer dizer que a tecnologia não contasse, mas sua participação no resultado final era pequena
Aprender e criar software funcional era imensamente mais difícil do que hoje, e havia pouquíssima coisa em que se basear. No MS-DOS havia quase nada de código aberto significativo, muito menos motores de jogos open source. Nesse ambiente, se o código-fonte do AGI tivesse vazado amplamente, poderia ter sido bastante relevante pelo menos como um projeto mostrando exatamente como alguns dos jogos de PC mais populares da época eram feitos
Especialmente se for um código que não contém segredos exploráveis por hackers, como chaves ou backdoors. Código vazado obviamente não vem com licença, então, se você quer evitar processos, não pode reutilizá-lo diretamente no seu produto. No fim, é preciso ler o código, entender as técnicas e aplicá-las ao seu próprio trabalho sem deixar cheiro de violação de direitos autorais, o que em geral é mais difícil do que fazer do zero. Mesmo que haja casos vantajosos, também me pergunto com que frequência isso se traduz em uma vantagem competitiva real. Desenvolvedores costumam escrever código novo mesmo quando existe open source bem documentado e com licença permissiva. Ler código muitas vezes é mais difícil do que escrevê-lo, e até simplesmente recompilá-lo pode ser difícil. Isso poderia facilitar um pouco a clonagem, mas jogos normalmente eram crackeados e distribuídos em poucos dias, e talvez o código de proteção contra cópia nem estivesse incluído no fonte
Provavelmente havia várias ordens de grandeza menos pessoas capazes de falar essas linguagens, e menos ainda capazes de criar algo coerente com elas
Hoje ela está caindo rapidamente, então as coisas com que entramos em contato agora não têm tanta força para moldar os pesos internos quanto tinham naquela época
Os comentários de histórico de alterações são realmente ótimos
Numa época muito anterior àquela em que ferramentas de controle de versão passaram a mostrar isso claramente, eles demonstram um alto nível de cuidado e artesanato. Francamente, mesmo depois de CVS/SVN/Git, isso ainda não ficou claro para muita gente. O texto também me lembra o famoso artigo “No Silver Bullet”[1], que em 1986 previa que o software continuaria sendo, em grande parte, escrito penosamente por programadores, um comando por vez, como era então. O fato de o código e os comentários do motor de jogo do post original se parecerem com algo que eu poderia ter escrito hoje parece, quase 40 anos depois, reforçar essa previsão
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
A versão de Famicom de Air Fortress tem uma quantidade absurda de coisas colocadas sem querer na ROM
Há código ASM não compilado, listagens de diretórios do MS-DOS, strings de um dos EXEs usados para compilar o jogo e muito mais. O cartucho japonês tinha 128+128 KB. Depois, ao fazer a versão americana para NES, a maior parte dos 128 KB de dados gráficos era composta de gráficos duplicados ou não usados, e os gráficos realmente únicos somavam cerca de 36 KB. Eles removeram a imagem de um planeta em um dos finais para reduzir os gráficos para 32 KB e lançaram o jogo em um cartucho de 128+32 KB em vez de 128+128 KB
Fonte: https://tcrf.net/Air_Fortress
Esse tipo de situação acontecia com muita frequência
The Cutting Room Floor lista cerca de 500 casos, que vão desde pequenas partes de código incluídas por acidente até a maior parte dele
https://tcrf.net/Category:Games_with_uncompiled_source_code
Fico curioso se chego à mesma conclusão. A mesma coisa aconteceu em discos de King's Quest III e, na verdade, parece ter ocorrido quase na mesma época do caso de Space Quest II
A parte de que mais gosto é que parece que ninguém descobriu o código-fonte deixado no disco por uma geração inteira
“Surpreendentemente, nem a Sierra, nem os concorrentes, nem os clientes parecem ter percebido que isso havia acontecido, e a descoberta só ocorreu décadas depois. A primeira descoberta conhecida foi feita em outubro de 2016 pelo usuário online NewRisingSun.” Isso me lembra também avanços recentes em Tetris e Super Mario Bros. Quando eu jogava esses jogos na infância, achava que, décadas depois, eles seriam artefatos esquecidos, impossíveis até de executar exceto pelos hobbyistas mais dedicados. Mas a internet e os emuladores deram nova vida a esses jogos e à computação inicial
Certamente houve pessoas que encontraram os arquivos apagados, mas, antes de a internet se popularizar, é bem possível que isso não tenha se espalhado nem sido registrado
Alguém pode ter encontrado dados remanescentes em espaço livre ao gerar a imagem desses discos
Entre 1987 e 1993, preparei cerca de nove discos master para dois apps de Mac
Eu sempre usava disquetes novos e tinha uma checklist longa para verificar se o disco estava correto. Felizmente, todos saíram bem, e alguns deles, em especial, foram usados para produzir 100 mil discos. Ainda bem que hoje ninguém mais precisa fazer esse tipo de coisa
Já vi camadas assim: base, adicionar ferramentas, adicionar código-fonte, compilar, apagar código-fonte, apagar ferramentas adicionais, lançamento. É o tipo de situação de “por que a imagem Docker está tão grande? Bem, armazenamento é barato...”. Também existem soluções fáceis, como builds multi-stage ( https://docs.docker.com/build/building/multi-stage/ ). Mas, se a pessoa não sabe que a visualização atual de uma imagem Docker inclui todas as camadas anteriores, esse erro ainda acontece de vez em quando
Na época em que os artefatos de release eram feitos à mão, era comum entrar sobras que não deveriam ser lançadas
Coisas como conteúdo cortado[1] ou símbolos de debug[2]. Quando encontrei por acaso símbolos de debug escondidos dentro do arquivo de dados da versão demo de um videogame em que eu estava fazendo engenharia reversa, foi inesperado, mas ajudou demais. Hoje, graças a CI/CD, builds automatizados e outras práticas modernas de desenvolvimento, é provável que isso aconteça menos
[1] https://tcrf.net
[2] https://www.retroreversing.com/games/symbols
Se não houver erros, ninguém fica olhando milhares de linhas de saída do console. Mesmo que o pacote final de release inclua conteúdo desnecessário em excesso, é provável que os testes passem. Por isso, minha intuição é justamente a oposta. Isso pode acontecer com mais frequência, ou pelo menos o CI/CD pode tornar esse tipo de coisa mais provável do que builds manuais. Também pode haver outros fatores