Como você interpreta o Cluster Chain Run em um registro NTFS MFT?

31 10 44 0b 00, mais 16 clusters começando em 2.884 de 29.917.440, que é o cluster # 29.920.324 É aqui que minha matemática se desvia da matemática deles. Eles dizem cluster # 29.840.452. eu preciso de ajuda

Não é sua matemática que está errada, o cara demonstrando no vídeo está errado ou pelo menos ignora uma questão importante:

Ele trapaceia um pouco e apenas lê os valores dos valores interpretados da coluna à esquerda como se estivesse convertendo os valores que destaca na hora.

Mas seus valores convertidos práticos levam em consideração a matriz de sequência de atualização que ele não menciona.

Atualizar matriz de sequência e valor de correção

A execução com a qual você está tendo problemas não 31 10 44 0b 00 é . Se observarmos atentamente sua sequência de bytes no vídeo, veremos que os dois últimos bytes da execução são os dois últimos bytes em um setor de 512 bytes:

Portanto 0b 00 não são os dois bytes que pertencem a esta execução, é o 'conserto'. Para obter os valores reais, você precisa lê-los no chamado 'Array de seqüência de atualização' para o qual o deslocamento é armazenado no deslocamento de byte 4 na entrada MFT (geralmente 0x30).

No deslocamento 0x30, você verá os bytes 0b 00 (o valor de correção), os próximos dois bytes serão os valores originais dos últimos dois bytes do primeiro setor da entrada da MFT, os próximos 2 os do próximo setor.

Vou ilustrar usando uma entrada MFT da minha unidade:

Então 31 10 44 0b 00, na verdade, é 31 10 44 xx xxonde você substitui xx pelos bytes da matriz de sequência de atualização e, em seguida, faz suas contas.

O objetivo dos valores de correção é detectar corrupção. Portanto, assim que lemos a entrada da MFT, verificamos o valor da correção e comparamos com os últimos 2 bytes de cada setor, eles devem corresponder, caso contrário, o setor está corrompido. Para realmente trabalhar com a entrada, precisamos primeiro corrigir o valor de correção com valores da matriz de sequência de atualização.

Como esses campos são interpretados como little-endian e como esse é um campo de comprimento flexível (os sinalizadores dizem quantos bytes), então por que você teria zeros à esquerda?

TBH, não tenho a menor ideia. Na época em que estava estudando isso, fiz isso para escrever um programa de recuperação de arquivos NTFS (além disso, redescobri seu código-fonte muito recentemente e recompilei para ver se ainda funcionaria. Funcionou ! )

De qualquer forma, o que quero dizer é que, quando descobri as execuções de dados, nunca mais as observei com muita atenção porque escrevi o código para lidar com elas.

Mas sim, você está certo. Mais uma vez, voltei-me para o meu próprio disco rígido e obtive esta entrada:

Assim obtemos:

31 - 38 - 12 39 09 
43 - 76 2B 01 - 42 77 BB 03 
43 - A7 82 01 - 91 14 D6 00 <<
33 - DC D1 01 - 5B 2B FE  
33 - D9 E4 01 - A2 B3 FD 
etc ..

E, de fato, os << zeros não fazem nenhuma diferença, tanto quanto eu posso ver. De fato, se pedirmos ao DMDE para interpretar a lista de execução, ele simplesmente ignora os zeros também:

Referência: https://flatcap.github.io/linux-ntfs/ntfs/concepts/file_record.html