Jump to content
Tuts 4 You

ghandi's Blog

Sign in to follow this  
  • entry
    1
  • comments
    10
  • views
    4,607

Bruteforcing Armadillo Encryption Template

ghandi

4,566 views

I'm not really used to the whole 'blog' thing so bear with me while i simply spill some thoughts, :)

Anybody who has seen the Keymaker.c source code for Armadillo keygenerating can see how the keys are built and put together, i'm not going to be explaining how i came to any conclusions aside from referring back to that document.

The single most important thing to make genuine Level 10 Short V3 keys is the Encryption Template, from it the symmetric key is made as well as the private key being generated from it for ECDSA signing. People have already successfully attacked the signature verification as well as symmetric key verification, so this post isn't revealing anything new.

The string is uppercased in a function called 'CookText' before it is hashed with the MD5 algorithm.

Looking at the source code, we can see that the BasePointInit value for the elliptic curve used is also taken from the Encryption Template, the first unsigned long of the MD5 hash to be precise.

So, what do we have at the moment?


// Hypothetical variables
unsigned long MD5Hash[4];
char temp[256];
unsigned long BasePointInit;
unsigned long Symmetric;

// Get the hash of the uppercased string
CookText(temp, EncryptionTemplate);
md5(MD5Hash, temp, strlen(temp));

// Set BasePointInit and Symmetric values
BasePointInit = MD5Hash[0];
Symmetric = MD5Hash[0] ^ MD5Hash[1];

// Remembering the ECDSAPrivateKey is derived from EncryptionTemplate.

Okay, not a lot to look at to begin with but with the BasePointInit, we have the first dword of the MD5 hash and we can perform a bruteforce lookup for any hashes that begin with that value.

On its own, this would be totally useless because it returns a lot of false positives so incorporating a check to see whether or not the generated symmetric key will yield a matching checksum when passed through the symmetric checksum function was necessary.

Now, using CUDA and the symmetric check plus a large charset, it finds a 6 character encryption template in 80 seconds.

Nothing to jump up and down about but the main thing is it works at all! There would most likely be a way to speed it up more but i'm not sure where to start, it is only a PoC and i'm sharing the theory only so please don't ask me for a copy.

* Take Checksum, Salt (if used) and BasePointInit.

* CUDA bruteforce matching MD5 hashes.

* On matching hash, pass to checksum generation for testing (CPU).

* On success, exit loop otherwise continue iterating strings until max length is reached.

210kmsn.png

I also had the brainwave idea of bruteforcing the 128 bit value which is the private key for ECDSA signing but couldn't find a way that was fast enough using my limited math experience, hehe.

My conclusion from this little experiment is that although it is possible to recover the encryption template, the character set and probable length of the strings used by Armadillo's users will prevent it from becoming an attack vector for keygenning, especially when the ECDSA_Verify and symmetrickey can both be defeated with faster means.

HR,

Ghandi

  • Like 13


10 Comments


Recommended Comments

mrexodia

Posted

I got to say this is an interesting method... I once thought of it, but the length of the real encryption template is actually a very bad limitation. Another problem was that my brute force algorithm is very bad (no CUDA, nor multithreaded stuff) I believe it took about 5 minutes finding the string 'TEST'

Very interesting stuff again,

Mr. eXoDia

Share this comment


Link to comment
ghandi

Posted

As i've stated before, this was purely for learning purposes.

It has no real life application unless the user of Armadillo has used a short encryption template, something which Silicon Realms were advising against and now they've even gone to the lengths of generating psuedo-random template names on the fly with the format:

Random Encryption Template xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Even with the 'Random Encryption Template' prefix being known, to guess the other 50 chars denoted by the 'x' in the above example would take eons.

HR,

Ghandi

Share this comment


Link to comment
Apuromafo

Posted

really amazing... if was a POC, really amazing(false hit 6872 omg!)

impressive the cuda.. exist some related to example in pentium 4 ->SSE?

Share this comment


Link to comment

Not for this same purpose but if one were to obtain some code for SSE2 based MD5, it wouldn't be hard to add a string generator and compare at the end, you could even optimize the last rounds because only the first 32 bits are used for comparison.

HR,

Ghandi

Share this comment


Link to comment
Apuromafo

Posted

and if have the correct sym, and the parameth of base init?

how much time can be done?

Share this comment


Link to comment
FrenFolio

Posted

The string is uppercased in a function called 'CookText' before it is hashed with the MD5 algorithm.

In a function 'CookText' not only the string (called Encryption Template) is uppercased, but also cut off all spaces. So you could cut off the symbol ' ' (space) from character set too. As you understand It's decreases a some time needed for bruteforcing.

Share this comment


Link to comment

Thank you for pointing that out, i should have mentioned that CookText strips space, tab, carriage return and new line from the string and excluded it from the charset, i'm not really sure what i was thinking there....

Unfortunately though, this will still not make any difference to recovering an encryption template if it is of sufficient length because the bruteforcing process still has to process an enormous number of strings, it is only the secondary testing of collisions that is different to any other md5 bruteforce.

With a valid symmetric and the basepointinit, you can recover the second dword of the md5, meaning you have 50% of the original hash but once again, bruteforcing still has to process the same amount of keys to find possiblities, it is only secondary testing.

As much as i would like to see it broken properly, i don't think the ECDSA system is going to fall via md5 bruteforce given current technology and keyspace to search.

To explain why even 50% of the original hash wont help, i must point out that the encryption template has another string appended to it before being hashed again to make the private key seed. This 'seed' is divided against the curve base order to ensure it is less and the quotient makes the private key, i don't see how having more of the original string hash can help with this second stage.

Share this comment


Link to comment
delldell

Posted

thank you ghandi I like read your post

always with so much details and good information

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×