Um belo dia aquele HD que continha seus dados deu “piripac” e você lembrou que não tinha cópia dos dados… e agora, quem poderá me defender?

“Palma, palma, não priemos cânico…”, diria o Chapolim Colorado.

Antes de chorar, faça alguns testes para saber se o mesmo tem recuperação. Existem alguns testes básicos que você mesmo pode fazer e assim ter informações suficientes para a tomada de decisão.

Antes, porém, uma dica universal: NÃO FORMATE!

E outra: Nunca, jamais, sob hipótese alguma desmonte o disco, pois ele é fechado hermeticamente para evitar danos nos discos (que são magnéticos e atraem tudo quanto é tipo de sujeira).

Todo HD, para ser reconhecido pela BIOS, deve:

a) ser alimentado (energia elétrica);

b) estar jumpeado ou pelo menos ser reconhecido automaticamente em nível de conexão (primário, secundário, sata, ide, sas (novo scsi), etc);

Se ele não aparecer na tela inicial da BIOS existem boas chances de a placa eletrônica (alguns chamam de placa lógica) – (externa – de circuitos eletrônicos, geralmente da cor verde) estar danificada ou a CMOS não conseguiu identificá-lo adequadamente (HD Sata são automaticamente reconhecidos).

Vamos aos testes.

Primeira Fase de teste

1º teste

Entre na BIOS e verifique se ele está sendo detectado (o local depende muito do fabricante da BIOS), mas geralmente no primeiro item da tela da BIOS ou em STANDARD CMOS FEATURES (PHOENIX – AWARD BIOS) ou MAIN (American Megatrends Inc.)

Verifique:

1º Teste

Ele aparece na BIOS?
Sim: O problema não está na placa lógica/eletrônica externa.

2° Teste: Ligue o cabo de energia nele e observe:

- Não vibra (como se os discos estivessem rodando)?

Então o problema pode ser apenas na placa  lógica/eletrônica externa.

- Vibra, mas não faz barulho: Coloque-o no ouvido (ou use um estetoscópio) e verifique se está fazendo algum ruído.

Se o houver ruídos do tipo estalos, provavelmente a cabeça de leitura está se movendo e causando estragos.

Em alguns casos uma leve pancada pode fazer a cabeça se afastar do disco. Geralmente este tipo de problema não tem solução, mas vale a pena fazer um orçamento numa empresa especializada na área de recuperação de dados.

Não é detectado na BIOS…

Ótimo, talvez o problema pode ser solucionado na troca da placa lógica externa.

A placa pode ser trocada como em todo equipamento eletrônico, porém, deve-se levar em conta:

Alguns componentes da placa também podem ser trocados, basta que exista um técnico em eletrônica disposto à fazer isto.

Alguns casos de barulho na cabeça de leitura podem ser solucionados congelando o HD.

Se o HD tiver cabeças de leitura arranhando as trilhas, impossibilitando o acesso a seus dados, deixá-lo no freezer fará com que os cilindros se contraiam e assim as cabeças desencostem das trilhas. Por um intervalo curto de tempo (enquanto houver contração nos metais), o HD poderá voltar a girar, até que o HD aqueça. O tempo é suficiente para a gravação dos dados em outra mídia. Recomenda-se, por razões óbvias, embalar o HD de forma hermética antes de inseri-lo no freezer. [Fonte: http://www.tecmundo.com.br/tira-duvidas/58891]

Obs: Já obtive sucesso com essa técnica.

A segunda fase de testes é via sistema

Coloque o HD com problema como secundário num outro computador e verifique se o sistema o reconhece.

O Windows reconhece o disco?

Se o Windows reconhecer, quando você clicar na letra de unidade dele (EX: E:) aparecerá uma mensagem pedindo pra formatá-lo, clique em NÃO e tente o comando CHKDSK /R UNIDADE: (EX: CHKDSK /R E:) no modo comando – (Clique em INICIAR/EXECUTAR (1-2), digite CMD (3), clique em OK (4) e na tela de comando (5) digite: CHKDSK /R UNIDADE: e dê enter). Aguarde até que o processo esteja concluído. Se tudo der certo você pode acessar os dados.

Se o Windows não reconhece o HD, tente verificar se ele aparece como uma partição oculta.

Acesse o Painel de Controle (1), clique em Ferramentas Administrativas (2), escolha a opção Gerenciamento do Computador (3) e verifique Gerenciamento de Discos (4 e 5).

Se ele aparecer lá, verifique a letra de unidade definida para ele e tente usar o comando CHKDSK /R UNIDADE: (EX: CHKDSK /R E:);

Se nesta fase nenhuma das alternativas acima funcionarem ou não se enquadrarem no seu caso…

Inicie o computador com um CD/DVD do Ubuntu, escolha a opção EXPERIMENTAR LINUX UBUNTU e quando ele carregar a área de trabalho, clique em LOCAIS/COMPUTADOR

Se não aparecer é provável que a partição esteja oculta.

Verifique isto em SISTEMA/ADMINISTRAÇÃO/EDITOR DE PARTIÇÕES GPARTED

Se aparecer como uma partição oculta, clique nela com o botão direito e escolha a opção MONTAR.

Se não aparecer como oculta e nem visível, é bem provável que a placa do HD esteja avariada.

Lembra que eu disse no início para NÃO FORMATAR?

As chances de se recuperar dados após uma formatação diminuem consideravelmente…

Instalar o sistema operacional ou mesmo copiar arquivos para o HD após formatado diminuem ainda mais.

Os testes acima são casos experimentais, que durante meus anos de experiência eu coloquei em prática e – acreditem – na maioria das vezes eu consegui recuperar dados.

Se você enviar o disco para uma empresa especializada provavelmente eles farão os mesmos testes, e só então depois eles desmontarão os discos.

Antes de enviar para uma empresa certifique-se que eles tenham um laboratório, pois os discos só podem ser abertos num ambiente sem umidade, poeira, magnetismo, etc.

Na maioria das vezes o primeiro teste que eu faço é o da energia, depois uso um Live CD/DVD do Linux para acessar a partição.

Só depois desses testes, se nenhum der certo…

Se o sistema solicitar que o mesmo deve ser formatado, verifique:

Pronto, agora você pode formatar o disco e tentar recuperar os dados via software.

Existem bons softwares que recuperam dados, como o Recuva, que recupera dados na camada mais alta ou numa pesquisa mais profunda – recomendado para recuperação de fotos e documentos de discos removíveis.

Para recuperação de dados em partições perdidas (ocultas ou ilegíveis) recomendo o Active File Recovery, que é pago, mas é excelente e já consegui recuperar muitos dados com ele.

Mas se o HD não é reconhecido pela BIOS ou continua fazendo barulho, mesmo após a troca da placa eletrônica então é porque o erro pode ser na outra placa que controla a cabeça de leitura, nesse caso só abrindo o HD mesmo (que deve ser feito por empresas que têm laboratório para isto).

Deixe seu comentário, caso de sucesso, conte sua história ou deixe sua pergunta que a gente responde.

Já visitou meu blog? Curtiu minha página? Me adicionou no Twitter?

Veja perfil e 15 post(s)

A etapa de testes no processo de desenvolvimento de software ainda é vista com olhos ruins por muita gente. Na verdade, isso existe pelo conflito de interesses: os desenvolvedores de um lado, querendo mostrar que o seu programa é isento de falhas, e a equipe de QA do outro, buscando a qualquer custo encontrar falhas no sistema.

Mesmo que de certa forma tenhamos que trabalhar esses conflitos, é importante ter outra equipe que teste o que foi desenvolvido. Como já disseram por aí, “não existe filho feio para a mãe”, e o programador tem um tendência natural a achar que tudo que desenvolveu está perfeito.

Contudo trabalhar com somente com uma equipe pode não resolver todos os problemas. Ainda que essa seja boa o suficiente para cumprir o seu papel, o usuário é o verdadeiro tester, já que é quem usará o programa no dia-a-dia. Com a ideia do usuário como tester surgem dois conceitos, chamados de Teste Alfa e Teste Beta.

O Teste Alfa  é aquele realizado no ambiente do desenvolvedor, mas pelo usuário final do programa. Já o Teste Beta é realizado no ambiente do cliente, sem a presença do desenvolvedor, aonde o próprio cliente relata quais são erros observados que serão posteriormente corrigidos.

Os testes de software podem ainda ser classificados quanto a  técnica utilizada. Dentre eles os principais são:

Existe ainda a Técnica Baseada em Erros, que se baseiam na inclusão de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais).

Por fim, lembre-se: bons testes de software são aqueles que apresentam maior probabilidade de revelar erros ainda não descobertos!

Veja perfil e 26 post(s)

Dando continuidade à série de posts sobre Django, vou indicar algumas ferramentas de testes para que você também possa deixar com que os testes guiem o desenvolvimento de suas aplicações.

Afinal, testar é preciso

Sem dúvida nenhuma! Mas não espere que o framework adeque-se a você, você precisa ter a iniciativa de tentar compreender as melhores maneiras para escrever testes em Django.

Por exemplo, se você tem por hábito isolar os modelos para testá-los de forma unitária, pode passar por certa dor de cabeça com o Python/Django. Não que seja impossível, mas o comportamento default do framework é criar uma base de dados “fake” para você não precisar ter este trabalho.

Enfim, talvez a forma de utilizar estas ferramentas caiba em um outro post, o objetivo deste é apenas apresentá-las.

A unittest é uma biblioteca padrão do Python que ajuda (e muito) a escrever testes automatizados com a linguagem.

Os testes são escritos através de classes, onde utilizamos os esquemas de assertions para garantir o comportamento do código testado (nenhuma novidade até aqui). Para quem utiliza testes unitários no Java não vai sentir grandes mudanças na abordagem, já que a unittest é inspirada na JUnit (sendo muitas vezes até chamada de PyUnit):

O test runner padrão do Django irá procurar por subclasses de unittest.TestCase nos arquivos models.py e tests.py. A suíte de testes tenta facilitar ao máximo a sua vida… execute a seguinte instrução e confira se a sua aplicação está ok ou não:

Peraí que não acabou! Apresentando a TestCase

Testar aplicações Web com a unittest pode ser dureza. Pensando nisso o Django disponibiliza a TestCase, que estende a unittest adicionando funcionalidades como carregamento de fixtures, roteamento de urls e um client para fazer requisições Web e testar as suas views (o TestClient, detalhado mais abaixo).

Admito que escrever documentação de software não é o meu forte… mas com doctests pode-se documentar métodos ao mesmo tempo em que escreve-se testes!

A doctest é uma biblioteca padrão do Python que procura e interpreta docstrings na aplicação. A sintaxe nesses trechos de docstrings é diferenciada, simulando um interpretador interativo do Python:

Assim como com a unittest, o test runner padrão do Django procurará por ocorrências de docstests em models.py e tests.py.

E como fazer para testar requisições Web? Por exemplo, você não quer testar a sua view de forma isolada, quer testar desde a parte de roteamento ao comportamento com o banco de dados, como se você se estivesse realmente visitando a página. Neste caso entra a test client.

Toda a classe TestCase possui uma instância da Django Test Client. Então escrever testes com requisições à sua aplicação fica muito simples utilizando classes:

É perfeitamente possível utilizar a test client em doctests também:

Particularmente, tive a oportunidade de implementar testes unitários já no início do meu aprendizado em Django. Deixar os testes te guiarem é uma prática excelente!

Tudo parte do bom senso, óbvio. Nenhum processo ou ferramenta deveria substituir o “feeling” do profissional… também não é muito sadio ser extremamente “by the book“. Mas se puder utilizar testes para guiar o seu desenvolvimento, use-os!

Na segunda parte deste post pretendo apresentar algumas ferramentas que irão turbinar ainda mais o seu desenvolvimento orientado a testes.

Até lá!

Fonte: Klaus Laube

No post anterior, conhecemos as ferramentas default para construção de testes automatizados em Django. Acontece que você pode “sair um pouco da caixa” e usufruir de ferramentas “third-party“, que enriquecerão o seu ambiente de desenvolvimento e lhe trarão maior segurança em seus testes de software.

É perfeitamente possível criar testes de aceitação em Django com a TestClient e lxml. Mas vamos ser sinceros, é deveras trabalhoso “parsear” os resultados das suas views.

Com a Splinter, uma ferramenta para testes de aplicações web, você pode automatizar ações executadas por navegadores, como visitar uma página, preencher um formulário ou clicar em um link; tudo isso sem preocupar-se com parsing, nós, DOM, nem nada do tipo:

O que eu acho mais bacana nesta ferramenta são os seletores, facilitam muito na hora de checar resultados e comportamentos.

A comunidade em volta desta ferramenta está em constante crescimento e atividade. Portanto, caso você queira contribuir com o projeto, vá agora mesmo para o repositório no GitHub e colabore.

E quando queremos fugir da regra? Aposto que chegará um momento em que a estrutura de diretórios padrão, necessária para a execução dos seus testes em Django, não te satisfará mais. O que fazer neste caso? Simples, recorra ao Nose!

O Nose estende os recursos da unittest e facilita a escrita e carregamento dos testes em projetos Python. De uma forma mais detalhada, ele percorre o seu projeto (ou uma determinada região de seu escolha) executando subclasses da unittest.TestCase ou funções que contenham “test”. Por exemplo:

Ao executar o comando nosetests o nose se encarregará de procurar e carregar os testes:

É claro que existe uma “mágica” aí. Na verdade o nose pesquisará por arquivos Python com “test” em seu nome, por funções com “test” em seu enunciado, e por classes com métodos “test” em sua declaração. Ele age mesmo como um “runner“, tendo a capacidade de lidar com testes escritos com unittest ou não.

Essa é só a ponta do iceberg. É possível construir plugins para o nose, permitindo melhorar ainda mais o seu ambiente de testes (como por exemplo, permitir que o nose funcione em subprocess separados).

Caçando testes em seu projeto (Django)

Para facilitar ainda mais a escrita de testes em Django existem plugins como o django-nose, que permite que você substitua o Test Runner padrão da framework por um específico que utiliza o nose, unindo assim a facilidade e “add-ons” do nose com o ambiente de testes do Django.

E se você estava se perguntando sobre BDD em Django, eu apresento a Lettuce!

Esta ferramenta, baseada na Cucumber, permite com que você escreva estórias utilizando linguagem ubíqua, mais próxima da área de negócios do que da área técnica, e automatize a validação delas.

O mais bacana é que ela já vem preparada para o Django, permitindo que a gente execute os testes de comportamento de forma fácil e rápida:

Basta executá-lo da seguinte maneira:

Confira mais informações sobre como utilizar o lettuce com Django.

O Fudge é um módulo Python que auxilia na construção de objetos “dublês” (mocks e stubs), que permitem escrever testes sem necessariamente possuir um serviço ativo ou um objeto construído.

Um caso comum: Você está construindo uma API que autentica via OAuth ao Twitter e está utilizando testes para guiar o seu desenvolvimento. Não é interessante que nossos testes sejam dependentes da disponibilidade do serviço do Twitter, portanto, escrevemos um “objeto mentiroso”, que simulará este serviço, aceitando uma entrada e gerando um saída:

Pronto! Sabendo que valores serão passados, e quais os resultados, podemos simular o comportamento daquele serviço. Prático, não?

Estas são as ferramentas que eu costumo utilizar em meus projetos Python/Django. É claro que existem outras, na verdade existem várias. Tenha em mente que a ferramenta é apenas um meio de garantir, através de testes, que você está guiando a sua aplicação para o lugar certo. Os testes automatizados no final servem para garantir que ela ainda segue este caminho, que contribuições realizadas tardiamente não “quebraram” o comportamento que você escreveu no início do desenvolvimento.

Tenho a intenção de escrever um post mais prático sobre testes e Django. Fiquem no aguardo

E você? Tem alguma ferramenta para recomendar? Utilize os comentários abaixo para compartilhá-la.

Até a próxima…

Fonte: Klaus Laube

Dando continuidade à série de posts sobre Django, vou indicar algumas ferramentas de testes para que você também possa deixar com que os testes guiem o desenvolvimento de suas aplicações.

Afinal, testar é preciso

Sem dúvida nenhuma! Mas não espere que o framework adeque-se a você, você precisa ter a iniciativa de tentar compreender as melhores maneiras para escrever testes em Django.

Por exemplo, se você tem por hábito isolar os modelos para testá-los de forma unitária, pode passar por certa dor de cabeça com o Python/Django. Não que seja impossível, mas o comportamento default do framework é criar uma base de dados “fake” para você não precisar ter este trabalho.

Enfim, talvez a forma de utilizar estas ferramentas caiba em um outro post, o objetivo deste é apenas apresentá-las.

A unittest é uma biblioteca padrão do Python que ajuda (e muito) a escrever testes automatizados com a linguagem.

Os testes são escritos através de classes, onde utilizamos os esquemas de assertions para garantir o comportamento do código testado (nenhuma novidade até aqui). Para quem utiliza testes unitários no Java não vai sentir grandes mudanças na abordagem, já que a unittest é inspirada na JUnit (sendo muitas vezes até chamada de PyUnit):

O test runner padrão do Django irá procurar por subclasses de unittest.TestCase nos arquivos models.py e tests.py. A suíte de testes tenta facilitar ao máximo a sua vida… execute a seguinte instrução e confira se a sua aplicação está ok ou não:

Peraí que não acabou! Apresentando a TestCase

Testar aplicações Web com a unittest pode ser dureza. Pensando nisso o Django disponibiliza a TestCase, que estende a unittest adicionando funcionalidades como carregamento de fixtures, roteamento de urls e um client para fazer requisições Web e testar as suas views (o TestClient, detalhado mais abaixo).

Admito que escrever documentação de software não é o meu forte… mas com doctests pode-se documentar métodos ao mesmo tempo em que escreve-se testes!

A doctest é uma biblioteca padrão do Python que procura e interpreta docstrings na aplicação. A sintaxe nesses trechos de docstrings é diferenciada, simulando um interpretador interativo do Python:

Assim como com a unittest, o test runner padrão do Django procurará por ocorrências de docstests em models.py e tests.py.

E como fazer para testar requisições Web? Por exemplo, você não quer testar a sua view de forma isolada, quer testar desde a parte de roteamento ao comportamento com o banco de dados, como se você se estivesse realmente visitando a página. Neste caso entra a test client.

Toda a classe TestCase possui uma instância da Django Test Client. Então escrever testes com requisições à sua aplicação fica muito simples utilizando classes:

É perfeitamente possível utilizar a test client em doctests também:

Particularmente, tive a oportunidade de implementar testes unitários já no início do meu aprendizado em Django. Deixar os testes te guiarem é uma prática excelente!

Tudo parte do bom senso, óbvio. Nenhum processo ou ferramenta deveria substituir o “feeling” do profissional… também não é muito sadio ser extremamente “by the book“. Mas se puder utilizar testes para guiar o seu desenvolvimento, use-os!

Na segunda parte deste post pretendo apresentar algumas ferramentas que irão turbinar ainda mais o seu desenvolvimento orientado a testes.

Até lá!

Fonte: Klaus Laube

“Selenium IDE é um ambiente integrado de desenvolvimento para scripts de testes automatizados. Ele é implementado como uma extensão do Firefox e permite gravar, editar e depurar os testes.O  Selenium IDE inclui o Selenium Core , permitindo que você facilmente e rapidamente possa gravar e reproduzir os testes no ambiente real que será executado.”

É muito simples criar seus scripts de testes utilizando o Selenium IDE por ser uma ferramenta gráfica integrada com o Firefox. Além de automatizar os testes de sistema a ferramenta também simplifica  os testes de regressão, já que a qualquer momento pode-se realizar um mesmo teste nas novas versões do sistema.

A escrita dos scripts de maneira gráfica é simples, com o Selenium IDE aberto basta clicar com o botão direito em cima do elemento e adicionar o evento, originalmente o script é gerado em HTML mas pode ser exportado para C#, PHP, Java e outras linguagens.

Existe a versão do Selenium WebDrive em que se pode escrever os scripts na linguagem suportada. Esta versão é indicada para testes mais elaborados e por usuários familiarizados com a ferramenta. Geralmete usa-se o Selenium IDE para testes básicos, exporta-se o script e depois edita-se o script para realizar testes mais elaborados.

O download da ferramenta pode ser feito em http://seleniumhq.org/download/

Conhece outra ferramenta bacana para testes automatizados? Deixe seu comentário!

Fonte: Blog Rômulo Campos

* Eduardo Neves

Conhecidas no mercado como web security scanners, as ferramentas utilizadas para a execução de testes de segurança automatizados são comercializadas por diversos fabricantes. Com características e tecnologias proprietárias as diferenciando, mas em comum, todas funcionam vasculhando o conteúdo e estrutura do website e comparando os resultados obtidos com suas bases de dados. Essas ferramentas trazem comportamentos que indicam vulnerabilidades potenciais e apresentam os resultados em um relatório configurado para estabelecer níveis de criticidade, auxiliando os responsáveis na tomada de decisão de onde corrigir primeiro.

Com isso, um web security scanner identifica com velocidade muitas vezes superior a uma análise manual, as falhas no desenvolvimento da aplicação web (ex.: SQL Injection ou falha de autenticação) e vulnerabilidades que estejam presentes em bases de dados (ex.: abertura para execução de exploits).

Apesar de serem excelentes ferramentas para serem incluídas no processo de testes e obrigatoriamente ser parte da caixa de ferramentas de um analista de segurança, algumas observações devem ser consideradas no uso deste tipo de produto:

Em processos onde é necessário realizar um teste somente por questões de compliance com um padrão e existe uma forte limitação de orçamento para a empresa ir além dos testes automatizados, a melhor escolha acaba sendo optar por um teste automatizado, uma vez que um teste manual realizado por um profissional sem experiência nunca vai alcançar o mesmo nível de eficiência entregue por uma boa ferramenta automatizada.

Porém, é fundamental entender que o papel fundamental de um web security scanner é fornecer ao analista de segurança resultados que serão posteriormente analisados para adequar a qualidade das vulnerabilidades identificadas – o que supera a simples remoção de falsos positivos e entra na investigação de causa das mesmas – e ainda fornecer subsídios para testes manuais complementares.

Os Testes Manuais de Segurança

Os testes manuais de segurança são muitas vezes ignorados pelos responsáveis na segurança de uma aplicação web, pois parecem apresentar resultados factíveis somente quando o técnico que realiza as análises tem um conhecimento que agrega competências em diversas práticas que vão de protocolo HTTP até programação na linguagem utilizada para o desenvolvimento da aplicação web em questão.

O motivo deste equívoco é colocar todos os testes manuais em um mesmo cenário, uma vez que existem abordagens complementares que são diferentes e devem ser adotadas de acordo com o tipo de resultado que se quer, cuja alocação de esforço pode ser dimensionada de forma pontual com resultados vantajosos. Existem dois tipos de testes que podem ser aprofundados ou enriquecidos com novos componentes, de acordo com o objeto de análise:

Conclusão

Utilizar uma abordagem com as vantagens geradas pela amplitude de um web security scanner com a profundidade possibilitada pelos testes manuais é a melhor opção em qualquer cenário onde o objetivo seja identificar falhas de segurança em uma aplicação web, e não somente realizar um processo que seja considerado para um evento de compliance com padrões de mercado. Em resumo, a abordagem ideal deve sempre considerar três etapas mínimas:

1. Avaliação do nível de segurança por meio do uso de um web security scanner adequadamente configurado para o ambiente informatizado em questão.

2. Considerar os resultados desta avaliação como base para testes manuais, que devem não só fazer uma revisão de qualidade das vulnerabilidades identificadas, como ainda explorar falhas potenciais nos elementos de suporte envolvidos, tais como Servidores Web e Bancos de Dados.

3. Produzir relatórios de resultados que permitam ao leitor ir além das vulnerabilidades técnicas – relacionando quais são as conseqüências das mesmas para o negócio que é suportado pela aplicação web – e que contenham ações que resolvam efetivamente o problema, eliminando a vulnerabilidade e se possível, apontando a causa que deve ser posteriormente corrigida.

Estabelecer o nível de segurança de uma aplicação web somente com os resultados dos testes realizados por este tipo de ferramenta é um convite para estabelecer uma falsa sensação de segurança e deixar vulnerabilidades críticas abertas e disponíveis para serem exploradas em um ataque. Criar e manter um nível de proteção adequado em uma aplicação web é um processo, onde é necessário ir além do óbvio e conhecer não só os componentes das camadas de arquitetura, redes de dados e aplicações envolvidas. É fundamental entender como a aplicação funciona, qual é o nível de interação com os seus usuários e como falhas potenciais podem ser exploradas por pessoas que realmente queiram alocar esforços para cometer uma fraude contra o produto.

*Eduardo Neves é conselheiro de segurança do Site Blindado S/A, empresa que realiza blindagem em sites e disponibiliza o selo Site Blindado (www.siteblindado.com.br)