Escrevendo em discos sem sistemas de arquivos

Passo algumas maneiras de como escrever em um dispositivo sem que ele possua um sistema de arquivos e como usar isso para segurança. Também é possível aproveitar a dica para realizar formatações sem perder dados e qualquer coisa do gênero.

[ Hits: 24.063 ]

Por: Douglas Ritter em 27/04/2009


Introdução ao sistemas de arquivos



Imagine um livro qualquer. Daremos para esse livro 400 páginas e diremos que o tamanho das letras compreendem mais ou menos o tamanho 8 de uma fonte de computador X qualquer. Pode você ver quanta coisa temos escrita aí? Suponha que o livro em questão foi você que escreveu. São suas memórias passadas. De repente você sente uma vontade súbita de ler novamente o que você disse nele sobre quando caiu da bicicleta pela primeira vez. Onde está? São 400 páginas! Como eu não disse quando você começou a andar de bicicleta e nem o quanto sua vida toda representa, ninguém pode, nem mesmo, ter uma idéia onde essa informação vai estar ao longo das 400 páginas, certo?

Tão logo você percebe que o único jeito é passar o olho, pelo menos, nas 400 páginas, de forma aleatória ou não, até encontrar. Depois de passar por isso, você resolveu criar algo para facilitar da próxima vez. Se o ser humano cria é porque ele precisa; isso é regra universal. Eis que você sentou-se com livro e escreveu mais 20 páginas. Nelas, você escreve o que as outras páginas descrevem e assim, quando precisar olhar tal fato outra vez, terá um ponto de referência. Meus parabéns, você acaba de criar o índice!

Usando essa mesma teoria, vamos olhar para um disco rígido qualquer: vamos chamar seus setores de páginas e os dados neles, cada byte vamos chamar de letra. Então temos um HD com várias páginas e muita coisa escrita, concorda? Como se achar diante toda essa confusão? Sim, imagine se o HD tiver que procurar cada vez que uma determinada coisa for solicitada em todo o disco? E digo mais: você sabe o que tem no seu livro porque foi você que escreveu, mas como fazer outra pessoa saber a mesma coisa? Tão logo, um componente T qualquer não pode solicitar nada para o HD, se nem ele sabe o que existe lá! Partindo daí precisamos de um índice nesse HD, algo que possa informar, o que quer que seja, sobre o que há nele e onde exatamente está. E daí surgiram o sistemas de arquivos. E eu afirmo: sem eles a informática que conhecemos não existiria, ou seja, encare como você encarar, ainda assim, de um jeito ou de outro, ele teria que ser inventando. E ele foi!

Hoje são muitos. Todos tem muito em comum e somente algum diferencial a mais. Uns não permitem escrever mais que tantas gigas; outros garantem mais segurança contra perdas de dados; outros são somente a teoria da sua necessidade, e assim vai. Enquanto no mundo Windows, hoje, o mais comum é o NTFS, no mundo Linux o EXT3 é muito usado. Eles são um script. Um pequeno script posto em seu HD e que possui uma tabela, que é seu índice em questão. Ela sabe onde um determinado conjunto de dados começa e onde termina. Ela sabe, também, quantos bytes tem essa tal informação. E para fazer referência a ela foi criado o arquivo. O arquivo nada mais é o nome dado para essa informação. Pronto! Agora qualquer um pode chamar uma informação qualquer e o HD pode precisamente ir atrás dela. Interessante, não?

Novamente, imagine o livro. Desta vez ele não está completamente cheio. Ele tem um espaço nas páginas 44 e 378, que cabe exatamente uma letra cada uma. Você quer escrever justamente duas letras. Não há como fazer isso no livro, exceto se você quebrar colocando uma letra em cada página. E foi o que você fez. Olhando assim isso parece ridículo, mas dando esse exemplo para o HD, veremos que acontece toda hora. Seu HD está quase cheio, tendo somente 2MB disponíveis. Onde uma está no setor 34 e a outra no setor 48500, ou seja, bem distantes uma da outra. E quer você gravar 2MB. E agora? Agora entra um dos diferenciais do sistema de arquivos! Se nesse HD o sistema de arquivos foi FAT, por exemplo, será impossível gravar essa informação. Porém se for NTFS, por exemplo, ele irá quebrar o arquivo em 1 MB e colocar a primeira parte no setor 34 e a outra no setor 48500, referenciando isso na sua tabela. Assim, sempre que tal arquivo for chamado, o HD irá pegar a primeira parte no setor 34 e saberá que outra parte no setor 48500. Meus parabéns, você acaba de criar um arquivo fragmentado.

Bem, praticamente isso é um sistema de arquivos. Um pequeno script, cujo a função é gerenciar os dados postos dentro do HD e que seja fácil encontrá-los novamente. E isso é feito na formatação de disco. Antes de explicar isso vou explicar uma convenção. Cada setor tem 512 bytes, sem importar o tamanho do dispositivo (hd, disquete, pendrive, ...). O tamanho total do dispositivo (tal informação pode ser obtida por exemplo usando o cfdisk, no Linux) dividido por 512 resultará quantos setores esse disco tem. Sempre serão divisíveis exatos por 512. Dois arquivos não podem ocupar o mesmo setor.

Por exemplo, sejam dois arquivos: telefone_gatinha.txt (8 bytes) e datas_provas.txt (273 bytes). Somando isso tudo teremos somente 281 bytes, ou seja, pouco mais da metade de um setor, porém ao gravar isso no HD estaremos dando um setor para cada um. O telefone_gatinha.txt usaria 8 bytes do primeiro setor e deixaria 504 bytes livres, essas não seriam preenchidas e o segundo arquivo 281 bytes seriam usadas e 231 bytes ficariam sem uso, porém o próximo arquivo começaria no setor 3, mesmo que ele tivesse somente 1 byte. Ou seja, baseado nesses dois arquivos, você já teve 735 bytes perdidos. Porém quando usamos sistema de arquivos, esse tamanho pode ser 512 (formato físico no disco) ou algum múltiplo seu como: 1024, 2048, 4096, 8192 e assim por diante e todos ali representados em byte.

O Windows XP, por padrão em NTFS, formata os HDs com 4kb de bloco, ou seja, 4096 bytes. Cada arquivo que há no disco ocupa sempre 8 setores, mesmo ele tendo tamanho inferior a esse quantidade de bytes. Tão logo é possível afirmar que o tamanho total de um dispositivo pós formatado dividido pelo tamanho do seu bloco resultará no tamanho máximo de arquivos que esse disco poderá ter se todos esse arquivos forem inferiores ao número do bloco. Para explicar isso melhor, pegarei o exemplo de um disquete, segue abaixo seus dados pós formatados:

Espaço total (após formatado, pois sem o sistema de aquivos ele ainda é maior): 1. 457. 664 bytes (1,38mb aprox.)
Tamanho do setor (bloco): 512 bytes

Logo, dividindo o tamanho total pelo setor temos 2847 e isso é a quantidade máxima de arquivos que podemos pôr nesse disquete. Jamais ele terá mais arquivos que isso, pelo menos não enquanto tiver nesse tipo de formatação. E para atingir essa quantidade, nenhum arquivo pode ser maior que 512 bytes. Ou seja, aqui você pode ver que formatar o disco com blocos grandes reduz a quantidade de arquivos que ele poderá ter. Outro detalhe interessante é que 2847, supondo que cada arquivo tenha 1 bytes, é 2,8 kb aproximadamente, ou seja, quase nada para um dispositivo que tem 1,38MB, mesmo assim estará cheio.

Isso foi uma rápida explicação sobre o que é o sistema de arquivos, sua importância e como ele influencia o uso de um dispositivo.

Motivo do artigo

Porque você iria querer escrever em um dispositivo sem usar sistema de arquivos? Há várias razões, mas vou citar uma que está sempre na moda em computação: segurança. Usando sistema de arquivos, você até pode dar um atributo de oculto para um arquivo, mas isso não impede que ele seja encontrado. Agora se ele tiver no disco, mas não no sistema de arquivos, jamais aparecerá, até porque ele nem terá nome de arquivo, seus dados somente estarão lá.

Torna em anos luz mais complicado a vida de qualquer um que encontrar e ainda mais pra quem nem sabe que há algo lá. Imagine você poder colocar um arquivo no seu pendrive muito importante e não ter preocupação caso ela seja roubado, pois não terá acesso ao arquivo lá dentro e tão pouco saberá que ele está lá. Isso só tem um preço: como não estará no sistema de arquivos, poderá ser sobrescrito caso algo escreva nos setores que o correspondem. Ou seja, não posso garantir segurança quanto a perder o arquivo, mas posso garantir muito trabalho e dedicação de quem for tentar recuperá-lo. Também, esse artigo mostrará maneiras exatas de evitar que o mesmo seja sobrescrito e maneiras de complicar sua recuperação, talvez até, essa última, com certeza matemática. Somente você poderá trazê-lo de volta.

    Próxima página

Páginas do artigo
   1. Introdução ao sistemas de arquivos
   2. Escrevendo sem sistemas de arquivos: mão na massa!
   3. Considerações gerais
   4. Manter arquivo no dispositivo depois de formatação
   5. Conclusão
Outros artigos deste autor

Criando ou aumentando a memória virtual (SWAP) no Linux

Leitura recomendada

Análise de Malware em Forense Computacional

5 comandos que ninguém nunca deve executar no Linux

Gerenciando certificados A1 fornecidos pelo ICB-Brasil no navegador Chrome sobre Linux

Melhorando a segurança do Firewall com Bridges usando Snort_Inline no Debian Etch

SSH: Métodos e ferramentas para invasão

  
Comentários
[1] Comentário enviado por capitainkurn em 27/04/2009 - 20:05h

Muito interessante e criativo seu artigo! Parabéns! Já o adcionei em meus favoritos.

[2] Comentário enviado por rodrigomanga em 27/04/2009 - 21:10h

ótimo artigo!
me deu até algumas idéias

volta e meia tenho q formatar micros com XP, e lotado de videos e mp3, ao inves de eu usar gparted, posso copiar os arquivos direto pro hd.

será q não tem um jeito de usar o tar sem compactação pra juntar os arquivo e pegar a saida da linha de comando pra jogar direto no dd?

[3] Comentário enviado por gustavoh84 em 28/04/2009 - 00:08h

Excelente artigo!
Tá de parabéns mesmo!

[4] Comentário enviado por removido em 28/04/2009 - 01:34h

Excelente artigo, em minha opinião um dos melhores publicados nos últimos meses. Muito interessante para estudantes da área de TI.

[5] Comentário enviado por dstter em 28/04/2009 - 07:51h

rodrigomanga excelente idéia e tem sim.

tar -cvf - suaentrada | dd of=caminhosaida seek=x (Use seek caso queria pular n setores no dispositivos de saida)

Lembrando geral que NUNCA "suaentrada" deve possuir arquivo(s) nos setores que dd ira começar a escrever, por exemplo:

Dispositvo com 1000 setores (/dev/qlr)
Arquivo gravado dos setores 650 até 850 (do mesmo dispositivo (/dev/qlr))
nome do arquivo: teste.vol

tar -cvf - teste.vol | dd of=/dev/qlr SEEK=702

Aqui ele faria e não daria nenhum erro. Porém, como ele começou a escrever no setor 703 e nesse setor contia uma parte do arquivo teste.vol o mesmo ficou corrupto, pois agora naqueles setores está o inicio desse mesmo arquivo. Ficou alguma coisa assim:

Lendo setor 650 e escrevendo em setor 703
Lendo setor 651 e escrevendo em setor 704
...
...
...
Ou seja podemos prever que ao ler o setor 703 ele já vai estar escrevendo do 756, porém esse setor 756 será idêntico em dados que o 650 e 703 (esse obviamente). E as partes do arquivos que estavam ali foram trocadas pelos dados do 650. O mesmo aconteceu com o setor 704 que passou a ter os dados que tinham o setor 651 e assim seguidamente. É preciso ter certeza que os setores o DD irá escrever não há dados consideráveis e ainda devem ser lidos, senão resultará em erro. Eu não consegui me expressar bem, mas espero que tenha deixado a imagem.


[6] Comentário enviado por aaron.binner em 28/04/2009 - 16:53h

Ótimo artigo, muito bem detalhado. já foi para os meus favoritos!

[7] Comentário enviado por removido em 28/04/2009 - 18:14h

Texto muito bem escrito, didática excelente, tema muito interessante. Mas a sua aplicação em segurança é ridícula! Seria uma piada tentar esconder arquivos valiosos desta forma. Existem trilhões de softwares prontos para escovar cada bit do disco em busca de qualquer coisa relevante. Infinitamente mais seguro, simples e prático utilizar um sistema de arquivos criptografado. O truecrypt permite até mesmo criar volumes escondidos. Mas o artigo é excelente! Gostei muito de ler e tive muitas idéias legais (decidi escrever o meu próprio sistema de arquivos por diversão). Sem dúvidas uma ótima contribuição.

[8] Comentário enviado por dstter em 29/04/2009 - 06:22h

Olá bpiero, poderia me passar quais programas você se referia? Eu fiz milhões de testes antes de escrever esse artigo e não posso garantir, mas não é bem assim para trazer o arquivo de volta, contudo eu também especifiquei que o uso mais adequado era para usuário doméstico. Você não vai varrer um dispositivo se não souber que tem algo interessante nele, certo? Já se você criptografar estará dizendo que é algo importante tão logo fará curiosidade e onde tem curiosidade tem gênio e onde tem gênio em função do tempo tem descoberta. Criptografias podem ser quebradas. Eu coloquei um arquivo na area "conclusão" onde a idéia justamente era essa: tentar trazer de volta e invalidar a idéia. Como Darwin, eu a jogaria no lixo. Atualmente também trabalho em um projeto de segurança que não só criptografará (com logaritmos alternados) como também irá mover as bits de seus lugares tornando o arquivo impróprio. Aposto 20 mil reais aqui para quem me indicar um programa que traga o arquivo postado no megaupload de volta (sem passar pelo script). Com todo respeito, acho errado ser liberado uma informação sem antes ter certeza do que esta sendo dito, sobretudo agradeço você e aos demais aqui pelo apoio e positivação ao artigo. Boas idéias a todos :)

PS: Eu não tenho 20 mil reais, alguém tem um programa para recuperar o arquivo? xP

[9] Comentário enviado por gustavs em 29/04/2009 - 20:20h

Belo artigo!
Mas como bpiero disse, não é exatamente seguro: 'esconder' nunca será o mesmo que 'trancar' - mas usar os dois pode definitivamente ajudar. E sobre criptografia, talvez fosse mais útil e prático utilizar o número do setor que você teria que guardar para criptografar o arquivo normalmente do que fazer o indicado.

Mas há um jeito de inutilizar qualquer programa que busca por cabeçalhos zip ou qualquer outro padrão, muito simpes:

"Scrambler" (embaralha os bits de um arquivo)
Pseudo-código:

for ( i = 1; i <= comrpimentoArquivoBits; i++ ) {
..temp[i mod 4] = arquivo[i]
..if ( i mod 4 == 0 ) {
....for ( i2 = 4; i2 <= 1; i2++ ) {
......arquivo_saida[i] = temp[i2]
....}
..}
}


Eu fiz um algoritmo simples poque ele pode ser utilizado para codificar e decodificar
(bom ele é bem simples: ele só mudaria uma sequência de 12345678 para 43218765, mas nada conseguiria identificar esse padrão, mesmo que simples)

[10] Comentário enviado por dstter em 01/05/2009 - 16:54h

Oooolhaaa! Embaralhar as bits também faz parte da criptografia que eu estou criando. É uma do total de 10 modulos, mas como eu disse.. isso era para uso doméstico. Nenhum programa que escove HD dará o arquivo de cara para ninguém. Tá certo que para uso doméstico uma criptografia é muito melhor e mais pratica (mas estou escrevendo programa que faz o que eu disse a cima) Contudo, imagine você puder entrar numa empresa fazer copias e sair com o pendrive na mão sem medo? Esse é o lado ruim do procedimento, mas o lado bom é ter documentos que não existem. Se empresas guardassem coisas assim seria muito melhor. Imagine uma pilha de cds, disquetes ou seja lá o que for.. Ai de 1000, 700 estão cheio de nada (mas aparecerá dados) e os outros 300 tem dados importantes.. Muito mais dificil ter tempo para achar e roubar a informação...


[11] Comentário enviado por marcrock em 14/05/2009 - 03:01h

Muito bom seu artigo !
Essa maneira pode não ser a mais indicada para segurança de dados, mas é com certeza um modo interessante de dificultar o acesso a eles. Talvez fosse possível também fazer um script que dividisse o arquivo em muitas partes e escrevesse essas partes de maneira aleatória de acordo com uma senha ou algo parecido e depois para recuperar os bytes ela voltasse a ser usada pra indicar os setores onde estariam os dados . Quanto aos programas que o bpiero citou, com certeza existem softwares otimizados para isso ( creio que sejam usados principalmente em ações forenses ), realmente nesse tipo de análise onde se ignora os sistemas de arquivos e se faz até varredura de carga residual nos bits, não creio que dá pra escapar , já na criptografia ainda existem algoritmos que não foram quebrados com a capacidade de procesamento atual , mas é questão de tempo :-p !

Parabéns pelo artigo .


Até +.

[12] Comentário enviado por dstter em 16/05/2009 - 15:05h

Olá todos. Não é que eu não aceite criticas, nem esteja defendendo meu método, porque o artigo é meu. Programas forenses não fazem milagre. Se alguém me recuperar o arquivo que postei, ai eu sedo a mão, mas tenho conhecimento nessa area, eu sei do que estou falando. Agradeço a todos pela parabenizações :)


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts