O caminho para o nosso Ficheiro

Um ficheiro Index, como se viu, limita-se a listar os diretórios ou ficheiros que inclui, fornecendo as informações que verificámos e principalmente a sua entrada na MFT. É nas entradas da MFT que estão definidos ficheiros e índices e onde se encontram os seus dados.

• Quando o registo do índice é um nó (diretório), a sua entrada na MFT vai apontar para um outro Index.
• Quando é um ficheiro, a sua entrada na MFT ou contém os seus dados porque é muito pequeno ou indexa o local onde estão os seus dados, como já vimos.

No caso presente o registo 22 contém referência a um nó da árvore (diretório) que se encontra no ramo que é o nosso caminho, portanto a sua entrada na MFT deverá apontar para o local externo onde o respetivo Index se encontra.

Pelo descrito, já estamos a perceber que os ficheiros Index são os descritores do conteúdo dos nós da árvore, isto é, aqueles que indicam por onde se expandem o vários ramos que saem desse nó.

Vamos verificar se é assim.

De acordo com a leitura desse 22º registo, a sua descrição encontra-se na entrada 51BEh ou 20.926 da MFT. Então, vamos lá fazer umas contas, para traduzir isto em offset. Conforme já verificámos na descrição do ficheiro $MFT, onde localizámos a MFT:

• A 1ª parte da MFT tem 16 registos que ocupam os seus 4 Clusters, registos de 0 a 15.
• A 2ª parte da MFT tem início no offset 11481000h e começa com o registo 16.

O que queremos encontrar é o início do registo 20.926, que está na 2ª parte da MFT. Ora a segunda parte da MFT começa com o registo 16, como dissemos. Mas, como 0 é um registo, a 1ª parte da MFT tem 16 registos (0 a 15). Então, se na MFT há 20.926 entradas antes desta (0 a 20.925), na 2ª parte da MFT haverá 20.926-16=20.910 entradas antes desta. Como cada entrada ocupa 1.024 Bytes, o seu offset deverá ser 11481000h + 146B800h(1.024×20.910) = 128EC800h. E é para lá que vamos

Todas as Imagens – Entrada na MFT – Offset 128EC800h

Efetivamente, viajando até esse offset, lá está a entrada em MFT do nosso diretório “Todas as Imagens”, conforme representação do editor hexadecimal que juntamos na figura 41.

No Cabeçalho do registo lêem-se as habituais informações. Experimentem insistir e fazer a vossa própria leitura com base no que já vimos,

O 1º atributo é um $STANDARD_INFORMATION, tipo 10h, residente, sem nome, que fornece as habituais informações sobre datas, sobre o próprio atributo e outras que têm a ver com chaves para outros ficheiros da MFT, como $Secure, $Quota e $UsnJrnl, de que não falámos ainda por não terem a ver com o objetivo que perseguimos.

O 2º atributo é um $FILE_NAME, tipo 30h, que para além das informações habituais deste atributo sobre ele próprio e as mesmas datas nos fornece o nome no namespace DOS – “TODASA~1”.

O 3º atributo é um $FILE_NAME, tipo 30h, idêntico ao anterior mas que nos fornece o nome no namespace Win32 – “Todas as Imagens”.

O 4º atributo é um “INDEX_ROOT, tipo 90h, é residente, tem nome e é um índice grande, precisando portanto de alocação externa. O seu nome é $I30, o que indica um índice de diretório. Sobre o índice nada se lê, uma vez que ele está alocado. Passemos portanto ao atributo seguinte.

O 5º atributo é um $INDEX_ALLOCATION, tipo A0, não residente, com nome, com tamanhos alocado, real e inicial de 1000h, ou seja, 1 Cluster. O seu nome é $I30 e o data run que o define e localiza tem o valor

41 01 D2 95 1F 01 00 …

vendo-se que é só um data run e que tem:

• 1 Byte para a dimensão em clusters, que é 01h
• 4 Bytes para o seu offset em clusters, 01 1F 95 D2h, ou seja 18.847.186 clusters, ou offset 11F95D2000h.

O 6º atributo é um “BITMAP, tipo B0, residente e com nome, que nos indica na forma de mapa de bits os clusters ocupados e cujo valor é 01h, indicando que o único cluster está ocupado.

Os bytes 128ECA58h a 128ECA5Bh indicam a terminação da cadeia de atributos.

Vamos então agora navegar para o Índice de Diretório indicado na MFT para “Todas as Imagens“, onde podemos encontrar o que  indexa e as respetivas entrdas na MFT e que se encontra no offset 11F95D2000h.

Todas as Imagens – Índice de Diretório – Offset 11F95D2000h

Finalmente chegamos ao índice propriamente dito, isto é, ao local onde estão indicados todos os ficheiros ou nós (diretórios) que são apontados por este nó (diretório). Efetivamente, no offset indicado encontramos o INDEX que vai definir este nó (diretório).

Vamos juntar a imagem do diretório dada pelo explorador do Windows na figura 42, lembrar que o nó (diretório) seguinte no caminho é o Diversos Pessoais e juntar também a imagem do editor hexadecimal para a parte significativa deste cluster na figura 43.

O cabeçalho, que começa pela palavra INDX, a assinatura do ficheiro, define um índice. Ocupa 1 cluster.

O 1º registo descreve o diretório Diversos Pessoais no namespace Win32, indica que se encontra descrito na entrada 5271h da MFT e que o diretório Pai está na entrada 51BEh da MFT, de onde acabámos de vir.

O 2º registo descreve o diretório DIVERS~1, a forma como o sistema transforma automaticamente o nome Diversos Pessoais para o namespace DOS.

O 3º registo descreve o diretório Empresa no namespace Win32 e DOS, pois o comprimento do nome é menor ou igual a 8 carateres.

O 4º registo descreve o diretório Fotografias Digitalizadas no namespace Win32.

É importante reparar aqui que  não está escrito “Digitalizadas” mas antes “Digitaliza.as”. É aqui que se percebe o conceito do update sequence (06 00 = . .) e do update number (64 00 = d .) que a substitui no fim de cada setor. Na interpretação literal feita pelo nosso amigo editor, que desconhece essa coisas de updates aparece aquilo que lá está escrito. Mas o SO, devido à informação que lhe é dada pelo cabeçalho, faz a interpretação correta do nome. Portanto, embora no disco esteja registado 06 00 (a update sequence), o SO lê-o como 64 00 (o update number) pois sabe que está no limite de um setor e que 0600 corresponde à update sequence.

O 5º registo descreve o mesmo diretório FOTOGR~1 no namespace DOS.

O 6º registo descreve o ficheiro “SyncToy 114005b4-45e8-4bc6-964a-9edcfbdcb2e2.dat” no namespace Win32. Este é um ficheiro criado por um programa de sincronização de dados.

O 7º registo descreve o mesmo “SYNCTO~1” no namespace DOS.

O 8º registo descreve o diretório TT no namespace Win32 e DOS.

O 9º registo não aponta nada na MFT, tem 10h de comprimento e a flag 2 que indica que é o último.

Continuemos o nosso caminho. Vamos então para o registo 1, aquele que descreve o diretório “Diversos Pessoais”, o nó seguinte no nosso caminho e vamos analisá-lo com mais pormenor. Usando os processos já antes vistos na análise de uma entrada de índice podemos constatar que este registo indica que esse nó seguinte está descrito na entrada 5271h ou 21.105 da MFT.

Vamos fazer as contas habituais. A 2ª parte da MFT começa no offset 11481000h. Antes do registo que aí se inicia estão já 16 outros. Vamos ter que procurar por 21.105-16=21.089 registos após o referido offset, para termos o offset de início do registo que queremos (relembramos que a contagem começa em 0 e portanto a entrada 21.105 corresponde ao registo nº 21.106). Então 21.089 x 1.024 = 21.595.136 = 1498400h. Somando este valor ao inicial 11481000h + 1498400h = 12919400h, obtemos o offset para o qual vamos ter que viajar para continuarmos a nossa procura. E efetivamente, ao chegarmos lá encontramos o pretendido

Diversos Pessoais – Entrada na MFT – Offset 12919400h

Vamos passar a ser bastante mais sintéticos nas descrições, pois tornam-se repetitivas. Agora, presumo que já saibam fazê-las. Vamos acompanhar com a figura 12-44 a descrição.

• Temos no início o cabeçalho, que nos dá as habituais informações sobre o ficheiro, depois
• o atributo $STANDARD_INFORMATION,
• um atributo $FILE_NAME no namespace DOS que nos dá o nome “DIVERS~1”,
• outro atributo $FILE_NAME no namespace Win32, que nos dá o nome “Diversos Pessoais”,
• um atributo $INDEX_ROOT que  remete para uma alocação do índice,
• um atributo $INDEX_ALLOCATION que nos dá a localização do índice deste nó (diretório),
• um atributo $BITMAP e
• finalmente o terminador FFFFFFFF dos atributos e do ficheiro.

Vamos analisar o atributo $INDEX_ALLOCATION, porque é aquele que nos diz o caminho que devemos tomar para chegarmos ao destino.  Tem um data run

41 01 D9 B1 0C 01 00 00

que nos diz que:

• tem 1 byte para a dimensão em clusters, que é 01 h e
• tem 4 bytes que definem o offset em clusters, que é 010CB1D9h=17.609.177 o que corresponde a um offset global de 17.609.177 x 8 x 512 = 72.127.188.992 = 10CB1D9000h, que é o offset para onde vamos viajar já de seguida.

Diversos  Pessoais – Índice de Diretório – Offset 10CB1D9000h

Nesse offset encontramos o INDX que define a composição do nosso diretório Diversos Pessoais, cuja representação no Explorer do Windows juntamos na figura 45 e cuja edição hexadecimal juntamos na figura 46:

• O cabeçalho com a assinatura INDX.
• Anuário vem descrito no namespace Win32 e DOS.
• Diversos 1, no namespace Win32
  
• Diversos 2, no namespace Win32
  
• Diversos 3, no namespace Win32
  
• Diversos 4, no namespace Win32
  
• Diversos 1, no namespace DOS como DIVERS~1.
• Diversos 2, no namespace DOS como DIVERS~2.
• Diversos 3, no namespace DOS como DIVERS~3.
• Diversos 4, no namespace DOS como DIVERS~4.
• Viagens no namespace DOS.
• O Terminador.

Vamos olhar melhor para o subdiretório Diversos 1, que faz parte do nosso caminho. Segundo indica a sua entrada neste índice, encontra-se na entrada 528Ah =  21.130 da MFT.

Procedendo como até agora, o offset de início desse registo será 11481000h + 149E800h ((21.130-16) x 1.024) = 1291F800h, que é o offset para que agora vamos viajar na nossa procura pelo tesouro tão bem escondido.

Porque a formação de nomes em DOS aqui utilizada pode conduzir a uma interpretação errada do significado do dígito colocado à frente de vários nomes iguais, vamos aqui fazer uma clarificação sobre a forma como o SO faz a formação de nomes em DOS.

A Formação de Nomes em DOS.

Os números 1, 2 , 3 e 4 que aparecem nas descrições DOS dos ficheiros podem aparentemente induzir em erro pois parece serem o número final na descrição Win32.

Mas é só aparente e é errado!

Realmente na descrição Win32 fazem parte do nome do ficheiro. Mas na descrição DOS não. Para entendermos isto precisamos de saber como é que o SO abrevia o nome Win32 para o descrever em DOS.

Quando o SO abrevia um nome do namespace Win32 para o namespace DOS, aproveita as primeiras 8 letras do nome e coloca-as em maiúsculas. Caso existam dois ou mais ficheiros em que as 8 primeiras letras sejam iguais, então são aproveitadas as 6 primeiras e é introduzido o sinal ~ seguido do número da amostra. Portanto, os nossos diretórios podiam ter nomes de Diversos qualquer coisa, que a sua abreviatura seria sempre a que correspondesse à ordem do ficheiro encontrado, em que os primeiros 6 carateres fossem aqueles.

Vamos então viajar para o offset 1291F800h à procura da entrada na MFT de Diversos 1

Diversos 1 – Entrada na MFT – Offset 1291F800h

Chegamos à entrada de Diversos 1 na MFT, com representação hexadecimal na figura 47 onde:

No início temos o habitual cabeçalho, com as habituais informações sobre o ficheiro, o atributo $STANDARD_INFORMATION, um atributo $FILE_NAME no namespace DOS que nos dá o nome “DIVERS~1” , outro atributo $FILE_NAME no namespace Win32, que nos dá o nome “Diversos Pessoais”, um atributo $INDEX_ROOT que  remete para uma alocação do índice, um atributo $INDEX_ALLOCATION que nos dá a localização do índice deste nó (diretório), um atributo $BITMAP e finalmente o terminador FFFFFFFF dos atributos e do ficheiro.

Pela leitura do atributo $INDEX_ALLOCATION a sua alocação é-nos dada pelo data run

41 01 B3 9E 0A 01 00 00

que nos diz que:

• tem 1 byte para a dimensão em clusters, que é 01 h e
• tem 4 bytes que definem o offset em clusters, que é 010A9EB3h=17.473.203 clusters. A isto corresponde o offset 17473203 x 8 x 512 = 71570239488 = 10A9EB3000h.

Vamos então para esse offset 10A9EB3000h, para que conhecermos o que indexa Diversos 1 e suas respetivas entradas na MFT.

Diversos 1 – Índice de Diretório – Offset 10A9EB3000h

A partir daqui vamos reduzir a representação hexadecimal do Index referindo apenas o cabeçalho, a descrição do diretório que nos interessa e a parte final, como se pode ver edição hexadecimal representada na figura 48.

Na  descrição da representação hexadecimal podemos então ver:

• O cabeçalho com a assinatura INDX.
• A descrição de Diversos no namespace Win32 e DOS.
• A descrição de Diversos 1999 no namespace Win32.
• Um espaço onde decorrerão as restantes representações do Index nos namespace necessários.
• A terminação do ficheiro Index.

A lista total dos nós apontados por este (os filhos) é mostrada através da sua apresentação no Windows Explorer como na figura 49.

Vamos então olhar para a descrição do diretório “Diversos 1999”, o último do nosso caminho (já não era sem tempo), verificando que a sua entrada na MFT é a 528Bh ou 21.131. Ora, seguindo os mesmos procedimentos (21.131-16) x 1.024 = 21621760 = 149EC00h que somado ao offset 11481000h, indica o offset 1291FC00h para início da entrada  do nosso diretório na MFT.

Diversos 1999 – Entrada na MFT – Offset 1291FC00h

Mais uma entrada na MFT, representada pelo editor hexadecimal na figura 50, onde podemos ler:

• Começando pelo cabeçalho,
• passando pelo atributo $STANDARD_INFORMATION,
• pelo atributo $FILE_NAME no namespace DOS, com o nome DIVERS~1,
• pelo atributo $FILE_NAME no namespace Win32, com o nome Diversos 1999,
• pelo atributo $INDEX_ROOT que indica a necessidade de alocação externa,
• chegamos ao atributo $INDEX_ALLOCATION que nos dá a localização do índice deste Diretório.
• Temos ainda o atributo $BITMAP e
• o terminador FFFFFFFF.

O atributo $INDEX_ROOT indica a necessidade de alocação e o atributo $INDEX_ALLOCATION, diz-nos onde se encontra o índice alocado através do data run

41 01 AE 67 0A 01 00 FF

sendo que os dados do índice de Diversos 1999:

• tem 1 byte para a sua dimensão em clusters, que é 01 h e
• tem 4 bytes que definem o offset em clusters, que é 010A67AEh=17.459.118 clusters, o que significa que o offset para o seu início será 17.459.118 x 512 x 8 = 71.512.547.328 Bytes após o início do volume ou no offset 10A67AE000h.

E é para este  offset 10A67AE000h que vamos viajar à procura daquilo que Diversos 1999 indexa e respetivas entradas na MFT.

Diversos 1999 – Índice de Diretório – Offset 10A67AE000h

Na imagem do editor hexadecimal da figura 51 podemos ler:

• O cabeçalho com a assinatura INDX,
• o primeiro registo, correspondente ao ficheiro Picture10.jpg no namespace Win32,
• o registo correspondente ao nosso ficheiro Picture4.jpg descrito no namespace Win32+DOS,
• o último registo, que é PICTUR~1.MIX, a versão em namespace DOS do ficheiro Picture10.mix em namespace Win32, descrito no registo anterior mas não visualizável neste quadro e
• o terminador do INDEX.

A totalidade dos ficheiros referidos por este índice pode-se ver na figura 39.

Vamos então passar à análise do registo do nosso ficheiro neste INDX.

Para além das habituais informações sobre as datas e sobre a própria entrada de índice, dá-nos aqui já a informação:

• do tamanho alocado para o ficheiro, que é 54F000h = 5.566.464 Bytes ou 1.359 Clusters (o tamanho é sempre múltiplo de clusters),
• do tamanho real do mesmo, que é de 54E8DFh = 5.564.639 Bytes e
• da sua entrada na MFT, onde estará registada a sua localização no volume. Ele está na entrada 528Eh = 134 da MFT.

Fazendo os cálculos habituais (21.134-16) x 1.024 = 21.624.832 = 149F800h que adicionado a 11481000h, dá o offset inicial da entrada da MFT que nos interessa, 12920800h. E é para aí que vamos navegar para saber quala localização e composição do nosso ficheiro.

Picture4.jpg – Entrada na MFT – Offset 12920800h

Vamos lá ler esta entrada, com edição hexadecimal na figura 52 com algum pormenor, uma vez que agora se trata de um ficheiro mesmo, concretamente daquele que procuramos.

O cabeçalho diz-nos:

• que é uma entrada com a assinatura FILE,
• que o offset para a update sequence é 30h,
• que a update sequence é composta por 3 palavras,
• o número de sequência no $LogFile,
• o número de sequência, 01 00,
• o número de hard links, que é 1,
• o offset para o 1º atributo, que é de 38h,
• um tamanho real para este ficheiro de registo de 160h = 352 Bytes e
• o tamanho alocado para o mesmo de 400h = 1.024 Bytes.

O 1º atributo é um $STANDARD_INFORMATION,

• correspondente ao tipo 10h,
• tem o tamanho de 60h,
• é residente,
• sem nome,
• os dados do atributo têm 48h de comprimento e dizem-nos que este ficheiro:
  • foi criado em 25/04/2010 às 23:06:08 (a data de criação é a de criação neste volume),
  • foi modificado em 11/11/2002 às 13:14:46 (a data de modificação é a da última vez em que foi alterado),
  • a modificação da MFT foi em 25/04/2010 às 23:06:08 (a data de modificação da MFT é a da última vez em que foi alterado e provocou uma alteração nas suas entradas na MFT) e
  • o último acesso foi em 25/04/2010 às 23:06:08 (a data de acesso é a da última vez em que foi obtido se não alterado),
  • que as permissões DOS são de Arquivo.
• o offset para eles é de 18h.

O 2º atributo é um $FILE_NAME,

• correspondente ao tipo 30h,
• residente, tem uma referência ao diretório Pai na entrada 528Bh da MFT (a entrada de “Diversos 1999” como se pode verificar atrás)
• tem as datas todas iguais,
• tem um tamanho alocado de 5.566.464 ou 1.359 clusters, como também já se tinha visto atrás e
• tem o nome “Picture4.jpg”, descrito no namespace Win32 e DOS.

O 3º atributo é um $DATA,

• correspondente ao tipo 80h,
• não residente,
• sem nome,
• com início no VCN 0 e
• com termo no VCN 54Eh =1.358,
• com nova referência ao tamanho alocado de 54F000h = 5.566.464 (1.359 clusters),
• com o tamanho real de 54E8DFh = 5.564.639 Bytes e
• igual tamanho da corrente de dados inicial.

O data run (porque é só um) é

42 4F 05 5F 62 0A 01 00 00

ou seja,

• 2 Bytes que definem a sua dimensão em clusters e que se encontram já a seguir a este 42  –   054Fh = 1.359
• 4 bytes que definem o seu offset em clusters, bytes esses que se encontram logo após os 2 bytes que definem o seu tamanho 4F 05 e que são 010A625F h = 1.091.109 clusters, ou seja, no offset 10A625000h.

Esta informação diz-nos que o ficheiro que procuramos não está fragmentado e se encontra nos 1.359 clusters seguintes ao offset 10A625000h.

Percebemos por aqui que, uma vez encontrada na MFT a entrada do ficheiro, ficamos com toda a informação sobre a sua localização no disco, fragmentado ou não. Só no caso muito excecional de a cadeia de data runs não caber no espaço da entrada do ficheiro na MFT (ficheiro muito grande e largamente fragmentado), assim não será.

A partir daqui já não adianta vermos o aspeto do editor hexadecimal, pois o que lá se encontra é o código constituinte do ficheiro, ilegível para nós.