However, CryptGenRandom requires a handle to a CSP (acquired by calling CryptAcquireContext). If all we want is random bytes, this no good; a full-fledged CSP takes too many resources (and time to load) for the task at hand. So an alternative is to use the lower level function RtlGenRandom, which doesn’t require a CSP context. This name is an actual alias for the function ‘SystemFunction036′ in advapi32.dll. MSDN reports: “This function has no associated import library. This function is available as a resource named SystemFunction036 in Advapi32.dll. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Advapi32.dll”. But what if we don’t want the pain of loading and unloading libraries at runtime? I’ll show you how to make the required import library to avoid this.

The main problem you will encounter  is that RtlGenRandom’s calling convention is __stdcall, whereas its actual name in advapi32.dll does not reflect that (__stdcall functions have the number of bytes passed as parameters in the stack appended in the function name. In this case, it expects SystemFunction036 to be called SystemFunction036@8). Using the LIB utility doesn’t help, even when using aliases: it always expects the appended number of bytes to be there. So first idea is to use function ordinals. Running DUMPBIN /EXPORTS on advapi32.dll shows us:

621  26C 00008292 SystemFunction036 = _SystemFunction036@8

So now we know the ordinal of our function: 621. With this in mind, we can now use LIB to create a .lib to link against our application. First, create a .def file with the following lines:

LIBRARY advapi32.dll

EXPORTS

SystemFunction036@8 @ 621

Now run:

lib /DEF:RtlGenRandom.def /OUT:RtlGenRandom.lib /MACHINE:X86

Now you can just link the resulting .lib with your application to have the desired result.

However, this is not a good solution. Ordinals are by no means fixed (unless you’re dealing with Winsock2 or MFC dynamic libraries) and you have no guarantee they’ll be the same across Windows versions. So here’s another way to do it. First, create a C source file and declare an empty function equal to RtlGenRandom:

#include <windows.h>
#define RtlGenRandom SystemFunction036
#define DLLEXPORT 	__declspec(dllexport)
DLLEXPORT BOOLEAN WINAPI RtlGenRandom(PVOID in, ULONG len) {}

Now create a .def like the following:

LIBRARY advapi32.dll
EXPORTS
SystemFunction036

Now we compile the source and feed the DEF to the linker:

cl dummy.c dummy.def

The actual binary output of this compilation is irrelevant; what we want is the resulting dummy.lib. You can now link against this import library and it will link to the real advapi32.dll, thus giving us what we want. I used the following test source to try it out:

#include <stdio.h>
#include <windows.h>

#define RtlGenRandom                    SystemFunction036
BOOLEAN WINAPI RtlGenRandom(PVOID, ULONG);

int main(int argc, char **argv)
{
    BYTE blah[20];
    DWORD i;

    RtlGenRandom(blah, 20);

    for(i=0; i < 20; i++)
        printf("%02X ", blah[i]);

    return 0;
}

Compile with:

cl /O2 /MT test.c dummy.lib

Problem solved. Try it out.

PS: Someone’s bound to comment “oh but Windows’ PRNG is flawed, there was a paper on it some time ago”. That’s correct. However, both attacks (forward and backward security compromised) assume you already have knowledge of the whole state of the PRNG (i.e. you’ve owned the box) and that you’re running a Windows previous to XP SP3, which fixed the issue.

oh no!!!!

De maneira, que da última vez que falei com ela, ela não me pareceu que tivesse emagrecido muito, mas pelo menos não morreu. Disse-me ela que não apanhou a sida, mas que gostou muito de lamber sanitas. Descobriu que gostava de comer merda e que agora fazia daquilo profissão. Diz que faz filmes com uma amiga e que são bastante famosas na Internet. Perguntou-me se eu já tinha visto um trabalho muito famoso que ela fez com essa amiga e com um copo. Eu disse-lhe que não fazia ideia do que ela estava a falar, e ela a seguir pediu-me para eu lhe lamber o olho do cu. Fiquei chocado com a proposta, mas depois fui buscar umas fatias de pão e fiz uma sandocha de nutella.

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

falso: plz2not forget ipod with minor threat

software: plz2not forget lipstick to suck cock

É 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.

Comecemos por correr o Twilight Hack
Fazer o download aqui
Inserir o SDcard no computador e criar o seguinte directório: /private/wii/title/RZDP/
Depois de feito o download e extraído, aparecem quatro ficheiro. Isto vai variar de acordo com a vossa versão do Twilight Hack, mas em princípio será PAL, portanto terão que copiar o rzdp0.bin
Copiar este ficheiro para o directório criado no SDcard e renomear para data.bin (aconselho a, antes de tudo isto, copiar o save do jogo de dentro da Wii para o SDcard e depois para o computador)

Agora já temos o Twilight Hack no SDcard, vamos passar à parte de o colocar para a memória da Wii.

Utilizando o Twilight Hack
Inserir o SDcard no leitor frontal da Wii e ligá-la.
Depois ir a Wii Options - Data Management - Save Data - Wii
Aqui encontrarão o vosso save do jogo (FAÇAM BACKUP ANTES DE TODOS ESTES PROCESSOS), cliquem Erase e depois Yes.
Agora há que abrir o SDcard e clicar no save “Twilight Hack”, clicar em Copy e depois Yes.
Já temos o save do jogo dentro da memória da Wii.
Vamos passar à parte de instalação do Homebrew Channel.

Homebrew Channel
Fazer o download aqui do ficheiro encontrado abaixo de .ELF
Depois de feito o download, extrair e copiar o Boot.elf para a raíz do SDcard e criar um directório chamado apps.
Agora que temos tudo pronto, vamos de novo à Wii, colocar o SDcard, ligar e abrir o jogo.
Aparecerá um save, carreguem o save e vão falar com o homenzinho que aparece.
Após isto o ecrã mudará e o Homebrew Channel será instalado.

Agora com o Homebrew Channel instalado vamos passar ao homebrew GBA Emulator

Usar o GBA Emulator
Fazer o download aqui
Extrair e copiar o que está dentro de Homebrew Channel Version para o SDcard (directório apps), ficará assim: apps/vbawii
Após isto temos que criar um outro directório na raíz do SDcard chamado VBA, e dentro dele criar: ROMS, SAVES, BIOS

Dentro do ROMS estarão os roms, poderão fazer download aqui
Dentro do SAVES ficarão os saves dos jogos e dentro da BIOS coloquem isto e renomeiem para BIOS.GBA, ficando /VBA/BIOS/BIOS.GBA

Agora com tudo pronto basta voltar à Wii, colocar o SDcard. Quando for iniciada um novo canal aparecerá, entrar nele e depois aparecerá o emulador. Basta clicar no icon que aparece e seleccionar o jogo.

Atenção que o sinal vem em NTSC, portanto jogarão a preto e branco (a não ser que a televisão suporte isto)

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.