Website patrocinador: Emergency Boot CD (somente em inglês)




Um guia para o DEBUG
( Programa Microsoft® DEBUG.EXE )
Direitos reservados©2004,2007,2009,2017 para Daniel B. Sedory

Esta página pode ser copiada gratuitamente apenas para uso pessoal !
( Não pode ser usada para qualquer outro propósito, a menos que você tenha
primeiro contatado (somente em inglês) e tenha recebido permissão do autor ! )


Sítio traduzido para a língua portuguesa por
Augusto Manzano com autorização expressa do autor
(vide fim da página 2).
Acesse aqui a versão original em inglês.




Uma História para o MS-DEBUG


Início

   Em 1980, Tim Paterson começou a trabalhar em um sistema operacional de 16 bits para a placa 8086 S-100 que ele havia projetado para a SCP (Seattle Computer Products) no ano anterior. Para o correto funcionamento de seu sistema, chamado QDOS (posteriormente denominado 86-DOS) Tim criou um depurador e um chip de ROM: o código dessa ROM foi lançado no regime de domínio público. Mais tarde, Tim adaptou o código para ser executado como um programa .COM em QDOS e adicionou a capacidade de desmontar o código de máquina do processador 8086. Enquanto isso, a Microsoft® estava comprando os direitos do sistema QDOS de Tim para a IBM® que projetava 'secretamente' seu PC. Tim foi contratado pela Microsoft como o principal autor de seu primeiro sistema operacional. Quando completou seu trabalho no IBM Personal Computer DOS 1.00 em 1981, seu utilitário DEBUG.COM foi incluído nele. Todas as funcionalidades implementadas por Tim no DEBUG ainda estão no programa e pouco foi adicionado a ele (a principal exceção é o comando Assemble (montagem), implementado no DOS 2.0.
[ Agradeço ao próprioTim Paterson por ter analisado esta perspectiva no início do DEBUG. ]

Mudanças no DEBUG

Com o lançamento do DOS 2.0 o DEBUG ganhou a capacidade de montar instruções diretamente no código de máquina (comando A). Este é um dos comandos mais importantes para muitos de seus usuários. Embora falte muito da funcionalidade de um Assembler autônomo, como por exemplo, executar Jumps (saltos) baseados em rótulos (só é aceito saltos com endereços hexadecimais), muitos programas .COM úteis foram escritos com este comando. No DOS 3.0 o comando P (Proceed) de prosseguir foi adicionado permitindo ao DEBUG executar sub-rotinas. Ao mesmo tempo, tornou-se possível fazer uso de Interrupções com o comando T (Trace) de acompanhamento. Quando o DOS passou a fazer uso de funções EMS (Memória Expandida) sob o DOS 4.0, quatro novos comandos: xa, xd, xm e xs foram adicionados ao DEBUG e são raramente usados por nós programadores. Para a maioria de nós, a única alteração notável no DEBUG foi a inclusão do comando de ajuda '?' no DOS 5.0.

O código DEBUG passou por uma série de mudanças (e também de 'correções de erros') ao longo dos anos. Algumas dessas alterações internas foram relacionadas às chamadas do sistema DOS e à saída da tela, então, houve a alteração no suporte do tipo de arquivo .COM para .EXE no DOS 5.0. Apesar de todas essas mudanças e outras que se seguiram, o DEBUG nunca teve uma revisão oficial desde a versão 2.40 (esses dígitos foram incorporados em todas as versões do DEBUG desde o DOS 3.0). Só podemos especular sobre os reais motivos pelos quais a Microsoft® nunca atualizou o DEBUG para lidar com instruções além dos processadores Intel® 8086/8087/8088. A Microsoft® desenvolveu seu próprio Assembler (MASM), compilador 'C' e Debugger (CodeView) que também poderia ser usado, se você estivesse disposto a pagar um valor extra por isso de modo que poderia ter sido esse um dos motivos para não focar o programa DEBUG. Ao invés de usar o MASM e o CodeView muitos optaram pelo montador Borland® (TASM) e pelo Turbo™ Debugger mais baratos quando lançados ou usaram outros produtos comerciais. No entanto, os usuários e estudantes podem aprender muito sobre a linguagem Assembly ao utilizarem o programa DEBUG.

DEBUG no Windows® 9x/Me

As estruturas internas dessas versões do Windows® para o DEBUG parecem muito diferentes de qualquer estrutura usada anteriormente no DOS, pelo menos à primeira vista. No entanto, você encontrará a indicação "Vers 2.40" em um local diferente. O próprio Windows® passou por muitas mudanças durante esse período, como lidar com o sistema de arquivos FAT32. Mas sem acesso ao código fonte não podemos ter certeza se houve grandes diferenças no DEBUG. As mudanças podem ocorrer devido a algo simples como apenas reorganizar as mensagens de erro no código-fonte e/ou usar um novo Assembler/Linkeditor.

O DEBUG sempre foi uma ferramenta eficaz nas mãos de qualquer programador, mas algum tempo após a introdução do Windows 95 e especialmente com o Windows 98, essa eficácia diminuiu quando seus comandos de I/O se tornaram menos confiáveis. Seja devido a um 'bug' no DEBUG propriamente dito ou no Windows®. O fato é que os comandos de I/O no Windows 9x/Me não são confiáveis para acesso direto a discos rígidos. Se você executar nosso ATA drive ID script (somente em inglês) no Win9x/Me, verá que os dados retornados são tão interessantes quanto perturbadores: parece que todos os demais bytes ainda estão corretos. Então, a pergunta que não quer calar é: qual a causa desse problema?

DEBUG no Windows® NT/2000/XP/2003

O programa DEBUG incluído no Windows® NT/2000/XP/2003 parece operar de maneira semelhante junto ao DOS 5.0, mas com duas principais exceções:

1)
No DEBUG não é permitido carregar ou escrever em nenhum setor de HDD lógico. Somente os arquivos nomeados ainda podem ser lidos ou gravados em um sistema operacional do tipo NT. No entanto, é possível acessar setores de disquete nas unidades de drives A:\ ou B:\ com o comando L (Load) de carregar e W (Write) de escrever, mas somente se os disquetes contiverem um sistema de arquivos que o sistema operacional host (2000, XP, 2003) pode reconhecer.
(Consulte comando L na seção Tutorial [somente em inglês] para obter mais informações.)

[ Obs: O DEBUG nunca conseguiu acessar diretamente áreas de um disco rígido fora dos volumes de unidade, como uma tabela de partição estendida ou mesmo o setor MBR. No entanto, o DEBUG pode ser usado para acessar esses dados programando-os para executar comandos INT13 ou usando um arquivo de script sob DOS (por exemplo, nosso antigo script CopyMBR [somente em inglês]). Note que nenhuma versão do Windows após o Win98/ME permitirá acesso aos comandos INT13. ]

2) Os comandos I e O são essencialmente inúteis, uma vez que a interface do programa com o resto do sistema só está sendo emulado sob essas versões do Windows® ao invés de ter acesso direto ao hardware. Isso já era recorrente em versões anteriores do Windows®.

Isso pode surpreendê-lo: propositadamente mencionamos a versão do DOS 5.0 do DEBUG já que o arquivo DEBUG.EXE incluído no Windows® XP (e todas as outras versões da série NT são exatamente o mesmo arquivo de programa criado para o MS-DOS 5.0 com md5sum = c17afa0aad78c621f818dd6729572c48). O DEBUG era apenas mais um dos pequenos programas do DOS 5.0 que não exigiam alterações para serem executados em um sistema operacional NT. É quase irônico que outro desses programas seja o EDLIN, um editor de linha não apreciado pela maioria dos usuários do DOS. Embora o EDLIN tenha sido criado por Tim Paterson, ele fez isso em duas semanas e ficou chocado quando soube que a IBM tinha incluído esse programa na versão 1.00 do PC-DOS. Sem sombra dúvida, Tim desejava que esse programa tivesse sido substituído por algo melhor em 1981. Isso não ocorreu até o lançamento do DOS 5.0, quando o EDLIN foi efetivamente substituído pelo programa Microsoft EDIT.COM (v 1.0 no ano de 1991. Obs: A primeira versão do EDIT necessitava do programa QBASIC para ser executado). No entanto, o programa EDLIN foi mantido para ser 'compatível' com versões anteriores de vários arquivos Batch de terceiros. Embora o NOTEPAD, mais avançado, esteja presente no Windows™, você pode usar a versão autônoma de 1995 do programa EDIT(v 2.0.026) no prompt de comando do Windows™ XP: seus menus respondem adequadamento aos cliques do mouse.

Resumo

Embora tenha sido criado no início da era do processador de 16 bits (antes dos 80286 existirem) as versões mais recentes do DEBUG (como as encontradas no arquivo EBD.CAB do disquete de inicialização de emergência do Windows™ Me ou 98SE) ainda são úteis para técnicos de PCs no que tange ao acesso direto a determinadas posições de memória em sistemas atuais como por exemplo (Intel® Pentium IV). O DEBUG também pode ser muito útil para fins educacionais. E mesmo para depurar o código de montagem que é necessário durante o processo de inicialização: o software que verifica a tabela de partição em discos rígidos e carrega os setores de inicialização do sistema operacional na memória. Infelizmente, muitos dos programas de inicialização de setores MBR mais recentes usam instruções que exigem uma CPU de classe 386 (ou mesmo 486) para funcionar, tornando difícil usar DEBUG para tal propósito Devido às questões de compatibilidade com versões anteriores da maioria dos processadores Intel® e ao fato de que foi incluído no Microsoft® Windows™ XP e 2003 o DEBUG teve uma vida útil muito maior do que o esperado. Embora a CPU ITANIUM não fosse x86-compatível o processador AMD64 era. Em 2005 a Intel® criou as chamadas CPUs "x64-based" que eram mais uma vez x86-compatíveis. Então o DEBUG continua a encontrar algum uso em computadores de 64 bits, até mesmo nas máquinas baseada no Intel® Core™ 2 Quad (4 processors in one).

Capítulo final?

Sim, o programa DEBUG e alguns outros utilitários anteriores a época do DOS foram removidos da linha de comando da versão de 64 bits do Windows 7 e nunca mais serão usados no sistema operacional Microsoft. No entanto, é possível há algum tempo executar o IBM PC DOS 1.x0, 2.x0 e 3.30 (e possivelmente outros) juntamente com suas versões do DEBUG em uma pequena janela no Windows XP (32-bit), Windows 7 (64-bit), 8 e até a última atualização do Windows 10 (Anniversary). Leia aqui sobre o programa PCE (PC Emulator) de Hampa Hug (somente em inglês). Se você deseja executar a última versão do MS-DEBUG a partir do MS-DOS 6.22 ou executar o programa DEBUG de 32-bits clone que é abaixo indicado, talvez seja necessário instalar o programa BOCHS, QEMU ou outro emulador como o VPC, VirtualBox, VMWare Player ou ainda outro tipo de programa de máquina virtual. Há o programa PCE que possui uma característica interessante: você pode executar com este programa no seu computador um código de compatível com a ROM-BIOS de um computador IBM-PC original como se estivesse utilizando a máquina física da época..

 

Um bom DEBUG Clone (para código de 32 bits)

Há uns anos usamos um "clone" do MS-DEBUG desenvolvido para o sistema operacional FreeDOS que vem melhorando ao longo deste tempo. Você pode baixar e usar este programa de graça. Atualmente recomendamos uma página feita para ele em um sítio criado por Vernon C. Brooks, que tinha sido um programador sênior para o sistema operacional PC DOS 7.0 da IBM. O sítio em questão trata do histórico do IBM PC DOS, sendo este muito informativo (PC DOS Retro):
Enhanced DEBUG (versão atual, desde dezembro de 2014, é 1.30b).

C:\DEBUG> DEBUGX
-?
assemble        A [endereço]
compare         C intervalo de endereços
dump            D[B|W|D] [intervalo]
dump interrupt  DI interrupção [contador]
dump LDT        DL seletor [contador]
dump MCB chain  DM
dump ext memory DX [endereço_físico]
enter           E endereço [lista]
fill            F lista de intervalos
go              G [=endereço] [endereços]
hex add/sub     H valor1 valor2
input           I[W|D] porta
load file       L [endereço]
load sectors    L [endereço] [unidade] [primeiro setor] [número]
move            M intervalo de endereços
set x86 mode    M [x] (x=0..6)
set FPU mode    MC [2|N] (2=287,N=não FPU)
name            N [[unidade:][caminho]nome do arquivo [lista de argumentos]]
output          O[W|D] byte da porta
proceed         P [=endereço] [número]
proceed return  PR
quit            Q
register        R [registrador [valor]]
MMX register    RM
FPU register    RN[R]
toggle 386 regs RX
search          S lista de intervalos
trace           T [=endereço] [contador]
trace mode      TM [0|1]
unassemble      U [lista]
write file      W [endereço]
write sectors   W [endereço] [unidade] [primeiro setor] [número]

prompts: '-' = real/modo-v86; '#' = modo-protegido
-

 

As Limitações do MS-DEBUG

O DEBUG foi originalmente projetado para trabalhar com programas .COM com tamanho máximo de 65.280 bytes [ (64 x 1024) - 256 ] ou menos. Quanto menos, dependia do número máximo de bytes que o programa poderia colocar na Stack (pilha) ao mesmo tempo. A subtração de 256 bytes é necessária uma vez que o DEBUG geralmente usa a área do deslocamento 00 até FF hex para alguns dados internos como o nome do arquivo carregado. Lembre-se, de que os programas.COM por definição devem caber dentro de um único segmento de memória (somente 64 KB).

Mesmo quando executado o MS-DEBUG no sistema operacional Windows® mais recente por ser um antigo aplicativo DOS de 16 bits. Você só poderá abrir arquivos cujos nomes foram salvos na convenção DOS 8.3, ou seja, 11 caracteres no total usando 8 caracteres para o nome e 3 caracteres para a extensão.

Posterior ao DOS 1.10 o DEBUG foi capaz de carregar arquivos maiores que 64 KB. Basicamente o tamanho de um arquivo que o DEBUG pode usar com segurança sem erros depende da quantidade de memória disponível e da maneira como o sistema operacional gerencia a memória. Vamos ver mais sobre isso abaixo .

 

A. Uso do programa DEBUG iniciado sem a chamada de parâmetros na linha de comando:

1) Aloca todos os 64 KB do primeiro segmento de memória livre.

2) Os registros de segmentos CS, DS, ES e SS são definidos com os valores de localização do segmento de 64 KB (CS=DS=ES=SS=Local do Segmento).

3) O ponteiro de instrução (IP) fica definido para CS:0100 e o ponteiro de pilha (SP) fica definido como SS:FFEE (em DOS 3.0 ou superior).

4) Os registradores AX, BX, CX, DX, BP, SI e DI são sinalizados como zero juntamente com os bits de flags nos registradores de flags. Exceto: o flag Interrupts que fica configurado para Enable Interrupts. (Consulte o Apêndice, The 8086 CPU Registers [somente em inglês] para mais informações.)


B. Uso do programa DEBUG iniciado com nome de arquivo (diferente de um .EXE):

1) Aloca pelo menos 64 KB do primeiro segmento de memória livre para depurar programas ou examinar arquivos especificados na linha de comando. [Obs: Desde a versão DOS 1.10 o DEBUG teve a capacidade de carregar (e salvar) arquivos maiores que 64 KB. O tamanho de um arquivo manipulado depende do sistema operacional e da memória disponível. Mas antes de você fazer uso do DEBUG para salvar algum arquivo grande é necessário saber a quantidade de memória limitada que está disponível na MEMÓRIA CONVENCIONAL. Lembre-se, se um arquivo pode ser depurado no seu sistema, não significa que outra pessoa poderá fazê-lo. ]

2) Os registradores de segmento CS, DS, ES e SS são definidos para os valores dos primeiros 64 KB dos segmentos (CS=DS=ES=SS=Local do Segmento). Para arquivos maiores que 64KB, você terá que definir diferentes valores de segmento para acessar todos os bytes carregados na memória além dos primeiros 64 KB.

3) O ponteiro de instrução (IP) fica definido para CS:0100 e o ponteiro de pilha (SP) fica definido como SS:FFFE (versão 3.0+). [ OBS: Isto não é o mesmo que SS:FFEE in A. como indicado acima, há uma diferença de 16 bytes. ]

4) A maioria dos registradores segue o mesmo padrão acima, exceto para os registradores CX e às vezes BX, onde o tamanho do arquivo será colocado na combinação linear dos registradores BX e CX. Para arquivos com menos de 64 KB - 256 bytes, apenas CX é usado. Exemplo: Se você carregar um arquivo de 360.247 bytes, então BX=0005 e CX=7F37 ( 57F37 hex = 360.247 ). Se você carregar um arquivo com exatamente 65.536 bytes a partir de um prompt, esses registradores serão: BX=0001 e CX=0000. Mas devido ao deslocamento automático de carga no endereço 100h os últimos 256 bytes do arquivo terão sido carregados no início do próximo segmento de 64 KB.

Lembre-se: Os segmentos atribuídos ao DEBUG dependem da quantidade de memória em uso e não da memória disponível no computador. A mesma máquina DOS que possui 16 ou 4096 MB de memória geralmente carrega o DEBUG nos mesmos segmentos, a menos que um programa 'termine e permaneça residente' ou quando a memória não é desabilitada antes de ser executado o DEBUG.


Usando DEBUG com arquivos .EXE

Qualquer versão do DEBUG do DOS 2.0 ou superior faz uso da função EXEC do sistema operacional, o que significa que é possível executar uma quantidade limitada de depuração em programas .EXE. No entanto, o DEBUG nunca pode ser usado para salvar um .EXE ou um arquivo .HEX em disco, uma vez que ambos os tipos de arquivo contém dados extras que o DEBUG não foi programado para acessar após a função EXEC remover da memória esses dados. É bem possível, porém, alterar a extensão de um arquivo .EXE, por exemplo, para .BIN, e então usar o DEBUG para editar esse arquivo e, em seguida, alterá-lo novamente para uma extensão .EXE. Normalmente, recomendamos usar um editor Hexadecimal. É propício salientar que o DEBUG pode ser usado com arquivos de lote e scripts para atuar sobre essas edições automaticamente.

Um dos programas .EXE mais simples que você pode usar com o DEBUG é o DOS "Stub" encontrado em muitos executáveis do Windows®. Para saber mais sobre este assunto acesse as informações aqui (somente em inglês).

 

Localização de memória especial no MS-DEBUG

Sempre haverá algum código e dados colocados nos primeiros 256 bytes do segmento para uso do próprio DEBUG. E, embora o DEBUG funcione geralmente como esperado se você desligar esta área poderá ocorrer alguns casos em que você desejaria não ter feito isto. Os bytes de código são simples e sempre são encontrados nos mesmos locais: os dois primeiros bytes desta área ("CD 20") são o código de máquina para a interrupção do DOS: INT 20. Os bytes de deslocamento 50h e 51h ("CD 21") formam um INT 21 e o byte "CB" no deslocamento 52h é uma instrução RETF.

  Ao inicializar o DEBUG a partir de um disco de instalação de atualização MS-DOS 6.22 serão apresentados os seguintes dados (offsets 90h - FFh todos definidos com zero bytes):

A:\>debug
-d 0 8f
1787:0000  CD 20 C0 9F 00 9A EE FE-1D F0 4F 03 EB 11 8A 03   . ........O.....
1787:0010  EB 11 17 03 EB 11 38 0E-01 01 01 00 02 FF FF FF   ......8.........
1787:0020  FF FF FF FF FF FF FF FF-FF FF FF FF 5F 0F 4E 01   ............_.N.
1787:0030  AB 16 14 00 18 00 87 17-FF FF FF FF 00 00 00 00   ................
1787:0040  06 16 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1787:0050  CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20   .!...........
1787:0060  20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20           .....
1787:0070  20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00           ........
1787:0080  00 0D 75 73 0D 0D 00 00-00 00 00 00 00 00 00 00   ..us............

Ao executar o DEBUG sem um nome de arquivo, o que for indicado na linha de comando, exceto o comando em si, será exibido a partir dos bytes dos offsets 82h em diante que são frequentemente referenciados como parâmetros ou parâmetros do DOS. Assim sendo, o "us" na tela acima foi obtido a partir do comando "keyb us" no arquivo AUTOEXEC.BAT do disco de instalação do DOS 6.22. E se tivéssemos executado o comando "dir /w" antes de executar o DEBUG teria aparecido aqui um "/w" . Obs: as utilizações sucessivas dos parâmetros do DOS nunca são removidas da memória, apenas substituídas. Assim, muitos caracteres de uma sequência de parâmetros muito longa ficam intactas e, como consequência, são copiadas para os bytes dos offsets 82h por meio de FFh cada vez que DEBUG é executado.

Um desses locais de dados (o Word de offsets 36h - 37h) salva o segmento atribuído ao DEBUG para nosso uso. No entanto, se continuarmos a carregar o arquivo edit.com e despejarmos o início do segmento novamente, veremos que o próprio valor do segmento muda de 1787h para 1798h (uma diferença de 11h ou 17 parágrafos, no valor de 256 + 16 = 272 bytes):

-n edit.com
-l
-d 0 8f
1798:0000  CD 20 C0 9F 00 9A F0 FE-1D F0 4F 03 EB 11 8A 03   . ........O.....
1798:0010  EB 11 17 03 EB 11 DA 11-01 01 01 00 02 FF FF FF   ................
1798:0020  FF FF FF FF FF FF FF FF-FF FF FF FF 75 0F E8 49   ............u..I
1798:0030  EB 11 14 00 18 00 98 17-FF FF FF FF 00 00 00 00   ................
1798:0040  06 16 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1798:0050  CD 21 CB 00 00 00 00 00-00 00 00 00 00 45 44 49   .!...........EDI
1798:0060  54 20 20 20 20 43 4F 4D-00 00 00 00 00 20 20 20   T    COM.....
1798:0070  20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00           ........
1798:0080  09 20 45 44 49 54 2E 43-4F 4D 0D 00 00 00 00 00   . EDIT.COM......

Em primeiro lugar, não estávamos seguros por qual motivo o DEBUG estava fazendo isso, sabíamos que não tinha nada a ver com o tamanho do programa, que é de apenas 413 bytes. Isto ocorreu pelo fato de ser o "programa" (EDIT.COM) em vez de ser outro tipo de arquivo. O DEBUG não fez isso ao carregar arquivos maiores de outros tipos, mas fez isso novamente ao carregar qualquer um dos programas *.EXE. Em seguida, confirmamos uma alteração semelhante ao carregar programas *.COM ou *.EXE no DEBUG em uma máquina XP, mas a mudança foi maior: ele adicionou até 91 parágrafos. Após mais testes, usando os comandos SET e PATH, descobrimos que o DEBUG precisava carregar uma cópia das "variáveis de ambiente" do DOS entre sua "área de dados" inicial e uma nova área de dados de 256 bytes que ele cria ao depurar apenas no DOS arquivos de "programas". Mesmo quando não existe nenhuma variável PATH o DEBUG precisa criar uma nova "área de dados" para arquivos *.COM ou *.EXE.


Ao executar o DEBUG em uma janela DOS do Windows® (em CMD.exe) o despejo dos seus primeiros 256 bytes quase sempre mostrará o mesmo string fragmentado (mostrado abaixo em texto na cor branca). Os caracteres apresentados são os restos da execução do programa Ntvdm (que é iniciado assim que qualquer comando de 16 bits é executado) quando lida cada uma das linhas do arquivo AUTOEXEC.NT (localizado na pasta [diretório] C:\WINDOWS\system32), ou seja, a mesma área de memória onde os parâmetros da linha de comando são armazenados. A linha mais longa nesse arquivo, incluindo seu byte 0Dh (carriage return) é sucessivamente substituída por linhas mais curtas do arquivo até o processo resultar no que foi copiado para os offsets 82h por meio de CEh do segmento do DEBUG:

 
C:\>debug
-d 0 cf
0B20:0000  CD 20 FF 9F 00 9A EE FE-1D F0 4F 03 84 05 8A 03   . ........O.....
0B20:0010  84 05 17 03 84 05 25 04-01 01 01 00 02 FF FF FF   ......%.........
0B20:0020  FF FF FF FF FF FF FF FF-FF FF FF FF 28 05 4E 01   ............(.N.
0B20:0030  44 0A 14 00 18 00 20 0B-FF FF FF FF 00 00 00 00   D..... .........
0B20:0040  05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
0B20:0050  CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20   .!...........
0B20:0060  20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20           .....
0B20:0070  20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00           ........
0B20:0080  00 0D 20 20 20 53 45 54-20 42 4C 41 53 54 45 52   ..   SET BLASTER
0B20:0090  3D 41 30 0D 64 64 72 65-73 73 2E 20 20 46 6F 72   =A0.ddress.  For
0B20:00A0  20 65 78 61 6D 70 6C 65-3A 0D 20 6F 6E 20 4E 54    example:. on NT
0B20:00B0  56 44 4D 2C 20 73 70 65-63 69 66 79 20 61 6E 20   VDM, specify an
0B20:00C0  69 6E 76 61 6C 69 64 0D-20 6F 6E 6C 79 2E 0D 00   invalid. only...

Nenhum dos line feeds (0Ah) no final de cada instrução do arquivo AUTOEXEC.NT será apresentado devido o carriage returns (0Dh) os proceder. Isto faz com que o cursor seja enviado sempre para o início das linhas todas as vezes que 0Dh é encontrado ou quando ocorrer a existência do caractere espacial (20h). É devido a isso que o "REM" das últimas três linhas não é apresentado neste local.

O byte no deslocamento 81h é sempre 0Dh, mesmo se o arquivo AUTOEXEC.NT contiver um único byte de qualquer valor.

Obs: Se você renomear ou excluir AUTOEXEC.NT não poderá executar o DEBUG (nem qualquer outro programa de 16 bits, o qual deve ser executado em Ntvdm). No entanto, você pode salvar uma cópia do AUTOEXEC.NT para depois editá-lo e ver como suas alterações afetam o que foi copiado para o DEBUG. Você pode reduzir seu tamanho apenas para um único byte. No entanto, para ver qualquer coisa além de zero bytes nos offsets 82h e posterior, pelo menos um byte especial (20h) deve ser colocado entre um byte não-especial no início de uma linha e o que você deseja ver. Se o arquivo contiver apenas 3 bytes: "T", espaço e "S", 0s offsets 82h e 83h serão "S" seguidos de 0Dh.

 

Área "Dynamic Stack" do DEBUG

Esta seção está "em desenvolvimento", mas se estiver vendo isso antes de seu término poderá imaginar do que se trata?

 

Você encontrou um "Bug" no DEBUG?

Embora quase todos os códigos utilizados pelos programadores funcionem como esperados, uma vez que eles eliminaram seus próprios erros de lógica, ocasionalmente, poderá acontecer o surgimento de resultados inesperados porque os programadores não foram a fundo o suficiente na leitura aprofundada dos manuais do processador usado em um PC. Programadores profissionais sempre testarão seus códigos de diversas maneiras de um ponto de vista razoável, mas é fundamental estudar os detalhes de programação do processador, especialmente as seções relacionadas a qualquer tarefa a ser executada, tendo este objetivo no topo de sua lista.  OBS: Se você deseja ser um hacker melhor, o exemplo aqui mostrado pode fazer com que você mergulhe de cabeça nos detalhes técnicos do processor Intel e sobre como suas CPUs lidam com as diversas instruções que possui.

Você encontrou duas linhas distintas de instruções assembly que o DEBUG executa sem nunca parar na segunda linha? O exemplo seguinte é um dos muitos exemplos que podemos listar nesta situação. Abra qualquer instância do DEBUG (DOS ou Windows - qualquer versão), copie e cole o pequeno código seguinte por meio do comando E (Enter) a partir do prompt (-):

e 100 8C C8 8E D0 B0 74 90 90

Após entrar o código anterior execute "u 100 107" e observe o que é apresentado:

 xxxx:0100 8CC8    MOV   AX,CS  <- Deixe o segimento CS na pilha.
 xxxx:0102 8ED0    MOV   SS,AX  <- Uma instrução da tecla!
 xxxx:0104 B074    MOV   AL,73  <- Pode ser qualquer coisa.
 xxxx:0106 90      NOP
 xxxx:0107 90      NOP

Agora, execute o comando "r" e na sequência execute o comando (t). Assim que você entrar no comando t notará que o deslocamento usado fica definido de 0102h, até o deslocamento 0106h. Será este um "bug" nunca tratado? A instrução do offset (deslocamento) 0104h ff poderia ser qualquer dado de: 1-, 2-, 3- ou mesmo 4- bytes. Escolhemos propositadamente uma ação que afeta o conteúdo do registrador, neste caso (AL) para que você pudesse ver que essa instrução realmente foi executada pela CPU, sem que o usuário tenha a opção de fazê-lo.

Este efeito sempre será observado independentemente da versão do DEBUG nos sistemas operacionais MS-DOS 7.1, 5.0 ou qualquer versão anterior, mesmo no IBM PC DOS 1.0. Se você expandir sua pesquisa para outras ferramentas de depuração perceberá que cada versão de duas ou mais ferramentas apresentam o mesmo "erro": muita coincidência. Então, por que será que esse código afeta as habilidades de ação sobre a interrupção de certo depurador?

Se você ainda não obteve o conjunto de manuais de referência de instruções do processador Intel®. É melhor obtê-los. Procure pelas palavras chave: Intel, IA32, Software, Instruction. Pelo menos faça o download de uma cópia digital PDF do conjunto de referência dos manuais (Geralmente encontrados em dois arquivos separados: Volume 2A: Instruction Set Reference, A-M e Volume 2B: Instruction Set Reference, N-Z).  Na cópia que eu obtive em janeiro de 2006 para "MOV—Move", foi encontrado: " Loading the SS register with a MOV instruction inhibits all interrupts until after the execution of the next instruction. (Carregar o registro SS com uma instrução MOV inibe todas as interrupções até a execução da próxima instrução). Esta operação permite que um ponteiro de pilha seja carregado no registrador ESP com a próxima instrução (MOV ESP, valor do ponteiro de pilha) antes da ocorrência de uma interrupção1." (IA-32 Intel® Architecture Software Developer’s Manual, Volume 2A: Instruction Set Reference, A-M, 253666-018, Jan 2006, "MOV—Move," páginas 3-584).   A nota de rodapé 1 afirma claramente que: " If a code instruction breakpoint (for debug) is placed on an instruction located immediately after a MOV SS instruction, the breakpoint may not be triggered. [Se um ponto de interrupção de instruções de código (para depuração) for colocado em uma instrução localizada imediatamente após uma instrução de MOV SS , o ponto de interrupção pode não ser acionado]" (páginas 3-585). Para os novatos no uso de programas depuradores a operação no "ponto de interrupção da instrução" a que se refere não é um ponto de interrupção definido pelos usuário, mas sim, um ponto de interrupção definido automaticamente pelo próprio depurador. Então, de acordo com a documentação dos manuais, o que você julga ser um "bug" do DEBUG é de fato uma ação realizada pelo processador naquilo em que foi projetado para fazer.

Devido a isto acreditamos que o MS-DEBUG é completamente livre de "bugs"? Não. No futuro, publicaremos alguns exemplos de 'bugs' reais do programa DEBUG.


Antes de usar qualquer um dos comandos de depuração (Trace, Procedure) ou Register, você deve se familiarizar com as abreviaturas dos Registradores da CPU referenciados pelo programa DEBUG (Veja o Apêndice, Os registradores da CPU 8086 para maiores detalhes.)

Você também deve saber sobre o método de endereçamento SEGMENT:OFFSET usado pelo DEBUG (e por outros programas utilitários).

Uma nota sobre onde e como DEBUG é usado na memória de um computador.

Usar o DEBUG em uma janela prompt do Windows® pela primeira pode facilmente confundir você. Se você abrir duas instâncias do DEBUG (uma por janela DOS) e examinar toda a memória que pode ser acessada, notará a existência de dados completamente diferentes em muitas das mesmas localizações de memória em ambas as janelas. A razão disso advém do fato de que cada aplicação sob o sistema operacional Windows™ é (teoricamente) executada de forma separada como se fosse um "computador virtual" de 4 Gigabytes para reproduzir uma cópia dos dados críticos dentro do primeiro Megabyte de memória da máquina feito em cada instância em execução do DEBUG. Somente abaixo do DOS de 16 bits o DEBUG realmente tem acesso aos locais reais de memória nos quais o próprio sistema operacional está sendo executado, tornando muito mais fácil travar todo o sistema se um erro ocorrer. No Windows® a teoria diz que tais erros devem travar apenas a janela do aplicativo CMD que causou o problema, mas não no computador inteiro. Pelo menos é assim que o Windows® deve operar. Por experiência, parece que o Windows 2000/XP faz um trabalho muito melhor para manter o controle de seus sistemas nas mesmas circunstâncias que muitas vezes terminaram em Blue Screen (famosa tela azul) como ocorre com versões anteriores.

OBS: Se você decidir usar um programa de emulação como PCE emulation (somente em inglês) o DEBUG existirá inteiramente dentro do espaço de memória configurado pelo emulador para qualquer sistema operacional que você esteja executando. Vamos tentar localizar e apontar quaisquer inconsistências ao usar o PCE com as versões iniciais do DEBUG, mas apreciaremos os comentários dos nossos leitores.



Links rápidos para todos os comandos
(Listados em ordem alfabética)

Recomendamos ler todo o Tutorial do DEBUG antes de usar esses links de comandos rápido.

Para obter ajuda sobre todos os comandos disponíveis dentro do DEBUG, basta inserir um ponto de interrogação (?) no prompt do DEBUG ao fazer uso do DOS 5.0 ou superior.

Clique em um dos comando a seguir para obter mais detalhes:

-?
assemble    A [endereço]
compare     C intervalo de endereço
dump        D [intervalo]
enter       E endereço [lista]
fill        F lista de intervalos
go          G [=endereço] [endereços]
hex         H valor1 valor2
input       I porta
load        L [endereço] [unidade] [primeiro setor] [número]
move        M intervalo de endereços
name        N [caminho] [lista de argumentos]
output      O byte da porta
proceed     P [=endereço] [número]
quit        Q
register    R [registrador]
search      S lista de intervalos
trace       T [=endereço] [valor]
unassemble  U [intervalo]
write       W [endereço] [unidade] [primeiro setor] [número]





Página Dois



Atualizado: 9 de dezembro de 2007 (09/12/2007); 12 de fevereiro de 2009 (12/02/2009); 24 de agosto de 2009 (24/08/2009); 20 de abril de 2015 (20/04/2015).
Última atualização: 18 de fevereiro de 2017. (18/02/2017)


Página: The Starman's Realm Assembly (somente em inglês)