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.242 ]

Por: Douglas Ritter em 27/04/2009

0 0

Denuncie Favoritos Indicar Impressora

Conclusão

Sem dúvida as possibilidades explicadas no final podem não ser de uso claro ou necessário, mas no meu caso foram um salva vidas de primeira, contudo a parte de proteger dados escondidos dentro do disco pode ser muito útil a muita gente. Obviamente deixei de mencionar muita coisa. Encare os dados acima somente como exemplos, qualquer jeito que encare a lógica dará a mesma coisa. Espero que goste da ideia e ela seja útil para você. Muito obrigado por ler esse artigo.

Conclusão extraordinária (salve as princesas)

Como prometido, mando um arquivo feito usando as informações acima para quem quiser testar como seria recuperar algo. Obviamente o que eu fiz não será dito, pois esse será o mesmo cenário para qualquer um que for tentar recuperar seus dados. Só direi que o arquivo abaixo possui algumas fotos em JPG contidas dentro de um zipado comum, desses feito no Windows XP. Você acha que consegue trazer elas para sua tela? Boa sorte! :)

Desculpe os erros de português e coisas assemelhadas; "O Captain! My Captain" eu termino aqui, senhor!

Download do arquivo: http://www.megaupload.com/?d=Q11A21R4

Download do script*: http://www.megaupload.com/?d=9QVV0QI2

* Esse script foi feito rapidinho, é linha de comando bem básica mesmo. Mas quando executado no mesmo local que está o arquivo, é capaz de trazê-lo de volta (exemplo vale para esse somente). Caso você tente e não consiga, aí está a maneira de reverter o processo feito por mim. É uma maneira interessante de você andar com dados de campo A para campo B sem preocupação quanto a amostra desses dados. E como o script fica pequeno, pode ser tranquilamente armazenado na internet por exemplo. Se você o ler, verá que não traz nada a mais senão os próprios comandos necessários para trazer o arquivo de volta.

Página anterior

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

From Deploy WAR (Tomcat) to Shell (FreeBSD)

Monitorando as conversas do MSN

OpenBSD IDS - Solução Snort e BASE

Construindo um Log Server utilizando Linux, Unix e Windows

Jogando pesado na segurança de seu SSH

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