Teste de exclusão de partição MBR: antes e depois no WinHex
Isso Teste de exclusão da partição MBR mostra como uma partição ausente pode ficar sem alocação, enquanto seu setor de inicialização NTFS permanece legível. No caso registrado, a exclusão da partição do meio removeu seu mapeamento da tabela do MBR. A partição seguinte ocupava o segundo espaço da tabela, e o terceiro espaço estava vazio. A reconstrução de uma entrada posteriormente tornou a unidade E: visível novamente, e verificações subsequentes confirmaram que os dados recuperados estavam completos.
O caso diz respeito a partições NTFS primárias em um disco de dados MBR básico com setores lógicos de 512 bytes. Ele explica as alterações registradas no WinHex e suas consequências. Para conhecer a estrutura subjacente, consulte o Guia sobre a tabela de partições MBR.
Índice
Test Disk e Evidências
O registro histórico de testes mostra um disco separado identificado como “Disco 1” no Gerenciamento de Discos do Windows. Os números dos discos e as letras das unidades servem apenas para identificar este caso específico; não se trata de instruções para selecionar o disco de outro computador.
Item | Condição registrada |
Disco de teste | Disco MBR básico, exibido como 2,00 GB |
Volumes iniciais | D: 1,00 GB; E: 500 MB; F: 521 MB, conforme exibido pelo Gerenciamento de Discos |
Sistema de arquivos | NTFS nos três volumes |
Objeto excluído | Partição primária intermediária, originalmente E: |
Ferramentas de inspeção | Gerenciamento de Discos do Windows e WinHex |
Tamanho do setor lógico | 512 bytes, também codificados como |
Resultado do teste | E: reapareceu como uma partição primária NTFS de 499 MB; verificações posteriores confirmaram que os dados recuperados estavam completos |
As capturas de tela registram o layout antes da exclusão, a região não alocada após a exclusão, as informações remanescentes do setor de inicialização e a reconstrução. A versão do Windows, a versão do WinHex, o tipo de HDD/SSD/disco virtual subjacente e a data do teste não foram registrados.
Não há nenhum dump do LBA 0 salvo antes da exclusão. Consequentemente, trata-se de uma análise de caso, e não de uma auditoria completa da exclusão, byte por byte. Os bytes exatos da entrada original não podem ser apresentados como uma linha de base medida.
O que mudou na tabela de partições do MBR?
O MBR está localizado no LBA 0 do disco. Sua tabela de partições ocupa os deslocamentos 0x1BE–0x1FD, com quatro registros de 16 bytes. Os bytes da assinatura 55 AA ocupar 0x1FE–0x1FF.
Cada registro inclui um tipo de partição, o LBA inicial e o número de setores. Essas informações descrevem uma região do disco; elas não contêm suas pastas nem o conteúdo dos arquivos.
A partição a seguir ocupou o slot 2
A captura de tela pós-exclusão do WinHex contém estes dois registros ocupados:
Campo MBR | Slot 1, associado a D: | Slot 2, associado a F: |
Início da gravação |
|
|
Tipo |
|
|
Bytes iniciais do LBA |
|
|
LBA inicial, decimal | 128 | 3,121,280 |
Bytes de contagem de setores |
|
|
Número de setores, decimal | 2,097,152 | 1,067,008 |
Os slots 3 e 4 estão preenchidos com zeros. O volume do meio, que está faltando, não possui nenhum registro que descreva seu início e tamanho.
A sequência registrada, portanto, corrobora a compactação dos registros remanescentes: F: ocupa o espaço 2 após a remoção da partição do meio. A exclusão da segunda partição não deixa necessariamente o segundo espaço vazio. Outras ferramentas podem apagar um registro sem reorganizar as entradas restantes.
LBA 0 após a exclusão: as entradas remanescentes referem-se às unidades D: e F:. O terceiro e o quarto registros estão vazios, e a assinatura do MBR está presente.
O WinHex também lista uma região NTFS intermediária sem letra de unidade. Sua lista de partições pode incluir sistemas de arquivos detectados além daqueles atualmente registrados no MBR. Os registros brutos determinam o que a tabela realmente contém; a simples detecção de uma região NTFS não significa necessariamente que o Windows a tenha montado.
Interpretando os bytes corretamente
Os campos de endereço multibyte do MBR utilizam a ordem little-endian. Por exemplo:
- 80 A0 2F 00 -> 0x002FA080 -> LBA 3.121.280
Esses são endereços de setores lógicos. O guia de endereçamento de blocos lógicos explica como o tamanho do setor e a origem do endereço afetam sua interpretação.
Por que a unidade E: ficou sem alocação?
O Windows normalmente utiliza registros de partição para identificar as regiões do disco que contêm volumes. Quando a região do meio não possui mais um mapeamento válido, ela deixa de estar disponível como o volume E: original por meio do acesso comum aos arquivos.
Isso explica a barra preta “Não alocada”. Isso não significa que todos os setores daquela região contenham zeros.
A exclusão de uma partição também difere da exclusão de seus arquivos individuais. A exclusão de arquivos altera os registros do sistema de arquivos. A exclusão de uma partição altera o layout do disco por meio do qual o sistema operacional acessa esse sistema de arquivos. O Tabela de arquivos mestre NTFS armazena registros de arquivos dentro do volume; ele é independente dos quatro registros de partição do MBR.
As capturas de tela mostram os metadados de inicialização que sobreviveram. Sem uma comparação completa do disco, elas não comprovam que todos os demais setores permaneceram inalterados. Também não é possível determinar se o código de inicialização ou os bytes da assinatura do disco permaneceram inalterados, pois o dump original do LBA 0 não está disponível.
Como localizar o setor de inicialização NTFS da partição excluída
A primeira partição que se conservou oferece uma hipótese inicial útil:
- D: LBA inicial = 128
- D: comprimento da partição = 2.097.152 setores
- Primeiro LBA após D: = 2.097.280
- Deslocamento em bytes com LBAs de 512 bytes = 2.097.280 × 512
- = 1,073,807,360
- = 0x40010000
O registro original também mostra o setor de inicialização de backup de D: no LBA 2.097.279, imediatamente antes desse endereço. Uma partição vizinha não precisa necessariamente começar logo em seguida; portanto, esse cálculo identifica uma possibilidade, e não uma regra universal.
No LBA 2.097.280, o WinHex exibe um setor de inicialização NTFS com vários campos mutuamente consistentes:
Deslocamento do setor de inicialização | Bytes registrados | Interpretação |
|
| Instrução de salto do código de inicialização neste setor NTFS |
|
| Identificador do fabricante original (OEM) |
|
| 512 bytes por setor |
|
| Campo de setores ocultos: 2.097.280 |
|
| Campo de contagem de setores do NTFS: 1.021.951 |
|
| Marcador de fim do setor de inicialização |
Os deslocamentos nesta tabela são relativos ao setor de inicialização do NTFS, e não ao LBA 0.
A captura original do WinHex mostra o setor de inicialização NTFS em questão no LBA 2.097.280. Sua localização e o campo de setores ocultos coincidem.
O valor de quatro bytes em 0x1C é não é o campo de setores reservados do NTFS. Confundir esses campos levaria a uma identificação incorreta do início da partição. Da mesma forma, procurar por EB 52 90 isso por si só não é suficiente: cópias antigas do setor de inicialização e bytes correspondentes não relacionados podem gerar resultados enganosos. Confirme o identificador do sistema de arquivos, o tamanho do setor, os limites e os metadados acessíveis em conjunto.
Reconstruindo o incidente: o que os autos revelam
A reconstrução documentada preservou primeiro a partição F:, copiando seu registro para o slot 3. Em seguida, preencheu o slot 2 com a região NTFS ausente.
O slot 2 gravado contém:
Campo | Valor registrado |
Indicador de inicialização |
|
Tipo de partição |
|
Bytes iniciais do LBA |
|
Bytes de contagem de setores |
|
Esta comparação “antes e depois” da tabela de partições MBR distingue os estados observados dos bytes originais indisponíveis:
Estado | Layout ou resultado do Windows | Evidências do MBR |
Antes da exclusão | D:, E: e F: visíveis no Gerenciamento de Discos | Os 0 bytes originais do LBA não foram capturados |
Após a exclusão | Região central Não alocada | Ponto 1: D:; ponto 2: F:; pontos 3–4: vazios |
Reconstrução | E: reaparece posteriormente | Posição 1: D:; posição 2: registro NTFS reconstruído; posição 3: F: preservado |
A primeira linha descreve o layout visível original; ela não define a ordem original dos slots byte por byte.
A captura da reconstrução mostra os bytes iniciais 80 00 20 00 e bytes de comprimento FF 97 0F 00. Esses são os valores registrados, e não parâmetros genéricos de recuperação.
Por que o comprimento precisa de uma verificação adicional
Um registro MBR requer o comprimento total da partição. A contagem do setor de inicialização do NTFS não deve ser copiada automaticamente para esse campo.
O volume D: anterior permite uma verificação cruzada dentro do mesmo registro: o comprimento do MBR é de 2.097.152 setores, enquanto seu setor de inicialização NTFS de backup contém FF FF 1F 00 00 00 00 00, ou 2.097.151.
Para o layout NTFS documentado na implementação do NTFS no Linux, o número de setores de inicialização é um a menos do que o total, incluindo o setor de inicialização de reserva. Aplicando essa relação a este candidato, obtém-se:
- Contagem de NTFS registrada = 1.021.951
- Intervalo total do candidato = 1.021.952 setores
- LBA de backup candidato = 2.097.280 + 1.021.951
- = 3,119,231
O intervalo candidato seria codificado da seguinte forma: 00 98 0F 00, em vez do registrado FF 97 0F 00. Esta última descreve uma partição que termina um setor antes.
Este é um cálculo de limite, não um valor de substituição confirmado. Confirme o setor de backup real e a extensão da partição original antes de gravar qualquer coisa. A partição original também poderia ter incluído espaço adicional além do volume NTFS. A unidade F: começa no LBA 3.121.280, deixando 2.048 setores após a extensão NTFS completa candidata; essa lacuna não deve ser automaticamente incorporada ao volume recuperado.
O teste de recuperação após a exclusão do MBR foi bem-sucedido?
O teste foi bem-sucedido: a reconstrução da entrada do MBR restaurou o acesso à unidade E:, e verificações posteriores confirmaram que os dados recuperados estavam completos. A captura de tela final do Gerenciamento de Discos mostra a partição reconhecida como NTFS com o status “Em bom estado (Partição primária)”.
Após a reconstrução, E: aparece como uma partição primária NTFS de 499 MB.
A captura de tela inicial exibia 500 MB; a final, 499 MB. Essa diferença, somada ao problema da contagem de setores, impede que se afirme que os limites originais exatos foram restaurados. A capacidade exibida, por si só, não é suficiente para compensar a contagem de setores originais que está faltando. A recuperação completa dos dados e a restauração exata da extensão original da partição são conclusões distintas.
Os dados da partição recuperada foram verificados após a reconstrução e confirmou-se que estavam completos. Portanto, esse teste demonstrou tanto o restabelecimento do acesso à partição quanto a recuperação completa dos dados. O resultado se aplica a este teste específico; a recuperação em outro disco depende de os metadados do sistema de arquivos e o conteúdo dos arquivos permanecerem intactos.
Ao repetir esse experimento, verifique os arquivos recuperados, bem como a estrutura da partição:
- Seus limites abrangem a extensão validada do sistema de arquivos e não se sobrepõem a outra partição.
- Os locais do setor de inicialização principal e do setor de inicialização de reserva estão de acordo com o layout proposto.
- É possível ler diretórios e nomes de arquivos esperados.
- Arquivos importantes podem ser copiados para outro disco e abertos em seus respectivos aplicativos.
- Compare os tamanhos dos arquivos com a linha de base original, quando disponível. Se houver hashes anteriores à exclusão, compare-os como uma verificação adicional de integridade.
Quando a partição e seus arquivos podem ser recuperados?
Um experimento com uma entrada de partição do MBR excluída demonstra por que a recuperação estrutural pode funcionar: o mapeamento pode desaparecer, enquanto uma parte suficiente do sistema de arquivos permanece intacta para que ele possa ser identificado novamente.
O caminho para a recuperação depende do que restar:
Condição | Implicações práticas |
Setores de inicialização consistentes, metadados NTFS legíveis, limites conhecidos | A reconstrução da partição pode restaurar o acesso |
Limites incertos, mas metadados do arquivo legíveis | Recupere os arquivos para outro disco antes de alterar a tabela |
Conteúdo do arquivo sobrescrito | Recriar o registro não permite restaurar os bytes sobrescritos |
Dados criptografados sem a chave necessária | A restauração do mapa de partições não descriptografa o conteúdo |
Erros de leitura ou hardware instável | Priorizar a realização de exames de imagem adequados ou a avaliação de um especialista |
Partition reconstruction writes disk-layout information. File recovery extracts surviving files to another destination. Boot repair addresses startup structures. These operations solve different problems.
For an actual missing drive, follow the lost partition recovery guide. Avoid creating or formatting a replacement volume over the missing region before protecting its files.
How to Inspect the Same Evidence Safely in WinHex
Use a disk image or disposable test disk for experiments. Preserve an untouched copy before any reconstruction.
- Identify the physical disk by capacity and layout, using Gerenciamento de disco do Windows for orientation.
- Open the corresponding physical disk or image in WinHex using read-only/view mode.
- Inspect LBA 0 and record all four entries at
0x1BE,0x1CE,0x1DE, e0x1EE. - Decode starting LBAs and lengths, then inspect candidate NTFS sectors using the correct logical-sector size.
- Keep inspection separate from writing. Test any proposed reconstruction on a copy and perform the validation above.
For a new controlled deletion test, save LBA 0 before deletion, immediately afterward, and after reconstruction. Also preserve the relevant boot sectors and a file inventory with hashes. Those records establish which bytes changed and whether the recovered files match the originals.
Perguntas frequentes
Excluir uma partição é o mesmo que apagar o MBR?
55 AA assinatura presente. Apagar todo o LBA 0 removeria informações adicionais e constitui uma operação diferente.Por que o WinHex consegue detectar o NTFS, enquanto o Windows mostra “Não alocado”?
A letra de unidade E: existe em alguma entrada do MBR?
Um setor de inicialização NTFS de backup pode restaurar o MBR inteiro?
Essa experiência permite prever os resultados da recuperação do SSD?
O status “Saudável” comprova que todos os arquivos foram preservados?
