Disassembler

[gabriel]

Bom dia pessoal, tenho que fazer o disassemble da minha BIOS meu processador suporta Virtualização (AMD) mas é desabilitado na BIOS pelo fabricante do note, já ví que algumas pessoas conseguiram abilitar isso achando o flag na BIOS alterando e gravando a BIOS alterada, mas os procedimentos não funcionam pra minha versão então vou tentar eu mesmo.

Alguém sabe recomendar algum disassemble freeware/open-source pra fazer o disassemble para AMD64.

Atenciosamente.

[Ricardo Nascimento]

p/ esse tipo de procedimento você pode usar o “IDA”.

https://www.hex-rays.com/products/ida/support/download_freeware.shtml

--
--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "ccppbrasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para ccppbrasil+...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Alberto Fabiano]

Gabriel,

Tente usar o ndisasm ou o objdump; para este último há um front end
interessante que é o dissy: https://code.google.com/p/dissy/

Confesso que não é minha opção, mas para x86_64 é na faixa, é o que
funciona melhor.

[ ]s

Alberto

2013/3/1 gabriel <newbi...@gmail.com>:

[Gabriel Silva Moreira]

O IDA parece ser a melhor opção, só vou ter que preparar uma VM de 64bits minha VM windows é 32 ai ele não abre.

--
/**
* Gabriel [newbie_x11] Moreira
* My game project? *http://newbie-x11.blogspot.com
*http://sourceforge.net/projects/newbie-engine
Obrigao.
*/

[Alberto Fabiano]

2013/3/1 Ricardo Nascimento <ricard...@gmail.com>:

> p/ esse tipo de procedimento você pode usar o “IDA”.
>
> https://www.hex-rays.com/products/ida/support/download_freeware.shtml
>
>

A versão freeware do IDA (5.0) não suporta adequadamente código (AMD)
x86_64, não conseguindo decodificar muitos opcodes, aliás alguns
x86_64 switches são tratados adequadamente apenas na versão PRO 6.2.
Por isto recomendei o objdump com o Dissy, que não chega aos pés do
IDA Pro, mas é funcional.

Aliás, esta versão freeware do IDA sofre crash em várias situações,
algumas inclusive exploradas por malwares, do qual as versões Pro
possuem bugfix como um caso com eax++, seja de refresh do stack trace,
análise de structure type anônimas, utilização do uiswitch, análise de
typedef x x e principalmente em análise de alguns códigos feitos
específicos para tentar causar memory corruption que acabam gerando
este mesmo efeito também no IDA inclusive em em quase todos os
releases da versão 5.x. Por isto recomendo fortemente o uso da versão
6.2 que é muito estável.

Aliás, existem packers que dentro das features de "anti-debugger" eles
injetam propositalmente trash opcodes que ferram como OllyDBG/Immunity
Debugger, WinDBG, IDA Pro e o Hiew. Para lidar com isto existem
plugins para evitar eses crashs, para o IDA muitos não suportados pela
versão freeware.

PS: Se alguém leu isto e ficou tentado em usar versões "bucaneiras" já
aviso que keygens e cracks para o IDA PRO são adoradas pelos VXers
para se injetar código malicioso como downloaders de trojans e
rootkits.

[ ]s

Alberto

[Alberto Fabiano]

2013/3/1 Gabriel Silva Moreira <newbi...@gmail.com>:

> O IDA parece ser a melhor opção, só vou ter que preparar uma VM de 64bits
> minha VM windows é 32 ai ele não abre.
>

Gabriel, as chances do IDA Freeware (5.0) abendar tratando código
x86_64 até porque esta versão não suporta muitas instruções x64 e por
possuir muitos bugs relacionado a este contexto, corrigidos em versões
superiores onde o melhor suporte é da versão 6.2, tende a ser muito
grande.

Mas, feel free e boa sorte! ;-)

Depois compartilhe o resultado de suas experiências.

[Alberto Fabiano]

2013/3/1 Alberto Fabiano <alb...@computer.org>:

> 2013/3/1 Ricardo Nascimento <ricard...@gmail.com>:
>> p/ esse tipo de procedimento você pode usar o “IDA”.
>>
>> https://www.hex-rays.com/products/ida/support/download_freeware.shtml
>>
>>
>
> A versão freeware do IDA (5.0) não suporta adequadamente código (AMD)
> x86_64, não conseguindo decodificar muitos opcodes, aliás alguns
> x86_64 switches são tratados adequadamente apenas na versão PRO 6.2.
> Por isto recomendei o objdump com o Dissy, que não chega aos pés do
> IDA Pro, mas é funcional.
>
> Aliás, esta versão freeware do IDA sofre crash em várias situações,
> algumas inclusive exploradas por malwares, do qual as versões Pro
> possuem bugfix como um caso com eax++, seja de refresh do stack trace,
> análise de structure type anônimas, utilização do uiswitch, análise de
> typedef x x e principalmente em análise de alguns códigos feitos
> específicos para tentar causar memory corruption que acabam gerando
> este mesmo efeito também no IDA inclusive em em quase todos os
> releases da versão 5.x. Por isto recomendo fortemente o uso da versão
> 6.2 que é muito estável.
>
> Aliás, existem packers que dentro das features de "anti-debugger" eles
> injetam propositalmente trash opcodes que ferram como OllyDBG/Immunity
> Debugger, WinDBG, IDA Pro e o Hiew. Para lidar com isto existem
> plugins para evitar eses crashs, para o IDA muitos não suportados pela
> versão freeware.
>

Shit!:-( Acima onde está "como OllyDBG" eu queria escrever "ferra
com o OllyDBG" e etc..

Mas enfim, para instruções x86 sem junk code de instruções
anti-tamper, anti-debugger, anti-disassembly, anti-trace, anti-VM e
dbg-killer o IDA Freeware (5.0) e muitas tools funcionam muito bem. E
com o IDA o plus é que há uma grande comunidade que o utiliza a
tempos, por isto se encontra muito material sobre ele, além de existir
muitos plugins que ajudam com certas operações.

Mas quando estamos falando de instruções x86_64 (que é o caso) a
coisa muda de figura. E mesmo quando se fala que o disassembler "tem
suporte" nem sempre este é pleno. O próprio IDA PRO foi ter um suporte
legal na linha 6.x.

Curiosidade: Conheci um analista de malware na ásia que comentou que
se ele começava a analisar um artefato com o OllyDBG ou IDA PRO e
ocorria um crash para ele era malware. Então comentei para a criatura
que poderia ser um programa legítimo empregando instruções x86_64 não
suportadas pelo disassembler ou ainda um software legítimo empregava
estas técnicas para proteger propriedade intelectual, então ele me
interrompeu e comentou: "truth! I hadn't thought on it before." Fiquei
pasmo e respondeu minha pergunta que iria ser como ele fazia para
identificar quando não era malware e ocorria isto. Então um colega que
estava ao lado comentou: "if its proprietary code then is malware".
Olhei para ambos e demos risada, mas confesso que fiquei com aquela
sensação amarga na boca e uma vontade de socar ambos.

[Alberto Fabiano]

Gabriel,

Desculpe o flood, mas subitamente lembrei de algo:

- Talvez o seu problema está ocorrendo porque ao alterar a BIOS você
está invalidando a assinatura digital dela, coisa normal em tempos de
(U)EFI (TPM/TXT) e no update esta BIOS alterada está sendo rejeitada.
Se for isto, um hack que alguns utilizam é o de desabilitar o módulo
de autenticação e verificação de integridade do loader, que é algo bem
arriscado. Visto que este mecanismo existe para evitar BIOS Rootkit e
ao desabilitar isto em alguns firmwares você também desabilita de
tabela o SecureBoot que também protege de Bootkits e alguns kernel
rootkits.

Mas enfim, verifique isto. Em conversa de bar, já ouvi falar de
gambiarras de BIOS com "assinatura digital" alternativa que não
quebram o SecureBoot para fazer exatamente isto que você deseja.
Habilitar um recurso de virtualização. Que também não deixa de ter
seus riscos.

[ ]s

Alberto

--
http://about.me/AlbertoFabiano

2013/3/1 gabriel <newbi...@gmail.com>:

> --
> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~---------------------------------~----------~--~----~
> [&] Colabore com a Pesquisa de Preferência de Conteúdo
> para Eventos do Grupo C & C++ Brasil:
> http://www.surveymonkey.com/s/GBBGTXN
> ------~----~-------~---~---~---~---~----------------~------------~---------~
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para
> ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> Emprego & carreira: vag...@ccppbrasil.org
> http://groups.google.com/group/dev-guys?hl=en
>

[Rodrigo Madera]

Posso ter entendido errado, mas se for código de BIOS, talvez nem rode instruções 64 no POST.

Já depurei alguns BIOS com o velho e bom debug.com, lá em 1998, na "preparatória", pra poder entrar na BIOS sem saber a senha dos computadores. Era coisa simples, bastando trocar o famoso JZ -> JNZ, ou vice versa.

Enfim, faz séculos que não vejo o dump de um firmware BIOS. Agora, só uC.

Boa sorte,

Mx

P.S. Pra mim, IDA é lei, não opção... XD

2013/3/1 Alberto Fabiano <alb...@computer.org>

[Gabriel Silva Moreira]

Sou novo no assunto também, vou começar a fuçar com BIOS agora e a chance de acabar danificando meu notebook é bem grande, esse tipo de coisa que torna o desafio mais interessante.

já tenho alguma referência, mas quero fazer em outra versão da mesma BIOS

http://marcansoft.com/blog/2009/06/enabling-intel-vt-on-the-aspire-8930g/

Enabling Intel VT

The easiest way to enable the setting as far as I can see is to dump out the entire BIOS, patch the setting into the Setup variable (which is part of the data storage section – we aren’t modifying any actual BIOS code, as this is the equivalent of changing a CMOS setting on other BIOSes), and then flash the resulting image. These laptops use a weird flash-behind-EC hardware solution for which there is no open flasher, so instead we can just use the normal BIOS flashing tool. In short, we’ll flash the existing BIOS back on, but in the process also modify a Setup setting.

...

Next, run vtenable.py. This will attempt to locate the Setup EFI variable on the non-volatile storage section and patch the VT byte to one.

...

Only two or three bytes should change: one or two adjacent bytes for the checksum (they should be decremented by one when you look at them as a 16-bit unsigned integer), and the VT enable byte should change from 00 to 01. Right after the checksum bytes you should be able to see the Setup name in UTF-16 (something like S.e.t.u.p.).

nos próximos dias vou analisar o código pra ver se eu acho onde fica o flag da virtualização AMD na minha BIOS.

[Rodrigo Madera]

Rapaz, certeza que quer brincar disso no teu notebook?

Pega um computador antigo pra isso. Um que já tenha pelo menos as "novas" tecnologias de BIOS.

Mx

2013/3/1 Gabriel Silva Moreira <newbi...@gmail.com>

Sou novo no assunto também, vou começar a fuçar com BIOS agora e a chance de acabar danificando meu notebook é bem grande, esse tipo de coisa que torna o desafio mais interessante.

[Cláudio Souza]

Pelo post do blog, dá para perceber que a parada é instável mesmo,
heim. Tem que estar com grana sobrando e muita vontade de habilitar o
VT-X!!!

Alterar BIOS sempre foi algo arriscado, desde os tempos das aventuras
on-the-fly by debug.com

Agora eu fiquei interessado é nestas conversas de boteco onde se
discute técnicas de diassembly, anti-malware, dicas para burlar
proteção de BIOS... conversa com asiático analista de malware, onde
acontece estes bate papos? rs

Sobre a lei, pelo que andei estudando, em em engenharia reversa tenho
a sensação que o Olly e o windbg hoje em dia são mais utilizados que o
próprio IDA Pro, não?

[ ]s

csz

Em 1 de março de 2013 14:30, <zht...@gmail.com> escreveu:

>
>
> On Friday, March 1, 2013 2:18:32 PM UTC-3, Rodrigo Madera wrote:
>>
>> Rapaz, certeza que quer brincar disso no teu notebook?
>>
>> Pega um computador antigo pra isso. Um que já tenha pelo menos as "novas"
>> tecnologias de BIOS.
>
>

> Não basta ter as tecnologias, tem que ter hardware, implementação e versão
> de BIOS equivalente.
>
> Vide os últimos casos da Lenovo, Toshiba e Samsung.
>
> Da mesma forma, UEFI plugin deveria ser "default", porém há plugins que
> rodam em placas ASUS e mais em nenhuma outra, por problemas de
> compatibilidade.
>
> Assim, ele pode testar num e funcionar na boa e na hora de ir para outra
> detonar totalmente.
>
> Afinal, coisa mais simples que isto que é simplesmente instalar um Linux
> onde detonando notebook Samsung por aí, justamente por melda de
> implementação de UEFI Bootloader e também do lado do Linux...
>
> [ ]s
>
> Lê

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Rodrigo Madera]

Obvio que o firmware não será compatível, né.

Mas treina a brincadeira num computador antigo, pra somente depois fazer a missão no notebook.

Bom, cada um sabe dos seus riscos.

Mas agora estou curioso. Comenta os resultados aqui, Gabriel.

Mx

2013/3/1 <zht...@gmail.com>

On Friday, March 1, 2013 2:18:32 PM UTC-3, Rodrigo Madera wrote:

Rapaz, certeza que quer brincar disso no teu notebook?

Pega um computador antigo pra isso. Um que já tenha pelo menos as "novas" tecnologias de BIOS.

Não basta ter as tecnologias, tem que ter hardware, implementação e versão de BIOS equivalente.

Vide os últimos casos da Lenovo, Toshiba e Samsung.

Da mesma forma, UEFI plugin deveria ser "default", porém há plugins que rodam em placas ASUS e mais em nenhuma outra, por problemas de compatibilidade.

Assim, ele pode testar num e funcionar na boa e na hora de ir para outra detonar totalmente.

Afinal, coisa mais simples que isto que é simplesmente instalar um Linux onde detonando notebook Samsung por aí, justamente por melda de implementação de UEFI Bootloader e também do lado do Linux...

[ ]s

Lê

 

[Lê Rodrigues]

>
> Agora eu fiquei interessado é nestas conversas de boteco onde se
> discute técnicas de diassembly, anti-malware, dicas para burlar
> proteção de BIOS... conversa com asiático analista de malware, onde
> acontece estes bate papos? rs
>

Cuidado com o que você deseja! Certamente nestas conversas o pessoal
não vai falar de futebol, carro ou das gostosas do BBB que saiu na
última playboy. Mas ainda é uma boa fuga.

> Sobre a lei, pelo que andei estudando, em em engenharia reversa tenho
> a sensação que o Olly e o windbg hoje em dia são mais utilizados que o
> próprio IDA Pro, não?
>

Tipo assim: depende, né? Afinal, pode ser engenharia reversa de ELF,
APK, ARM, MIPSel. E não dá nem para falar que se quer fazer reversa de
"código normal", como antes o pessoal falava de PE32/64, pois hoje em
dia a computação virou babel de processadores novamente, com mais
destaque para ARM/Cortex-like que Intel.

[ ]s

Lê

[Rodrigo Madera]

Estou vendo que tem escovadores de bits nesta lista, que estavam "dormentes".

E o projeto do Garoa, sai ou não sai?

Juntar o povo e vomitar estes papos com certeza parece interessante.

Mas se alguém falar de BBB, voto em expulsão imediata, em fila india.

Mx

2013/3/1 Lê Rodrigues <zht...@gmail.com>

[Cláudio Souza]

Em verdade não Mx.

A brincadeira pode ser divertida num caso e trágica no outro, óbvio
que sempre tem as lições aprendidas.

Acho que o segredo é mapear a porta de saída ou o o disco recovery
BIOS, caso algo der errado. Este é o segredo.

Era assim nos primórdios e assim ainda é.

[ ]s

csz

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Ariel Gomes]

A pergunta é: porque será que eles estavam dormindo??

[ ]s

Ari Gomes

--

"if debugging is the process of removing bugs, then programming must be the process of putting the in" 

(Edsger Dijkstra)

[Rodrigo Madera]

2013/3/1 Ariel Gomes <arie...@gmail.com>

A pergunta é: porque será que eles estavam dormindo??

Acredito que por serem mais C do que C++.

Mais opcode, do que função.

Algo que ao meu ver circula mais na 2600 do que em C++, por si.

Mx

[Cláudio Souza]

Mas a lista não é de "linguagem C" e C++?

Se o meu caso conta, eu me interessei pelo subject.

C++ gera código nativo e depende de ferramental de escovação de bits
também. E se pode fazer binary "bare metal" também com C++, assim como
é possível utilizar C++ para device drivers e kernel mode também. Se
bem que a linguagem preferida para isto é C e há que se tomar muito
cuidado em C++ para estes fins. É aquela história:

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do it blows your whole leg off". --(Bjarne Stroustrup)

>
> Mx

>
> --
> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~---------------------------------~----------~--~----~
> [&] Colabore com a Pesquisa de Preferência de Conteúdo
> para Eventos do Grupo C & C++ Brasil:
> http://www.surveymonkey.com/s/GBBGTXN
> ------~----~-------~---~---~---~---~----------------~------------~---------~
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para
> ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> Emprego & carreira: vag...@ccppbrasil.org
> http://groups.google.com/group/dev-guys?hl=en
>
> ---

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Rodrigo Madera]

Cláudio,

Sim, a lista é de C também. E aparecem assuntos C puro de vez em quando.

Acredito que todos (ou pelo menos a maioria) aqui sabemos da influência do C no C++, e especialmente das suas capacidades no mundo prático. Fica tranquilo.

Já assuntos como firmware hacking, são menos comuns, mas quando acontecem, talvez tenham maior alcance numa reunião específica, como a do Garoa, que falaram.

Eu particularmente sou adepto da 2600.org, que tem organização P2P e faz essas reuniões, mas aqui no Brasil apenas tem em Belo Horizonte. Já que a marca aqui é desconhecida, o Garoa HC me pareceu um evento similar onde podemos tratar estes bate-papos.

Happy hacking,

Mx

2013/3/1 Cláudio Souza <clo...@gmail.com>

Você está recebendo esta mensagem porque se inscreveu no grupo "ccppbrasil" dos Grupos do Google.

Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para ccppbrasil+...@googlegroups.com.

[P.]

Em sexta-feira, 1 de março de 2013 15h21min39s UTC-3, Cláudio Souza escreveu:

 

C++ gera código nativo e depende de ferramental de escovação de bits
também. E se pode fazer binary "bare metal" também com C++, assim como
é possível utilizar C++ para device drivers e kernel mode também.  Se
bem que a linguagem preferida para isto é C e há que se tomar muito
cuidado em C++ para estes fins. É aquela história:

#include <map>

#include "PowerfulStruct.h"

namespace
{
  std::map<int, PowerfulStruct *> map;
}

extern "C" int must_be_called_by_arch (int index)
{
  PowerfulStruct * x =map[index]; // reuse rules

  // do powerful stuff
}

Próximo?

--
 P.

[Cláudio Souza]

Grande Pedro Lamarão,

Fuga de mangle usando extern não era o que eu tinha em mente ;-)

[ ]s

csz

[Ariel Gomes]

2600 marca desconhecida? :-) Sei não...

Lembro de uma vez estar no Garoa e alguém comentou que participava de 2600 meetings em São Paulo desde 1997. De verdade eu não sei o nome dele, mas lembro dele ter comentado desta lista, a ccppbrasil e acho que ele é um dos sócios-fundadores do Garoa.

Mas assim, eu já participei de uns encontros no Garoa onde se falou de Python, sem ser nada muito avançado e achei legal pra caramba. Assim como já vi palestra de Ruby e Node.JS. Será que fazer algo assim de C/C++ lá não seria melhor? Mais inclusivo? 

[ ]s

Ari Gomes

[Rodrigo Madera]

2013/3/1 Ariel Gomes <arie...@gmail.com>

Lembro de uma vez estar no Garoa e alguém comentou que participava de 2600 meetings em São Paulo desde 1997.

Vou ver nas edições da época e ver se tem registro das reuniões.

Se rolaram, esqueceram de registrar como oficiais.

Mx

[Ariel Gomes]

Mx, não sei se foi isto.

Mas o Juca (presidente do Garoa) comentou que o tal tinha ido em conferência de desenvolvimento de virus em Buenos Aires em 1994, que frequentava BBS Hacker em 1992, já programava em 1988 e é um dos fundadores do Garoa. 

Não guardei o nome dele, mas não esqueci destes detalhes pois me pareceu muito surreal, afinal em 1988 ainda engatinhava  e o cara já programava e o DQ (chanceler supremo do Garoa) publicava seu primeiro livro de Assembly, no qual este cara que eu não sei o nome diz que estudou Assembly nos livros do DQ.

De qualquer forma, se eram 2600 "meetings" ele não estava sozinho, haviam outros caras com ele, este é o ponto. E possivelmente deve ter gente aqui na lista que também participou.

[ ]s

Ari Gomes

--

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
---

Você está recebendo esta mensagem porque se inscreveu no grupo "ccppbrasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para ccppbrasil+...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Rodrigo Madera]

Entendi.

Bom, será legal conhecer. Especialmente por ter "presidente", "chanceler", e tudo mais.

Será bem diferente do 2600, onde não existem tais caixas. E acredito que o Inglês nem-sempre-presente do Brasil tenha afetado a disseminação dela.

Se houver pessoal MMDC na lista, manifestem-se. Pode ser interessante manter a tradição, especialmente na capital.

Mx

2013/3/1 Ariel Gomes <arie...@gmail.com>

[Cláudio Souza]

Ari,

O histórico que você descreveu, acho que não é compartilhado por
muitas pessoas. Por alguns pontos desconfio quem seja e quem acompanha
a lista do Garoa também! Mas como é desta lista e que interagiu
inclusive nesta thread, vou esperar ele se manifestar, vai que cometo
uma gafe...

Rodrigo,

Apesar de haver estes cargos no Garoa, não o imaginei como uma
instituição quadrada. Boa parte destes cargos existem por zoeira e
alguns por necessidade legal, visto que se trata de uma associação
legalizada com CNPJ e tudo como manda os conformes.

Mas o Garoa é uma instituição semi-anarquica e muito legal,
normalmente frequentada por gente mais legal ainda e o que mais gosto
é que lá não possui a típica disputa e egos que há em alguns grupos,
lá existe grande humildade e muito conhecimento sendo o povo da chuva
gente boa pra caramba. Diferente de alguns grupos "hackings" existente
por aí com pessoas com um ego do tamanho do mundo.

[ ]s

csz

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Rodrigo Madera]

Bacana.

Assim que tiver reunião, avisem, pra conferir esses conformes.

Mx

2013/3/1 Cláudio Souza <clo...@gmail.com>

Ari,

[Gabriel Silva Moreira]

Vou dar uma estudada no assunto, mas pressa eu não tenho vou ver como esse lance de bios funciona direitinho, que a tarefa complexa.

Obrigado pelas dicas pessoal.

[Alberto Fabiano]

P.S. Pra mim, IDA é lei, não opção... XD

Acho que a pergunta do foi "disasslember freeware que funcione para x86_64" que pelo que já foi explicado, o IDA Freeware não funciona. Sendo assim, este é um exemplo onde "a lei é falha"! ;-)

Sim, foi por isto que não falei do IDA Freeware para este caso.

Aliás, depois ficar um tempo com o IDA Pro 6.1, que seja 6.2 todo bombado com vários plugins... ao usar o IDA Freeware bate até uma depressão.

[ ]s

Alberto

[Fernando Mercês]

Alberto,

Eu não entendi por que disassemblar o BIOS para x86-64. Não seria 16-bits?

Gabriel,

Como você tá extraindo o BIOS? Tem certeza que está com ele inteiro?

Abraços.

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/5 Alberto Fabiano <alb...@computer.org>

[Alberto Fabiano]

Mercês,

Simples! Estas BIOS que tem restrições de habilitação de VT-x para AMD, sendo-se que o processador tem este recurso em binary x86_64 em AMD64 e não 16bits.

Mas confessso que eu fui  extremamente otimista, pois afirmei acreditando que era este caso, pois se não for isto; o VT-x não será habilitado por uma razão simples, ele não existe neste target! ;-)

 

[ ]s

Alberto 

--

http://about.me/AlbertoFabiano

2013/3/5 Fernando Mercês <nan...@gmail.com>

[Fernando Mercês]

Mas o código do BIOS não é de 16-bits? Ainda não entendi por que disassemblá-lo em 64-bits. ;)

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/6 Alberto Fabiano <alb...@computer.org>

[Ygor da Rocha Parreira]

To caindo de paraquedas no meio da thread, mas o meu entendimento é o mesmo que o do mercês.

Mesmo pq o processador boota em modo real neh? É o kernel que passa pro modo protegido, e dpois disso só rola VM86 ou reboot pra voltar pro modo real.

[Alberto Fabiano]

Eaê!

Jovenzinhos, esta thread virou balaio de gato! ;-) Estamos falando de coisas distintas. 

Há um clássico problema que alguns computadores com processadores AMD64, que a flag de identificação do AMD-V é desligado e a BIOS não dá suporte para se realizar um enable. Há casos onde basta se atualizar a BIOS e voalá, uma opção mágica para se realizar um enable aparece e é só ativá-lo, mas parece que este não é o caso do notebook dele.

Há alguns BIOS hacks para ativá-lo que o  Dogulas afirma ter tentado mas ele não teve sucesso. E agora ele deseja fazer a reversa desta BIOS e para isto ele solicitou recomendações de disassemblers freeware / open source.

Acontece que o IDA Freeware (5.0) não suporta o disassemler de EBC (UEFI Byte code) assim como de alguns opcodes x86_64, todos elementos de uma típica BIOS AMD64 UEFI, mostrando vários unknowns e inclusive abendando.  Problemas já corrigidos em release da versões do IDA PRO.

Desta forma, tentei poupá-lo deste momento raivoso, decepcionante e triste e indiquei  a ele o objdump com o dissy, que atende os requisitos para a diversão dele. 

Eu só queria que ele se divertisse fazendo reversa, só isto gente!

Porém, meu excesso de zelo gerou todo este efeito colateral.

Só isto gente! ;-)

[&]s++;

Alberto

--

http://about.me/AlbertoFabiano

2013/3/5 Ygor da Rocha Parreira <ygor.p...@gmail.com>

--

[Tiago Natel de Moura]

Alberto, desculpe, mas das alternativas citadas, o objdump parece ser o menos indicado. Visto ele ser feito para análise de "object binaries" (que possuem formato) e a imagem da BIOS ser um "flat binary" (only 16-bit instruction code, ate onde eu sei...).

objdump é uma péssima alternativa se o binario nao possui segmentos/seções. Nesses casos eu recomendaria o ndisasm mesmo (setando origin pra 0x00).

Outro detalhe, sei de BIOS que fazem CRC checking no boot. Então TALVEZ uma simples modificação de bits não solucione o problema (dependendo da BIOS, tornará a máquina inutilizavel...). O reverse deverá ser mais aprofundado e se tiver uma validação de checksum, vai ter que alterar esse valor tb (talvez um simples $ strings ./bios.img dê pra  descobrir isso).

Sei que pra windows, existe bastante ferramenta old-school pra analisar opções desabilitadas (e escondidas) de BIOS. Vale a pena dar uma procurada nesses fóruns de tunning de CPU (overclock). Na bio-mods tem bastante coisa interessante (até mesmo uns BIOS-EDITOR, mas eu não recomendo estas coisas hahahaha): http://www.bios-mods.com/downloads/

abraços.

--
Tiago Natel de Moura
Consultor de Segurança da Informação
http://www.linkedin.com/in/tiagonatel
http://www.secplus.com.br/
http://github.com/tiago4orion
http://code.google.com/p/bugsec

[Alberto Fabiano]

Tiago,

A opção -b binary do objdump serve para estes casos, sendo ele
amplamento indicado para exatamente este tipo de situação, onde mesmo
já utilizei para análises de bootloaders.

Sobre a questão do MIC, eu já havia comentado noutra iteração desta
mesma thread; onde no caso de BIOS UEFI assinada digitalmente não
basta apenas acertar um CRC, o problema é mais embaixo.

[ ]s

Alberto

2013/3/6 Tiago Natel de Moura <tiago...@gmail.com>:

[Alberto Fabiano]

Mercês e dmr,

Tava eu tomando um café, incomodado com o desenrolar da thread e
surgiram dois lampejos:

1) Shit! Eu cometendo aquela velha falha de convenção, de novo! Desde
o princípio da thread (uma velha falha minha) e acabei lembrando do
Linus.

2) Preciso esclarecer esta pendenga pois eu estou meio-certo e eles
também estão meio-certos e todo mundo meio-errado.

Sobre a falha de convenção:

- Para evitar todos estes tipos de questionamentos, por convenção a
um bom tempo tem se separado, BIOS é uma coisa e (U)EFI é outra, até
porque isto é fato. A EFI nasceu para substituir e superar todas as
limitações da velha e ultrapassada e vulnerável ROM BIOS.

Em resumo:

- BIOS é o velho PC Bootloader conhecido como ROM BIOS que sim,
executa em 16-bit real mode e é facilmente hackeável.

- (U)EFI é um bootloader que roda em 64bits e não fica só na ROM,
entre muitas "tantas" outras diferenças como por exemplo suportar
drivers modulares (em EFI byte code ou EBC) e suportarem plugins que
são utilizados por alguns gamers mods. E necessita de uma partição
especial, "podem ser" assinados digitalmente, tem sérias
complicações para se fazer um hacking, complicando a vida dos
Bootloaders Rootkits... apesar de haver prova de conceito de UEFI
Rootkit, mas de hiper-difícil propagação.

Com processadores 64bits com BIOS rola uma comutação de modos 64bit
para 16bits (real mode) e o boot iniciam em 16bits e só depois o
processador entra em modo x64 que gera toda uma grande latência
desnecessária. Com UEFI tudo rola em 64bits e é bem mais rápido. Este
por exemplo era um dos segredos do boot e wakeup rápido que todos
babavam nos MacBooks, visto que em notebooks a Apple foi a primeira a
fazer este change de BIOS para UEFI, enquanto a Intel criou para o
Itanium, portanto servidores e muitos nem se davam conta deste recurso
por razões óbvias de interatividade.

Quando se faz o dump de UEFI, drivers EBC vem junto e então rola um
mashup embaçado.

Porque lembrei do Linux?

Por causa de um mimi dele (tá isto é pleonasmo) comentando de EFI:
"this other Intel brain-damage" reclamando de como complicaram o que
era simples, blá, blá, blá... até que alguém afirmou que

"EFI is basically a bigger suckier BIOS"

http://kerneltrap.org/node/6884

Enfim, há muita, muita, mas muita coisa mesmo de diferente entre as
velhas plataformas de 32 e 16 bits e um bom hardware de 64 bits,
tantas que chega ser irônico certas simplificações e o UEFI é uma das
remodelagens.

PS: A partir de hoje nunca mais cometerei esta gafe de usar a
expressão BIOS (U)EFI... so sorry! ;-)

[ ]s

--
http://about.me/AlbertoFabiano

2013/3/5 Ygor da Rocha Parreira <ygor.p...@gmail.com>:

[Alberto Fabiano]

Ah!

E não é só no boot process (onde com a BIOS Convencional rola o change
de Real para Protection mode enquanto a UEFI rola todo em protection
mode) que está a diferença, o sequência de blocos de processo é outro
mas uma das diferenças significativas é a seguinte:

- A velhos ROM BIOS firmwares eram desenvolvidos em FORTH e/ou Assembly.

- UEFI firmware é desenvolvido inteiramente em C.

Aliás, uma das coisas que o Linus também implicou, afirmando que C
gera código desnecessário.

[ ]s

--
http://about.me/AlbertoFabiano

2013/3/6 Alberto Fabiano <alb...@computer.org>:

[Lê Rodrigues]

Alberto,

Você não está errado em referenciar a UEFI como BIOS UEFI ou UEFI
BIOS, isto não está errado.

Mas é verdade que acabou-se criando esta convenção para reduzir as
possibilidades de confusões, mas você não fez confusão alguma, sendo
muito preciso do começo até sua última mensagem. Achei até que você
havia cometido um deslize neste trecho:

>
> Aliás, uma das coisas que o Linus também implicou, afirmando que C
> gera código desnecessário.
>

Pois para desenvolvimento de UEFI se utiliza C e C++ e "achei" que foi
pela linguagem do tio Bjarne que o Linus implicou, além de toda a
questão do que o Linus chama de "complexidades desnecessárias"
inseriadas no Kernel para dar suporte ao boot UEFI, visto que ele
gosta de manter as coisas o mais simples (e estúpidas) possível e ele
chegou a comentar que o EFI foi uma complicação indevida da Intel.

Mas ao ver a thread vi que o Linus reclamou da linguagem C mesmo, que
maluco! O cara queria então que tudo continuasse sendo feito em
Assembly 16-bits rolando todo aquele samba do afro-descendente-doido
em Real Mode?

Oras bolas, por limitações da MBR e da ROM BIOS é possível inicializar
discos de até 2 Terabytes apenas. Já o UEFI consegue inicializar
discos de até 9,4 zetabytes. Como citado por Andy Patrizio:

http://h30565.www3.hp.com/t5/Feature-Articles/How-UEFI-Will-Change-Your-Computer-Management/ba-p/1014

Será que então teríamos que parar nos 2 TB só porque o Linux acha
estúpido ter discos maiores do que isto?

Algo que é chocante é o fato da ROM BIOS ser limitada a no máximo 1MB,
enquanto a UEFI pode utilizar até 384 MB, imagina o pessoal que antes
se matava para inserir um driver novo tendo todo este espaço agora?

Mas do que interessa, não vi imprecisão em nada do que você comentou,
muito pelo contrário.

Quanto a linguagem, sei que o C++ é mais utilizado pela Intel e C mais
pelos tradicionais desenvolvedores de BIOS firmware tipo Phoenix e
AMI, porém como ele é modular, pode haver módulos em ambas as
linguagens convivendo pacificamente. Além de ter mais campo de atuação
para programadores C++ e C, inclusive.

[Tiago Natel de Moura]

Sim Alberto, da pra usar, mas como eu disse (na minha opinião) o objdump é uma péssima alternativa pra disassembly de raw binary... Já tive algumas más experiencias com ele quando tenho um binario flat que contem instruções e data misturados.. Ndisasm possui uma opção de sync-mode, que sempre me salva.

[]'s

i4k

[Alberto Fabiano]

2013/3/6 Tiago Natel de Moura <tiago...@gmail.com>:

> Sim Alberto, da pra usar, mas como eu disse (na minha opinião) o objdump é
> uma péssima alternativa pra disassembly de raw binary... Já tive algumas más
> experiencias com ele quando tenho um binario flat que contem instruções e
> data misturados.. Ndisasm possui uma opção de sync-mode, que sempre me
> salva.
>

Bom, já tive más experiências com o WinDbg, OllyDbg e com o IDA Pro
(crash) com o objdump também; e realmente ele não é melhor
alternativa mesmo.

O Ndisasm tenho que confessar que já utilizei algumas vezes mas tenho
pouca experiência com ele.

[Mauro Risonho de Paula Assumpção]

Já foi falado sobre as tools mais conhecidas, mas achei interessante compartilhar um site, um pouco antigo, mas interessante sobre BIOS/Malware.

Não é o foco central dessa thread, mas pode ser interessante para alguém:

https://sites.google.com/site/pinczakko/home

Espero ter ajudado.

@firebitsbr

[Rodrigo Madera]

Que livro animal!

Muito bacana! Pena que não leio Russo... tem 33% de mais informações,
segundo o autor.

Mas ta valendo!

Mx

2013/3/6 Mauro Risonho de Paula Assumpção <mauro....@gmail.com>:

[Fernando Mercês]

Opa, Alberto, acho que a questão não é se é ROM BIOS, UEFI ou qualquer outra coisa. O lance é que o ROM BIOS é 16-bits (não sei se existe diferente disso pra PC) e você sugeriu disassemblers de 64-bits. É neste ponto que estou intrigado. rs

Como o i4k falou, o objdump não é indicado mesmo, até porque ele não disassembla 16-bits afaik.

Abraço

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/7 Mauro Risonho de Paula Assumpção <mauro....@gmail.com>

[Alberto Fabiano]

Oi Mercês,

Este é o ponto, sim há "BIOS" de 64bits, utilizada em computadores com
processador de 64bits como o de AMD64 do Gabriel, que são UEFI; este é
o ponto.

Assim temos BIOS de:

a) 16bits (real mode) - convencionais existentes a mais de 30 anos,
basicamente é um firmware. Aposentada, mas que ainda fará hora extra
por muito tempo em processadores de 32 bits e nos legados. E tem
tamanho restrito até 1MB, monolítico, fácil, fácil de se fazer
reversa. até porque ela é bem enxuta. Como ela é programado em
assembly fica bem mais fácil de entender seu fluxo de execução.

b) 64bits (modo protegido)- que seguem o padrão EFI (de 1999 para cá)
ou (U)EFI (de 2007 para cá) basicamente é um EOS que executa em
paralelo com o OS em execução, sendo mais adequadas para processadores
de 64bits, como o AMD64 do Gabriel que abriu a thread. Onde o
front-end de gerenciamento pode ter suporte a mouse, gráficos
bonitinhos e é mais complicado para se fazer reversa por uma série de
fatores. Onde até pouco tempo atrás um dos complicadores era até a
falta de disassembler para 64bits com suporte total aos opcodes deste,
mesmo mal que dificultava também a análise de malwares de 64bits.

c) 32bits (modo protegido) - que segue o padrão UEFI mas é utilizado
em processadores de 32bits, ele pode parecer um estranho no ninho, mas
ele tem o propósito de oferecer os mecanismos de proteção e aplicar os
padrões do TCG de para Trusted Computing, já existente em alguns
computadores com processades de 64bits, em computadores de 32 bits.

A diferença entre a BIOS de 16bits e a de 64bits (e 32bits) é
gritante, um é monolítico o outro é modular, tem fluxo de execução,
arquitetura, capacidade, modo de carga, desenvolvimento e entre muitas
diferenças o que você bem colocou quanto ao modo desenvolvimento além
de proteção contra algumas ameaças.

Mauro,

Este livro é totalmente relevante!

Ele é muito bom, eu o estudei uns 6 anos atrás e tem umas técnicas bem
legais. Apesar de ser um livro de quase 7 anos atrás e algumas
mudanças significativas ocorreram neste período, como a nova versão do
padrão UEFI com esquemas de criptografia, proteção extra da própria
carga, autenticação de rede entre algumas mudanças bem interessantes e
significativas do ponto de vista de engenharia reversa, até porque
alguns empregam ofuscação de código justamente para dificultar o
desenvolvimento de rootkits, coisa que nem se sonhavam em fazer antes.

Algo que achei curioso é o agradecimento ao Kris Kaspersky, pois
noutra thread houve menção ao livro dele, o Code Optimization. Este
russo é muito gente fina e bem maluco, tendo vários livros
interessantes.

Porém, ele ficou muito famoso quando apresentou uma pesquisa de
malwares que mostrou como alguns artefatos maliciosos estavam
empregando falhas dos processadores Intel. Muitas deles muito bem
documentado nas erratas da Intel destinado aos desenvolvedores de
firmware (BIOS) outros era opcodes não documentaos que possuiam falha
de elevação de privilégio.

O curioso é que muitos analisaram os mesmos malwares que ele, mas o
que muitos acreditavam ser junk code, ele foi lá mapeou testou e foi
descobrindo o que de fato era. Por um lado, este é o típico trabalho
que dificilmente é realizado no research team de empresa de
anti-malware por ser extremamente meticuloso. Quando ele o fez ele era
meio que freelancer, consultor independente. Hoje ele trabalha na
McAfee, obviamente usando seu nome veradeiro que não é este, mas desde
que ele entrou lá tem mais publicado pesquisas interessantes como ele
fez no passado.

Lê,

Sobre a questão do nome, ela é meio complicada mesmo. Neste guideline:

BIOS Protection Guidelines
http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf

Em alguns pontos não há muita distinção, ele aborda ambos os casos, se
você não estiver "ligado" a leitura pode até ficar meio confusa.

Por outro lado, algo que gostei quando eu o li pela primeira vez logo
que ele foi lançado em 2011, são alguns fluxos de execução de ambos,
que esté bem legal e fácil de entender como a diferença é gigante no
modo de funcionamento.

Sobre a diferença de capacidade de discos, basta dizer que da BIOS
convencional a MBR suporte até 2 TiB (2^40 bytes) e na EFI o GPT
(substituto da MBR) permite 8 ZiB (2^70 bytes).

Mas isto é só a ponta do iceberg das diferenças.

[&]s++;


Alberto Fabiano


2013/3/6 Fernando Mercês <nan...@gmail.com>:

[Fernando Mercês]

Ok mas só porque o processador é de 64bits, o BIOS também precisa ser? Pergunto pois nunca vi um ROM BIOS de 64-bits e já vi vários de 16-bits trabalhando normalmente com processadores de 32-bits. Não consigo enxergar esta dependência do código do BIOS ter de ser do tamanho da palavra. :(

Abraço!

Att,

Fernando

[Augusto Lenz]

Eaí,

Depois de acompanhar de longe todo esse papo, uma pergunta tosca: em
um sistema AMD64 com UEFI, onde ocorre o chaveamento do modo real para
o modo protegido?
Ou nem tem mais modo real?

Augusto L. Lenz

2013/3/6 Fernando Mercês <nan...@gmail.com>:

[Ygor da Rocha Parreira]

Até onde eu sei, o ISA e modos de operação do AMD64 é o mesmo do EM64T da Intel, e sendo assim quem faz o chaveamento é o sistema operacional dpois do boot loader [1].

Nesse esquema de EFI (nunca mexi com EFI) eu não sei como funciona, mas uma coisa que me encuca é o seguinte: Depois que o processador sai do modo real ele só volta para este modo por meio de um reset, então como o EFI faz essa mágica de rodar código de 64 bits em modo real?

Outro ponto é que em cima do Intel EM64T, não existe modo x64, mas sim IA-32e (que é o modo de 64 bits).

[1] - http://duartes.org/gustavo/blog/post/kernel-boot-process

[Ygor da Rocha Parreira]

O unico limite que conheço sobre isso está relacionado a BIOS utilizar MBR, onde vc acaba tendo limitação de tamanho de disco (2 ^ 32 blocos * 512 = o que da 2.2 tera). De resto acho que não tem problema.

[Fernando Mercês]

E por sinal no MBR normalmente há outro código de 16-bits. Também não entendo como rodar código de 64-bits sem SO.

Abraços.

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/7 Ygor da Rocha Parreira <ygor.p...@gmail.com>

[Augusto Lenz]

Bom rodar código 64 bits sem SO, eu não vejo problema algum... o que
eu não sabia é que era possível (nem sei se realmente é) sair rodando
direto em 64. Eu achei que teria um código inicial em 16 bits que
faria a alteração no modo de operação.

http://en.wikipedia.org/wiki/X86-64#Operating_modes

Augusto L. Lenz

2013/3/6 Fernando Mercês <nan...@gmail.com>:

[Fernando Mercês]

Augusto, foi o que eu quis dizer. Sem SO [para fazer o switch]. hehe

Abs

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/7 Augusto Lenz <august...@gmail.com>

[Ygor da Rocha Parreira]

Minha dúvida nem é sobre como fazer switch sem o S.O., mas sim como o cara volta pra 16 bits pra passar a bola pro sistema operacional sem dar um reset.

[Felipe Magno de Almeida]

2013/3/6 Ygor da Rocha Parreira <ygor.p...@gmail.com>:

>
> Minha dúvida nem é sobre como fazer switch sem o S.O., mas sim como o cara
> volta pra 16 bits pra passar a bola pro sistema operacional sem dar um
> reset.

Você seta a flag de modo protegido para zero. Isso é comum no próprio
bootloader,
entrar e sair do modo protegido.

[]'s
--
Felipe Magno de Almeida

[Alberto Fabiano]

Augusto,

Se entendi sua pergunta, o processo de "pré-arranque" em UEFI já
começa em modo protegido e em long mode, portanto acessando toda a
memória de endereçamento e ainda em multi-thread carregando drivers de
inicialização de hardware de forma paralelizada e não em modo
sequencial como é numa BIOS convencional de 16bits, sendo algumas das
coisinhas que faz um boot UEFI assim como um wakeup ser muito rápido.

O real mode ainda existe, mas não para limitar o processo de boot! ;-)

Mercês,

Sim, um processador com "arquitetura de 64 bits" pode usar uma BIOS
convencional de 16bits, monolítica, com limite de 1Mb de memória e
single-thread. O computador terá muitas limitações que vai além das
relacionadas a SVM, RVI, mas funcionaria para alegria dos rootkits.

Simplificando ao máximo:

- Na evolução dos processadores de "arquitetura x86" (16 bits) para
x86-32 (32 bits), como de x86-32 para IA64 e x86-64 (64 bits) as
mudanças mais notáveis foram de arquitetura e recursos computacionais
e não apenas de tamanho de palavras.

- Os firmwares PC System BIOS foram evoluindo com o passar do tempo,
mas ainda estavam restritos a limites definidos em 1981 que já estavam
sendo impactantes desde a mudança de microarquitetura P5 para P6,
forçando os firmware developers a arrancar leite de pedra para
conseguir inserir o suporte a novos padrões de hardware. Quando a
Intel começou a projetar o IA64 perceberam que aquele era um bom
momento para se projetar um novo padrão de Sytem BIOS e parar de
sacrificar a evolução computacional, criando assim a EFI e a AMD o
acabou seguindo para o AMD64 (x86-64).

- E o EFI tornou-se UEFI, foi evoluindo ganhando recursos importantes.
Mas a maioria dos processadores x86-64 (até onde sei) empregam este
linha de de System BIOS, que são de 64bits. Simples, assim.

Não é uma questão de tamanho de palavra.

[ ]s

Alberto Fabiano

2013/3/6 Augusto Lenz <august...@gmail.com>:

[Rodrigo 'Skhaz' Delduca]

Senhores, gostaria de dizer que esta discussão está muito
interessante, estou aprendendo *muito* com ela

2013/3/6 Alberto Fabiano <alb...@computer.org>:

http://nullonerror.org/
-- flipping bits whilst updating pixels

[Rodrigo Madera]

2013/3/6 Rodrigo 'Skhaz' Delduca <rodrigo...@gmail.com>

Senhores, gostaria de dizer que esta discussão está muito
interessante, estou aprendendo *muito* com ela

Idem.

Agora quero uma palestra de BIOS rootkits por alguém aqui da lista! =P

Mx

[Ygor da Rocha Parreira]

Opa,

Realmente checando aqui no manual da Intel vi que rola mesmo, flag PE do CR0, e também encontrei o texto que me confundiu:

"The processor is placed in real-address mode following power-up or a reset.", o que me vez entender que somente nestas duas condições (ligar a máquina ou reset) se entra em modo real. Alias, acho que já li isso também em algum livro de S.O. e/ou de arquitetura. Vou checar...

[Ygor da Rocha Parreira]

Haha,

Manda mail pro opcode (Edgar Barbosa) pedindo, afinal, foi ele quem realmente fez o Blue Pill :)

--

[Cláudio Souza]

Em 7 de março de 2013 00:04, Rodrigo Madera <rodrigo...@gmail.com> escreveu:

Aleph e Opcode, são os dois caras que já trombei que mais conhecem de
Boot Rootkit.

Um dia que eu estava no Garoa passei umas duas horas conversando (acho
que aprendendo) sobre rootkits e a sensação que tive é que o Aleph se
masturba por fazendo engenharia reversa de malwares com paixão
especial por rootkits.

> --
> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~---------------------------------~----------~--~----~
> [&] Colabore com a Pesquisa de Preferência de Conteúdo
> para Eventos do Grupo C & C++ Brasil:
> http://www.surveymonkey.com/s/GBBGTXN
> ------~----~-------~---~---~---~---~----------------~------------~---------~
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para
> ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> Emprego & carreira: vag...@ccppbrasil.org
> http://groups.google.com/group/dev-guys?hl=en
>
> ---

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Cláudio Souza]

Em 7 de março de 2013 00:14, Ygor da Rocha Parreira
<ygor.p...@gmail.com> escreveu:

>
> Haha,
>
> Manda mail pro opcode (Edgar Barbosa) pedindo, afinal, foi ele quem
> realmente fez o Blue Pill :)
>

Hahahah

Opcode 2 x 1 Aleph! ;-)

Mas o Aleph serve para uma introdução superficial de 36 hs falando sem parar...

> Você recebeu esta mensagem porque está inscrito em um tópico do grupo

> "ccppbrasil" dos Grupos do Google.

> Para cancelar a inscrição neste tópico, acesse
> https://groups.google.com/d/topic/ccppbrasil/ygdXjh4NNY8/unsubscribe?hl=pt-BR.
> Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um

[Alberto Fabiano]

2013/3/7 Cláudio Souza <clo...@gmail.com>:

> Em 7 de março de 2013 00:14, Ygor da Rocha Parreira
> <ygor.p...@gmail.com> escreveu:
>>
>> Haha,
>>
>> Manda mail pro opcode (Edgar Barbosa) pedindo, afinal, foi ele quem
>> realmente fez o Blue Pill :)
>>
>
> Hahahah
>
> Opcode 2 x 1 Aleph! ;-)
>
> Mas o Aleph serve para uma introdução superficial de 36 hs falando sem parar...
>

Vou considerar este comentário um elogio ;-/

Mas o Opcode é uma opção mais qualificada.

[ ]s

[Tiago Natel de Moura]

E não é que vale a pena aturar as viadices teóricas de C++ dessa lista hahahaha Por essas poucas threads low-level que ainda estou por aqui.

[]'s

i4k

--
--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
              para Eventos do Grupo C & C++ Brasil:
                        http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

---
Você está recebendo esta mensagem porque se inscreveu no grupo "ccppbrasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para ccppbrasil+...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

[Fernando Mercês]

Bom, então vou continuar.. hehehe

Por exemplo, aqui, Alberto. Tenho um Dell aqui com CPU de 64-bits. Se liga:

~$ cat /proc/cpuinfo 

processor : 0

vendor_id : GenuineIntel

cpu family : 6

model : 42

model name : Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz

---

$ sudo dd if=/dev/mem of=bios bs=1 skip=$((0x8000)) count=$((0x8148-0x8000))

328+0 records in

328+0 records out

328 bytes (328 B) copied, 0.00472525 s, 69.4 kB/s

---

$ objdump -b binary -M intel -m i386 -D bios 

bios:     file format binary

Disassembly of section .data:

00000000 <.data>:

   0: 52                   push   edx

   1: 56                   push   esi

   2: be 1b 81 e8 39       mov    esi,0x39e8811b

   7: 01 5e bf             add    DWORD PTR [esi-0x41],ebx

   a: f4                   hlt    

   b: 81 66 8b 2d 83 7d 08 and    DWORD PTR [esi-0x75],0x87d832d

  12: 00 0f                 add    BYTE PTR [edi],cl

  14: 84 e2                 test   dl,ah

  16: 00 80 7c ff 00 74     add    BYTE PTR [eax+0x7400ff7c],al

  1c: 46                   inc    esi

  1d: 66 8b 1d 66 8b 4d 04 mov    bx,WORD PTR ds:0x44d8b66

  24: 66 31 c0             xor    ax,ax

  27: b0 7f                 mov    al,0x7f

  29: 39 45 08             cmp    DWORD PTR [ebp+0x8],eax

  2c: 7f 03                 jg     0x31

  2e: 8b 45 08             mov    eax,DWORD PTR [ebp+0x8]

  31: 29 45 08             sub    DWORD PTR [ebp+0x8],eax

  34: 66 01 05 66 83 55 04 add    WORD PTR ds:0x4558366,ax

  3b: 00 c7                 add    bh,al

  3d: 04 10                 add    al,0x10

  3f: 00 89 44 02 66 89     add    BYTE PTR [ecx-0x7699fdbc],cl

  45: 5c                   pop    esp

  46: 08 66 89             or     BYTE PTR [esi-0x77],ah

  49: 4c                   dec    esp

  4a: 0c c7                 or     al,0xc7

  4c: 44                   inc    esp

  4d: 06                   push   es

  4e: 00 70 50             add    BYTE PTR [eax+0x50],dh

  51: c7 44 04 00 00 b4 42 mov    DWORD PTR [esp+eax*1+0x0],0xcd42b400

  58: cd 

  59: 13 0f                 adc    ecx,DWORD PTR [edi]

  5b: 82                   (bad)  

---

Dá uma olhada no offset 0x5b. Isso prova que não é código de 32-bits e sim de 16-bits. Com um olhar clínico vemos em 0x58 a famosa INT 0x13, mas não está sendo reconhecida como tal porque estou disassemblando em 32-bits (já que o objdump não disassembla em 64-bits).

Abraço.

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/7 Tiago Natel de Moura <tiago...@gmail.com>

[Fernando Mercês]

Ops, falei errado no final. A frase certa é:

já que o objdump não disassembla em 16-bits

16-bits, não 64.

abs

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/7 Fernando Mercês <nan...@gmail.com>

[Augusto Lenz]

Alberto Fabiano,

Resumindo a essência da minha pergunta: um processador 64 bits, já sai
rodando em 64 bits desde o power-up? Ou começa em algum modo de
compatibilidade (em 16 bits) e em algum estágio inicial do boot muda
pra 64?

Aproveitando... é possível sair no modo protegido sem um reset?

Estou precisando atualizar meus conhecimentos... estou estacionado nos
16 bits. Hehe.

Agradecido pelos esclarecimentos.

Augusto

2013/3/7 Fernando Mercês <nan...@gmail.com>:

[Ygor da Rocha Parreira]

Fala Augusto,

Sobre a primeira pergunta, o computador inicia em real-address mode.

Sobre a segunda, realmente da pra voltar pra real-address mode sem um reset, vide 9.9.2 Switching Back to Real-Address Mode:

=> http://download.intel.com/products/processor/manual/325384.pdf

No item acima do manual te fala sobre passar de real-address mode para modo protegido (IA-32, 32 bits). O comum é o sistema operacional entrar em modo Virtual-86 mode (a.k.a. VM86) pra rodar código de 16 bits, pois assim ele preserva os esquemas de proteção e mantem o ambiente multitask.

[Fernando Gomes]

Em 7 de março de 2013 02:19, Fernando Mercês <nan...@gmail.com> escreveu:
> Ops, falei errado no final. A frase certa é:
>

não foi só a escrita que foi errada...

[Ygor da Rocha Parreira]

??

[Alberto Fabiano]

Mercês, estou sempre empregando o termo "maioria" pois sei que não são todos.

[ ]s
--
Sent from my mobile, excuse-me my fingers.

2013/3/7 Fernando Mercês <nan...@gmail.com>:

[Ygor da Rocha Parreira]

Opa,

Tem algumas coisas que ainda não estão claras in my head, e como não to com tempo pra pesquisar mais a fundo, lanço os pontos aqui.

1 - Vi numa apresentação dum tal de John da NGSS (a NGSS era foda na época do Chris Anley e Litchfield), sobre UEFI Hacking - apresentado na Black Hat. O cara fala que o código do UEFI eh bytecode, logo concluímos que temos uma VMM interpretando isso (e parece que também vi isso escrito pelo Alberto Fabiano nesta thread);

2 - Vi também em diversos lugares que nego programa essas UEFI em C;

3 - Pelo manual da Intel, o sistema boota com o processador em real-address mode.

Dentro disso, concluo:

A - Se a poha do código do UEFI é bytecode, perde o sentido discutir qual modo de operação do código, pois ele nem chega a ser código nativo. O que teríamos que discutir é sobre o código da VMM que executa estes bytecodes.

B - Assumindo o FATO do processador iniciar em real-address mode, aomenos parte do código dessa VMM teria que ser em 16 bits. Se é misto com código de 64 bits ou não, isso já é outra história. E se ele muda pra 64 bits, depois tem que voltar pra 16 bits pra passar a bola para o loader do S.O.

Agora a pergunta de 1 milhão de dólares: Respondendo o ponto B acima, qual a sequencia de ações executada pela VMM do código UEFI?

[Fernando Mercês]

entao, se o dele for de 64bits nada do que falei adianta ne? rs

bem, acho q falta agora o augusto dizer se o bios dele eh 16 ou 64bits (uefi de repente), ai a gente pode ajudar mais.

mas queria aproveitar pra deixar uma coisa clara aqui gente... este eh um campo de estudo onde conheco muito pouco e varios aqui julgo que conhecem bastante. Nao estamos tentanto "pegar um ao outro", estamos apenas discutindo e entendo/aprendendo coisas. Na verdade pouco importa QUEM esta certo ou errado mas sim QUAL informacao eh certa ou nao.

eu tava o tempo todo falando de bios 16bits e o alberto de 64 (q eu nem sabia que existia). Acho que foi essa a confusao. No final das contas, tudo o que ele falou eh valido pra 64 e tudo o que eu falei, acho, eh valido pra 16.

Peço desculpas ao Alberto, Ygor e Augusto por parecer que eu quero aparecer ou saber mais que alguem o provar que alguem esta errado. Essa nunca foi minha indole. Eu to aqui para aprender, nao para aparecer.

Abraços.

Att,

Fernando

[Ygor da Rocha Parreira]

Fala Merces,

Poha mermão, larga de ser viado. Se continuar com essa viadagem vou parar de andar com vc hemm. Todo mundo aqui é homem, e nenhum dessa merda de geração Y sentimental do caralho. Meu carater foi cunhado a bala assistindo filmes de westerns, então pode parar com essa merda de viadagem.

Eu mesmo aprendi coisa aqui que achava que já sabia, e tudo numa boa. E o massa dessa thread foi que fomentou diversas dúvidas in my head, que se ninguem aqui responder, dpois eu vou research e done.

[s];

[Alberto Fabiano]

Salve Folks!

Mercês, tô relax, mega-confortável com a discussão! Tanto que, tive
um dia corrida e noite também e eu estava ansioso para responder tais
questionamentos eu só estava sem tempo durante o dia e noite! ;-)

Prezo muito o debate de idéias e não ligo para firulas e se estou
errado, sem crise. Faz parte. Errar faz parte.

Sobre o assunto, um fato que é bom ressaltar é que uma coisa é a spec,
outra coisa são as implementações reais e as customizações dos OEM
(montadores e fabricantes de hardware) e que depende de cada OEM a
adoção do UEFI, onde até 3 anos atrás alguns só enxergam o benefício
de aumento da capacidade de barramento e endereçamento portanto alguns
o utilizarou apenas em servidores, já outros como a Apple, MSI,
AsusRock, HP, IBM, Lenovo, Samsung e Sony já o utilizam em notebooks,
servers, desktop e tablets a algum tempo.

E o mais importante, há customização do OEM, que pode fazer uma caca
fenomenal ou fazer uma obra de arte como a Apple e a HP tem feito.

Ygor,

Tentarei ser o mais breve possível! ;-))

O processo de inicialização UEFI tem vários estágios, na realidade 5
in-life execution e 2 "after", que é inclusive chamada de AF Phase ou
AFter Life Phase.

SEC -> PEI -> DXE -> BDS -> TSL -> OS Load Start (AF / RTP) OS Load

Uma boa curiosidade é o AF (AFter Life) Phase que foi definido para se
tentar identificar crashs de carga de sistema operacional e se criar
ações de recovery do próprio sistema, fazendo uso inclusive de
serviços com conectividade. Pois é, no UEFI pode existir IPSec e SSL,
além de autenticação com certificado digital.

O (U)EFI foi projetado para ser executado a maior parte do tempo em
modo protegido (64 bits) onde o primeiro módulo dele, chamado de SEC
Phase, é inicializado em "real mode" e já chaveia para modo protegido,
onde todos os outros módulos dele são executados e modo protegido até
chegar no(s) loader(s).

Quando o SO é UEFI compatível ele não tem passagem em modo real, a
carga do OS é em modo protegido, onde via a RT (Run Time) Phase ele
pode inclusive interagir com o ambiente e serviços pré-inicializados
na PEI Phase, de pré-inicialização.

Mas por compatibilidade há a carga via OS Legacy Loader, que neste
modo ele chaveia para real mode e faz carga de qualquer OS legado.

Porém, o modo recomendado de operação dele é no modo UEFI OS Loader,
que quando devidamente implementado oferece o UEFI Secure Boot.

Vale lembrar que a OEM adapta o UEFI e pode colocar uma opção para
aque o usuário decida se o computador fará carga de OS Legacy, ou não.
Onde apenas os UEFI compatíveis são inicializados.

E segue comentários e tentativas de complementos e respostas para suas
considerações:

> 1 - Vi numa apresentação dum tal de John da NGSS (a NGSS era foda na época
> do Chris Anley e Litchfield), sobre UEFI Hacking - apresentado na Black Hat.
> O cara fala que o código do UEFI eh bytecode, logo concluímos que temos uma
> VMM interpretando isso (e parece que também vi isso escrito pelo Alberto
> Fabiano nesta thread);

Mais ou menos, drivers, services e plugins "podem ser" em EBC, EFI
Byte Code, nem tudo roda na EBC VM. Em verdade há um grande mix onde
na SEC Phase se começa em real mode e logo se vai para big-real mode
se faz algumas verificações de integridade e se chaveia para modo
protegido de "32 bits" passa a execução para uma fase chamada de
"Pre-EFI Initialization" (PEI) Phase, que então chaveia para 64 bits e
ativa o long mode e se faz parte da mágica do boot speedup. E neste
modo começa a carga de drivers de inicialização pela EFI Byte Code
Virtual Machine ou EBC VM.

Na sequência há o DXE (Driver eXecution Environment) Phase onde são
carregados drivers de hardware em EBC que podem ser todos em 64 bits e
assinados digitalmente.

Quer saber o mais sinistro de tudo? Se o sistema operacional for UEFI
compatível, pelo que é chamado de RT (Run Time) Phase, já com o
sistema operacional em carga ou carregado ele consegue entre muitas
coisas saber quais drivers tiveram problema de inicialização por falha
de assinatura digital ou por outros motivos, entre outras coisas, como
por exemplo ter informações de plugins que tinham serviço de
conectividade e que fizeram alguma conexão via IPSec ou SSL na UEFI PI
(Platform Initialization)

> 2 - Vi também em diversos lugares que nego programa essas UEFI em C;

Aqui tem a pegadinha do malandro! ;-)

Drivers, services e plugins são desenvolvidos em linguagem C mas
compilados para EBC, isto é EFI Byte Code! ;-) Gerados pelo Intel C
Compiler for EFI Byte Code.

> 3 - Pelo manual da Intel, o sistema boota com o processador em real-address
> mode.
>

Sim, na SEC Phase. Mas como comentei ele logo já cheveia para modo
protegido, 32 ou 64 bits dependendo da versão e implementação.

> Dentro disso, concluo:
>
> A - Se a poha do código do UEFI é bytecode, perde o sentido discutir qual
> modo de operação do código, pois ele nem chega a ser código nativo. O que
> teríamos que discutir é sobre o código da VMM que executa estes bytecodes.

Pois é, apesar deste byte code ser bem próximo do código nativo, ele
de fato não é.

E parte desta EBC VM pode ser 32 bits (na PI Phase) e parte 64 bits e
tudo em 64 bits na DXE Phase, se for uma UEFI de 64 bits. Pois para
complicar mais, foi criado a pouco tempo a UEFI de 32 bits que tem
sido utilizado por tablets e netbooks.

O EBC foi desenvolvida para ser agnóstica mais o mais simples
possível, o mais próximo de código de máquina, mas é byte code.

Mas do ponto de engenharia reversa, vale a pena comentar que o IDA Pro
já tem suporte a decodificação de EBC, tanto que eu já analisei
(confesso que não entendi muita coisa) a UEFI de um notebook HP
EliteBook que eu tinha (furtado em Buenos Aires) e era possível
identificar alguns drivers e código deles, que é bem simples de
entender.

> B - Assumindo o FATO do processador iniciar em real-address mode, aomenos
> parte do código dessa VMM teria que ser em 16 bits. Se é misto com código de
> 64 bits ou não, isso já é outra história. E se ele muda pra 64 bits, depois
> tem que voltar pra 16 bits pra passar a bola para o loader do S.O.
>

O momento que ele roda em real mode é um curto período na SEC Phase
(em tese pois depende de implementações este período pode não ser tão
curto) e "talvez" na TSL (Transient System Load) Phase para carga de
Sistemas Operacionais Legados, não UEFI OS Loader compliance.

Caso o modo de operação de suporte a carga de sistemas legados estar
desabilitado, é só no SEC que há execução em 16 bits, mas na realidade
em "big-real mode"

Em fato, a carga em de OS legado, quebra todo um esquema de proteção e
verificação de integridade, os impactos deste modo são muito grandes.

> Agora a pergunta de 1 milhão de dólares: Respondendo o ponto B acima, qual a
> sequencia de ações executada pela VMM do código UEFI?
>

Lembrando da sequência:

SEC -> PEI -> DXE -> BDS -> TSL -> OS Load Start (AF / RTP) OS Load

Que na realidade é bem mais complexo que isto por ter certas
interações e rollbacks.

A EBC VM está na PEI e na DXE, sendo utilizado para carregar drivers
de pré-inicialização, device drivers e services desenvolvidos
inclusive para interagir ou preparar algo para RT Phase ou AF Phase,
que já é na carga do Sistema Operacional, sendo parte de uma
estratégia de boot speedup ou serviços server ou cliente de manutenção
remota via IPSec, que vai da criatividade do desenvolvedor! ;-)

E vale lembrar que, este é um universo novo e em evolução, pois a todo
ano surgem tanto novas especificações. E se antes era algo mais
restrito a quem deseja oferecer mais capacidade a servidores ou early
adopters como a Apple, ele tende a dominar o mercado por causa da
estratégia de Secure Boot do Windows 8, que não restringe-se só a
controle de integridade, que também utiliza-se de outros recursos
disponíveis da UEFI.

[ ]s


2013/3/7 Fernando Mercês <nan...@gmail.com>:

[Alberto Fabiano]

2013/3/7 Ygor da Rocha Parreira <ygor.p...@gmail.com>

Fala Merces,

Poha mermão, larga de ser viado. Se continuar com essa viadagem vou parar de andar com vc hemm. Todo mundo aqui é homem, e nenhum dessa merda de geração Y sentimental do caralho. Meu carater foi cunhado a bala assistindo filmes de westerns, então pode parar com essa merda de viadagem.

Eu mesmo aprendi coisa aqui que achava que já sabia, e tudo numa boa. E o massa dessa thread foi que fomentou diversas dúvidas in my head, que se ninguem aqui responder, dpois eu vou research e done.

Ygor, acho que há um potencial vetor de research na exploração de más implementações, pois algumas OEM cometaram algumas falhas de customização para interação com OS Loader, gerando crashs malditos. 

Agora se eles falharam nisto, no que mais eles falharam?  ;-P

[Fernando Mercês]

Bom, eu postei um pedido de desculpas porque cada um interpreta o email de um jeito. Apesar de achar que estamos numa lista técnica e o que deve ser levado em consideração aqui são os assuntos técnicos (e não sociais, políticos ou afins), mesmo assim prefiro evitar qualquer tipo de confusão.

Para mim tá ok a parte do BIOS ser ou não de 16-bits. O meu aqui é (eu acho). E tem gente que não é. Resolvido.

Abraços.

Att,

Fernando Mercês
Linux Registered User #432779
www.mentebinaria.com.br
------------------------------------
"Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade de mudança é preciso mudar". (Elliot Gould)

2013/3/8 Alberto Fabiano <alb...@computer.org>

[Alberto Fabiano]

Relax Mano! ;-)

Do meu lado tá limpo.

Eu fiquei pensando aqui seria uma numa atividade de hands-on bem psicodélica com UEFI plugin development, que seja utilizando as implementações do VirtualBox ou da VMWare, empregando o C Compiler for EBC e depois fazendo a reversa com o IDA Pro.

Mas haja software proprietário para fazer esta parada... 

[ ]s

2013/3/8 Fernando Mercês <nan...@gmail.com>

[Augusto Lenz]

Beleza.

Na verdade não estou "mexendo" com nada relacionado a isto, minha
pergunta foi por mera curiosidade.

De qualquer forma, minha dúvida foi respondida.

Valeu Alberto Fabiano, Merces e cia.

2013/3/8 Alberto Fabiano <alb...@computer.org>:

[Ygor da Rocha Parreira]

Esclarecido, obrigado.

E viva a dialética da amizade!

[s];

[Cleiton Alves]

Merces quando comeca a pedir desculpas para todo mundo eh porque ja bebeu pra caramba e esta  carente,precisando de carinho.

[Ariel Gomes]

Escovadores de bit de boa vontade,

Esta thread está fascinante! ;-)

[2] Parabéns pela dialética da amizade

É louco ver que Alberto acabou revelando para muitos (inclusive para mim) novas oportunidades para programadores C, eu não tinha idéia que era possível desenvolver plugins para BIOS.

Comecei a googlar um pouco sobre o assunte nestes links que acho que pode ajudar a esclarecer mais, e sem querer duvidar acaba confirmando quase tudo que o Alberto comentou:

http://resources.infosecinstitute.com/uefi-and-tpm-2/

Que aliás, acho que já vi o Alberto (Aleph) falando de TPM e TCG e componentes eletrônicos seguros noutro momento, pelo jeito hardware design seguro é especialidade dele.

Outro fato fascinante é de que o comentado por aí do tal UEFI Secure Boot é muito superficial, não dá para imaginar todo este universo comentado aqui e que compreende estes novos paragimas de  BIOS, no final percebemos que a Microsoft não está sendo "vilã" como muitos comentam.

 Eu fico imaginando como o Linus deve ter ficado revoltado, pois tratar tudo isto no kernel deve dar muito trampo mesmo, porém é a evolução, tinha que ser feito mesmo.

Ygor,

Seria esta a apresentação que você comentou da NGSS? Se não for é algo que diante de tudo o que já foi comentado aqui, depois da overdose de informação gerada pelo Alberto, ajuda a esclarecer bastante:

https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf

Percebi que algo que o Alberto chamou de AF Phase nesta apresentação chama-se AL Phase, porém aqui neste outra página também é chamado de AF:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=PI_Boot_Flow 

Vocês sabem dizer o porque desta dualidade? Houve mudança de nome durante a evolução das specs?

Pelos slides vi que há este framework open source de UEFI BIOS que é da Intel:

http://sourceforge.net/projects/tianocore/

E na wiki dele, como já citado no caso do AL vs AF Phase, tem muito disto que foi comentado aqui e muita informação importante, que complementa o conteúdo desta thread.

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-firmware-implementation-paper.pdf

http://www.uefi.org/events/EBC_Compiler_Presentation.pdf

De qualquer forma, estou apenas compartilhando um pouco do que pesquisei nestes dias.

Parabéns pessoal pela condução da thread, pela quantidade de informação útil, principalmente pela maturidade, pois por menos já vi gente brigando em outras listas e aqui tudo foi conduzido com a maior civilidade digna de pessoas maduras, mostrando que homens de verdade conversam e não ficam dando porrada um no outro.

[ ]s

Ari

[s];

--

"if debugging is the process of removing bugs, then programming must be the process of putting the in" 

(Edsger Dijkstra)

[Ariel Gomes]

Em 8 de março de 2013 11:32, Cleiton Alves <cleito...@gmail.com> escreveu:

Merces quando comeca a pedir desculpas para todo mundo eh porque ja bebeu pra caramba e esta  carente,precisando de carinho.

Papo estranho, maluco. E pelo jeito o Alberto (Aleph) Void Techberto quando fica bêbado só pensa em engenharia reversa e em como hackear o mundo! rs

--

[Fernando Gomes]

Em 8 de março de 2013 03:26, Alberto Fabiano <alb...@computer.org> escreveu:
>
>
> 2013/3/7 Ygor da Rocha Parreira <ygor.p...@gmail.com>
>>
>>
>> Fala Merces,
>>
>> Poha mermão, larga de ser viado. Se continuar com essa viadagem vou parar
>> de andar com vc hemm. Todo mundo aqui é homem, e nenhum dessa merda de
>> geração Y sentimental do caralho. Meu carater foi cunhado a bala assistindo
>> filmes de westerns, então pode parar com essa merda de viadagem.
>>
>> Eu mesmo aprendi coisa aqui que achava que já sabia, e tudo numa boa. E o
>> massa dessa thread foi que fomentou diversas dúvidas in my head, que se
>> ninguem aqui responder, dpois eu vou research e done.
>
>
> Ygor, acho que há um potencial vetor de research na exploração de más
> implementações, pois algumas OEM cometaram algumas falhas de customização
> para interação com OS Loader, gerando crashs malditos.
>

exemplo de crash maldito são as brickagens de notebooks da Samsumg
comentado aqui:

http://dangerousprototypes.com/2013/02/06/defcon-20-hacking-measured-boot-and-uefi/

Lenovo e Toshiba também fizeram bobagens com péssimas implementações.

> Agora se eles falharam nisto, no que mais eles falharam? ;-P
>

Esta pergunta é a pergunta de 1 milhão de dólares! rs

[Alberto Fabiano]

Ari,

Não me considero especialista, como você comentou, mas tenho
conhecimento avançado em arquitetura de sistemas seguros, entre outras
coisas tendo inclusive experiência prática de design de bootloader
seguro, não utilizando UEFI mas sim mecanismos muiiiiiiitoooooo mais
simples, mas o suficiente (por exemplo) por ter reduzido a superfície
de ataque e ter obtido um expressivo case de sucesso.

No geral tenho histórias de terror para contar pois certos tipos de
projetos dependem de cultura de P & D, arrojo e stakeholders mais
preocupados com a qualidade do que qualquer outra coisa. E numa destas
troquei uma carreira estável numa excelente empresa para atuar no
desenvolvimento de um projeto de XTM (Extensible Threat Management) em
"pretenso" Embedded Network Security Appliance, que empregaria entre
muitas coisas UEFI Secure Boot e revelou-se (para mim) numa das
maiores decepções e decisões mais erradas da minha vida profissional.

Fracassos e falências podem fazem parte da vida, mas poder tirar algo
bom de tudo e ainda poder colaborar compartilhando conhecimento
adquirido nestas péssimas fases da vida, não tem preço.

[ ]s

--
Sent from my mobile. Excuse-me my fingers.


2013/3/8 Ariel Gomes <arie...@gmail.com>

[Ygor da Rocha Parreira]

Fala Ariel,

Esta mesmo :)

[Rodrigo Madera]

Aproveitando o assunto, tenho uma dúvida, mais como curiosidade do que qualquer coisa...

Os virtualizadores, estilo VMware, Parallels, etc etc... eles chegam a utilizar algúm código da BIOS do host, ou somente o "imposto" à máquina virtual?

Sempre tive essa dúvida.

Mx

2013/3/8 Ygor da Rocha Parreira <ygor.p...@gmail.com>

--

[Rodrigo Strauss]

Me desculpem. Eu sei que isso não é Facebook ou Twitter, mas preciso compartilhar meus sentimentos...

Sinto um agradável calor tomar meu pobre coração ao ver que estamos tendo uma longa discussão sobre Disassembly de BIOS e EFI. Uma felicidade inenarrável. Mesmo.

Espero não estragar a thread com meus sentimentos. Por favor, continuem.

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

2013/3/8 Rodrigo Madera <rodrigo...@gmail.com>

[Lê Rodrigues]

Strauss,

A thread tá bacana mesmo! Eu também curti pacas, aprendi um bocado.

O mais legal é que ao ler os papers recomendados pelo aqui, assim como
posts e slides e fui direto na fonte:

http://www.uefi.org/specs/

E fui vendo que as afirmações aqui foram muito fidedignas as specs,
parabéns pelo domínio!

Eu nunca tinha ouvido falar de "big-real mode", se ouvi eu tinha
esquecido, então a tia wikipedia me ajudou a entender:
http://en.wikipedia.org/wiki/Unreal_mode

O interessante é que achei a thread surreal e nela descobri o que é o
Unreal Mode! ;-P

E compilador C que gera byte code? Eu também nunca tinha ouvido falar
nisto, que EFI Secure Mode é muito mais que trollagem e FUD da Intel e
da Microsoft, como os xiitas do Open Source tavam dizendo eu já
suspeitava, mas que era algo tão superior e louco assim, eu não
imaginava.


[ ]s

Lê


2013/3/8 Rodrigo Strauss <rod...@1bit.com.br>:

[Bruno (xacid low)]

Strauss,

Felicidade inenarrável é uma boa definição mesmo, acho que meu cérebro dilatou ao ler a thread! Kkkk

Ao ler que tem cara que tem que sabe dos bugs entre versões do IDA Pro, sabe qual opcode identifica um tal comportamento e lê erratas da Intel e entende como isto pode ser utilizado...  

Lê, eu já achava surreal debugging de kernel, agora de BIOS? 

Estou sem palavras.

Alberto,

Sobre desenvolver plugin em C para EFI, terei muita dificuldade para explicar para minha mãe isto... aliás, para mim mesmo.  

Que exemplos de aplicações eu poderia criar com este conhecimento, partindo do pressuposto que o indivíduo não trabalha numa OEM, nem com hardware, não desenvolve appliance, etc...  você poderia dar alguns exemplos?

[ ]s

Bruno

2013/3/8 Lê Rodrigues <zht...@gmail.com>

--

"given enough eyeballs, all bugs are shallow"

[Alberto Fabiano]

Mx,

Lembrando que na BIOS há device drivers, indiretamente sempre há uso
no acesso a hardware.
Sei que a VMWare utiliza no ESXi recursos da (U)EFI apenas para
proteção da SMM, não para a virtualização em si.

bfamthx,

Nunca subestime a criatividade e a estupidez do ser humano.

Assim como nunca subestime suas oportunidades futuras. A área de
segurança da informação e de sistemas de utilitários de
infra-estrutura são segmentos que tem potencial de desenvolver
extensões de BIOS para segurança de sistemas. Por exemplo, sei de uma
empresa de segurança que irá lançar em 2013 (ou 2014) um sistema que
utilizando possibilidades da tecnologia TPM/TXT, terá na SMM um módulo
de análise de ameaças (exploits / ataques / malwares) e que em seu
roudmap está previsto uma extensão (U)EFI que trabalhará com este
sistema.

Se system programmimg não é tua praia, realmente...

E alguns gamers tem criado plugins UEFI para criar mods

Strauss,

Sim, também curti a thread! ;-)

[ ]s

Alberto Fabiano


2013/3/8 Bruno (xacid low) <bfa...@gmail.com>:

[Rodrigo Rubira Branco]

Opa so pra dizer que o nome dele eh Kris Kaspersky mesmo ;)

Rodrigo (BSDaemon)
http://twitter.com/bsdaemon

Alberto Fabiano <alb...@computer.org> escreveu:
Oi Mercês,

Este é o ponto, sim há "BIOS" de 64bits, utilizada em computadores com
processador de 64bits como o de AMD64 do Gabriel, que são UEFI; este é
o ponto.

Assim temos BIOS de:

a) 16bits (real mode)  - convencionais existentes a mais de 30 anos,
basicamente é um firmware. Aposentada, mas que ainda fará hora extra
por muito tempo em processadores de 32 bits e nos legados. E tem
tamanho restrito até 1MB, monolítico, fácil, fácil de se fazer
reversa. até porque ela é bem enxuta. Como ela é programado em
assembly fica bem mais fácil de entender seu fluxo de execução.

b) 64bits (modo protegido)- que seguem o padrão EFI (de 1999 para cá)
ou (U)EFI (de 2007 para cá) basicamente é um EOS que executa em
paralelo com o OS em execução, sendo mais adequadas para processadores
de 64bits, como o AMD64 do Gabriel que abriu a thread. Onde o
front-end de gerenciamento pode ter suporte a mouse, gráficos
bonitinhos e é mais complicado para se fazer reversa por uma série de
fatores. Onde até pouco tempo atrás um dos complicadores era até a
falta de disassembler para 64bits com suporte total aos opcodes deste,
mesmo mal que dificultava também a análise de malwares de 64bits.

c) 32bits (modo protegido) - que segue o padrão UEFI mas é utilizado
em processadores de 32bits, ele pode parecer um estranho no ninho, mas
ele tem o propósito de oferecer os mecanismos de proteção e aplicar os
padrões do TCG de para Trusted Computing, já existente em alguns
computadores com processades de 64bits, em computadores de 32 bits.

A diferença entre a BIOS de 16bits e a de 64bits (e 32bits) é
gritante, um é monolítico o outro é modular, tem  fluxo de execução,
arquitetura, capacidade, modo de carga, desenvolvimento e entre muitas
diferenças o que você bem colocou quanto ao modo desenvolvimento além
de proteção contra algumas ameaças.

Mauro,

Este livro é totalmente relevante!

Ele é muito bom, eu o estudei uns 6 anos atrás e tem umas técnicas bem
legais. Apesar de ser um livro de quase 7 anos atrás e algumas
mudanças significativas ocorreram neste período, como a nova versão do
padrão UEFI com esquemas de criptografia, proteção extra da própria
carga, autenticação de rede entre algumas mudanças bem interessantes e
significativas do ponto de vista de engenharia reversa, até porque
alguns empregam ofuscação de código justamente para dificultar o
desenvolvimento de rootkits, coisa que nem se sonhavam em fazer antes.

Algo que achei curioso é o agradecimento ao Kris Kaspersky, pois
noutra thread houve menção ao livro dele, o Code Optimization. Este
russo é muito gente fina e bem maluco, tendo vários livros
interessantes.

Porém, ele ficou muito famoso quando apresentou uma pesquisa de
malwares que mostrou como alguns artefatos maliciosos estavam
empregando falhas dos processadores Intel. Muitas deles muito bem
documentado nas erratas da Intel destinado aos desenvolvedores de
firmware (BIOS) outros era opcodes não documentaos que possuiam falha
de elevação de privilégio.

O curioso é que muitos  analisaram os mesmos malwares que ele, mas o
que muitos acreditavam ser junk code, ele foi lá mapeou testou e foi
descobrindo o que de fato era.  Por um lado, este é o típico trabalho
que dificilmente é realizado no research team de empresa de
anti-malware por ser extremamente meticuloso. Quando ele o fez ele era
meio que freelancer, consultor independente. Hoje ele trabalha na
McAfee, obviamente usando seu nome veradeiro que não é este, mas desde
que ele entrou lá tem mais publicado pesquisas interessantes como ele
fez no passado.

Lê,

Sobre a questão do nome, ela é meio complicada mesmo. Neste guideline:

BIOS Protection Guidelines
http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf

Em alguns pontos não há muita distinção, ele aborda ambos os casos, se
você não estiver "ligado" a leitura pode até ficar meio confusa.

Por outro lado, algo que gostei quando eu o li pela primeira vez logo
que ele foi lançado em 2011, são alguns fluxos de execução de ambos,
que esté bem legal e fácil de entender como a diferença é gigante no
modo de funcionamento.

Sobre a diferença de capacidade de discos, basta dizer que da BIOS
convencional a MBR suporte até 2 TiB (2^40 bytes) e na EFI o GPT
(substituto da MBR) permite 8 ZiB (2^70 bytes).

Mas isto é só a ponta do iceberg das diferenças.

[&]s++;


Alberto Fabiano


2013/3/6 Fernando Mercês <nan...@gmail.com>:
> Opa, Alberto, acho que a questão não é se é ROM BIOS, UEFI ou qualquer outra
> coisa. O lance é que o ROM BIOS é 16-bits (não sei se existe diferente disso
> pra PC) e você sugeriu disassemblers de 64-bits. É neste ponto que estou
> intrigado. rs
>
> Como o i4k falou, o objdump não é indicado mesmo, até porque ele não
> disassembla 16-bits afaik.
>
> Abraço

>
>
> Att,
>
> Fernando Mercês
> Linux Registered User #432779
> www.mentebinaria.com.br
> ------------------------------------
> "Ninguém pode ser escravo de sua identidade; quando surge uma possibilidade
> de mudança é preciso mudar". (Elliot Gould)
>
>

> 2013/3/7 Mauro Risonho de Paula Assumpção <mauro....@gmail.com>
>>
>>
>> Já foi falado sobre as tools mais conhecidas, mas achei interessante
>> compartilhar um site, um pouco antigo, mas interessante sobre BIOS/Malware.
>>
>> Não é o foco central dessa thread, mas pode ser interessante para alguém:
>>
>> https://sites.google.com/site/pinczakko/home
>>
>> Espero ter ajudado.
>>
>> @firebitsbr
>>
>>
>> Em 6 de março de 2013 15:40, Alberto Fabiano <alb...@computer.org>
>> escreveu:
>>
>>> 2013/3/6 Tiago Natel de Moura <tiago...@gmail.com>:
>>> > Sim Alberto, da pra usar, mas como eu disse (na minha opinião) o
>>> > objdump é
>>> > uma péssima alternativa pra disassembly de raw binary... Já tive
>>> > algumas más
>>> > experiencias com ele quando tenho um binario flat que contem instruções
>>> > e
>>> > data misturados.. Ndisasm possui uma opção de sync-mode, que sempre me
>>> > salva.
>>> >
>>>
>>> Bom, já tive más experiências com o WinDbg, OllyDbg e com o IDA Pro
>>> (crash)  com o objdump também; e realmente ele não é melhor
>>> alternativa mesmo.
>>>
>>> O Ndisasm tenho que confessar que já utilizei algumas vezes mas tenho
>>> pouca experiência com ele.
>>>
>>> > []'s
>>> > i4k
>>> >
>>> > Em 6 de março de 2013 12:03, Alberto Fabiano <alb...@computer.org>
>>> > escreveu:
>>> >
>>> >> Ah!
>>> >>
>>> >> E não é só no boot process (onde com a BIOS Convencional rola o change
>>> >> de Real para Protection mode enquanto a UEFI rola todo em protection
>>> >> mode) que está a diferença, o sequência de blocos de processo é outro
>>> >> mas uma das diferenças significativas é a seguinte:
>>> >>
>>> >> - A velhos ROM BIOS firmwares eram desenvolvidos em FORTH e/ou
>>> >> Assembly.
>>> >>
>>> >> - UEFI firmware é desenvolvido inteiramente em C.
>>> >>
>>> >> Aliás, uma das coisas que o Linus também implicou, afirmando que C
>>> >> gera código desnecessário.
>>> >>
>>> >> [ ]s
>>> >>
>>> >> --
>>> >> http://about.me/AlbertoFabiano
>>> >>
>>> >> 2013/3/6 Alberto Fabiano <alb...@computer.org>:
>>> >> > Mercês e dmr,
>>> >> >
>>> >> > Tava eu tomando um café, incomodado com o desenrolar da thread e
>>> >> > surgiram dois lampejos:
>>> >> >
>>> >> > 1)  Shit! Eu cometendo aquela velha falha de convenção, de novo!
>>> >> > Desde
>>> >> > o princípio da thread (uma velha falha minha) e acabei lembrando do
>>> >> > Linus.
>>> >> >
>>> >> > 2) Preciso esclarecer esta pendenga pois eu estou meio-certo e eles
>>> >> > também estão meio-certos e todo mundo meio-errado.
>>> >> >
>>> >> > Sobre a falha de convenção:
>>> >> >
>>> >> >  - Para evitar todos estes tipos de questionamentos, por convenção a
>>> >> > um bom tempo tem se separado, BIOS é uma coisa e (U)EFI  é outra,
>>> >> > até
>>> >> > porque isto é fato. A EFI nasceu para substituir e superar todas as
>>> >> > limitações da velha e ultrapassada e vulnerável ROM BIOS.
>>> >> >
>>> >> > Em resumo:
>>> >> >
>>> >> > - BIOS é o velho PC Bootloader conhecido como ROM BIOS que sim,
>>> >> > executa em 16-bit real mode e é facilmente hackeável.
>>> >> >
>>> >> > - (U)EFI é um bootloader que roda em 64bits e não fica só na ROM,
>>> >> > entre muitas "tantas" outras diferenças como por exemplo suportar
>>> >> > drivers modulares (em EFI byte code ou EBC) e suportarem plugins que
>>> >> > são utilizados por alguns gamers mods. E necessita de uma partição
>>> >> > especial, "podem ser" assinados digitalmente,   tem sérias
>>> >> > complicações para se fazer um hacking, complicando a vida dos
>>> >> > Bootloaders Rootkits... apesar de haver prova de conceito de UEFI
>>> >> > Rootkit, mas de hiper-difícil propagação.
>>> >> >
>>> >> > Com processadores 64bits com BIOS rola uma comutação de modos 64bit
>>> >> > para 16bits (real mode) e o boot iniciam em 16bits e só depois o
>>> >> > processador entra em modo x64 que gera toda uma grande latência
>>> >> > desnecessária. Com UEFI tudo rola em 64bits e é bem mais rápido.
>>> >> > Este
>>> >> > por exemplo era um dos segredos do boot e wakeup rápido que todos
>>> >> > babavam nos MacBooks, visto que em notebooks a Apple foi a primeira
>>> >> > a
>>> >> > fazer este change de BIOS para UEFI, enquanto a Intel criou para o
>>> >> > Itanium, portanto servidores e muitos nem se davam conta deste
>>> >> > recurso
>>> >> > por razões óbvias de interatividade.
>>> >> >
>>> >> > Quando se faz o dump de UEFI, drivers EBC vem junto e então rola um
>>> >> > mashup embaçado.
>>> >> >
>>> >> > Porque lembrei do Linux?
>>> >> >
>>> >> > Por causa de um mimi dele (tá isto é pleonasmo)  comentando de EFI:
>>> >> > "this other Intel brain-damage" reclamando de como complicaram o que
>>> >> > era simples, blá, blá, blá... até que alguém afirmou que
>>> >> >
>>> >> > "EFI is basically a bigger suckier BIOS"
>>> >> >
>>> >> > http://kerneltrap.org/node/6884
>>> >> >
>>> >> > Enfim, há muita, muita, mas muita coisa mesmo de diferente entre as
>>> >> > velhas plataformas de 32 e 16 bits e um bom hardware de 64 bits,
>>> >> > tantas que chega ser irônico certas simplificações e o UEFI é uma
>>> >> > das
>>> >> > remodelagens.
>>> >> >
>>> >> > PS: A partir de hoje nunca mais cometerei esta gafe de usar a
>>> >> > expressão BIOS (U)EFI... so sorry! ;-)
>>> >> >
>>> >> > [ ]s
>>> >> >
>>> >> > --
>>> >> > http://about.me/AlbertoFabiano
>>> >> >
>>> >> > 2013/3/5 Ygor da Rocha Parreira <ygor.p...@gmail.com>:
>>> >> >>
>>> >> >> To caindo de paraquedas no meio da thread, mas o meu entendimento é
>>> >> >> o
>>> >> >> mesmo
>>> >> >> que o do mercês.
>>> >> >>
>>> >> >> Mesmo pq o processador boota em modo real neh? É o kernel que passa
>>> >> >> pro
>>> >> >> modo
>>> >> >> protegido, e dpois disso só rola VM86 ou reboot pra voltar pro modo
>>> >> >> real.
>>> >> >>
>>> >> >>
>>> >> >> Em 5 de março de 2013 22:38, Fernando Mercês <nan...@gmail.com>
>>> >> >> escreveu:
>>> >> >>
>>> >> >>> Mas o código do BIOS não é de 16-bits? Ainda não entendi por que
>>> >> >>> disassemblá-lo em 64-bits. ;)

>>> > Tiago Natel de Moura
>>> > Consultor de Segurança da Informação
>>> > http://www.linkedin.com/in/tiagonatel
>>> > http://www.secplus.com.br/
>>> > http://github.com/tiago4orion
>>> > http://code.google.com/p/bugsec
>>> >
>>> > --
>>> >
>>>
>>>
>>
>>
>
>

[Rodrigo Rubira Branco]

a Intel tem software de monitoramento rodando em SMM ha muito tempo.

Na Phrack sairam alguns artigos sobre SMM rootkits (se pode esconder pode achar) tambem...

Tem um material da Vnsecurity e Xcon que ampliam o aspecto de protecao de hardware tambem...

E na KAS (kaspersky analyst summit) uma pesquisa axademica patrocinada pela kaspersky foi mostrada usando-se gpu como processador externo (na phrack tem o uso de gpu pra esconder dados tambem).

Na phrack tem rootkits pra bios (com exemplos q funfam em vmware tbm).

E finalmente artigo da Joanna fala de bypass de dma (muito usado pra fornecer checagem de rootkits).

Na mesma linha eh bom ver sobre desync d itlb e dltb (artigo da Phrack tbm) pois afeta a inspecao via smm (incoerencia de cache eh discutida no artigo de smm).

Abracos (maus nao postar os nomes e links diretos mas via phone eh fogo e como ja entrei tarde na thread...).

Rodrigo (BSDaemon)
http://twitter.com/bsdaemon

Alberto Fabiano <alb...@computer.org> escreveu:

> "given enough eyeballs, all bugs are shallow"
>

[Alberto Fabiano]

Rodrigo,

Pelo CV dele, o nome dele é Likhachev Nikolay: http://n2k.me/cv.pdf

Mas sei lá...

[ ]s

2013/3/11 Rodrigo Rubira Branco <rodri...@gmail.com>:

[Alberto Fabiano]

Rodrigo,

Valeu pela contribuição.

Sim, a Intel tem, mas a idéia era dar um exemplo de algo que está
sendo desenvolvido agora, no momento veio-me este exemplo, que na
realidade é ligado uma plataforma de anti-malware e de monitoramento
agentless usando o VMCI, agora com este agente em SMM e em roadmap tem
este módulo UEFI.

A verdade é que dá para se tirar um dia só para falar de ameaças em
BIOS legadas, ACPI Rootkits e inclusive possibilidades de UEFI
Rootkits, com as atuais provas deconceito, seja em EBCVM como em PE32+
do UEFI Shell.

É um tema bem interessante em vários aspectos.

[ ]s

Alberto Fabiano

2013/3/11 Rodrigo Rubira Branco <rodri...@gmail.com>:

[Lê Rodrigues]

2013/3/11 Alberto Fabiano <alb...@computer.org>:

> Rodrigo,
>
> Pelo CV dele, o nome dele é Likhachev Nikolay: http://n2k.me/cv.pdf
>
> Mas sei lá...

Agora isto é um impasse! ;-)

A frase pode ser intepretada como:

a) "pseudônimo profissional Kris Kaspersky" ou

b) "pseudônimo profissional de Kris Kaspersky".

Mas se eu fosse russo e tivesse este nome e nao quisesse trabalhar
para o Eugene Kaspersky e nem ser sequestrado, eu criaria um um
pseudônimo e só usaria ele.

E se fosse o contrário seria bem ridículo, mas porque não Kris
Likhachev Nikolay?

Estranho, e "Likhachev" parece ser algo como "Like Hacker", curioso.

O fato é que o cara manja muito de C e engenharia reversa! ;-)

[P.]

Em quarta-feira, 6 de março de 2013 18h58min15s UTC-3, Alberto Fabiano escreveu:

 

Este é o ponto, sim há "BIOS" de 64bits, utilizada em computadores com
processador de 64bits como o de AMD64 do Gabriel, que são UEFI; este é
o ponto.

Assim temos BIOS de:

a) 16bits (real mode)

b) 64bits (modo protegido)

c) 32bits (modo protegido)

O que você quer dizer com "de 64 bits"?
Isso significa que o boot loader recebe o controle com o processador no "long mode"?
Com certeza x86 e x86-64 sempre começa no "real model" certo?

--
 P.

[Alberto Fabiano]

2013/3/11 P. <pedro....@gmail.com>:

Olá Lamarão,

Sim, eu até já tinha esclarecido noutra mensagem da thread.

Ele sempre começa em "real mode", certíssimo!

Mas o UEFI em processadores de 64 bits, é executado a "maior parte do
tempo" em 64 bits. Esta transição já ocorre na primeira de suas 5
fases de execução. Na segunda-fase de execução ele entre em "long
mode" e isto é feito para que ele possa utilizar-se o máximo de
recursos do processador, inclusive empregando paralelismo, e assim
realizar o boot o mais rápido possível, sendo parte do segredo do
"fast boot".

Porém, mesmo assim há boas práticas a ser seguida para que o OEM
garanta que seu hardware faça verdadeiramente um "fast boot" e não
cause problemas aos usuários; e alguns problemas observados nos
últimos 6 meses só tem ocorrido por que "alguns OEMs" não terem
seguido estas boas práticas.

[ ]s

>
> --
> P.

[Fernando Gomes]

Como assim PE32+ na UEFI BIOS?

Eu dei uma googlada sobre UEFI e não encontrei nada disto.

Acabei encontrando sobre codificação em C que gera EFI Byte Code para
Virtual Machine EFI, não sobre PE32+.


[ ]s

FerG0

[Alberto Fabiano]

Oi Fernando,

O UEFI utiliza um subset do formato PE32/COFF, usando a estrutura mas
sendo específico dele, também chamado de EFI PE32+. Sendo-se que o "+"
(plus) identifica que ele também comporta código de 64-bits, na
realidade ele pode ser:

// PE32+ Machine type for EFI images
#define EFI_IMAGE_MACHINE_IA32 0x014c
#define EFI_IMAGE_MACHINE_IA64 0x0200
#define EFI_IMAGE_MACHINE_x64 0x8664
#define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 0x01C2
#define EFI_IMAGE_MACHINE_EBC 0x0EBC

Onde o 0x0EBC é cross-platform, como se deveria esperar de um "byte code".

// PE32+ Subsystem type for EFI images
#define EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION 10
#define EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER 11
#define EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12

Onde a extensão é sempre .EFI, por exemplo:

BOOTx64.EFI
BOOTARM.EFI

E imagens EFI tipo "APPLICATION" podem ser executados num EFI Shell.

http://www.uefi.org/specs/download/UEFI_Spec_2_3_1.pdf



2013/3/11 Fernando Gomes <fer...@googlemail.com>: