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.
Caso seja escrito nos setores onde está o arquivo em questão, sem dúvidas a soma não dará certo e o arquivo estará corrompido. Para evitar isso passo algumas idéias:
Quando for possuir sistemas de arquivos, não coloque as informações no começo do primeiro setor (da formatação: lembre que pode ser 512 bytes; 1024 bytes, 2048 bytes e assim por diante. NTFS padrão é 4096 bytes) e nos últimos setores finais do dispositivo, ou seja, uma formatação em um pendrive usando FAT e tamanho do bloco 1024 bytes: evite colocar os dados nos primeiras 1024 bytes e nos últimas 1024 bytes.
Tenha noção quão tamanho vale no dispositivo o setor que está seu arquivo, por exemplo, o setor 50500 vale exatamente as primeiras 25 mb no dispositivo, tão logo se você escrever mais que isso, com certeza atingirá os dados que passou pelo DD e impedirá sua recuperação com sucesso.
Sistemas FAT armazenam sempre em sequência. Ou seja, se tal arquivo foi de setor 0 até o setor 6, o próximo será do setor 7 até o quanto ele precisar. Caso você apague o primeiro arquivo (cujo dados estão no setor 0 ate o 6) e queira gravar outro que caiba nesse setores, ele será colocado aí. Por exemplo, se ele precisa de 4 setores, ocupará os 4 primeiros setores disponíveis. Mas como FAT nunca QUEBRA arquivos (ou seja fragmenta), caso ele não caiba no setor 0 até o 6, será colocado inteiro no próximo setor disponível a partir do último ocupado. Isso vale para o FAT, já outros sistemas de arquivos quebram dados para preencher setores.
Evitar a recuperações do arquivo por terceiros
Se uma pessoa não souber onde está o arquivo jamais irá recuperar. Talvez nem faça idéia que há dados que podem ser recuperados ali. Mesmo assim, quanto mais segurança você colocar, sempre melhor. Procure criptografar dados, colocar senha em compactados e qualquer outra coisa que você pensa que possa ajudar, abaixo mando umas dicas.
Mudar de ebdic para ascii usando o DD (parâmetro conv=). Assim ele fica irreconhecível e nenhum programa que passe sobre esses dados será capaz de reconhecê-lo. Por exemplo, no caso do arquivo zip em cima, nesse exemplo tal programa que eu citei não seria capaz de encontrar os arquivos dentro do zipado.
Inverter ordens do arquivo quebrando-o também é uma boa maneira de confundir. Quanto mais você inventar, melhor. Eu costumo criar scripts em shell para trazer o arquivo de volta, assim não perco tempo revendo as informações necessárias. E dentro do próprio script, posso colocar o md5sum embutido, assim fica tudo em um arquivo só. Use a imaginação, invente!
Sei que ficou pouco confuso, porém sinta-se a vontade para perguntar qualquer dúvida que aparecer. Se gostou da idéia, muito obrigado (mais adiante coloco um arquivo feito por mim para que você pode tentar recuperar e notar qual é o grau de dificuldade).
[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.
[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 !
[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 :)