Mais um blog inútil.

Never Forget

Aparentemente uma coisa que criou hype na Crypto2008 foi a descrição do “Cube attack” do Shamir. É essencialmente mais um ataque algébrico: apenas cifras/hashes que possam ser descritas como um polinómio multivariável de grau reduzido (o exemplo que ele deu tinha grau 16) estão vulneráveis. Informação detalhada aqui:

http://www.mail-archive.com/cryptography@metzdowd.com/msg09686.html

E aparentemente alguém se deu ao trabalho de fazer um exemplo em python:

http://webpages.charter.net/curryfans/peter/cubedemo.py

Curtia ver este ataque a funcionar em algum algoritmo a sério (Trivium é um dos principais candidatos).

Para os pseudo-jornalistas online que relacionaram isto com LFSRs: estes já são vulneráveis há décadas (cf. Berlekamp-Massey).

Aparentemente alguém foi mais inteligente que os cromos da Kaspersky:

http://rump2008.cr.yp.to/6b53f0dad2c752ac2fd7cb80e8714a90.pdf

O ataque não é surpreendente. Uma vez que é utilizado RC4 para cifrar os ficheiros (eles usam a CryptoAPI), é utilizado o mesmo tipo de ataque que no famoso WEP. Basta ter ficheiros suficientes para conseguir obter correlações.

O que me leva a perguntar: porque raio ainda tanta gente usa RC4? Existem tantas outras stream ciphers seguras e que têm mecanismos próprios para definir chaves e IVs (e.g. Salsa20, Sosemanuk, Trivium, etc). Caso o autor usasse uma destas cifras sem tremendos problemas (é ridículo descartar os primeiros 1024 bytes da stream de RC4 porque libertam informação sobre a chave) com um IV para cada ficheiro, seria efectivamente impossível recuperar os dados.

Suponho que quem ler isto conheça, ou pelo menos tenho noção, de como funciona o RSA. Com a API do Windows é-nos permitido gerar novas chaves, mas o expoente público (também conhecido por e) é sempre 65537 (0×10001). E se quisermos usar outro que não este?

Para minha surpresa, é impossível. Com o Enhanced Provider da Microsoft (rsaenh.dll), verifiquei que o valor 65537 está mesmo hardcoded no código; para gerar chaves com outro expoente temos de alterar o dll. Ao analisar o binário, rapidamente chegamos à função 6800FBD9 - é nesta que a geração é efectuada. Primeira paragem:

.text:6800FC34                 push    eax             ; int
.text:6800FC35                 mov     byte ptr [ebp+var_4], 1
.text:6800FC39                 mov     byte ptr [ebp+var_4+1], bl
.text:6800FC3C                 mov     byte ptr [ebp+var_4+2], 1
.text:6800FC40                 mov     byte ptr [ebp+var_4+3], bl ; var_4 = 0×00010001 == 65537
.text:6800FC43                 mov     [ebp+var_C], 3  ; length(var_4) = 3 bytes

Vemos aqui o valor e o seu tamanho a serem colocados numa variável. Portanto será aqui o primeiro lugar a alterar para o valor pretendido (e.g. 3 ou 17). Mas não fica por aqui.

.text:6800FC7D                 push    eax
.text:6800FC7E                 push    [ebp+var_C]     ; sizeof(10001)
.text:6800FC81                 lea     eax, [ebp+var_4]
.text:6800FC84                 push    eax             ; Ptr to 0×10001
.text:6800FC85                 push    esi             ; Keysize (bits)
.text:6800FC86                 call    sub_68027FDD    ; Generate public/private keypair

Vemos aqui o expoente público a ser passado à função que gera os a chave pública e privada. Adiante:

.text:6800FD8A                 push    [ebp+var_10]    ; Prime #1
.text:6800FD8D                 push    [ebp+var_8]     ; Prime #2
.text:6800FD90                 push    10001h          ; push 65537 — public exponent
.text:6800FD95                 push    [ebp+arg_14]    ; Keysize in bits
.text:6800FD98                 push    eax             ; PRIVATEKEYBLOB (out)
.text:6800FD99                 push    dword ptr [edi] ; PUBLICKEYBLOB (in)
.text:6800FD9B                 call    sub_6801F9C0    ; Creates the PUBLICKEYBLOB/PRIVATEKEYBLOB structure

Vemos novamente ali o valor hardcoded a ser usado. Temos de mudar o valor colocado na stack para o desejado. No final desta função, teremos uma chave gerada com o expoente que queremos. Para mais info sobre as estruturas de saída desta função, vejam isto.

epa sintam só a capa do cd! e do DVD. E DAQUELE BONGO QUE SE CALHAR VOU COMPRAR PARA FUMAR UMA ERVADA COM O OB

OBcecado: plz2not forget weed

falso: plz2not forget ipod with minor threat

software: plz2not forget lipstick to suck cock

O GNU/Lunix, tal como o Goatse, gira todo à volta da abertura. Assim sendo, não existem debuggers decentes para analisar código binário, sem acesso ao código nem symbols disponíveis. É possível configurar o gdb para ser remotamente útil (cf. first post) mas continua a ser incoveniente e pouco funcional, particularmente quando comparado com as ferramentas disponíveis em Windows para o efeito.

É neste contexto que apresento o EDB Debugger. Embora esteja longe de ser uma ferramenta completa para reverse engineering, é um passo em frente quando comparado com as outras ferramentas rudimentares disponíveis.

Este não é um projecto novo, longe disso…a novidade está no facto de desde esta última versão (0.9) este suportar x86-64, o que pelo menos para mim é bastante útil. Faltam, no entanto, algumas funcionalidades essenciais…não existe detecção de x-refs (o plugin incluído ou funciona mal ou não funciona de todo), pelo que temos de constantemente recorrer ao IDA para qualquer coisa séria; o OpcodeSearcher é muito limitado, assim como o StringSearcher (mais uma vez, IDA to the rescue).

Apesar de tudo, bastante melhor que qualquer debugger feito por freetards.

Pois é, meus amigos.

Há alguns dias deparei-me com isto: http://forum.kaspersky.com/index.php?showtopic=71652

Aparentemente, os bons senhores da Kaspersky acham boa ideia factorizar um módulo de 1024 bits para de alguma forma combater o ransomware gpcode. Boa sorte com os vossos 100 anos de factorização.

E que tal obterem o utilitário que faz a decriptação (paguem ao gajo se for preciso, nós também temos de vos pagar), e extrairem de lá a chave? Sim, já que não percebem de criptografia, ao menos de reverse engineering devem ter umas luzes.

Enfim.