Roubo de dados empresariais

Neste artigo vou abordar um tema que já me passou pelas mãos várias vezes, e que há bastante tempo tinha ideia de falar sobre ele, mas não se tinha proporcionado.  Desta feita, dado que fiz uma apresentação sobre o tema na última edição da Confraria de Segurança de Informação, aproveito a embalagem e passo para o “papel” os esboços mentais.

Dentro daquilo que pode ser considerado roubo de dados, vou abordar a vertente “Insider Threat”, ou seja, as ameaças provenientes do interior da organização, que podem facilmente conduzir a uma situação de roubo de dados.  Este tipo de situação não é noticia tão frequentemente como um ataque externo que expõe informação interna da empresa, que gera muito mais “burburinho”, mas no meu ponto de vista pode ter tanto ou até mais impacto para a organização do que um ataque externo.  Uma diferença fundamental é que num ataque externo que se torne público, existe uma perda de imagem corporativa, que pode levar a perdas de clientes ou financeiras. Numa ameaça interna, apesar de usualmente não vir a público, os dados roubados podem ser usados para extorsão, venda, ou como acontece mais frequentemente (pelo menos em Portugal), são usados no próximo emprego ou para abrir um negócio concorrente e evitar começar do zero.

Este tipo de ameaças internas pode ter duas fontes de motivação diferentes, pode ocorrer por simples erro humano ou acaso, ou pode ser premeditada, sendo que também pode conduzir a dois desfechos diferentes, onde no primeiro tipo de motivação pode levar a que se abra um incidente interno, se a motivação do envolvido for a melhor, ou pode resultar em roubo de dados, quer porque alguém se aproveitou de uma circunstância, quer porque tinha esse objetivo de inicio.

Seja qual a circunstância, é importante ter em mente que isto é um problema real, e que acontece com muita frequência nas empresas nacionais, ou melhor, até mais aqui do que em outros países europeus, quer pela maturidade (ou falta dela) existente especialmente ao nível das PME’s, onde não existem sequer politicas de segurança definidas que ajudem quer empregadores quer empregados a entender quais são os seus direitos e deveres, quer também pela cultura em que estamos inseridos, a cultura latina, que tem imensas coisas positivas (e da qual gosto), mas no que toca a esta temática, é um tanto “deixa andar”, e enquanto não há problemas sérios, ninguém leva muito a sério o tema da segurança.

Mas não sejamos egoístas, porque isto não acontece apenas em Portugal, e lá fora até se fazem estudos sobre o tema, e um deles tem alguns resultados que merecem ser destacados. Um estudo mostra alguns números interessantes:

66% levaram ou levariam informação que eles próprios estiveram envolvidos na sua criação
72% rouba informação que pensa que lhe pode ser útil num emprego futuro
21% leva consigo as propostas da empresa
18% leva consigo os planos estratégicos da empresa

Outro aspeto interessante deste estudo é que indica que 66% das fugas de dados estão relacionadas com erros dos empregados ou dos sistemas, ou seja, o fator mais comum que dá inicio ao problema são erros, quer humanos, quer não. Os problemas relacionados são muitos, tanto que os custos legais médios para resolver este tipo de problema tem o valor de cerca de 30.000€, nem contanto com o valor dos dados roubados ou perdidos, que em alguns casos é muito dificil de quantificar.

A preocupação dos departamentos de IT com esta temática tem vindo a crescer, tanto que o mesmo estudo indica que 39% dos profissionais de IT estão mais preocupados com as ameaças internas do que externas, e que dentro das ameaças internas, 20% disse que a maior preocupação deles eram os empregados descontentes. Toda esta preocupação faz sentido, porque internamente o acesso já existe e na maioria a informação privilegiada, seja porque os colaboradores necessitam da informação para o trabalho do dia a dia, seja por não existirem ou estarem mal desenhadas as politicas de acesso à informação, como por exemplo, a implementação da politica de “least priviledge”.

Outro estudo interessante sobre este tema foi feito pelo CERT CMU (http://www.cert.org/), em que numa análise de 101 casos de roubo de PI (propriedade intelectual), cerca de 35% dos casos ocorreu na área de tecnologias de informação, o que também me parece natural, pois é onde o conhecimento de IT é maior, e pode levar mais facilmente a este tipo de situações. Logicamente também o estudo mostra que em cerca de 70% dos casos, o roubo ocorre Onsite, a partir do interior da organização.

Um dado muito curioso e ao mesmo conclusivo neste estudo foi que mais de 30% das ocorrências foram detetadas por meios não técnicos, enquanto apenas em 6% dos casos foram utilizadas soluções de software para a deteção. Pelo que me parece, a conclusão mais lógica é que a maior das organizações onde isto ocorre ainda não tem qualquer solução tecnológica para endereçar este tipo de problemática, ou então, se a tem, provavelmente não está adequada às reais necessidades da organização ou até poderá estar mal configurada, o que não seria de espantar também.  Por outro lado, é bom ver que o lado humano continua a funcionar, e que quando motivadas e formadas, as pessoas são sempre a melhor barreira de defesa da organização.

Em boa parte, porque é que o roubo de dados é uma realidade?  Penso que a primeira razão é porque é fácil, ou seja, com acesso à infra estrutura e muitas vezes com privilégios e acesso em demasia, é muito fácil ter acesso à informação.  Além disso, cada vez existe uma percepção maior, e com toda a lógica, que a informação é um ativo muito valioso, portanto, todos sabem que a informação a que têm acesso pode ser muito útil, especialmente se eventualmente mudarem de entidade empregadora no futuro.  Além disso, pelo menos por cá, ainda existem muitas lacunas ao nível do sistema juridico, quer em termos das disposições da legislação, mas especialmente na percepção que existe em relação aos tempo que demora um processo a decorrer, que faz com que por um lado, os “atacantes” pensem que provavelmente nunca serão acusados, ou mesmo que o sejam, que nunca vão sofrer consequências disso e da parte dos “defensores”, que nem vale a pena enveredar pela via juridica, pois é uma perda de tempo e dinheiro, pois no final das contas, a organização dificilmente é compensada pelas perdas.

Outro dos problemas que se coloca às organizações no que toca a este tema é que a maioria não tem uma politica bem definida de classificação de informação, e de acessos segregados com base nessa classificação de informação, o que leva a que ocorram muitas situações em que nem o empregado nem o empregador sabem ao certo o que podem fazer com determinado tipo de informação.  Claro está que do lado do empregado é uma situação algumas vezes dificil de gerir, pois não tem noção daquilo que pode fazer com a informação, se pode visualizar, alterar, copiar, enviar por email para fora da organização, etc.  Isto é um problema prático, porque até em tribunal, em algumas ocasiões, já ouvi a seguinte pergunta (ou semelhante): “A empresa tinha regras que indicavam que o colaborador não podia fazer determinada ação?”

Por último, a potenciar este tipo de situações existe uma problemática que se acentua nos últimos tempos, em que cada vez mais existe uma mistura grande entre o que é profissional e o que é pessoal. Provavelmente consultamos informação pessoal no nosso local de trabalho e também consultamos email profissional quando estamos em casa. Isto é mais complicado de gerir quando se produz PI (Propriedade intelectual), em que um colaborador usa quer recursos pessoais, quer profissionais para isso. Na área de segurança de informação isso é ainda mais comum. Por exemplo, é fácil encontrar um profissional que faz “research” sobre um tema, descobre uma vulnerabilidade, isto ao serviço da empresa, e depois publica isso num blog seu. Aqui coloca-se a questão entre o que é pessoal e o que é da empresa, e quem tem direitos sobre aquela informação ou conhecimento. A falta de regras claras neste ponto faz com que facilmente cada uma das partes tenha a sua perspectiva pessoal sobre o assunto, contraditória claro J

E na prática, isto é crime? O que é que acontece nestas situações em termos legais? A área legal é apenas um interesse para mim, mas aqui dependo do feedback de quem entende do assunto, e quando estava a preparar a apresentação sobre o tema, um advogado enumerou uma série de disposições legais que podem ser aplicadas, consoante as circunstâncias especificas do caso. Uma primeira disposição legal clara sobre o tema é aquela que se encontra no Código do Trabalho, Artigo 128, alinea nº1, f, onde diz o seguinte: “Guardar lealdade ao empregador, nomeadamente não negociando por conta própria ou alheia em concorrência com ele, nem divulgando informações referentes à sua organização, métodos de produção ou negócios.” Facilmente se conclui que como primeira consequência, quem rouba dados, pode ser despedido com justa causa, e eventualmente ter que indeminizar a entidade vitima desse roubo.

No que toca à área penal, existe ainda a Lei do Cibercrime (Lei nº 109/2009), artigos 4º, 5º e 6º, que podem ser aplicáveis a uma circunstância de roubo de dados informáticos, pois mencionam algumas ações que são feitas sem autorização para isso. Neste caso, podem existir penas de prisão de 1 a 5 anos. Por último, existe no código penal os crimes contra a propriedade, e o artigo 203º sobre o furto, onde menciona: “Quem, com ilegítima intenção de apropriação para si ou para outra pessoa, subtrair coisa móvel alheia, é punido com pena de prisão até 3 anos ou com pena de multa.” Portanto, seja de uma forma ou de outra, é uma situação séria, que penso que quem o faz talvez nem tenha noção da gravidade do tema.

Uma das razões que tem causado este fenómeno do roubo de dados aumentar drasticamente ao longo dos últimos anos é a facilidade com que pode ser feito, por exemplo, com a proliferação e uso de dispositivos USB, pen drives e discos rígidos externos, tornou-se extremamente fácil copiar grandes quantidades de dados num curto espaço de tempo, e com uma taxa de deteção muito baixa. Outra das formas comuns de copiar dados para fora da organização é pela utilização do email. Já vi algumas coisas curiosas, como por exemplo alguém usar o email da própria organização para enviar dados para os seus emails pessoais ou até para emails da concorrência, o que além da ação de roubo de dados propriamente dita, não revela muita inteligência.

Portanto, os meios para o fazer estão facilitados, mas quando acontece, em termos de análise forense, o que é que é possível analisar ou investigar para chegar à conclusão do que ocorreu, e se realmente ocorreu?  Não existe nenhuma solução “click and go” para este tipo de situação, em que facilmente se chegue a uma conclusão.  Em termos de análise forense, o que existe é um conjunto de de evidências, que relacionadas umas com as outras podem levar-nos a desenhar uma linha do que provavelmente pode ter ocorrido. Neste sentido, quem faz a análise forense deve entender que o seu objetivo é analisar os fatos e reportar os mesmo duma forma que o departamento juridico possa então decidir se as provas são suficientes e necessárias para abrir um processo disciplinar ou qualquer outro. Algumas vezes vejo pessoas que trabalham na área a quererem indicar nos relatórios que alguém é culpado de alguma coisa e quase que o constituem arguido, o que na prática não me parece a melhor abordagem, porque deve estar bem separada a área técnica do que é a área juridica.

Algumas linhas de evidência que podem ser usadas na análise forense, são as seguintes, e que vamos detalhar abaixo (vou usar várias terminologias em inglês, dado que são mais fáceis de entender):

– Registo do Windows
– Recent Files
– Link Files
– Prefetch files
– Logs
– E-Mail
– Timeline
– Stochastic Forensics
– USB devices

Vou abordar de seguida alguma destas fontes de evidência a um nível alto, e numa próxima ocasião abordarei alguns destes pormenores a um nível mais baixo.

O registo do windows é uma base de dados hierárquica que guarda uma série de configurações e opções relacionadas com o sistema operativo e com as várias aplicações instaladas que podem fazer uso do registo do windows para guardar as suas configurações. O Kernel, drivers, serviços, interfaces e outras aplicações guardam informações no registo para guardar configurações e até para medir performance do sistema.

O registo tem aquilo que se chama “Root Keys”, que são as chaves primárias, associadas com diferentes áreas do sistema, que são as seguintes:

HKEY_LOCAL_MACHINE – guarda configurações relacionadas com a máquina local.
HKEY_CURRENT_USER – guarda configurações relacionadas com o utilizador que está “loggado” na máquina.
HKEY_CLASSES_ROOT – contém informação sobre configurações de aplicações, como associações de ficheiros e classes OLE, fazendo a ligação entre as aplicações que usam estes ficheiros e bibliotecas.
HKEY_USERS – contém sub-chaves relacionadas com a Root Key “HKEY_CURRENT_USER” para cada utilizador registado na máquina local.

O registo do windows está guardado num conjunto de ficheiros guardados no disco, que são os seguintes:

Caminho – %SystemRoot%\System32\Config\

  • Sam – HKEY_LOCAL_MACHINE\SAM
  • Security – HKEY_LOCAL_MACHINE\SECURITY
  • Software – HKEY_LOCAL_MACHINE\SOFTWARE
  • System – HKEY_LOCAL_MACHINE\SYSTEM

Caminho – %USERPROFILE%\

Ntuser.dat – HKEY_USERS\<User SID> (linked to by HKEY_CURRENT_USER)

Existem diversas ferramentas para conseguir analisar o registo do windows, quer online (com o Sistema operative em funcionamento), quer offline. A mais conhecida é a ferramenta do próprio Windows, o “Registry Editor” (regedit.exe).

Registry

Para fazer um “parse” offline aos ficheiros do registo já é uma necessário uma outra ferramenta, sendo que existem algumas open source e outras comerciais. Uma open source de fácil utilização, que tem interface gráfica e também CLI, é desenvolvida em perl, com o nome RegRipper, em que se carrega um dos ficheiros da registry e se extraem as chaves necessárias através de plugins especificos ou então se extrai o conteúdo todo para análise posterior.

Regripper

A extração ocorre para ficheiros de texto, que são fáceis de fazer parse direto ou enviar o conteúdo para uma qualquer outra ferramenta, nem que seja excel.

Entre vários detalhes que é possível extrair do registo, um dos interessantes para o tema em causa são os ficheiros recentes (recent files), que se encontrar no ficheiro “NTUSER.DAT”, referente ao utilizador em causa. Por aqui conseguimos extrair por exemplo quais os últimos ficheiros de diversas tipologias que foram abertos, como pdf, doc, xls, etc. Isto pode ser interessante para localizar informação a que o utilizador teve acesso, e por aí concluir logo se existiu acesso a informação que não era suposto. Uma outra vertente dos ficheiros recentes é que conseguimos extrair informação sobre a localização onde esse ficheiro estava quando foi aberto, ou seja, a letra de unidade e o caminho completo onde estava a informação. Isso é um pormenor que pode ser extremamente útil para correlacionar com dados extraídos dos dispositivos USB, porque é possível por exemplo concluir que esses ficheiros foram executados de uma unidade externa, e eventualmente por si só pode ser uma violação da politica interna.

Outra fonte de evidência que pode ser usada para correlacionar informação são os atalhos (link files), que contêm alguma informação útil como por exemplo, informação sobre eles próprios, informação sobre o ficheiro original do qual foi efetuado o link, consegue ligar-se a um utilizador especifico, contém informação sobre o nome do volume e o caminho e por último podem recuperar-se diversas instâncias destes ficheiros do espaço não alocado. Curiosamente em alguns casos de roubo de dados em que trabalhei, os utilizadores gostam de fazer as coisas bem feitas, ou seja, copiam os dados seja para que suporte for e depois testam sempre alguns ficheiros para confirmar que a “coisa” está bem feita, o que em alguns casos, cria link files, que podem ser usados para correlacionar com outras fontes de evidência.

Um das fontes de evidência mais interessantes ao analisar sistemas windows, não só nesta circunstância, mas em muitas outras, são os ficheiros “Prefetch”.  Sempre que iniciamos a nossa máquina e corremos aplicações, o sistema operativo analisa esses padrões, de forma a que com base na utilização que fazemos da máquina possa antecipar certas ações e ao carregar informação em RAM, acelere o funcionamento geral do sistema operativo. Apesar de ter sido criado com o objetivo de aumentar a performance, esta funcionalidade é muito útil, pois conseguimos saber o nome do executável, uma lista de DLL’s utilizados por esse executável, quantas vezes a aplicação correu e qual a última ocasião em a aplicação foi executada. Em alguns casos de roubo de dados é interessante ver que algumas ocasiões foram utilizadas aplicações especificas para facilitar isso, como o caso de aplicações de FTP ou outras semelhantes, daí que é uma outra fonte de evidência que vale a pena analisar e correlacionar com outras.

Em todos os casos de análise forense, os logs são aliados valiosos, quando existem logicamente. No caso de roubo de dados isso não é exceção, e os logs podem conter informação muito valiosa sobre o que ocorreu, especialmente ações de Logon/Logoff, Acesso a objetos (como ficheiros), gestão de contas e logs aplicacionais. No entanto, os logs têm uma problemática, que já encontrei em vários situações em que trabalhei, sendo que primeiro que tudo é necessário serem ativados, pois não o estão por defeito. Como sabemos, uma boa parte dos sistemas são instalados e configurados com todas as opções por defeito, e ninguém mais se preocupa em olhar para o sistema ou fazer “hardening”, desde que esteja tudo a funcionar bem e ninguém se queixe de problemas. Isto faz com que infelizmente quando é necessário aceder aos logs, os mesmos não existam, ou então em outras ocasiões, existem, mas não existe nenhuma politica de retenção e backup de logs. O que acontece é que os logs também têm um tamanho limitado predefinido e quando chega ao seu limite, começa a reescrever os dados mais antigos, possivelmente perdendo uma boa parte da informação que pode ser útil.

Não desesperam que ainda temos mais algumas fontes de evidência pela frente. A próxima delas é o email, e até neste campo existem coisas incriveis, como utilizadores que usam o email empresarial para enviar dados (que supostamente não deveriam) para emails pessoais. Quando isso acontece, a investigação torna-se mais fácil, pois a maioria das organizações já utiliza sistemas de email centralizados, e se não for o caso, pelo menos toda a informação está guardada no endpoint. O problema maior reside quando o envio de informação é feito pelo email pessoal, como pelas contas de gmail, outlook, etc., onde nessas circunstâncias a única opção possível é a reconstrução de algumas partes possíveis do tráfego através de informação contida em ficheiros temporários dos diversos browsers utilizados.

Uma técnica muito utilizada em outras circunstâncias e que eventualmente pode ser utilizada também neste tipo de casos é a criação de uma “timeline”, ou seja, uma linha do tempo daquilo que ocorreu num determinado período. Por aquilo que ocorreu entende-se um conjunto de eventos ao nível de sistema de ficheiros ou aplicações que são mostrados em ordem cronológica de forma a entender uma sequência de eventos que possam estar relacionados. Um cenário concreto talvez ajude a perceber como pode ser útil uma timeline. Imaginemos que existe um ataque a um determinado sistema. Num dos pontos do ataque, o atacante consegue entrar dentro do sistema, sendo que um dos primeiros objetivos será criar uma forma de persistência para manter o acesso ao sistema caso o mesmo seja desligado ou reiniciado. Para isso, coloca um ficheiro executável com Malware num local recondito, e cria uma chave na registry, para que esse Malware seja carregado no arranque do sistema. Após isso, começa a vasculhar o sistema em causa e instala uma aplicação para transferência segura por FTP, para posteriormente iniciar o roubo de dados. Todas estas ações deixaram um rasto no sistema em causa, o que numa timeline pode ajudar a entender esta sequência de eventos, pois eles ocorrem numa ordem cronológica, o que seria muito dificil analisar cada um dos eventos isoladamente e depois correlacioná-los. Abaixo coloco os dados que são extraídos ao criar uma timeline.

Timeline-Chart

Podemos desta forma enviar todos estes dados para um ficheiro de excel, para fazer uma filtragem mais à nossa medida ou excluir determinados eventos que não sejam do nosso interesse, podendo resultar em algo semelhante a isto.

Timeline

De qualquer forma, esta é uma temática interessante para um futuro artigo.

Em penúltimo lugar nesta sequência de fontes de evidência, coloco uma técnica denominada “Stochastic Forensics”, que foi criada por um analista forense de nome Jonhathan Grier, em que se demostra que a distribuição estatistica dos metadados do sistema de ficheiros é afetada e alterada quando se copiam grandes volumes de dados, entenda-se, muitos diretórios com muitos ficheiros no seu interior. Este tipo de ação provoca alterações a nível do sistema de ficheiros que podem demonstrar (quando correlacionadas com outras fontes de evidência) que existiu uma cópia massiva de dados de um determinado sistema.

Por úlitmo, temos uma das fontes de evidências mais importantes neste tipo de casos, novamente para correlacionar com outras (acho que já mencionei isto várias vezes), que são as ligações de dispositivos USB, sejam eles pen drives, sejam discos rígidos. Esta é uma fonte de informação muito útil nestas ocasiões, pois dado aquilo que se consegue fazer com um dispositivo USB é incrivel, é possível copiar em muitos casos toda a informação de uma organização.

Existem 4 chaves para entendermos a forma como os dispositivos USB interagem com o sistema operativo, que são as seguintes:

– System\CurrentControlSet\Enum\USBSTOR. Esta chave contém informação importante para identificar o dispositivo, como o fabricante, o modelo e o número de série, que possibilitam como primeiro passo que consigamos saber qual o dispositivo usado para a cópia de dados. Aqui está um exemplo:

\ControlSet001\Enum\USBSTOR\Disk&Ven_WD&Prod_Elements_10B8&Rev_1007\57583631454333594B4E3737&0\Properties\{a8b865dd-2e3d-4094-ad97-e593a70c75d6}0000005

– System\MountedDevices. Esta chave contém informação sobre as letras de unidade (drive letters) que foram atribuídas aos dispositivos USB e contem ainda o número de série do dispositivo, possibilitando que seja possível concluir que um dispositivo especifico foi montado e estava acessível ao utilizador.

– NTUser.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2.  Esta chave permite identificar qual o utilizador que estava com a sessão iniciada na máquina quando o dispositivo USB foi ligado. Este é um aspeto importante, pois o objetivo de uma análise forense é perceber quem é o responsável por determinada ação.

– Root\Windows\inf\setupapi.dev.log. Este ficheiro contém informação sobre a data em que o dispositivo foi ligado pela primeira vez. Esta informação pode ser interessante para colocar numa timeline e eventualmente correlacionar com outras informações, até informações externas, ou não digitais, que limitem o foco da investigação.

Para já, chegamos ao fim das possíveis fontes de evidência para casos de roubo de dados.  Fim logicamente neste artigo, porque existirão com certeza mais fontes de informação úteis para este tipo de casos, algumas delas já existentes, outras talvez ainda por descobrir, à medida que se vão efetuando análises forenses neste campo.

Qualquer organização que passe por uma situação de roubo de dados, sabe as implicações que isso pode ter, por isso, como diz o povo: “casa roubada, trancas na porta”. Muitas vezes a proteção só é pensada após os incidentes, o que é mais complicado de gerir sem dúvida, mas ficam algumas dicas para possíveis soluções para minimizar o risco de roubo de dados e de perdas associadas.  No meu ponto de vista, o primeiro passo é a motivação dos colaboradores, ou seja, se as pessoas estiverem motivadas e satisfeitas com o que fazem, com as condições de trabalho e se forem reconhecidas pelo seu valor, o risco é diminuido para limites minimos, porque nestas condições a maioria das pessoas trabalha por gosto e para contribuir para um projeto e vão ser mais valias na organização.  Dentro de uma vertente mais técnica, existem algumas soluções que podem ser usadas numa perspectiva preventiva, mais ou menos complexas. Talvez a mais completa seja a utilização de uma solução DLP (Data Leak Prevention), que tem por objetivo controlar todos os fluxos de informação e a informação que está alojada em determinados suportes partilhados. Também é a mais complexa de implementar, pois exige que exista um projeto de implementação adequado às necessidades da organização. Outras soluções menos complexas podem ser a implementação de politicas de segurança e tentar de alguma forma fazer o “enforcement” dessas politicas, fazer a retenção e análise de logs e por último fazer auditorias regulares, que indiquem se as politicas de segurança estão a ser respeitadas.

Em resumo, não existe nenhuma solução “point and click” para casos de roubo de dados, mas existem muitas fontes de evidência que podem ser usadas para correlacionar dados, que nos possam ajudar a chegar a uma conclusão do que ocorreu e quem o fez.

A apresentação que fiz na Confraria está disponível aqui: https://ap2si.org/pt/2015/03/869.html

 

Posted in Digital Forensics, Information Security | Tagged , , , , , | Leave a comment

WD Firmware Finder App

I would like to share with the DR community a small App that I wrote to help on a very simple task of locating a specific Firmware version for WD Marvell families.

Well, this is not something new, that could not be done using some other apps, which probably most of us are using already for quite some time.  This is just my version of a tool that I think it’s useful.  I’m not a programmer by nature, but I was on a small C# course, and on this kind of courses, we always have a final task to accomplish.  Based on that, I decided to write this simple app that receives from the user the version that he’s trying to find and returns the folders (drives) that have that specific version.

There’s only one configuration to be done, that is creating a file called “Path.txt”, on the folder C:\Temp, with the location of the WDCMarvell folder that contains the Firmware for all WD Marvell families.  If that condition is met then it’s quite straightforward and I’m sure everyone can run it without major issues.

If someone finds a bug or some peculiar situation where the app does not work, or even any suggestions for future versions, let me know, so I can keep upgrading it.

Here is a screenshoot of the application main window.

WD Firmware Finder

You can download the application on this link: http://www.datarecovercenter.pt/Downloads/Find_Firmware_Version.zip

Hope you enjoy!

Posted in Data Recovery | Tagged , , | Leave a comment

Diferenças entre discos rígidos e SSD’s (Solid State Drives)

O meu primeiro artigo vai ser sobre um tópico que já abordei numa das Confrarias de Segurança da Informação cá em Portugal, a diferença entre discos rígidos e ssd’s (solid state drives).  Curioso é o facto de utilizar o termo disco rígido em português, mas sinceramente o termo disco de estado sólido é um pouco estranho, e parece-me que nem sequer é reconhecido no mercado.  Provavelmente se entrasse numa loja a pedir um disco de estado sólido, em alguns locais iam ficar a olhar para mim como se fosse uma pessoa estranha.  Por isso, vamos manter o termo inglês SSD.

O objectivo do artigo não é simplesmente explicar as diferenças em termos físicos e lógicos entre uma coisa e outra, mas sim abordar mais a temática da recuperação (de informação) e segurança associada a estes dois tipos de suporte de armazenamento, além dos desafios associados a cada um deles.

Primeiro que tudo temos que voltar atrás no tempo e perceber de onde aparecem estes termos e qual é a sua história.  Em boa parte, com isso, vai ser fácil perceber quais as diferenças entre os discos rígidos e os SSD’s.

No caso dos discos rígidos, a história começa há muito tempo, bem antes sequer de eu ter nascido, nos anos 50, quando a IBM (que neste momento já está fora desta indústria) produziu os primeiros discos rígidos, sendo que o primeiro a ter algum sucesso no mercado foi o IBM RAMAC 305, com uma estonteante capacidade de 5Mb (era mesmo na época!) e com um preço de 160.000 USD.  Parece que devido ao custo tão elevado que o disco tinha, uma das opções era o aluguer do disco durante um período de tempo.  Vou aqui abrir um parenteses, porque naquela época, a utilização do termo disco rígido não criava o mesmo quadro mental que cria nos dias de hoje, porque hoje quando pensamos nisso, temos um quadro mental de um dispositivo que mede uns centímetros e levamos na mão ou facilmente na nossa mala, mas naqueles tempos um disco rígido era maior ainda do que o frigorifico lá de casa.

Os anos passaram e logicamente o custo por MB foi diminuindo, assim como o tamanho dos dispositivos, até que em 1980, cerca de 30 anos após o arranque desta indústria, viu-se o primeiro disco rígido com um formato que talvez a malta mais nova já conseguisse associar a um disco, quando a Seagate lançou o modelo ST-506, o primeiro disco rígido de 5 ¼, com uma capacidade de 5Mb e um custo de 1.500 USD (veja-se bem a diferença do IBM RAMAC 305, em termos de custo e tamanho).

A partir dos anos 80, já começámos a assistir a uma massificação dos discos rígidos, alavancado claro está pela utilização cada vez mais crescente de computadores e a passagem de processos para formatos digitais.  Com isto, começou a pensar-se em como criar discos para uma utilização mais profissional, mais rápidos e mais fiáveis.  Foi a partir de algumas dessas necessidades que se desenvolveu o interface SCSI (Small Computer System Interface), que possibilitou elevar a fasquia em termos de desempenho, e este passou a ser o padrão utilizado em servidores.  Hoje, ainda existem muitos discos no mercado com este padrão, apesar de já ter sido substituído por outro mais recente, o SAS (Serial Attached SCSI).  Num próximo artigo falarei sobre estes e outros interfaces e as diferenças entre cada um deles.

Outro dos pontos altos dos discos rígidos foi quando em 2007, foi lançado o primeiro disco rígido de 1Tb (Terabyte).  Em grande parte todo este desenvolvimento foi muito potenciado pelos conteúdos que foram gerados, que impulsionaram a necessidade cada vez maior de espaço para armazenamento de informação digital.  Apenas para referir a última inovação mais mediática, quando este ano, começaram a ser lançados os primeiros discos rígidos com Hélio, o que, segundo os fabricantes, possibilita uma maior densidade e também um aumento do número de pratos que o disco pode conter.

Falando sobre a arquitetura de um disco rígido, de um modo simples pode ser dividida em duas grandes partes, a PCB (Printed Circuit Board) e o HDA (Head Disk Assembly).  Existem outras nomenculaturas ou formas de “dividir” um disco rígido, mas esta foi a que decidi usar para facilitar a explicação.  Basicamente, podemos dizer que a PCB é como se fosse a parte externa e o HDA a parte interna, com todos os seus componentes, que falaremos de seguida.  Além disso, existe o chassis que suporta todos os componentes, mas que não tem grande interesse para o objectivo deste artigo.

A PCB tem por missão efectuar tarefas como controlo de tráfego de dados, controlo dos componentes electrónicos, codificação e descodificação de dados e contém alguns componentes fundamentais ao funcionamento do disco rígido, como o MCU (Micro Controller Unit), que faz todo o processamento e cálculo, assim como controla o canal de escrita e leitura, que tem que transformar os sinais analógicos vindos das cabeças de leitura em sinais digitais para o processo de leitura e o reverso no processo de escrita.  Além disso, o MCU controla o fluxo de dados para o interface SATA, de forma a serem disponibilizados ao utilizador.  Todas as PCB’s têm também um chip denominado VCM (Voice Coil Motor) Controller, que controla o movimento do motor e também a deslocação das cabeças.  Se este chip estiver danificado, um dos comportamento típicos é o motor do disco rígido nem sequer inicializar.  Além do consumo de energia enorme, este chip pode aquecer bastante e isso é possível confirmar, colocando o dedo🙂

Como muitos outros dispositivos, os discos rígidos também têm uma memória, normalmente conhecida por cache, que pode ser de 16, 32 ou 64 MB, sendo estes os tamanhos mais comuns actualmente.  O objectivo desta memória é acelerar o funcionamento global do disco rígido, por colocar nela informação acedida regularmente, inclusive alguma informação relacionada com o Firmware do disco.  Um chip que a maioria das vezes está presente, mas nem sempre como memória física isolada, é a ROM (Read Only Memory), curiosamente um chip do tipo Flash.  Este componente contém uma parte do Firmware do disco, que é acedido quando o disco inicializa.  Em alguns casos já se verificou que não existe este chip, o que significa que o seu conteúdo está numa memória flash dentro do próprio MCU.

Existem ainda muitos outros componentes, mas a ideia não é descrever exaustivamente a PCB nem nenhum deles, apenas considerar os principais e a sua função.

Vou apenas referir mais um, que é um caso curioso.  Desde há uns anos para cá muitas PCB’s, talvez todas (não estive atento a confirmar isso), contêm um Sensor de Choque, que basicamente aquilo que faz é receber um sinal quando existe um determinado grau de choque no dispositivo e enviar uma instrução para alguns componentes, de maneira a que as cabeças possam entrar na sua zona de parqueamento e o motor possa parar, tudo isto sem causar (ou para impedir) danos nos componentes do disco rígido.  Até me recordo de há alguns anos atrás um fabricante ter feito uma publicidade enorme aos seus portáteis com base nesta tecnologia.  Devo dizer que aqueles clientes que testaram esta funcionalidade devem ter ficado desiludidos, pois na realidade não funciona (ou pelo menos quase nunca funciona), por isso, a ideia de deixar cair um disco rígido ou um portátil não é muito saudável (e isto falo com conhecimento de causa).

Bem, passando ao que chamamos de HDA (Head Disk Assembly), além do chassis, que até tem alguns pormenores interessantes (talvez num outro artigo fale sobre eles), vamos concentrar-nos no interior do disco rígido.  Os componentes que visualmente identificamos com facilidade são os pratos, o motor, o HSA (Head Stack Assembly), o pré-amplificador e um íman.  Logicamente, entre estes o mais importante é ou são os pratos, que é onde os nossos preciosos dados estão alojados (apesar de quando olhamos apenas vemos um género de um espelho), que são constituídos de alumínio polido ou de vidro, apesar de vidro ser muito menos frequente e bastante mais perigoso no caso das famosas quedas.  São depois revestidos por uma séria de compostos, inclusive uma camada ferromagnética, que aloja os sinais (ou os nossos dados).

Além dos pratos, um dos componentes mais importantes são as cabeças, cujo objetivo é realizar o processo de leitura e escrita nos pratos.  O HSA contém na sua extremidade as cabeças, que poderão ir de uma a dez, consoante o tamanho do disco.  As cabeças contêm um elemento de leitura e um elemento de escrita para que possam realizar ambas as operações e são na realidade um dos elementos mais sensíveis de todo o conjunto, e só poderiam ser, pois na realidade são responsáveis por conseguir ler os sinais alojados nos pratos que podem rodar a 10000 rotações por minuto, e “voam” a uma distância de cerca de 5 a 10 nanómetros dos pratos (sim, nunca entram em contacto com a superfície, pois na realidade, quando isso acontece é muito mau sinal).  Para termos uma ideia do que isto significa, basta pensarmos que um cabelo nosso em média tem cerca de 25000 nanómetros de diâmetro.  Por esta razão é fácil entender porque é que não é boa ideia abrir um disco rígido fora de uma câmara adequada para o efeito, pois se uma partícula entrar em contacto com as cabeças, pode facilmente fazer com que se danifiquem.  Por isso é que os discos têm que funcionar num ambiente em que ar tem que ser muito limpo e controlado.

Um outro componente importante é o pré-amplificador ou preamp.  O objectivo deste chip é controlar as cabeças e amplificar os sinais que são enviados ou recebidos.  Como os sinais das cabeças são muito fracos, o preamp tem que estar o mais próximo possível das cabeças, e essa é a razão pela qual está dentro do HSA, em vez de estar na PCB.

O último dos componentes principais dentro do HSA é o motor e tudo aquilo que o constitui, ou seja o motor propriamente dito, que é colocado num eixo, onde depois são colocados os pratos, divididos por anéis entre eles para criar o espaçamento necessário e finalmente fixos por um tipo de engate que suporta os parafusos que ligam os pratos ao eixo, permitindo que rodem todos ao mesmo tempo.

A nível de arquitetura a forma como os dados são guardados e acedidos é feita através de pistas concêntricas distribuídas pelas superfícies de todos os pratos, que por sua vez estão divididas em clusters, e finalmente em sectores.  Um cluster é um conjunto adjacente de sectores, e por norma é a menor unidade de espaço endereçável pelo sistema operativo.  Um sector pode conter 512 bytes ou 4096 bytes, nas unidades mais recentes.  Um cilindro é uma forma de endereçar a mesma pista em todas as superfícies.  Isso leva-nos à famosa notação CHS (Cylinder Head Sector), que não é mais do que a notação física de endereçamento dos sectores do disco rígido, em que com as coordenadas corretas, conseguimos endereçar todos os sectores do disco.  É óbvio que não é muito fácil para os utilizadores entenderem e lidarem com este endereçamento, daí que para facilitar muito as coisas isso foi transformado num endereçamento lógico muito mais simples chamado LBA (Logical Block Addressing), em que basicamente os sectores do disco rígido iniciam no zero e vão até um determinado número dependendo do tamanho do suporte.  Existe depois uma função a nível de Firmware de nome Translator, que é responsável por fazer a conversão das coordenadas físicas em lógicas.  Para o utilizador tudo fica simplificado e bem mais transparente.

Como muitos outros dispositivos electrónicos, um disco rígido também tem um firmware, que contem informação indispensável ao seu funcionamento.  Não conseguindo aceder ao firmware, nunca conseguiremos aceder aos dados alojados.

As falhas mais típicas associadas a discos rígidos e que originam perdas de dados são as lógicas (como dados apagados, falhas no master boot record, etc), as electrónicas (picos de tensão, etc), as de Firmware (informação crítica não acessível) e por último as físicas (cabeças danificadas, motor inoperacional ou preamp danificado).  Depois de falarmos sobre os SSD’s, falaremos mais um pouco sobre as diferenças entre as falhas comuns entre discos rígidos e SSD’s.

No que toca à segurança associada a um disco rígido, este ainda é um ponto de falha bastante grande, pois a maioria dos utilizadores não utiliza qualquer tipo de encriptação, o que significa que se alguém malicioso consegue aceder ao disco fisicamente, terá acesso a toda a informação contida no disco rígido.  Para isso, ultimamente temos assistido aumentarem o número de discos rígidos com a possibilidade de encriptação, quer parcial, quer total, normalmente chamados FDE (Full Disk Encryption).  Em termos de aplicações mais utilizadas no mercado empresarial para encriptação de discos rígidos, temos o Bitlocker, o Safeboot e o Safeguard, que utilizam AES128 ou AES256, o que torna as coisas bastante seguras.

Vamos começar então a falar de Flash.  A memória Flash foi inventada em 1980 pelo Dr. Fujio Masuoka (se não estou em erro trabalhava na Toshiba).  Um pormenor curioso é o nome em si, pois o processo de escrita nas células faz lembrar o Flash de uma câmara fotográfica, e daí ter sido o nome usado.  Existem dois tipos principais de memórias Flash utilizadas, que são as memórias NAND e NOR.  As memórias Flash, depois de serem apresentadas numa conferência da IEEE em San Francisco em 1984, foram apresentadas comercialmente pela primeira vez em 1988 pela Intel, naquele caso do tipo NOR.  Só alguns anos depois, em 1995, foi lançada no mercado a primeira memória Flash amovível.  A partir daí o desenvolvimento comercial e tecnológico foi grande, e as memórias Flash são utilizadas em inúmeros dispositivos sem sequer nos apercebermos, apesar de serem mais conhecidas pela sua utilização em pen drives USB, em cartões SD ou mais recentemente nos SSD’s.  Portanto, em conclusão, é tudo menos um tipo de memória novo, mas como em muitos outros casos, tem o seu tempo de desenvolvimento e maturidade no mercado.

A nível físico, em termos simples, existem células que guardam os electrões e que têm uma espécie de porta de entrada para os electrões entrarem e saírem.  Quando o electrão está dentro da célula significa que o resultado é 0 (zero) e quando o electrão está fora significa que o resultado é 1 (eu sei que parece estranho porque normalmente os bits são interpretados ao contrário).  Existem dois tipos de células utilizadas, o tipo SLC (Single Layer Chips) e o tipo MLC (Multi Layer Chips), em que a diferença é que o SLC grava 1 bit (0 ou 1) por transístor, enquanto o MLC grava dois bits por transístor, conseguindo o dobro da capacidade, mas diminuindo o desempenho de leitura e escrita.

Logicamente não podemos endereçar as células individualmente, por isso, em termos de arquitectura as memórias estão divididas em Pages, Blocks, Planes, Dies e TSOP’s (Thin Small Outline Package, que são o circuito integrado em si, ou chip).

Uma Page é um conjunto de células que compõem a unidade mais pequena em que é possível escrever (semelhante a um cluster nos discos rígidos).  O tamanho de uma Page pode ser variável dependendo do fabricante.  Um tamanho comum pode ser 4.314 bytes, onde apenas 4.096 bytes são utilizáveis, enquanto os restantes 218 bytes são utilizados para ECC, gestão e firmware.  Um Block é composto por 128 Pages, que segundo as contas acima, é uma unidade de 512 Kb.  Tem o pormenor curioso de ser a unidade mais pequena que se consegue apagar (este é um pormenor importante, pois os SSD’s não podem escrever sobre Pages que não foram previamente apagadas, e isto leva a dois tópicos que são a degradação das células ao longo do tempo e a função TRIM, que falarei numa próxima oportunidade).  Planes são conjuntos de 2048 Blocks e  Dies são conjuntos de 2 Planes.  Cada SSD (dos mais comuns) pode conter 8 ou 16 TSOP’s, para perfazer o tamanho total pretendido pelo fabricante.

Um outro componente fundamental dos SSD’s é o MCU (Controller), que gere uma série de processos críticos para o funcionamento da unidade, como Wear Leveling, Bad Block Management, Erase Cycles, ECC, etc.

Desses processos críticos, o Wear Leveling tem por objectivo lidar com um problema das memórias flash, a degradação.  Os blocos que são escritos muitas vezes acabam por sofrer muito mais ciclos de destruição (para apagar os dados) do que outros blocos.  Por causa do número de leituras e escritas sobre os blocos, a probabilidade de falha é maior, até porque a memória teoricamente só pode ser escrita um determinado número de vezes (cerca de 100.000), e devido a isso, o número de ciclos é monitorizado e o controlador consegue mapear os blocos a escrever de forma a não utilizar sempre os mesmos e evitar assim a degradação mais rápida.  Um outro processo que está relacionado é o Garbage Collection, pois no funcionamento normal quando um utilizador apaga um conjunto de dados, fisicamente os dados não são eliminados.  O sistema operativo (Windows) utiliza o comando TRIM para informar o controlador que um determinado conjunto de páginas está disponível para utilização e o controlador desta forma sabe que os dados nestas páginas não são necessários e não necessita de efectuar o processo realocação, diminuindo assim o número de ciclos de escrita.

Normalmente uma parte do espaço disponível num SSD é reservado para o controlador, para que este possa fazer toda a gestão interna do SSD.  Isto permite em muitos casos que existam um conjunto de blocos vazios que estão preparados para ser utilizados assim que necessário.  Isto também pode ser a razão porque em alguns casos existem tamanho menos convencionais, como 60Gb ou 120Gb em SSD’s, e esta gestão pode ser feita pela funcionalidade de Over Provisioning.

Como qualquer outro suporte, o SSD não é excepção no que toca a produzir erros, e por isso existem uma série de processos para gerir esses erros, como por exemplo o Bad Block Management. Durante o processo de fabrico e posteriormente no processo de funcionamento de um SSD (o mesmo acontece no caso dos discos rígido), existem muitas células que já vêm inicialmente com defeitos e células que se vão danificar ao longo do tempo, e os fabricantes já preveem como lidar com isso por reservar um espaço determinado para guardar essa informação.  Esta parte do firmware faz a gestão quer dos defeitos iniciais, quer dos gerados com o tempo, para que essas células possam ser remapeadas e não utilizadas novamente.

Relacionados com a integridade dos dados existem dois processos críticos, o ECC (Error Correction Code), já é uma técnica bastante antiga, que também é utilizada em discos rígidos tradicionais, que tem por objectivo validar a integridade dos dados que passam no bus de dados, para detectar erros e incoerências e conseguir corrigir esses erros para que dados inválidos não sejam guardados e posteriormente acedidos.  Novamente, como no caso dos SSD’s existem milhões de células, a probabilidade de ocorrerem erros é muito alta e o controlador tem que gerir isso.  Além disso, existe ainda o CRC (Cyclic Redundancy Check), cujo objectivo é a protecção da integridade dos dados à semelhança do ECC, no entanto, o CRC garante que os dados que são escritos são os mesmos que são lidos e disponibilizados ao utilizador.  É gerado um valor CRC para um determinado conjunto de dados, que depois é gravado no SSD juntamente com os dados em si.  Quando esses dados são requisitados, é calculado novamente o CRC e verificado se está de acordo com o que está guardado.  Se estiver, significa que os dados são íntegros.  Se não estiver, significa que ocorreram erros e que os dados não são íntegros, e o utilizador tem que saber disso.  No entanto, o CRC é apenas uma validação e não corrige erros caso eles existam.

No que toca à componente recuperação de dados e segurança, aqui existe um pormenor que pode fazer muita diferença, pois na maioria dos actuais SSD’s existe encriptação por defeito (também AES128 ou AES256), e a chave de encriptação está guardada na maioria dos casos no MCU, o que significa que em caso de falha do MCU, a probabilidade de voltar a ver os dados é praticamente nula.

As falhas comuns que podem levar a perdas de dados em SSD’s são em boa parte semelhantes às dos discos rígidos, como por exemplo no que toca aos problemas lógicos, onde, na maioria dos casos, o problema está no utilizador, quando são apagados dados, criadas novas partições, etc.  Também existem problemas a nível electrónico, onde partilham problemas comuns com os discos rígidos, como os picos de tensão e outros.  Os SSD’s também contêm Firmware (apesar da sua estrutura ser diferente da dos discos rígidos), que pode ficar inacessível por diversas razões e levar à perda do acesso aos dados.

Por úlitmo, também podem ocorrer problemas com o próprio MCU, que por norma são aqueles de mais difícil solução, pois devido à questão da encriptação não é possível simplesmente substituir o MCU.

A nível de segurança os SSD’s partilham muito daquilo que os discos rígidos também têm, ou seja, FDE, utilizando as mesmas aplicações que são usadas para os discos rígidos, Bitlocker, Safeboot ou Safeguard.  Existe ainda a vantagem que os dados contidos nas memórias Flash estão encriptados na maioria dos SSD’s actuais, o que significa que mesmo retirando e lendo as memórias flash em RAW não é possível efectuar a reconstrução dos dados, o que acaba por ser uma vantagem no que toca à componente de segurança.

Vamos então agora às principais diferenças entre os discos rígidos tradicionais e os SSD’s.  Começo por focar a questão da segurança, que me parece que não existirão grandes diferenças, pois o que pode ser utilizado em um, pode também ser utilizado no outro, sendo que o SSD tem ainda a vantagem (pelo menos os mais recentes) de utilizarem encriptação a nível de hardware, o que é uma boa funcionalidade anti-tampering.

Uma das diferenças mais óbvias entre os discos rígidos e SSD’s são as partes móveis.  Os discos rígidos tradicionais têm um conjunto de partes móveis (especialmente as cabeças), o que os torna muito suscetíveis ao movimento, especialmente quando estão em funcionamento.  No caso dos discos rígidos as quedas são um elemento comum que leva a perda de dados e a danos muitas vezes irrecuperáveis.  Por outro lado, os SSD’s não têm partes móveis, apenas componentes electrónicos, o que os torna muito adequados para soluções onde a mobilidade é importante, e dessa forma é possível reduzir o risco de perda de dados.  Uma nota apenas, este simples facto não prova que os SSD’s sejam menos propensos a falhas do que os discos tradicionais, pois isso é apenas uma questão teórica.  Não existem estudos (pelo menos que eu conheça) que levem a essa conclusão, nem sequer as partes móveis são responsáveis pela maioria dos problemas com os discos rígidos.

No que toca à questão da recuperação de dados em discos rígidos versus SSD’s, ainda existe uma diferença substancial, pois nos discos rígidos já existe muito mais investigação neste sentido e as possibilidades de recuperação são sempre muito altas desde que o problema não esteja relacionado com a superfície dos pratos, ou seja, tudo é possível substituir à excepção dos pratos onde estão contidos os dados.  As técnicas existentes também já estão muito refinadas a ponto de permitirem recuperações parciais, mesmo quando uma ou mais superfícies tenham problemas.  No que toca aos SSD’s, a história é bastante diferente.  A investigação nestes dispositivos ainda é muito limitada e bastante complexa também.  Um dos problemas comuns, relacionado com o MCU, torna-se irrecuperável à partida, devido à encriptação ao nível das memórias Flash, e devido à construção destes dispositivos, mesmo que apenas um dos 8, 16 ou 32 chips esteja inacessível, a recuperação parcial ainda não é uma possibilidade existente (pelo menos do conhecimento limitado que tenho).  Daí que no toca à recuperação de dados, sem dúvida que a probabilidade é bem maior em discos rígidos do que em SSD’s (a palavra backup nunca fez tanto sentido para quem usa SSD).

Fugindo da questão da segurança e recuperação, sem dúvida que o SSD apresenta muitas vantagens ao nível do consumo, peso, rapidez, barulho.  A maior e única desvantagem óbvia é o custo, que ainda é altíssimo quando comparado com os discos tradicionais.

Conforme disse, falei sobre este tópico numa Confraria de Segurança da Informação em Abril deste ano.  Aqui fica o link da apresentação para quem quiser.

http://www.datarecovercenter.pt/Noticias/2013/Apresentacao-sobre-Diferencas-entre-Discos-Rigidos-e-SSD-s

Sintam-se à vontade para questões ou criticas.  Como dizia uma pessoa amiga, reservo-me o direito de responder a qualquer pergunta com a resposta “Não sei, vou procurar a resposta!”.

Posted in Data Recovery | Tagged , , , , , | Leave a comment

Intro

Finally I decided to write something to share with the community about some areas of activity that are not only my daily work, but also something I like to do. The aim will be sharing and discussing some topics that I have crossed in jobs that develop or on matters that sometimes I talked with someone, and after some research I think it would make sense to address the issue further.

I’ve been working for some years in the areas of Data Recovery (the oldest), Digital Forensics and Information Security in a national company, Data Recover Center.

My first question is if I write in Portuguese or English. I think I’ll do a mix of both, because it seems to me that some topics are already more than covered in English, but maybe there is a gap in Portuguese contents, and thus, to me it makes sense to share this content on my natural language, especially for the benefit of those who live in this corner (Portugal)!

Posted in Data Recovery, Digital Forensics, Information Security | Tagged , , , , , , | Leave a comment