Neste artigo, mostrarei como criar um contêiner de criptografia oculto. meios padrão Linux OS (LUKS e cryptsetup). Os recursos integrados do LUKS (como o uso de cabeçalhos externos e a colocação de dados reais em um determinado deslocamento) permitem que o usuário acesse dados ocultos dentro de um contêiner existente, bem como negar a existência de tais dados.

UPD: Como este post estava pronto há um mês, eu não conseguia nem imaginar uma morte tão estranha e inesperada do projeto. Bem, sim, talvez ainda não tenha morrido completamente, vejamos... Apesar disso, neste texto, decidi deixar todas as referências ao TrueCrypt como estão.

O que é "negabilidade plausível"?

Você pode encontrar uma descrição muito longa e detalhada deste conceito na Wikipedia: http://en.wikipedia.org/wiki/Plausible_deniability . Em suma, isso significa que você pode ter algo (ou poderia ter feito algo), cuja presença não pode ser suspeitada ou comprovada por ninguém (a menos que você mesmo admita, é claro). E depois você pode negar a existência (ou o fato de fazer) esse algo, se alguém quiser acusá-lo, pois (repito) esse fato é improvável. Bem, por exemplo, se uma criança chutasse seu irmãozinho na bunda, e o irmão fosse buscar a justiça de seus pais, o que aconteceria nesse caso?

Bem... Como se nada acontecesse. Porque esse cara vai recusar, e os pais, formalmente falando, não poderão pegá-lo pela mão (porque, em primeiro lugar, estupidamente não há testemunhas e, em segundo lugar, o irmão mais novo pode jogar seu jogo sujo). Assim, ninguém será punido. Bem, ou eles punirão ambos por cada bombeiro. Este foi apenas um exemplo do uso da possibilidade de negação plausível por uma criança propensa à agressão. Mas você e eu, é claro, somos brancos e fofos, e usaremos contêineres ocultos apenas para proteger nossos dados pessoais de bandidos. Tão certo? Claro, “o que é “bom” e o que é “ruim”” é uma questão separada... No entanto, mais direto ao ponto.

Ideia geral de implementação

Suponha que queremos armazenar alguns dados importantes dentro de um arquivo criptografado. Em geral, usaremos algum tipo de programa de proteção criptográfica que fará todo o trabalho sujo para nós. Podemos querer tratar o arquivo criptografado como se fosse um disco virtual, e isso reduz consideravelmente o número de possíveis candidatos. No entanto, há um "mas". Quase todos esses programas funcionam com um arquivo como com um pedaço de dados criptografados. Deixe-me explicar: o usuário geralmente tem 1 senha (e talvez alguns "sobressalentes") para tudo dados dentro do contêiner. Isso significa que há pelo menos um elo fraco: a senha do contêiner. Não quero mencionar que a senha deve ser criptograficamente forte, porque essa é uma verdade comum. O que quero dizer é que se o usuário desistir dessa senha por algum motivo (por exemplo, sob coação), todos os dados serão lidos. E esse fato me parece triste e completamente errado...

No entanto, geralmente há esperança. :) Por exemplo, existe um programa como o , que é bastante inteligente. O usuário pode criar dois containers em um arquivo: um é “dummy” com um certo número de arquivos “proibidos”, mas relativamente seguros, e o outro é real, com dados que não devem ser expostos em hipótese alguma. Assim, o TrueCrypt solicita duas senhas diferentes quando um usuário deseja criar um contêiner "duplo". Durante a operação, o usuário insere apenas uma senha para a parte "real" e trabalha com ela. Caso, sob pressão de circunstâncias externas, o usuário seja forçado a divulgar o conteúdo do contêiner a terceiros, ele simplesmente digita uma senha diferente e o TrueCrypt abre a "falsa". Ressalto (e isso é muito importante) que não há como comprovar a presença da parte oculta se o pesquisador não souber a senha correspondente.

E agora vamos descobrir rapidamente como esse lixo funciona... Na verdade, tudo é muito simples. O software divide o arquivo container em duas partes (de modo geral, desiguais). A primeira parte, que pode ser relativamente pequena, contém dados especialmente preparados; a segunda é real. Assim, o programa deve ser capaz de trabalhar com dois cabeçalhos (configurações) diferentes para duas partes diferentes, e também poder escolher qual parte descriptografar dependendo da senha inserida pelo usuário. E isso, devo dizer, não é a parte mais trivial do trabalho. Bem, simplesmente porque "oficialmente" apenas uma configuração "falsa" deve ser visível: se o contêiner tiver um cabeçalho padrão, ele deverá ser apenas um cabeçalho "falso"; se os parâmetros do contêiner forem armazenados em uma configuração separada, essa configuração deve permitir descriptografar apenas a parte "falsa". E depois de decifrar a parte "falsa", não deve haver um único indício da presença da real. Eles devem ser absolutamente independentes. Além disso, quando a parte “falsa” é aberta, o software deve mostrar a capacidade total do contêiner de criptografia, mesmo que o volume dessa parte seja muito menor.

Então e LUCAS?

Bem, aqui temos boas notícias e... erm... ainda mais boas notícias.

A boa notícia é que cryptsetup pode descriptografar e montar volumes criados pelo TrueCrypt ". Somente leitura, no entanto, mas isso não faz sentido. Já que há notícias melhores. Ou seja, podemos criar contêineres "ocultos" exclusivamente usando . Além disso, este utilitário permite que você crie qualquer número de partes "ocultas". Naturalmente, dentro de limites razoáveis. E aqui está como isso pode ser feito.

Mas antes de continuar,

AVISO ASSUSTADOR GORDO ENORME!!!

• Qualquer coisa descrita abaixo pode causar perda de dados irreversível.
• Em seu país, o uso de criptografia forte pode ser proibido, então você pode ser preso não por informações reais, mas simplesmente por ter um contêiner de criptografia que será encontrado em seu parafuso.
• A criptografia pode proteger seus dados, mas não o protegerá da tortura. Um container escondido pode ajudar a guardar informações valiosas, mas você não pode negar sua presença em caso de traição ou denúncia.
• Os caras que estão interessados ​​em seus dados criptografados podem não ser tão burros quanto você esperava. Mesmo que eles não possam provar a presença de uma parte oculta do contêiner, eles podem trancá-lo na mesma cela com criminosos experientes e, em alguns dias, você se lembrará de todas as senhas de todos os dados ocultos.
• Se você tem pessoas próximas (namorada/namorado, parentes, amigos), elas também podem se tornar alvo de forte pressão. E isso certamente o ajudará a lembrar de tudo em geral muito mais rápido, inclusive o que você nem sabia.

Portanto, é melhor pensar duas vezes sobre quanta informação é mais valiosa do que sua vida e a vida de seus entes queridos. E faça um backup. Apenas no caso de.

Bem, o cryptsetup pode nos dizer muito detalhes interessantes sobre as opções de linha de comando deste utilitário. Bem, por exemplo, vamos ver a opção --header:

Bem, tudo bem. Isso significa que agora podemos ter um volume de dados cheio de lixo aleatório, sem absolutamente nenhuma assinatura significativa. A descrição desta opção contém um pouco mais de informações, cuidados e advertências, mas no final das contas, isso é tudo o que é necessário. No entanto, eu recomendo a leitura deste excelente guia.

Outra opção muito útil é --align-payload , que permite posicionar os dados reais em um certo deslocamento em relação ao início do volume:

E isso também é legal, porque agora podemos transferir nossos dados livremente para qualquer parte do volume. Você entendeu a ideia, certo?

1. Inicializamos o volume para criptografia: o sobrescrevemos completamente com dados aleatórios.
2. Criamos um volume criptografado “oficial” e soltamos um pouco Varese infectada, muzla enrolada, pron software livre útil, gravações de sua banda de rock amadora, filmes de amor, etc., em geral, para os quais você não terá mais de dois anos de liberdade condicional.
3. Usando as opções esotéricas de cryptsetup acima, criamos um volume oculto (dentro do “oficial”) e transferimos seu título para mídia externa, onde você pode armazenar informações realmente perigosas (como suas fotos do jardim de infância ou planos para conquistar o mundo).

Na verdade, pessoal, isso é tudo. Nenhuma mágica. Naturalmente, você não pode encher o disco criptografado "oficial" até a capacidade pelo simples motivo de que parte de seu espaço é entregue a um contêiner oculto. E, como eu disse no início, você pode, se quiser, criar várias unidades ocultas seguindo a mesma lógica.

Aqui ... E se você ainda precisar de detalhes, especialmente para você -

Passo a passo

Atenção!

Os comandos a seguir destruirão seus dados se executados sem ativar o cérebro. As informações perdidas não podem ser recuperadas porque utilitários como o dd operam em um nível baixo (ou seja, abaixo do nível do sistema de arquivos). Portanto, não será possível reverter as alterações ou desfazer seu efeito, mesmo se você abortar imediatamente após o lançamento.

Em resumo, não faça isso a menos que você possa pensar em uma explicação significativa de como cada etapa se relaciona com seus objetivos. E faça um backup. Agora mesmo.

Então, digamos que temos um dispositivo com várias partições. Seja, por exemplo, /dev/sdb. E deixe /dev/sdb1 ser uma partição relativamente pequena (8 GB) dedicada à criptografia. Vamos dividi-lo de 5 para 3, onde a parte de 5 GB será "oficial" e a parte de 3 GB ficará oculta. Vamos supor também que manteremos a chave do disco criptografado em /etc/keys e o cabeçalho do contêiner oculto, respectivamente, em uma unidade USB externa, que montaremos em /media/user/ExtUSBStick. Suponho que você já saiba quais permissões você precisa definir no keystore, como configurar encfs / ecryptfs para armazenar com segurança dados confidenciais em dispositivos inseguros e também que faz sentido copiar chaves secretas reais e armazená-las em vários cofres separados geograficamente.

Bem, tudo bem, estou amarrando resmungos e passando para a essência da questão.

Inicialização do dispositivo /dev/sdb1:

Dd if=/dev/urandom of=/dev/sdb1 bs=16M

Criamos uma chave para um volume criptografado. 512 bits (64 bytes) para nossos propósitos através do telhado:

Dd if=/dev/urandom bs=64 count=1 >/etc/keys/secret.key 2>/dev/null

Criptografe o volume usando a chave recém-criada:

Cryptsetup luksFormat /dev/sdb1 /etc/keys/secret.key

Abra o dispositivo criptografado e configure o mapeamento em secretdata:

Cryptsetup luksOpen --key-file /etc/keys/secret.key \ /dev/sdb1 secretdata

Criar em um volume criptografado sistema de arquivo(por exemplo, btrfs):

Mkfs.btrfs -L SecretData /dev/mapper/secretdata

... e monte-o:

Monte /dev/mapper/secretdata /var/secretdata/

Tendo em mente o limite de 5 GB, defina a cota de subvolume:

Cota Btrfs habilita /var/secretdata/

Como as cotas btrfs se aplicam apenas a subvolumes, vamos criar uma coisa assim:

brfs subvolume criar /var/secretdata/workingvolume

... e aplique a cota especificada a ele (observe que os subvolumes btrfs podem ser montados como sistemas de arquivos regulares, portanto, pode ser mais conveniente montar esse subvolume específico em vez de todo o fs posteriormente):

btrfs qgroup limit 5G /var/secretdata/workingvolume

Preenchemos com alguns dados:

debootstrap --variant=buildd testando /var/secretdata/workingvolume

Isso é tudo, agora você pode esquecer esta parte:

Umount /var/secretdata cryptsetup luksFechar secretdata

Agora vamos criar um "peixe" para o cabeçalho e colocar lixo aleatório nele:

Dd if=/dev/urandom of=/media/user/ExtUSBStick/hidden.head bs=4M contagem=1

E agora chega o momento em que a verdadeira magia começa. (O quê? Eu disse que não havia mágica? Então eu menti.) Usamos a mesma chave secreta, no entanto, não em sua totalidade, mas apenas metade (de um deslocamento de 32 bytes). No entanto, os restantes 256 bits aleatórios são bastante capazes de fazer uma boa chave. Em seguida, vamos separar o cabeçalho e colocá-lo no pendrive. Por fim, informamos ao cryptsetup "y" que queremos compensar nosso contêiner oculto em 5 GB (ou seja, 10485760 blocos de 512 bytes) do início do volume:

Cryptsetup --keyfile-offset 32 ​​​​--header /media/user/ExtUSBStick/hidden.head \ --align-payload 10485760 luksFormat /dev/sdb1 /etc/keys/secret.key

Sim, é tão simples. Agora vamos abrir um novo dispositivo criptografado:

Cryptsetup luksOpen --key-file /etc/keys/secret.key --keyfile-offset 32 ​​\ --header /media/user/ExtUSBStick/hidden.head /dev/sdb1 realsecretdata

Vamos rolar qualquer fs que queremos:

Mkfs.btrfs /dev/mapper/realsecretdata

Links Úteis

Para quem quiser saber um pouco mais, aqui estão algumas fontes adicionais de informação:

• criptografia de disco, informações gerais sobre criptografia de disco: https://wiki.archlinux.org/index.php/Disk_encryption
• Criptografia negada, o conceito é um pouco mais restrito do que "negabilidade plausível", referindo-se apenas ao campo da criptografia: https://en.wikipedia.org/wiki/Deniable_encryption
• TrueCrypt

Disk (à la TrueCrypt). Eu sei que houve trabalho para adicionar suporte de criptografia ao GRUB2, mas ainda não está pronto. Alguma outra opção?

(Observe que eu realmente quero dizer criptografia de disco completo aqui, incluindo /boot)

A maioria das respostas descreve uma configuração em que /boot não é criptografado, e algumas delas tentam explicar por que um /boot não criptografado deve funcionar bem.

Sem entrar em uma discussão sobre por que eu realmente preciso que /boot seja criptografado, aqui está um artigo que descreve exatamente o que eu preciso, com base em uma versão modificada do GRUB2:

• http://xercestech.com/full-system-encryption-for-linux.geek

O problema é que essas modificações não parecem ser suportadas na base de código GRUB2 atual (ou talvez esteja faltando alguma coisa).

8 As soluções coletam formulários da web para “carregadores de inicialização Linux que suportam criptografia de disco completo?”

eu penso isso Versão Atual O GRUB2 não suporta carregar e descriptografar partições LUKS por si só (contém algumas cifras, mas acho que elas são usadas apenas para suportar senhas). Não consigo verificar a ramificação de desenvolvimento experimental, mas há algumas dicas na página do GRUB de que algum trabalho está planejado para ser implementado e que você deseja fazer.

Atualização (2015) : última versão O GRUB2 (2.00) já contém o código para acessar as partições criptografadas LUKS e GELI. (O link xercestch.com fornecido pelo OP menciona as primeiras correções para isso, mas agora elas estão incluídas na versão mais recente).

No entanto, se você estiver tentando criptografar a unidade inteira por motivos de segurança, observe que um carregador de inicialização não criptografado (como TrueCrypt, BitLocker ou GRUB modificado) não oferece mais proteção do que uma partição /boot não criptografada (conforme observado pelo SP no comentário acima). Qualquer pessoa com acesso físico ao computador pode substituí-lo facilmente por uma versão personalizada. É até mencionado no artigo xercestech.com que você vinculou:

Para ser claro, isso não torna seu sistema menos vulnerável a um ataque offline se um invasor substituir seu carregador de inicialização pelo seu próprio ou redirecionar o processo de inicialização para inicializar o seu próprio. próprio código, seu sistema ainda pode estar comprometido.

Observe que todos os produtos de software de criptografia de disco completo têm essa fraqueza, quer usem um carregador de inicialização não criptografado ou uma partição de inicialização/pré-inicialização não criptografada. Mesmo os produtos que suportam chips TPM (Trusted Platform Module), como o BitLocker, podem ser implantados sem alterar o hardware.

A melhor abordagem seria:

1. descriptografar no nível do BIOS (em placa-mãe ou adaptador de unidade ou hardware externo [smart card], com ou sem chip TPM), ou
2. carregar o código de autorização PBA (autorização de pré-inicialização) (a partição /boot neste caso) em um dispositivo removível (por exemplo, um cartão inteligente ou unidade USB).

Para fazê-lo da segunda maneira, você pode verificar o projeto Linux Full Criptografia de disco(LFDE) em: http://lfde.org/ que fornece um script de pós-instalação para mover a partição /boot para unidade USB externa criptografando a chave com GPG e armazenando-a em USB também. Desta forma, a parte fraca do caminho de inicialização (a partição /boot não criptografada) está sempre com você (você será o único com acesso físicoà decriptação do código e da chave). ( Observação: este site foi perdido e o blog do autor também desapareceu, porém você pode encontrar os arquivos antigos em https://github.com/mv-code/lfde apenas lembrando que o último desenvolvimento foi feito há 6 anos). Como alternativa mais fácil, você pode montar uma partição de inicialização não criptografada em uma unidade USB ao instalar o sistema operacional.

Atenciosamente, M. V.

Faça seu primeiro disco RAM e pasta /boot não criptografado.

Isso invocará um kernel "mínimo" com drivers e suporte para alternar para um sistema de arquivos raiz "real" que é criptografado.

Antes de dizer "é um hack", lembre-se - a maioria (se não todas) as distribuições Linux são inicializadas por padrão hoje. Isso permite explicitamente que seu sistema carregue e carregue o FS raiz usando módulos que precisam ser carregados do sistema de arquivos. (Uma espécie de problema de galinha e ovo). Por exemplo, se seu sistema de arquivos raiz estava em um volume RAID de hardware e você precisava carregar seu driver antes de poder montar o FS raiz.

Eu olhei para o link que você postou - embora partição de inicialização não, o disco rígido ainda possui um bootloader não criptografado que pode ser acessado e comprometido por um ataque malicioso. Estou procurando uma configuração semelhante que não tenha dados não criptografados no disco rígido, mas até agora só consegui executar o carregador de inicialização a partir de uma unidade removível.

Acredito que a maior parte do que você precisa é de uma instrução sobre como instalar um sistema operacional com um HD criptografado em primeiro lugar.

O Ubuntu tem uma página legal com instruções sobre como criar partições criptografadas, LMVP, pastas, etc, apenas sua versão da sua distro...

Não, eu não penso assim.

Você realmente precisa criptografar/carregar? Eu suspeito que não. O resto do sistema de arquivos pode ser criptografado com Programas Linux que reside no initramfs em /boot e avisa o usuário de acordo.

Você parece estar pedindo algo que não pode ser feito e comparando-o com Solução Windows, que oculta a implementação de você, mas na verdade faz a mesma coisa que o Linux faz.

A solução mais próxima que consigo pensar é usar HD, que implementa segurança e criptografia de senha. Algum Notebooks Thinkpad usar essas soluções de hardware.

A resposta está no artigo. "Isso agora é possível com extensões para o carregador de inicialização GRUB2 de próxima geração que foi corrigido para suportar mais do que apenas" e "queremos instalar uma nova imagem habilitada para grub2 luks mais tarde" e "Agora vamos compilar a fonte GRUB2 com LUKS Apoio, suporte. Parece haver uma correção ou extensão que você precisa obter e habilitar com o GRUB2 ou a fonte bifurcada do GRUB2.

Grub2 versão 2.02~beta3 pode fazer muito que o Grub2 versão 2.02~beta2 não pode, verificado por mim:

1. Inicializando usando um disco Super Grub 2
2. Digite "c" para ir para a linha de comando
3. Digite os comandos para montar a partição criptografada que eu quero
   • insmod lux
   • cryptomount (hd0, #) // onde # representa a partição criptografada
4. Digitar frase chave e digite alguns comandos
   • inicialização múltipla (crypto0) /grub/i386-pc/core.img
   • sapato

Isso inicializará outro Grub2 que está dentro da partição criptografada, nenhum ataque maluco aqui ... partição criptografada e inicializando o Grub2 com seu próprio menu, etc.

Atenção: Grub2 versão 2.02~beta2 não pode fazer o mesmo porque tem alguns bugs (que parecem ser corrigidos no Grub2 versão 2.02~beta3) relacionados ao comando cryptomount...

bugs beta2 que estou falando são:

1. Na verdade, ele não monta a partição criptografada, portanto, não permite acessar (crypto0)/*
2. Se houver mais de uma partição criptografada, usar cryptomount -a requer apenas uma senha
3. Depois de iniciar o cryptomount uma vez, ele inicia novamente, não faz nada

na versão beta 3:

1. Na verdade, ele monta a partição criptografada e permite acessar arquivos via (crypto0)/* ou (crypto1)/* etc se mais de um estiver montado ao mesmo tempo
2. Ele solicita cada senha (uma por seção criptografada)
3. Isso permite que você execute quantas vezes quiser, você pode instalar um, depois outro, etc.

Nota lateral: não descobri como desmontá-los além de reinicializar ou carregar outro ou um carregador de inicialização grub2/outros etc.

Espero que isso ajude a esclarecer as coisas, e espero que a versão 2.02~beta3 do Grub2 seja integrada ao LiveCD para que possamos instalá-lo sem ter que compilá-lo nós mesmos.

PD: Com uma unidade Super Grub 2, não vejo uma maneira de instalar o Grub2 versão 2.02~beta3 em uma partição MBR/boot, etc.

Neste artigo, tentarei comparar o desempenho de vários sistemas de criptografia no linux. Em teoria, é claro, sabe-se qual sistema é mais produtivo, e tenta-se calcular o desempenho sistemas diferentes nós estamos (). Truecrypt ainda contém um benchmark embutido (que mostra, no entanto, o desempenho na RAM, só pode ser usado para avaliar a velocidade de diferentes algoritmos de criptografia). Farei algo diferente - medirei a velocidade de um sistema de arquivos criptografado por vários meios como uma porcentagem em comparação com um sistema de arquivos não criptografado convencional.

Vamos criptografar uma partição separada em um disco rígido separado que não contém um sistema de arquivos raiz com o algoritmo usado por padrão em cada caso específico. Como um usuário comum, não entendo as nuances dos padrões de criptografia (por exemplo, como o hash RIPEMD-160 difere do Whirpool, qual desses modos é mais rápido, qual contribui para maior segurança), então apenas confiamos no fato que os fabricantes de cada produto de software escolheu parâmetros padrão suficientemente resistentes à criptografia. Talvez isso não esteja totalmente correto, porque o desempenho de vários algoritmos de criptografia não é o mesmo. Se desejar, é claro, você pode alterar o tipo de criptografia, mas não tenho certeza de que em todos os produtos testados haja um conjunto absolutamente idêntico de algoritmos. Vamos testar:

3) eCryptfs é o sistema padrão oferecido aos usuários do Ubuntu para criptografar diretórios pessoais, razão pela qual está incluído neste teste. Funciona em cima de um sistema de arquivos existente. Criptografa cada arquivo separadamente, para que todos possam ver os direitos, as datas de modificação, o número de arquivos criptografados; por padrão, os nomes dos arquivos também são visíveis, embora haja uma opção para criptografá-los. A ferramenta menos funcional de sempre.

4) EncFS - um análogo aproximado do eCryptfs, mas usa FUSE.

Portanto, para os testes, uma máquina separada de idade bastante avançada foi alocada na seguinte configuração: CPU - Intel Celeron 2000Mhz, RAM - 512 Mb DDR PC2700, HD do sistema- WD Caviar SE 5400 RPM 80 Gb, HD de teste - WD Caviar SE 7200 RPM 80 Gb.
SO - Ubuntu 12.04 LTS, as versões de todos os softwares são relevantes para os repositórios deste SO no momento da redação deste artigo (Truecrypt 7.1a-linux-x86 não é dos repositórios).

Testaremos o sistema de arquivos ext4 padrão para a maioria das distribuições. Para testes de desempenho, usaremos o utilitário iozone3 e um script de shell escrito “no joelho” para medir a diferença percentual nos testes.

Script de contagem. Nenhuma atenção especial foi dada à limpeza do código, o único critério para escrita era a presença do resultado correto.

#!/bin/sh gendifffile () ( #o procedimento gera um arquivo que é conveniente para análise. Primeiro, as linhas que não podem ser analisadas são truncadas; em segundo lugar, os dois primeiros números de cada linha são truncados, indicando # tamanho e registro do arquivo size, respectivamente ; em terceiro lugar, o arquivo inteiro é gerado linha por linha - #um resultado de teste por linha cat $1 | while read LINE ; do echo $LINE| grep "^[[:space:]]*[[:digit:] ]" | awk "(for (i=3;i<=NF;i++) {print $i}}" done > > $2 ) getline () ( #procedure gera o número da linha $2 do arquivo $1 head -n $2 "$1" | tail -n 1 ) compare () ( #procedure compara o arquivo $ 1 e $ 2 linha por linha, calculando a diferença percentual de cada par de testes #depois calcula a média aritmética, por qual porcentagem é mais rápida ou mais lenta #arquivo contendo o primeiro grupo de testes, o arquivo contendo o segundo grupo P=0 MAX=0 L1=`cat "$1" | wc -l` # número de testes no arquivo L2=`cat "$2" | wc -l` if [ $L1 -ne $L2 ]; então #se os arquivos contiverem um número diferente de testes, então não vamos compará-los echo error return fi STEP=$(($L1*5/100)) J=0 para I em `seq 1 $L1`; faça J=$(($J+1)) se [ $J -eq $STEP ]; então J =0 echo "$((100*$I/$ L1))% concluído ($I de $L1)" fi A=`getline "$1" $I` B=`getline "$2" $I` if [ ` echo $A \> $B|bc -l` - eq 1 ]; então D=`echo "100-($B*100/$A)"|bc -l` if [ `echo $D \> $MAX | bc -l` -eq "1" ]; então MAX=$D sleep 5 fi else D=`echo "100-($A*100/$B)"|bc -l` if [ `echo $D \ > $MAX| bc -l` -eq "1" ]; o n MAX=$D sleep 5 fi D="-$D" #se o valor tiver o sinal "-", este teste foi mais rápido #no segundo arquivo do que no primeiro fi P=`echo "$P+$D "| bc -l`done P=`eco $P/$L1| bc -l` #calcula a média aritmética echo PERCENT=$P MAX_PERCENT=$MAX ) genaverage() ( #procedimento para gerar um arquivo preparado para análise, sendo cada linha a #média aritmética das linhas correspondentes de todo relatório arquivos localizados no diretório analisado AVG=` mktemp` F=`ls "$1"|wc -l` #número de arquivos com relatórios no diretório especificado #desde que apenas esses arquivos sejam armazenados lá e nada mais #não verificaremos a correção dessa suposição if [ ! -d " $1" -o $F -lt 2 ]; então echo error >/dev/stderr #neste procedimento, enviaremos todas as mensagens para stderr, já que #stdout é substituído por outro procedure rm -f $AVG exit fi TMP=` mktemp` find "$1" -type f| while read FILE; faça #para cada arquivo de relatório iozone no diretório dado I=`mktemp` #gendifffile "$FILE" "$I " #names grava todos esses arquivos em "TMP" linha por linha echo "$I">>$TMP done L=`cat \`getline "$TMP" 1\`|w c -l` cat "$TMP"| enquanto lê LINHA; fazer #uma pequena verificação é bom L1=`cat "$LINE"| wc -l` #todos os arquivos contêm o mesmo número de testes if [ $L -ne $L1 ]; então echo error >/dev/stderr exit fi done STEP=$(($L*5/100)) J=0 for I in `seq 1 $L`; faça J=$(($J+1)) se [ $J -eq $STEP]; then J=0 echo "$((100*$I/$L))% done ($I of $L)" >/dev/stderr fi SUMFILE=`mktemp` #desta forma obtenho o valor da variável SUM do loop aninhado SUM=0 cat "$TMP"| enquanto lê LINHA; do SUM=$((`getline "$LINE" $I`+$SUM)) echo $SUM > "$SUMFILE" done echo `tail -n 1 "$SUMFILE"`/$F|bc -l >> $ AVG #pega a média aritmética #e escreve-a no local apropriado #do arquivo AVG rm -f "$SUMFILE" done cat "$TMP"| enquanto lê LINHA; do #delete os arquivos temporários rm -f "$LINE" done rm -f "$TMP" echo $AVG ) printf %b "\\033)