Mais um blog inútil.

Aparentemente saiu uma nova versão do xcrap, 2.8.7a. Eu reparei nisto e lembrei-me que houve um post do falso ha uns tempos que falava de como crackar opensores. Infelizmente, não tenho muito tempo por isso vou ser sucinto.

O leitor assíduo facilmente vai descompactar o executável (é uma versão antiga do UPX) e encontrar a função de interesse (sub_4018CD).

Aqui encontramos o algoritmo de verificação, que consiste essencialmente em:

Hash = SHA-1(Linha3|Linha4|Linha4)

E = 0x25F86508483EFD

N = 0xB5BA27D856CCBE6B61CFE96A387D8E265A65897510AE91212634A7397432D1B2407604CAFA9DC77EF29A87B86D938748E0C4921D46C3AC4BCE7E00EECDFCF782DBD0D44C46C9057724CCF7DEDF36924E4683721FF55EDC570C4C71927887D67C1B1488A33E0B3F64160701B2390C3B3F278490B22DE9906A65B9DFBDF4E838870EFD5851DC0B2C94E444E0B1D2DAAA5C6060D3976E170BB8692111E26D178871008AE42EE250A856D2354102B57F560420AC9F89D004AF761341764FBEDD194A27AF6F34B9C0E3A48013734C6CBD3C216CFAD9B1F3DFDB76FE8519C78E3E95F3C4B39006111DE983C88D72CD4613D4CB852D36244D7B8D4AB15C740415382735

GoodSignature = 00 01 FF FF … (tem de ter 256 bytes (2048 bit) … FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 | Hash

if (Linha2 ^ E (mod N) == GoodSignature) return GOOD else return BAD

OK, então temos basicamente uma assinatura digital baseada em RSA com 2048 bits. Não existem exploits óbvias (padding, expoente baixo, …) que se possam aproveitar; portanto, para fazer um keygen temos de alterar a chave pública. Escolham uma e substituam no sítio apropriado (public_key_n). Para gerar uma chave válida, temos então:

void generate_key(void)

{

char LInha1[] = “# Designed and implemented exclusively for the lulz”;

char Linha2[1024];

char Linha3[] = “Some Jew”;

char Linha4[] = “Crap”;

char Linha5[] = “More crap”;

HCRYPTPROV hProv;

HCRYPTHASH hHash;

unsigned char appendage[] = {00, 30, 21, 30, 09, 06, 05, 2B, 0E, 03, 02, 1A, 05, 00, 04, 14};

unsigned char good_signature[256];

unsigned char sha[32];

unsigned long tmp = 20;

mpz_t n, d, c;

memset(Linha2, 0, sizeof(Linha2)*sizeof(Linha2[0]));

CryptAcquireContext(&hProv, 0, 0, 1, 0xF0000000);
CryptCreateHash(hProv, 0x00008004, 0, 0, &hHash);
CryptHashData(hHash, Line3, strlen(Line3), 0);
CryptHashData(hHash, Line4, strlen(Line4), 0);
CryptHashData(hHash, Line5, strlen(Line5), 0);
CryptGetHashParam(hHash, 2, sha, &tmp, 0);
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);

memset(good_signature, 0xFF, 256);

memcpy(good_signature+220, appendage, sizeof(appendage));

memcpy(good_signature+236, sha, 20);

good_signature[0] = 0;

good_signature[1] = 1;

mpz_init_set_str(n, “9AFF449090074D691910719D0B384FDA86FAB987938E74CB6E6A91BE6086A8E11BDBD2EF7C1F3761EEBC3AB171F2FB9A79BD8A3CFBAD54A707F39FB8E804A0F4874447BE66550E9D444C496D251FF2402DC8DBAD7352124633F5CAF43A3971362B4466F28AAB1C2A1E81F36B8EE5E6284DD9645E500083B0B9102D559A57A52F0E831F7B39B630DC9B479E3914F34F33363A2075F372E650B94D230528A998D1613C097D78C1C66AE647E0DCF9590E3CA012C3A26614F851AE520163699044F6E8F71B8EDA7091DFDB4745FE27A806EF56E6B7B7175B7859B1725ACF6A03CC941DFED8773AA02DF350C3C0479744411B7F1CD625F5BF4F76E38DD42AC4901A89”, 16);

mpz_init_set_str(d, “36C70BF3DDBD70026346284E9E40E0B1637DD2FF8506F959772CBCEE7F2613A8697D8B822C6849753541DFAECA891A50C0F515E42F1BC8DFF2F48452BA27D29602E572DC9676512F1631AEF655C8F37C03C9E9E5E532CABE4ABD0E0495FA1556AC484D2F5F6E8AF08F934C80CC8D0369215FA2E5F73C0648509867BE61B766C716D84934F76699FAD81EC04E78E88CCC592D59B183361F35B2F3A0F2FEDC17F94F73831111984E5AB2AFCCC019090E4A48AB6CFE249066EFA6D02A4A9EA8369E60EF45A2CC921AE66C52CA1D273EB0355BAC9FD7598258FF94ED311100E732D22224B3744C3ABBB6BA4995781B8427D2BBF605488AC20E19483C10894283506D”, 16);

mpz_init(c);

mpz_powm(c, c, d, n);

printf("%s\n", Linha1);

gmp_printf("%Zd\n", c);

printf("%s\n", Linha3);

printf("%s\n", Linha4);

printf("%s\n", Linha5);

mpz_clear(n);

mpz_clear(d);

mpz_clear(c);

}

Disclaimer: este código foi feito de cabeça e nem sequer o tentei compilar. Se não funcionar, DESCUBRAM porquê!

Note-se que o autor implementou duas verificações para prevenir a alteração do executável (e assim também, da chave).

Primeira:

UPX0:004081EE loc_4081EE: ; CODE XREF: sub_4081BA+45j
UPX0:004081EE movzx edi, ds:public_key_n[ecx]
UPX0:004081F5 add edi, edx
UPX0:004081F7 shl edi, 1
UPX0:004081F9 inc ecx
UPX0:004081FA cmp ecx, 40h
UPX0:004081FD mov edx, edi
UPX0:004081FF jb short loc_4081EE
UPX0:00408201 cmp edx, 0B3A690A6h
UPX0:00408207 pop edi
UPX0:00408208 jz short loc_40822B

Segunda:

UPX0:00425A7A loc_425A7A: ; CODE XREF: sub_425A14+74j
UPX0:00425A7A movzx edx, byte ptr [eax]
UPX0:00425A7D imul ecx, 1Fh
UPX0:00425A80 add ecx, edx
UPX0:00425A82 dec eax
UPX0:00425A83 cmp eax, offset sub_401000
UPX0:00425A88 jnz short loc_425A7A
UPX0:00425A8A cmp ecx, 1D9AB667h
UPX0:00425A90 jz short locret_425A98

Certifiquem-se que corrigem isto quando alterarem o executável.

Já agora, a IDB comentada.

Um bem haja para todos.

Ois. Adoro quando estou no Vista a trabalhar e a ouvir música e a navegar nas interwebs feliz, contente e descansado da vida quando de repente oiço: BEEEEP. Eis que penso “olá…vai haver marosca!”. O portátil reinicia….transpiro e fico verde. Mordo o lábio, lanço um ou outro grunhido e não tenho outro remédio senão reduzir-me à minha significância e aceitar a minha condição de pseudo-(windows fag) e….enfim, esperar que esta merda lá reinicie e tenha de abrir tudo novamente, restaurar a sessão do Firefox, apoiar a cabeça na palma da mão, suspirar, olhar para o lado, pensar para o íntimo do meu arrependimento “Maldita hora em que não pus linux nesta merda…”. Adeus.

P.S. - O que vale é o SuperFetch do Vista, que torna o load das most-used-apps ultra rápido…

E se o estado enfiasse o IRS no cu do jynx, pah ?

Ois, amiguinhos. Tenho andado um pouco afastado desta rambóia por motivos sérios e profissionais, embora volta e meia faça um ou outro comment a um ou outro post. Sim, confirmo, a vida de pseudo-trabalhador / pseudo-estudante é, de facto, desgastante aborrecida, por vezes. Hoje deparei-me com um drama aqui no trabalhinho que até foi fácil resolver após uns minutinhos a pensar e a pesquisar no gugal. Na minha aplicação existe o try / catch habitual para handlar as exceptions. Existe também um finally para fazer qualquer coisa nomatter what. No entanto, e como estou a correr a aplicação na consola, caso faça um CTRL+C , o troçozinho de código que consta no finally não é executado, o que é uma maçada…Então pensei: “Ora o que eu queria mesmo…era uma forma de handlar este signal….em Java!!” . Em C isto seria coisa simples, mas nunca me tinha deparado com este drama em Java, apesar de a solução ser igualmente simples. Aqui vai a solução e espero que possa ajudar alguém (e também poupar alguma pesquisa):

public class AMinhaClass
{
      public static void main( String[] args )
      {
         Runtime.getRuntime().addShutdownHook( new Thread() {
                 public void run()
                 {
                     System.out.println( "Handler code goes here..." );
                 }
             }
         );
      }
 }

Ahmm…ok, aquilo deveria estar dentro de um ciclo ou qualquer coisa que justifique um handler, mas não me apetece estar a reeditar o post porque não me estou a dar bem com as formatações e o camandro e tenho de voltar para o trabalho. Adeus.

I stumbled upon this yesterday. It seems to be some kind of show/podcast where Steve Gibson talks out of his ass. One of them particularly pissed me off.

And it comes from really that bungling attempt I made a couple weeks ago when, well, it was the issue of double encryption, the question we answered several Q&As ago where some guy said hey, you know, what if I encrypt something with one key, then I encrypt it again with another key? Isn’t that, like, much better than encrypting it just once? And I absolutely know that it is, and I know why it is.

Oh really?

I mean, I’ve implemented Rijndael, which is the AES standard, in Assembly language. I know exactly how it works.

Oh, man. In assembly. You really are an expert.

Now, Leo, I found some math genius somewhere on the Internet who she spent her whole life coming up with cool ways to do factorials. I have the size of that number, thanks to her.

This must be really hard, seems to take some kind of math genius. Let’s fire up MAGMA:

> R := RealField();
> N := 2^128;
> size := (N*Log(N) - N + Log(N*(1+4*N*(1+2*N)))/6 + Log(Pi(R))/2)/Log(10);
> size;
1.29639227739158973521399965250E40

Damn, that was hard. Thanks to that math genius called Ramanujan now i know the size of the thing…

Precisely, the size of the total number of possible mappings that 128-bit cipher can have, I mean, it’s just so ridiculously small.

Then he goes around talking about how 2^128 and 2^256 are not huge numbers. I’d love to know in what parallel universe that is.

So the idea is, essentially, you have a bunch of carefully chosen random data, and the key is used, mixed with and to select from a pool of random data. And this is, it’s random, but it’s always the same.

OK, that made sense.

So, for example, public keys, where we were talking about 128 bits being all the strength you would ever need, public keys need to be 1024 bits in order to have the equivalent strength.

So NSA’s suite B doesn’t exist, right? Where ECC-256, ECC-384 and ECC-521 match 128, 192 and 256-bit symmetric key sizes, respectively. The sizes are double the size because with public key number theoretic algorithms one can always use Pollard’s Rho which runs in average for 2^(n/2) iterations.

So again, the guys who did Rijndael said okay, we’re aware of side-channel attacks. We’re going to make what Rijndael does not key dependent.

Right.

Now, for the main point. Is double encryption a good idea? Steve here thinks it is:

So the fact is, the original question that was asked back on Episode 120 was, if I encrypt it twice, with different keys, isn’t that better than once? And it’s absolutely the case that it is because, remember, somebody would be looking at the output from the second encryption, and the only attack is a brute force attack trying keys, you know, like a dictionary attack. And they would be looking for it to get plaintext out of the decryption. But the plaintext out of the second encryption is the encryption from the first, which means there is never going to be any plaintext. And as we’ve seen, the key spaces are such that there’s just no chance another one of those keys, I mean, virtually no chance another one of those keys is going to magically perform the double encryption for you. That’s just not - you have no access to the total number of mappings that are possible through a 128-bit block cipher.

Once again, our friendly security expert is short of the facts. One can use a meet-in-the-middle attack to break double encryption in only 2^(n+1) iterations. Yes, double the keysize and only double, not squared security? Yeah that’s a great idea.
He also mentions 3DES as an example of multiple encryption. But he fails to mention 3DES people actually knew what they were doing. The actual 3DES key is 112, not 168 bit. Triple encryption is only used to thwart meet-in-the-middle attacks, which apparently our expert knows nothing about. So if your tinfoil hat makes you think your key is too short, don’t be an idiot and just use a cipher that allows larger keys.

Steve Gibson is a moron. QED.

Já viram o novo “produto exclusivo” da fnac? O KIT SOFTWARE LEGAL? Agora pela módica (leia-se mórbida) quantia de 269.99 eur toda a gente pode usufruir deste fantástico produto.

[imagem perdida]

Estava eu a coç^?^?^?trabalhar arduamente quando aparece um tipo com um iPhone aqui no serviço para lhe configurarmos o acesso à rede wireless da universidade. Assim que a notícia se espalhou, levantou-se praticamente todo o serviço só para ver o gadget. A excitação só acalmou quando se percebeu que aquela merda nem sequer suporta 802.1x, e como tal não se pode ligar à nossa rede. Amei, do fundo do coração.

Amiguinhos, estou eu aqui a escrever sobre dramas com edição de video no open sores. Andei aqui à procura e a testar estas craps open sores e encontrei um razoável: Kino.

Já estive a fazer um video muitooooo simples (dedicado ao falfinho).

Sacar

Olá meus queridinhos.

Há pouco fiz um teste de programação (VB). E o VB em si estava com um bugzinho mesmo cheio de cancro… Não é que fiz um ciclo for em que ele lia os dados e guardava em cada posição de uma array, imprimindo o valor inserido numa picturebox. Até ali tudo funcionava.

Comecei a desenvolver um outro código mais complexo para fazer umas verificações, mas como não deu certo e não era obrigatório isto desisti, voltando a colocar o código antigo (comentado). Corri o programinha e agora ele já não imprimia os dados na picturebox. Fiquei 15min cheio de doenças na cabeça com aquilo, mas o código estava correcto.

Grande sidazinha.

Ois.  Os dramas não me largam…ou se calhar não são dramas, eu é que ando particularmente melodramático com esta história toda porque, tal como o disse,  estou fartinho do Java. Deveras…!! Chego a pensar em estupidezes só para desanuviar… Hoje uma simples frase dita por alguém no departamento despertou em mim uma súbita vontade de aprofundar o meu interesse pela filosofia…porque estava farto do Java. “Faz o que quiseres!!” . Hmmmm…é interessante porque, se fizermos o que nos apetece estamos a fazer a vontade à outra pessoa…No entanto, se não fizermos o que queremos, estamos a tomar a liberdade de a contrariar, fazendo o que nos dá na gana…portanto mais uma vez estamos a ceder à vontade dessa pessoa. Confesso que a reflexão sobre este tema me deu uma enorme cólica. Mas não era sobre isto que eu queria blogar. Hoje resolvi mais um Java drama…inútil. O objectivo era fazer com que a aplicação (que está a correr no JBoss, que por sua vez usa o Tomcat como webserver) suportasse NTLM Authentication. Basicamente, caso um user (logado num determinado NT Domain) fizesse um http request à aplicação, não seriam pedidas quaisquer credenciais. Ora, isto é tudo muito bonito quando se usa o IIS + m$ technologies (ASP, ou whatever…). Em Java começou por se revelar uma PITA até ter descoberto o jCIFS. O jCIFS não é mais do que uma biblioteca que suporta o protocolo SMB/CIFS e é 100% Java. Lindo, ahm? Poderão estar a perguntar-se “Mas porque é que esta besta não se limita a ver o resultado retornado ao invocarmos o método getRemoteUser() ao objecto request (HttpServletRequest) ? “. Pois…porque sem esta treta, será sempre null. Então, a solução passa por ir ao ficheiro web.xml da nossa aplicação, adicionar lá um pequeno filtro, adicionar o jcifs-versiongoeshere.jar à classpath do nosso projecto e voilá! O filtro é algo deste género:

<filter>
    <filter-name>NtlmHttpFilter</filter-name>
    <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

    <init-param>
        <param-name>jcifs.netbios.wins</param-name>
        <param-value>10.169.10.77,10.169.10.66</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.domain</param-name>
        <param-value>NYC-USERS</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.username</param-name>
        <param-value>somenycuser</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.password</param-name>
        <param-value>AReallyLoooongRandomPassword</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>NtlmHttpFilter</filter-name>
    <url-pattern>/*</url-pattern>

</filter-mapping>

Podem omitir os parametros “username” e"password”. Ora, caso o request venha de uma máquina que esteja logada no domínio que consta no filtro, o HttpServletRequest já contém informação necessária para ser processada, mais precisamente informação correspondente à nossa continha do Windows. Lindo!! Adeus.