Escrevendo em discos sem sistemas de arquivos

dstter

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: 26.243 ]

Por: Douglas Ritter em 27/04/2009

0 0

Denuncie Favoritos Indicar Impressora

Escrevendo sem sistemas de arquivos: mão na massa!

Para fazer isso você precisará de alguns requisitos:

Pacote coreutils (qualquer distribuição Linux o traz; Existe para Windows no site da GNU ou o Cygwin e semelhantes).
Saber quantos bytes tem seu dispositivo (para isso podemos usar o cfdisk, no Linux. Não tenho sugestão para Windows, mas deve haver).
Conhecimentos com os programas do pacote coreutils: dd, split, cat.
Uma calculadora (pode ser a expr do pacote coreutils também).
Papel e caneta (serão feitas muitas anotações).
Acesso a super usuário no Linux (seja por senha ou pelo sudo).

De posse disso e alguma matemática, podemos usar esse artigo para proteger informações, recuperar informações, formatar um HD sem perder os dados dentro dele e muitas coisas mais.

Protegendo informações: a maneira simples

Nosso dispositivo: pendrive
Referenciado em /dev em: /dev/sdb
Quantidade total de bytes: 2052547072 (2GB aprox)
Setores: 4008881 (lembrando que o zero, no início, conta como um setor)

Gravaremos:

Arquivo: projetos.zip
Tamanho: 263192926 bytes (251MB aprox)
Quantidade de setores usados: 514048 perfeitos e 1 imperfeito com 350 bytes, ou seja, faltaram 162 bytes para 512 bytes. TOTAL: 514049 setores (usado para fins de recuperação)

Primeiramente vamos fazer um md5sum desse arquivo para temos certeza que é ele que recuperamos no final. Vamos salvá-lo em um arquivo chamado projetos.zip.md5sum na pasta /home. Por exemplo, para isso:

# md5sum projetos.zip | dd of=projetos.zip.md5sum

Agora temos a soma para checarmos depois.

Dos 40 milhões e 88 mil e 81 setores do pendrive, vamos gravar nosso arquivo no setor 383300, por exemplo. Note que o setor que vamos gravar, mais número de setores que o arquivo ocupa, não pode ser maior que o número de setores do dispositivo, senão obviamente faltará espaço. Para isso:

# dd if=projetos.zip of=/dev/sdb seek=383299

Temos agora nosso arquivo lá. Mesmo que esse pen tivesse sistema de arquivos, ele não teria sido perdido, pois nada foi gravado em seus setores iniciais. Logo é possivelmente tanto ter um pen normal, como ter dados escondidos dentro dele. Note somente que se houver algumas informações referenciadas no sistema de arquivos no setor que acabamos de colocar o projetos.zip, ficará inválido, pois o conjunto de dados de projeto.zip o substituiu.

Para recuperar basta:

# dd if=/dev/sdb of=/home/t0 skip=383299 count=514049

Onde:

skip = setores que serão lidos no dispositivo if e ignorados;
count = quantidade de setores a serem lidos após skip e escritos.

Assim teremos um arquivo chamado t0 que contém os dados que haviam no local indicado. Vimos que nosso arquivo continha um setor imperfeito. Em teoria um arquivo ter dados a mais no seu final, não o corrompe, mas no md5sum por exemplo não dará certo, para ajeitar isso basta:

# dd if=t0 of=projetos.zip bs=263192926 count=1

Onde:

bs = quantidade que o dd lerá e escreverá.. Aqui é o tamanho do nosso arquivo.
count = quantidade de vezes que ele fará isso.. Nesses casos sempre será 1.

NOTA: Aqui temos um tamanho muito grande de dados em bs= e dependo da sua memória dará erro, pois esse valor é posto na memória para depois ser escrito na saída. Segue abaixo maneiras para contornar isso, caso esse seja seu problema:

Uma maneira mais simples:

# split -b 263192926 t0

Agora foram criados dois arquivos. Um com o tamanho do antigo projetos.zip chamado xaa e outro com o restante e que não pertencia a esse arquivo chamado xab.

Renomeie o xaa para projetos.zip e apague o xab:

# mv xaa projetos.zip
# rm xab

Agora passe o md5sum e veja que você acabou de obter o mesmo arquivo:

# md5sum -c projetos.zip.md5sum

Pronto!

Obs.: Nomes destino para os arquivos ficam por sua conta.

Vantagens e desvantagens dessa maneira

Essa é uma maneira fácil de fazer, porém apresenta alguns riscos caso pegue um usuário experiente. Por exemplo, no exemplo se tratava de um arquivo zip, no Windows existem programas que podem checar um arquivo zip e recuperar arquivos que estejam dentro de zipados, ou seja, se eu fizer uma imagem do pen inteiro gravando como um arquivo x.zip qualquer, posso usar esse programa para varrer o arquivo e recuperar o que tenha dentro. Uma alternativa a isso seria criptografar projetos.zip usando, por exemplo o CCrypt. Está certo que essa criptografia pode ser quebrada, mas aí já exige um usuário ainda mais experiente. Lembrando que aí, ao invés de ir ao arquivo zip será usado o procedimento no arquivo saída do CCrypt.

Uma maneira mais complexa

Segue abaixo uma maneira mais complexa de recuperar o mesmo arquivo exemplo. Aqui teremos um outro qualquer, por definição eu escolhi um exe do Windows e ele tem 4194604 bytes, ou seja, 4MB aproximadamente. Seu nome é programa.exe.

Aqui misturaremos nosso arquivo zip com outro qualquer, a qual chamaremos de arquivo garbage.

Vamos olhar o tamanho do nosso arquivo zip em termos de divisão: 263192926

Se termina em par, sabemos que divide exato por 2. Podemos então fazer 2 partes e em cada uma colocar um arquivo garbage, por exemplo:

projeto.zip.part2 + garbage + projeto.zip.part1 + garbage

Assim não teríamos mais um arquivo íntegro. Mesmo que o pendrive fosse lido do setor 0 até seu último, seria impossível o mesmo programa que citei acima achar o arquivo em ordem. Mostrarei esse exemplo abaixo.

Vamos pegar nosso arquivo garbage (no caso o .exe que mencionei acima) e quebrá-lo em 2 partes:

# split -b 2097302 programa.exe

Temos o arquivos xaa e xab. Para evitar confusão vamos renomeá-los como garbage1 e garbage2.

# mv xaa garbage1
# mv xab garbage2

Agora vamos repetir o processo no projetos.zip.

# split -b 131596463 projetos.zip

Temos agora os mesmos dois arquivos xaa e xab. Renomeie-os para part1.zip e part2.zip, respectivamente.

# mv xaa part1.zip
# mv xab part2.zip

Agora vamos unir da ordem mencionada acima:

# cat part2.zip garbage1 part1.zip garbage2 > arquivo_unido

Temos agora um arquivo chamado arquivo_unido, que é a junção da ordem acima. Somando o tamanho dos dois veremos que temos um arquivo com 267387530 bytes. Dividindo ele por 512 obteremos o valor de 522241 setores perfeitos e 1 imperfeito. Basta repetir o processo usado anteriormente para colocá-lo no pendrive:

# dd if=arquivo_unido of=/dev/sdb seek=383299

Para recuperar teremos um pouco mais de trabalho:

# dd if=/dev/sdb of=t0 skip=383299 count=522242

Obtivemos o arquivo copiado de volta. Teremos agora que quebrá-lo e montá-lo várias vezes para obtermos o que queremos.

Olhemos novamente como é a formação do arquivo que obtemos:

part2.zip garbage1 part1.zip garbage2

As partes garbage não nos interessa, pois elas estão ali somente para separar os dados que queremos proteger. Precisamos agora fazer um processo de quebrar em partes que queremos tirar e montar o restante.

Primeira parte: par2.zip | tamanho = 131596463
Segunda parte: gargabe1 | tamanho = 2097302
Terceira parte part1.zip | tamanho = 131596463
Quarta parte: garbage2 | tamanho = 2097302

Métodos para recuperar

Podemos usar o DD para recuperar a primeira parte e depois quebrá-lo em dois (deixando a terceira parte no início) e repetindo o processo, fica:

# dd if=t0 of=f2 bs=131596463 count=1 (aqui obteremos o part2.zip)

NOTA: Se você não tiver a quantidade especificada no parâmetro "bs", poderá obter erro. Sempre coloque valores que seu PC possa gerenciar. Use o count para isso. Se você você colocar bs=5 e count=10, ele é a mesma coisa que colocar bs=50 count=1.

Agora quebremos o arquivo t0 em dois e repetimos o processo no segundo arquivo, assim teremos o part1.zip.

# split -b 133693765 t0

Temos agora as partes: xaa e xab

Para nós somente interessa a parte xab. Basta repetir o mesmo comando dado ao dd no arquivo t0 para obtermos a parte1.zip:

# dd if=xab of=f1 bs=131596463 count=1

Depois una os dois arquivos e pronto:

# cat f1 f2 > projetos.zip

Faça md5sum e cheque:

# md5sum -c projetos.zip.md5sum

Pronto! Com certeza matemática seu arquivo é o mesmo.

Assim como esse jeito, existem muitos outros mais, bem como muitas outras coisas que eu ou não mencionei ou esqueci de mencionar, porém dá para ter uma idéia da lógica que eu quero passar. Qualquer maneira que você pense e que resulte partes corretas do arquivo, será a mesma coisa. Use a que fica mais em conta para você.

Página anterior 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

Prevenção e rastreamento de um ataque

Metasploit Framework

MSN-Proxy no Debian Etch

Biometria facial na autenticação do usuário root

Trilhas de Certificação em Segurança da Informação - Qual caminho seguir?

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.

0 0

[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?

0 0

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

Excelente artigo!
Tá de parabéns mesmo!

0 0

[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.

0 0

[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.

0 0

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

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

0 0

[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.

0 0

[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

0 0

[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)

0 0

[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...

0 0

[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é +.

0 0

[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 :)

0 0