Mais um blog inútil.

Useless

Junho 6, 2009

Cracking 101

Arquivado em: assembly, cracking, useless — falso @ 00:53

Ora viva!

O software há dias estava a tentar descobrir como se cracka um simples strncmp(3), então eu fiquei com ideias de criar um breve *curso* de cracking para os iniciantes.
Começamos com o seguinte sores:

#include <stdio.h>

int main() {
        char loljews[10];

        printf("--> ");
        scanf("%s",&loljews);
        if(strncmp(loljews,"morte",5)==0) {
                printf(" OK ;-)\n");
        } else {
                printf(" FAiLED!\n");
        }

        return 1;
}

O código julgo que é auto-explicativo. O que se pretende é, depois de ter o programa compilado alterar o executável de forma a que aceite qualquer palavra sem ser “morte” e diga OK.
Então corri o programa no gdb e fiz “disassemble main”

Dump of assembler code for function main:
0x08048464 <main+0>:    push   %ebp
0x08048465 <main+1>:    mov    %esp,%ebp
0x08048467 <main+3>:    and    $0xfffffff0,%esp
0x0804846a <main+6>:    sub    $0x20,%esp
0x0804846d <main+9>:    mov    $0x8048590,%eax
0x08048472 <main+14>:   mov    %eax,(%esp)
0x08048475 <main+17>:   call   0x8048368 <printf@plt> # print "-->"
0x0804847a <main+22>:   mov    $0x8048595,%eax
0x0804847f <main+27>:   lea    0x16(%esp),%edx
0x08048483 <main+31>:   mov    %edx,0x4(%esp)
0x08048487 <main+35>:   mov    %eax,(%esp)
0x0804848a <main+38>:   call   0x8048378 <__isoc99_scanf@plt>
0x0804848f <main+43>:   movl   $0x5,0x8(%esp)
0x08048497 <main+51>:   movl   $0x8048598,0x4(%esp)
0x0804849f <main+59>:   lea    0x16(%esp),%eax
0x080484a3 <main+63>:   mov    %eax,(%esp)
0x080484a6 <main+66>:   call   0x8048398 <strncmp@plt> # faz o call ao strncmp
0x080484ab <main+71>:   test   %eax,%eax
0x080484ad <main+73>:   jne    0x80484bd <main+89> # Se não é igual, salta pra bad_boy
0x080484af <main+75>:   movl   $0x804859e,(%esp) # good_boy
0x080484b6 <main+82>:   call   0x8048388 <puts@plt> # print "OK"
0x080484bb <main+87>:   jmp    0x80484c9 <main+101> # salta para o fim
0x080484bd <main+89>:   movl   $0x80485a6,(%esp) # bad_boy
0x080484c4 <main+96>:   call   0x8048388 <puts@plt> # print "failed"
0x080484c9 <main+101>:  mov    $0x1,%eax # fim
0x080484ce <main+106>:  leave
0x080484cf <main+107>:  ret

Primeiro uma lista de instruções normalmente usadas para o cracking e os seus opcodes em hexadecimal.

JNE - Jump if Not Equal - 75
JE - Jump if Equal - 74
JMP - Jump - EB
NOP - No Operation - 90
JA - Jump if Above - 77
JB - Jump if Below - 72
JNA - Jump if Not Above - 76
JLE - Jump if Less or Equal - 7E
JL - Jump if Less - 7C

O que se pretende então é alterar ali aquele JNE em <main+73>. Mas para o quê? A primeira ideia seria inverter o sentido do jump, em vez de ser JNE passava a ser JE. Mas assim ficávamos com um problema, ao metermos “morte” iamos parar ao “failed”.
Então o que podemos fazer perguntam vocês?

Para explicar primeiro precisei de instalar um hex editor para Linux. O biew pareceu-me bem. Abri o executável nele e andei à procura do naco de código acima (do gdb).

000004A6:E8EDFEFFFF                     calln     file:00000398
000004AB:85C0                           test      eax,eax                      
000004AD:750E                           jne       file:000004BD
000004AF:C704249E850408                 mov       [esp],0804859E
000004B6:E8CDFEFFFF                     calln     file:00000388
000004BB:EB0C                           jmps      file:000004C9
000004BD:C70424A6850408                 mov       [esp],080485A6
000004C4:E8BFFEFFFF                     calln     file:00000388
000004C9:B801000000                     mov       eax,00000001                 
000004CE:C9                             leave

O que eu fiz foi alterar os os bytes do JNE e da posição para onde salta “75 0E”, para dois NOPs (No Operation - Não faz nada) “90 90”. Assim ele nunca faz o teste, e segue sempre em frente para o good_guy e depois sai.

Espero que isto tenha alguma utilidade para alguém! Para a próxima talvez haja um com algo mais complexo tipo Username com Serial derivada do Username ou algo do género.

Até la, fiquem bem e crackem muito ;-)

Junho 5, 2009

Threefish - Part II

Arquivado em: assembly, coding, serious-business, useless — dcoder @ 22:28

Como prometido aos meus fiéis leitores ontem, hoje vamos ver como optimizar a cifra Threefish de 250 ciclos por byte (em 32 bit) para algo mais útil na prática.

Em primeiro lugar, e de longe mais relevante, vamos eliminar todos os loops e branches da função. Estes não apenas ocupam recursos que podiam estar a ser usados na cifração em si, mas impedem o uso de todas as unidades de execução. Em segundo lugar, queremos eliminar os acessos à memória desnecessários e manter o máximo de dados possível em registos: substituímos os arrays por variáveis para facilitar esta tarefa ao compilador. Infelizmente, não existem registos para toda a gente (em x86) e vamos sempre ter de aceder à stack para guardar alguns dados. Mas não faz mal. Assim sendo, ficamos com uma função do género:

void ThreefishEncrypt(const ThreefishKey ks, u8 *in, u8 *out)
{
	u64 *p = (u64*)in;
	u64 v0, v1, v2, v3;
	u64 f0, f1, f2, f3;
	int i, d;
		
	v0 = p[0];
	v1 = p[1];
	v2 = p[2];
	v3 = p[3];
	
	/* start of round 0 */
	v0 += ks->subkey[0][0];
	v1 += ks->subkey[0][1];
	v2 += ks->subkey[0][2];
	v3 += ks->subkey[0][3];
	
	MIX(f1, f0, v1, v0, 5);
	MIX(f3, f2, v3, v2, 56);
	
	v0 = f0; v1 = f3; v2 = f2; v3 = f1;
	
	/* start of round 1 */
	MIX(f1, f0, v1, v0, 36);
	MIX(f3, f2, v3, v2, 28);
	
	v0 = f0; v1 = f3; v2 = f2; v3 = f1;
	
	/* start of round 2 */
	MIX(f1, f0, v1, v0, 13);
	MIX(f3, f2, v3, v2, 46);

	v0 = f0; v1 = f3; v2 = f2; v3 = f1;
	......

	((u64*)out)[0] = v0 + ks->subkey[ROUNDS/4][0];		
	((u64*)out)[1] = v1 + ks->subkey[ROUNDS/4][1];	
	((u64*)out)[2] = v2 + ks->subkey[ROUNDS/4][2];	
	((u64*)out)[3] = v3 + ks->subkey[ROUNDS/4][3];	
}

Esta versão já é substancialmente mais rápida - passamos de 250 para 80 ciclos por byte. Em 64 bit passamos de 50 para 11!

Será que ainda podemos acelerar o processo?

A resposta é sim.

Recorrendo às instruções SSE2 presentes em essencialmente todos os CPUs x86 actuais, podemos cifrar 2 blocos simultaneamente por essencialmente o custo de um. Como é que isto é conseguido?

void ThreefishEncryptSSE2(const ThreefishKey ks, u8 *in, u8 *out)
{
	__m128i *p = (__m128i*)in;
	__m128i v0, v1, v2, v3;
	__m128i f0, f1, f2, f3;
	__m128i t0, t1, t2, t3;
	__m128i k0, k1, k2, k3;
		
	t0 = _mm_load_si128(&p[0]);
	t1 = _mm_load_si128(&p[1]);
	t2 = _mm_load_si128(&p[2]);
	t3 = _mm_load_si128(&p[3]);
	
	v0 = _mm_unpacklo_epi64(t0, t2);
	v1 = _mm_unpackhi_epi64(t0, t2);
	v2 = _mm_unpacklo_epi64(t1, t3);
	v3 = _mm_unpackhi_epi64(t1, t3);
	
	t0 = _mm_load_si128((__m128i*)&(ks->subkey[0][0]));
	t1 = _mm_load_si128((__m128i*)&(ks->subkey[0][2]));
	
	k0 = _mm_shuffle_epi32(t0, 0x44);
	k1 = _mm_shuffle_epi32(t0, 0xEE);
	k2 = _mm_shuffle_epi32(t1, 0x44);
	k3 = _mm_shuffle_epi32(t1, 0xEE);
	
	/* Round 0 */
	v0 = _mm_add_epi64(v0, k0);
	v1 = _mm_add_epi64(v1, k1);
	v2 = _mm_add_epi64(v2, k2);
	v3 = _mm_add_epi64(v3, k3);
	
	/* load next subkey */
	t0 = _mm_load_si128((__m128i*)&(ks->subkey[1][0]));
	t1 = _mm_load_si128((__m128i*)&(ks->subkey[1][2]));
	k0 = _mm_shuffle_epi32(t0, 0x44);
	k1 = _mm_shuffle_epi32(t0, 0xEE);
	k2 = _mm_shuffle_epi32(t1, 0x44);
	k3 = _mm_shuffle_epi32(t1, 0xEE);
	
	/* mix */
	f0 = _mm_add_epi64(v0, v1);
	f1 = _mm_xor_si128(_mm_xor_si128(_mm_slli_epi64(v1, 5),_mm_srli_epi64(v1, 64-5)), f0);
	f2 = _mm_add_epi64(v2, v3);
	f3 = _mm_xor_si128(_mm_xor_si128(_mm_slli_epi64(v3, 56),_mm_srli_epi64(v3, 64-56)), f2);
	
	/* permute */
	v0 = f0;
	v1 = f3;
	v2 = f2;
	v3 = f1;
	
	....

	/* Round 71 */
	/* mix */
	f0 = _mm_add_epi64(v0, v1);
	f1 = _mm_xor_si128(_mm_xor_si128(_mm_slli_epi64(v1, 59),_mm_srli_epi64(v1, 64-59)), f0);
	f2 = _mm_add_epi64(v2, v3);
	f3 = _mm_xor_si128(_mm_xor_si128(_mm_slli_epi64(v3, 50),_mm_srli_epi64(v3, 64-50)), f2);
	
	/* permute */
	v0 = _mm_add_epi64(f0, k0);
	v1 = _mm_add_epi64(f3, k1);
	v2 = _mm_add_epi64(f2, k2);
	v3 = _mm_add_epi64(f1, k3);
	
	// unpack
	t0 = _mm_unpacklo_epi64(v0, v1);
	t1 = _mm_unpacklo_epi64(v2, v3);
	t2 = _mm_unpackhi_epi64(v0, v1);
	t3 = _mm_unpackhi_epi64(v2, v3);
	
	// place holder
	p = (__m128i*)out;
	_mm_store_si128(&p[0], t0);
	_mm_store_si128(&p[1], t1);
	_mm_store_si128(&p[2], t2);
	_mm_store_si128(&p[3], t3);
}

Em primeiro lugar, carregamos os dois blocos para registos XMM. No entanto, quando fazemos isto, os inteiros de 64 bits dentro dos blocos ficam na ordem errada. Através da instrução PUNPCKLQDQ e PUNPCKHQDQ alteramos a ordem dos blocos de a0a1 a2a3 b0b1 b2b3 para a0b0 a1b1 a2b2 a3b3. Assim já podemos facilmente processar os dois blocos como se o estivessemos a fazer no caso acima, sem SSE2.

Ainda de notar é também o truque necessário para suportar o mesmo formato das subkeys: através de 2 loads e 4 shuffles, essencialmente extendemos a subchave a0 a1 a2 a3 para a0a0 a1a1 a2a2 a3a3.

Após as 72 iterações, temos de retornar os inteiros à ordem original, novamente com as instruções PUNPCKLQDQ e PUNPCKHQDQ. Após isto só nos resta armazenar as variáveis no buffer de saída.

Será que todo este trabalho vale a pena? Mais uma vez, sim. No modo CTR, passamos de 80 ciclos por byte (acima) para 26. Podemos ainda melhorar este número? Quebrando a compatibilidade com o formato das subchaves acima, podemos. Trocamos então 2 loads + 4 shuffles por 4 loads. Isto leva-nos ao resultado final de 19 ciclos por byte em 32 bit e 10 ciclos por byte em 64 bit. Isto não é óptimo, mas está bastante perto do óptimo num Core 2.

Para obter melhores desempenhos ainda, particularmente no modo CTR, poderíamos utilizar as variantes com blocos maiores do Threefish, e.g. 512 ou 1024 bits. Estas facilmente iriam parar aos 10 ou menos ciclos por byte em 32 bits. No entanto, blocos deste tamanho são incómodos para os tamanhos típicos de payloads cifradas - só para mensagens relativamente grandes é que faz sentido utilizar estas variantes.

O código utilizado para estas experiências está aqui. Não está bem comentado nem bem organizado - é apenas o resultado de experimentação. Divirtam-se.

Threefish

Arquivado em: coding, serious-business, useless — dcoder @ 03:54

Uma das formas de criar hash functions seguras passa por reutilizar uma cifra num ou noutro modo de operação especial. Entre estes encontram-se o modo Davies-Meyer, UBI, Miyaguchi-Preneel, etc.

Um dos candidatos ao SHA-3, o Skein, utiliza uma cifra nova em modo UBI — Threefish. Dada esta conversa toda sobre o AES-256 ser inseguro, e como não temos já cifras seguras suficientes, implementei esta cifra em C a partir das especificações acessíveis aqui. Existem vários tamanhos para o bloco e chave do Threefish — implementei apenas o mais realista para cifração de dados: bloco de 256 bits, chave de 256 bits.

Além do bloco e chave de 256 bits, esta cifra aceita um parâmetro adicional, chamado “tweak”. Tipicamente para cifração de dados não é muito útil, mas isto muda de figura quando queremos criar modos de operação para cifração sector a sector, como os utilizados pelo TrueCrypt e companhia. A cifra é bastante simples: 72 iterações de adições, xor e rotações em inteiros de 64 bits. A cada 4 iterações é misturada uma subchave derivada da chave com o bloco. No fim de cada iteração a ordem dos inteiros é alterada através de uma permutação. Se acederem às especificações da cifra, irão notar que esta não segue a estrutura típica de uma Feistel Network — trata-se de uma Substitution-Permutation Network. As vantagens deste design serão abordadas noutra altura mais conveniente.

Uma implementação canónica que aparenta respeitar as especificações encontra-se aqui. O desempenho desta implementação é miserável — ~250 cpb em 32 bits, ~50 cpb em 64 bit quando a cifra é usada em CTR mode.

O próximo post abordará como optimizar esta cifra para níveis usáveis de desempenho.

Junho 4, 2009

Samba e files por default.

Arquivado em: drama, fail, linux, lulz, useless, work — devnull @ 20:58

Que raio.

Quero fazer uma coisinha simples, uma directoria partilhada para toda a gente com acesso a leitura/escrita e deparo-me com uma complicação extrema de um ficheiro de configuraçao de samba por default em Debian completamente ilegivel, confuso e com um monte de “features” e comentários inúteis em que só me apetece pegar fogo ao ficheiro. Para não falar dos exemplos que não funcionam se nao Desactivarmos/Activarmos/Re-activarmos algumas opções que estão 34843 linhas acima.

Aqui está a receita para o que eu quero:

pidgeon:~# cat /etc/samba/smb.conf
[global]
workgroup = devnull
server string = Public Share 
netbios name = pidgeon
security = share
smb passwd file = /etc/samba/smbpasswd

[public]
guest ok = yes
guest only = yes
#guest account = ftp
path = /opt/shares/public/
writeable = yes 

Simples, hein?
Fantasticamente isto não vem no ficheiro de default do debian como um dos exemplos…

pidgeon:~# wc -l /etc/samba/smb.conf
13 /etc/samba/smb.conf
pidgeon:~# wc -l /etc/samba/smb.conf.old 
337 /etc/samba/smb.conf.old

337 linhas de lixo. Obrigado!

Maio 13, 2009

Arvorezinha - COBOL

Arquivado em: arvorezinha, coding, useless — falso @ 16:07

Outra submissão para a saga da arvorezinha, pelo meu colega João Saramago, desta vez em COBOL. Aqui vai:

IDENTIFICATION DIVISION.
PROGRAM-ID.  Arvorezinha.
AUTHOR.  João Saramago.

DATA DIVISION.

WORKING-STORAGE SECTION.
01  Linhas                                PIC 99  VALUE 5.
01  AUX                                   PIC 99 VALUE ZEROS.
01  AUX2                                  PIC 99 VALUE ZEROS.

PROCEDURE DIVISION.
Main.
    DISPLAY "Número de Linhas: " WITH NO ADVANCING
    ACCEPT Linhas.
    PERFORM VARYING AUX FROM 1 BY 1 UNTIL AUX GREATER THAN Linhas
       PERFORM VARYING AUX2  FROM 0 BY 1 UNTIL AUX2 EQUAL TO AUX 
          DISPLAY "*" WITH NO ADVANCING
       END-PERFORM
       DISPLAY ""
    END-PERFORM
    STOP RUN.

Para compilar usei o OpenCobol e para compilar é este comando:

cobc -free -x arvorezinha.cbl 

Maio 10, 2009

Arvorezinha - ARM Assembly

Arquivado em: arvorezinha, assembly, coding, useless — falso @ 23:18

Boas noites!

Venho de novo dar continuação à saga da arvorezinha, desta vez em ARM assembly para Linux. Esta foi relativamente simples, mas também depois de se ter feito em tantos tipos de arches já não há muito a diferir :-P

Aqui segue o código:

.equ SYSCALL_BASE,	0x900000
.equ SYSCALL_EXIT,	1
.equ SYSCALL_WRITE,	4

.text
.align 2
.globl _start

_start:
	mov r0,#5				@ total = 5
	mov r1,#0				@ counter1 = 0

_ciclo1:
	cmp r0,r1				@ compara c1 e tot
	beq _exit				@ se for igual sai
	mov r2,#0				@ counter2 = 0

_ciclo2:
	cmp r2,r1				@ compara c1 e c2 	
	beq _estrela			@ se for igual _estrela
	blt _estrela			@ se for menor _estrela

	stmfd sp!, {r0-r2}		@ guarda r0 a r2 na stack
	adr r1,newline			@ le \n
	bl _print				@ imprime
	ldmfd sp!, {r0-r2}		@ le da stack r0 a r2
	
	add r1,r1,#1			@ incrementa c1
	b _ciclo1				@ salta _ciclo1

_estrela:
	stmfd sp!, {r0-r2}		@ guarda r0 a r2 na stack
	adr r1,estrela			@ le *
	bl _print				@ imprime
	ldmfd sp!, {r0-r2}		@ le da stack r0 a r2

	add r2,r2,#1			@ incrementa c2
	b _ciclo2				@ salta _ciclo2

_exit:
	mov	r0,#0				@ resultado e' 0
	swi	SYSCALL_BASE+SYSCALL_EXIT	@ sai

_print:
	mov	r0,#1				@ 1 == stadout
	mov	r2,#1				@ tamanho da string
	swi	SYSCALL_BASE+SYSCALL_WRITE	@ imprime
	bx	r14					@ return

estrela:.string "*"
newline:.string "\n"

E aqui a prova-dos-nove:

:~/arvorezinha-arm$ cat /proc/cpuinfo
Processor       : XScale-IXP42x Family rev 1 (v5b)
BogoMIPS        : 266.24
Features        : swp half thumb fastmult edsp
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant     : 0x0
CPU part        : 0x41f
CPU revision    : 1
Cache type      : undefined 5
Cache clean     : undefined 5
Cache lockdown  : undefined 5
Cache format    : Harvard
I size          : 32768
I assoc         : 32
I line length   : 32
I sets          : 32
D size          : 32768
D assoc         : 32
D line length   : 32
D sets          : 32

Hardware        : Linksys NSLU2
Revision        : 0000
Serial          : 0000000000000000
:~/arvorezinha-arm$ make
rm -f arvorezinha.o arvorezinha *~
Using fallback suid method
as -o arvorezinha.o arvorezinha.arm.s
ld -o arvorezinha arvorezinha.o
:~/arvorezinha-arm$ ./arvorezinha
*
**
***
****
*****
:~/arvorezinha-arm$

Download do projecto: arvorezinha-arm.tar.

kryptwit 0.1

Arquivado em: coding, fail, useless — dcoder @ 05:41

Bom dia. Tenho, com alguma tristeza, assistido ao flagelo que o Twitter se tornou nos últimos tempos. Esta actividade inútil, ’twitar’, fomentou a minha última criação: o kryptwit. A prova viva que inutilidade gera inutilidade.

Esta biblioteca tem como função cifrar updates do twitter, por forma a poderem apenas ser lidos pelos possuidores de uma password adequada. O RFC que proponho é o seguinte:

Mensagens de entrada - Não podem ultrapassar os 100 bytes (isto inclui caracteres unicode que podem ocupar mais de 1 byte) de tamanho.

Mensagem de saída - Tem exactamente 139 caracteres ASCII de tamanho. Tem como prefixo “;-) “. Os seguintes 10 caracteres (em Base 85) correspondem ao IV utilizado. Os restantes caracteres, também em Base85, correspodem à mensagem propriamente dita.

Algoritmo para cifração - AES no modo CTR (RFC3686), chave de 256 bits.

Derivação de chave - Password de tamanho arbitrário (até 2^32 bytes), ‘salt’ consiste no nome do utilizador que envia a mensagem. O algoritmo utilizado é o PBKDF2, 1000 iterações, SHA-256.

O IV tem apenas 64 bits. Esta escolha foi feita para contrabalançar a probabilidade de colisões (2^(n/2)) com o tamanho roubado à mensagem. 64 bits dá-nos um bom balanço entre 10 chars e 2^32 mensagens por colisão, em média.

A implementação foi feita em C, recorrendo às implementações excelentes do Brian Gladman do AES, SHA-2 e companhia. O resultado é algo pouco retocado, mas parece funcionar.

Download.

A aplicação de exemplo, sample.c, pode ser utilizada para cifrar e/ou decifrar mensagens. A utilização é simples:

sample e/d username password mensagem

Apresento agora um exemplo de funcionamento:

C:\kryptwit>sample.exe e dongs morte "ola sirs"
;-) lyqf(mXkLw&xU[53F8fP#Owitr}o6VVMAsf[C,h$POG=(M{u9sDT9t68Tfgj{RM}k6sGG.[n#V4i(jbdmp-FLxr#ENS`+Djv
(zV+t*imiCz=Aj]H39iRKcImO&DcSsmqZu-.f#F

C:\kryptwit>sample.exe d dongs morte ";-) lyqf(mXkLw&xU[53F8fP#Owitr}o6VVMAsf[C,h$POG=(M{
u9sDT9t68Tfgj{RM}k6sGG.[n#V4i(jbdmp-FLxr#ENS`+Djv(zV+t*imiCz=Aj]H39iRKcImO&DcSsmqZu-.f#F"
ola sirs

Divirtam-se!

EDIT: Disponibilizei uma nova versão (no mesmo link), com 1 bugfix menor e um Makefile e binario para Unix (amd64).

Maio 9, 2009

arvorezinha em LUA

Arquivado em: arvorezinha, useless — gatuno @ 01:22

Olá a todos,

Depois de ter xatiado o falso um bocado, lá consegui que ele me abrisse uma conta… Ora bem.. primeiro post, vamos a ver se não fico mal…

A saga da arvorezinha continua a nos assombrar… desta vez em Lua (pelo menos ainda não vi por cá…) a correr na PSP, só para ser diferente =).

Aqui têm a “sores”, como vocês chamam:

verde = Color.new(0, 255, 0)
screen:clear()
arv="*"
for i=100,140,10 do
screen:print(200,i, arv, verde)
arv=arv .. "*"
endscreen.flip()
while true do
screen.waitVblankStart()
end

Parabéns aos gurus do malbolge e do assembly! Já agora, aproveito para lançar um desafio:

Que tal fazer em assembly para o MIPS da PSP? Alguém se atreve? ;)
http://jacksonm88.googlepages.com/linuxonpsp.htm

Maio 7, 2009

Useless one-liner #1

Arquivado em: serious-business, useless — ali-o-kimiku @ 21:51

Que tal arruinar uma das coisas mais úteis ?

hexdump -C /dev/urandom | grep -i jew

(aposto que o Dcoder consegue calcular de cabeça a probabilidade deste evento acontecer)

0081de30  fe 4e 4a 45 57 04 b9 dc  65 ed 7d 92 b0 cb ab 7e  |.NJEW...e.}....~|
008739e0  6d c3 d6 f4 52 cd 55 fc  9d 4a 65 57 c6 e8 2b cb  |m...R.U..JeW..+.|
008db5d0  0b b7 4b cc 6a 65 77 09  2f 63 b8 76 d6 82 fa 46  |..K.jew./c.v...F|
00b2d430  6f 46 ab d7 4f be 43 2b  52 cb 67 5d c5 4a 65 57  |oF..O.C+R.g].JeW|
00d3dbe0  b8 0b 35 7a 92 14 6a 45  57 f2 47 42 fa e2 c6 f5  |..5z..jEW.GB....|
00d76640  c4 1a d8 db d1 c7 98 cf  e2 7e 5a 7d 6a 65 77 66  |.........~Z}jewf|
00f081d0  d2 cf 34 c7 18 52 0c 4a  45 57 9b 63 bd b6 5d b5  |..4..R.JEW.c..].|
012ea540  dc 80 31 71 1d 4f 39 64  72 d7 c5 4a 65 57 be 07  |..1q.O9dr..JeW..|
01326920  fd b8 0b e4 6f 6a 45 77  25 1a 7a d2 2e 8b 70 0e  |....ojEw%.z...p.|
0148f3d0  4e ed bf 6f 6c ec 40 7d  fc 6a 45 57 33 a0 d3 71  |N..ol.@}.jEW3..q

Cenas do próximo capítulo:

hexdump -C /dev/urandom | grep -i dongs

Still no dongs found…

<3 obcecado

Maio 6, 2009

Geocities !!!

Arquivado em: drama, fail, useless — tatts @ 22:18

aids