Hey everybody good day , since I could not wait for a new version to come! . I dug myself in the android world and found that the algorithm just adds the two hashes in the "/data/system/password.key" file, like so the (SHA1 + MD5); so as in the OP bkerler is using the SHA1 part only(the 40 digit long part of the string), we could use the same command to break the password/PIN using the MD5 value to get the same value.

Yes, salted SHA1/MD5 is generic, iterated sha1 is apparently Samsung-specific. Yes, it makes no sense to attack sha1 if you can attack md5. BTW you would be surprised how weak the pattern lock is, it doesn't even make sense to attack it on GPUs. Still, long passwords or PINs can be relatively secure (and even more secure on Samsung). Pattern lock is VERY easy to crack.

P.S as of Android Jellybean 4.2.2 (Nexus 7), the sha1/md5 scheme is still in use.

I know that there are so many stupid and unbelievable things out there, especially if you do some security research, (embedded) device exploitation, password research or even reverse engineering. You come accross ,very* stupid things that you simply can't believe. And you learn you shouldn't cry because things are AS IS and vendors etc only change things if you FORCE them to change it somehow!?
This is definitely one of those things that is also very absurd to me.
Why in the world Google uses this/those schemes? Are they collaborating w/ governments?
This cannot be for real! There is no reason to append a (faster crackable) MD5 hash to a SHA1 hash...

So the 1024 iterations ARE completely a lose of energy! Believe me Google. Skip that SHA1 if you really need to append the MD5 (and of course to calculate this digest too), please skip it. This is maybe why my Android phone is always connected to the charger. hehe

There must be some clever decision/discussion behind this hashing scheme, but I really don't get it!!! Sorry.
Maybe "older" devices are too lame to calculate SHA1 fast? Is this a serious reason to calculate both SHA1 and MD5. NO

I didn't do any major research about this topic. Maybe someone can explain... BUT this is really a big *FAIL*
I like my Android phone, but this is really *for shame* (maybe also the "Encrypt phone" feature is completely broken, someone should dig into that!).

The "encrypt phone" feature is based on dmcrypt/LUKS and it is (usually) much more secure as compared to Samsung's algo. I say "usually" because key derivation iterations depend on the hardware the encrypted block device was created on and phone CPUs are slower than most desktop CPUs thus lower iteration count.

That said, I think many people underestimate password security on mobile devices and passwords like 4-digit pins may be common and that is feasible even for bruteforce attacks. Anyway I haven't tried to crack encrypted android volumes yet, so there might be specifics (like you definitely gotta be root in order to dd from the device node). BTW my program has a plugin to crack LUKS volumes on GPU and it's slow (speeds of like 1k-2k c/s are common for volumes created on a desktop system). It also supports only AES-128 and AES-256 block ciphers in CBC-ESSIV mode, while Android may use other scheme. Some time ago someone asked me about cracking encrypted Android volumes and from what I read about Android's FDE implementation, it should already be supported. I asked for a dd dump to test if it works, but still noone sent me one.